I am going fat again

[Andy Sjostrom]

Evolution of user interface is in an interesting phase. Fifteen years ago we went from character based DOS applications to Windows applications with a rich user interface. Then came the Web and initially we took quite a few steps back in terms of user interface richness. The first generation Web pages were, except for those ugly fonts, colors and frame borders, more or less on a DOS-level in terms of user interface. Web design has come a long way since then. The actual markup language (HTML) and the authoring tools have been significantly improved. During the improvments, Web applications have taken over the user interface battle against the so called "fat" Windows applications.<br /><br />But as soon as we finally believe that the thin Web applications have totally overthrown the fat clients, we see a trend in the opposite direction. The trend is more visible from a mobile device perspective than from any other perspective. Given the small screen sizes, fat clients offer distinct advantages over thin Web applications. If you really wish to optimize the use of valuable screen estate, then it is a serious pain to get everything from overall application navigation to the smallest pixels right in Web applications. This is not so when building fat Windows applications.<br /><br />The developer article <a href="http://www.devx.com/codemag/articles/2002/JulyAug/DiminishingHTML/codemag-1.asp">"The Diminishing Importance of HTML"</a> is an interesting read on the subject. The author, Rick Strahl, writes:<br />"What's Wrong with HTML as a Front End?<br />Although Visual Studio .NET makes it somewhat easier to build HTML-based Web applications, it is still far from simple. There are too many limitations in HTML's markup definition and no matter how fancy the wrapping is around the basic controls, HTML still produces an inferior interface to those found in desktop applications."<br /><br />Let's discuss! I am going fat again. The previously seemingly obvious choice, Web application design, is no longer so obvious. At least not from a mobile device perspective. What do you think?<br /><br /><img src="http://www.pocketpcthoughts.com/images/fat_01.gif" />

[pt]

html is great, and i think i'll always use for parts of a technology solution, but it won't be the only thing...i'm really interested in rich applications, that's what i build. with flash as the front end for example. as long as my presentation layer can support xml, video, sound, animation, etc...that's where things are going, that's what the market is asking for now.

fat is good.

cheers,
pt

[schwuk]

i've been doing some work with asp.net recently, and it is a good step forward in terms of building web applications. it is now possible to produce event-driven web apps without writing pages of javascript, but html is definitely limited for user interfaces. i'm still a fan of producing simpler layouts instead of fudging a ui using sliced'n'diced images, and i think flash will be the next step for me in terms of ui development now that i have got my head round truly separating the content from the layout. css allows you to do this separation and gives you far more control, but i get frustrated by the major differences in rendering between browsers, even the modern ones like ie and mozilla. to acheive full cross-browser compatability without resorting to fudges and hacks requires giving up too much functionality.

off-topic question for pt: you're obviously a long-term flash fan, but what do you think of svg?

[Ravenswing]

I've been doing some programming with C#, the Compact Framework, and Smart Device Extensions. I'm not a web programmer, I write applications, so a system where I can code functional chunks shareable easily across platforms and just have to specifically code the UI is excellent.

I've always thought complex, over-large web pages were a pain, even when I appreciate them (on a large screen over a broadband modem). You appreciate them a lot less when you have to download them over a slow modem or, worse, GSM, and if you have poor vision (or a small screen) they get worse.

OTOH, there will always be a place for web page applications because you can't go around downloading every application client to a PDA. I just wish that more applications had a UI a bit more like the Google search page; simple, clean, takes no time to download.

[juni]

Off topic? =

Designing user interfaces (=skins) for pdas is challenging. I always try to make my skins as easy to use as possible while still looking good. It is a challenge since I can never be sure if people want something that is flashy and uses up lots of screen real estate or something that has a tiny footprint and leaves tons of room for the actual data. Any input on this?

Examples:

http://www.wincustomize.com/skins.asp?searchtext=winsnoop2002&sort=updatedate&order=Descending&submit1=GO&library=14

This one has a minimal footprint.

http://www.wincustomize.com/skins.asp?searchtext=controlpad&sort=updatedate&order=Descending&submit1=GO&library=14

And this ones leaves less room for user data but is a bit flashier.

[Guy Van Houtte]

As a developer since 1982 (as amateur) and since 1991 (for a living), I noticed the shift from central based character interfaces, to distributed all-the-way full-features fat clients, and back to horrible character-look-alike interfaces.

I have been saying for the past 4 years that I do not believe in this latest trend: I am a believer in the fat interfaces.

Web-based (read: html interfaces within browser environments) applications tend to be slow, without much immediate feed-back to the user, with horrible network trafic (the whole interface is sent over the network, not only the data), and tend to be specifically tailored to suit the slowest user.

Applications using a fat client concept on the other hand are not only much more user-friendly, they are also responsive, and allow in many cases to the user to have more views open at the same time of its data (e.g. using treeview and detail screens at the same time).

The pocketpc is ideally suited for this fat client concept since the screen resources are extremely limited, and browsing around in the internet browser on the pocket pc is not really user friendly to say the least.

I leave the web-based believer to their believe. Live long and happy.
But I made the choise for myself. No web interfaces if I can avoid it. After all, user satisfaction is much more important than blindly following the trend-of-the-week just because your manager has read some article hypeing web-based development.

No offence to anyone with another opinion,

Guy.

[Andy Sjostrom]

Excellent thoughts, everyone! I thought I was about to get flamed...

It is important to add, though, that fat clients do not mean non-standard and proprietary. Fat clients can be as good Internet citizens as any Web browser. As long as the fat client adheres to the standards such as HTTP, HTML, XML, TCP-IP, XML Web Services etc, we won't nescessarily run into "walled gardens" just because we go fat!

[mobileMike]

I am also a fan of fatter clients. That said, I enjoy making these clients in Java and I have been really disappointed with the support of Java on the PocketPC. Sun had a BETA version which was nice (Integrated well with the PPC UI), but it is no longer supported. Insignia has a supported version which is shipped with the iPaq, but it looks horrible.

/ mike

[Ravenswing]

Excellent thoughts, everyone! I thought I was about to get flamed...

Never :o

As long as the fat client adheres to the standards such as HTTP, HTML, XML, TCP-IP, XML Web Services etc, we won't nescessarily run into "walled gardens" just because we go fat!

Point taken, but all that stuff doesn't guarantee compatibility. XML seems to be seen as the great data conformance standard to make everything compatible to everything else, but that is just plain rubbish. You can write unreadable XML just like you can write unreadable C, and just because something is written in XML, doesn't mean anything can read it. Even with a DTD, if you don't understand what the schema means, you aren't going to be able to use the data.

[Andy Sjostrom]

If you are into that Sun thing and still have a crush for Pocket PCs, what Java tools and VMs out there do you guys use?

[mookie123]

I am clueless but that doesn't prevent me to give opinion does it? heh heh

...there come a time when I seriously wonder all these pages of cute scripts, incredible buttons, bleeping, flashing 'things' on my screen really worth all the developer efforts, In the end it just to present a couple of paragrphs that says " today in the useless news department..." or "I am screaming to get your attention now tell me your credit card.."

Einstein's paper on theory of relativity weights less in total bytes than these flashy pages. Go to Xarchieve, a lot of those papers worth only ~400kbs, google main page, the most usefull page on the net, weighs even less.

So really...

This is definitely a trend toward bloatware on the net without increasing the quality of information.

[heliod]

I believe that very soon the Web Services issue will allow us to prepare fat clients that are not so fat, anyway... or putting in another way, Web applications with Windows clients.

That would be ideal for applications that require persistent mobile connection to the server for real time update of the database and real time update of the client.

Last CEBIT I've seen a company that prepared a mobile application for couriers; yes, those guys that go around in cars taking packages from one company and delivering on another. The application was beautiful, all Web based and relying on PIE. Every time he refreshed the screen, the courier got his new task and updated the status of the current task.

These guys spent a lot of work with HTML design. If they had Web Services knowledge at that time, they could have designed a beautiful CE interface window with less effort, and just called the server in a form of SOAP calls for each request of update or current task status report.

So, I believe we are beginning to walk in the direction of a combination of fat clients + Web Services, which will make application architecture a very interesting thing, and give a whole new importance to good and fast application development tools.

[Chris Forsberg]

As many said above, we have seen the move from text-based, to rich and back to "graphical text-based". I heard someone use the term "putting lipstick on the corps" when referring to web applications, and in many aspects it is true. The most important question is who benefits from the different models. The centralized (mainframe/web) model is benefitial for the folks running the app and the decentralized (fat client) is benefitial for the users. Who should get pain, and at what cost?

That said, I agree with them who said that there is probably a use for both models. What I find interesting is that the two models are merging in many ways. A simple early example are applets or ActiveX controls. Are those web pages really thin? And a more recent example is a rich interface getting all its data from the Internet using Web Services. Is that really a fat client in the "traditional" sense? The terms "thin" and "fat" are fading, and we will talk more about rich/web interfaces and online/offline data. I beleive that we will see more combinations of the two models, and the app requirements will drive the creation of an optimal combination.

This especially true for connected mobile applications. Considering the lower bandwidth in most scenarios, the merge of the two models is almost always a must. I'm a believer in the rich user interface (and Windows on both desktop and Pocket PC is a god alternative) and whether the app are online or offline depends on the scenario.

[mookie123]

fat client,

wasn't browser plug-ins the ultimate fat client models? and it fails to a certain degree? Aren't they the fat, space taking, slow, ugly, bewildering, crash prone, spyware, not compatible after 2 nanosecond which ultimately give the urge for smarter script and browser library?

and now .net?

boy I can see it now PPC all clutter up with gazzilions "fat client" just like media player, chat client, or proxy browser.

And please, do we really want a fickle company like Microsoft creating another 'internet standard'? I'll run the other way around fast.

[Ravenswing]

mookie, you appear to be arguing that thin clients don't work, and that fat clients are no good, and that, anyway, Microsoft will dump the whole .NET initiative the first chance they get so why bother.

What do you suggest we do? Should we junk the whole concept, pack away our PPCs and buy Palms (since all we'll be using them for is PIM functions)?

I believe Microsoft are betting a substantial amount of farm on .NET. Next spring they'll be releasing a server OS which, aside from making Active Directory scale properly :roll: , has only one big selling feature: it makes .NET work. If people don't buy it, Big Bill's fortune goes downhill.

Microsoft were once the most anti-Internet company going. It took a lot of courage to turn around and say "we woz wrong", but they did it and now it's so terminally easy to get on the Internet with a Windows machine it practically wires up the modem for you.

The time when Internet Standards were the province of university researchers is long gone. Standards are developed by big businesses of one kind or another and legitimised by usage as well as ratification by the IETF. All of those businesses are in for one thing: making money. None are better than the others (not even Apple).

Besides, don't be mean to Microsoft or your computer will stop working :lol:

[Will T Smith]

This is fad issue. Fat, thin, etc... It's all an attempt to impose a global ideology. That ideology often breaks when imposed on a lot of applications.

I worked in CORBA based systems for two years. During that time I came to understand that the effort to offload the fat onto either client or server is FOOLISH.

So called "thin" clients experience HUGE latency problems causing the user great consternation.


The solution is to distribute the fat where it is needed. Any and all operations that CAN be done on the client side, SHOULD be done on client side. The server in this model largely becomes an I/O sieve for database operations and intercommunication. Plus any relational operations external to the client which naturally cannot be performed client side.

Their is no buzzword for this. So imagine that managers wont embrace it. However, I like to talk about "pervasive" objects that exist both on client AND server.

When we stop clinging to buzzwords we stop being managers and start being sensible.

[Guy Van Houtte]

exactly my point, Will T Smith,

all (well... nearly all) processing that can be done at client side should be done at the client side.

And, as always, Keep It Simple and Stupid...

Guy.

[pt]

off-topic question for pt: you're obviously a long-term flash fan, but what do you think of svg?

i only like flash because it's avail and have great desktop / pocket pc pentration.

svg (the idea of it) is great, when there's a player for the desktop and device on more than 90+% on at least one of those (or close) i'll use svg more.

right now i've made some svg apps, but they're nothing interesting.

cheers,
pt

[dml]

One of the big advantages of new developments in web services, the move towards XML and .NET etc, is the fact that content and presentation can be completely separated. And because data is separate, it means that you can have any number of different fat and thin clients to access that data.

Which you choose to use might depend on how often you access the backend data. For example, if it is only rarely, you might not want to download a separate application but just rely on a perhaps less responsive and less flexible web interface. Alternatively, if you are a heavy user you may well want the benefits a separate application can bring.

If the data is served up the same way, and the different interfaces manage the same data, it becomes a matter of choice. Ultimately, of course, if you don't like the interfaces on offer you can just write your own!

[PPCRules]

I'm glad someone has had the guts and platform to make this point. I've been watching as it seems everyone is getting sucked into the "browser apps are [always] better" bandwagon, and I have not seen good results. There have always been compromises, usually in the user interface, without compelling advantages to outweigh them.

At my work, we have only recently gone to an online timecard system. It is delivered to us via a browser resident user interface. It is very clunky and slow, and not beautiful. It does, however, get the job done, and we paid a lot for it, so it will probably be around for a while. As far as I know, the only things connected to the network, where people would be using this app, are full blown PCs (not thin clients) running Windows and MS apps.

The thing I can't figure out is why, in an environment where the network people have complete control of my computer and regularly remotely stuff various other applications onto my computer whether I need them or not ("standardization"), we wouldn't be way ahead having a small (it wouldn't take much) Windows client that could feel like the Windows apps that everyone is familiar with, be stuffed with local error checking, run fast and could be remotely updated as needed. I can only figure we got sucked in to what had been a thoughtless trend (fad), but I hope we are seeing a turn around to doing what makes sense for a particular application.

[Scott R]

This was a great read. I'm primarily a VB developer and web developer doing HTML and PHP (not on my day job). The constantly changing trend from fat to thin and back again is usually done for a reason, not just as a swinging trend for no reason. Some history:

* Mainframe applications. Everything runs on the server. The user just has a simple text-based entry screen. Business logic (e.g. - data validation) was reasonably efficient simply because it wasn't pounded on by as many people at the same time as a modern web storefront would be. This was obviously a thin client.

* Client/Server applications. At my old job we did a lot of VB applications which sent data back and forth to the mainframe since that's where they were still storing their data. They still had old mainframe apps which needed access to this data. And, since they already had bought the mainframes (and data storage) years ago, why ditch it all and buy new servers for this purpose. I think this was a pretty good idea. The VB app would have the interface and do most of the validation. Then it would send the data (and just the data - in a long, long string) up to the mainframe which would add/change/delete records in the database. The logic for doing the database updates was in a mainframe (COBOL) application. This architecture could also be adapted to allow for running the client application remotely across a phone line or home internet connection. This was a fat client. A downside here was that whenever the client application changed, you had to reinstall it on all of the users' machines. When you have hundreds or thousands of users, this was a pain. It's also proprietary. Only works for Windows machines.

* Early web applications. HTML handles the front-end and all validation occurs on the remote server. As has been stated in this thread, there are a few problems here. One, it was a lot more difficult to make an interface as good as what could be done via Visual Basic. Two, when you have tons of people hitting the server at once, everything gets dreadfully slow. Three, any and all data validation occurs on the server. So, you had to wait to send the data up to the server, just to get a response back that you forgot to enter something important. The good thing is that if you make a change to your application, voila. Everyone sees the new application. Works on anything that can run a standard web browser. I'll add that it really works best if you have at least an 800-pixel wide screen, so we're mainly talking about computers here.

* A modified (and better) approach to the early web app is what we see more of now. Via JavaScript (or VBscript - if it's an intranet app and you know everyone will be using IE), you provide more client-side editing. Things can still be a lot less "snappy" than with a VB application and there are some nice VB controls that can't be emulated easily (or at all) without a lot of complex JavaScript code. Is this a fat client or a thin client? Somewhere in between.

I'll insert here that the early Java applets were supposed to improve things here. One problem was that they took forever to download. If you're running a business app, you dealt with it. If you were visiting someone's site, you usually left the page out of impatience. A better solution (downloaded faster, faster development times, etc.) was supposed to be Curl. But they had a horrible (greedy) licensing plan and nobody was/is biting (I won't get into it now, this post is already getting too long). I believe Macromedia is building this sort of power into Flash.

Let's talk about PDAs. Palm came up with a good idea with their PQA concept. You develop the interface (and, I think - not sure, some validation) into a client-side application. When I want to go into the app and even jump to various screens (where the data isn't going to change), I don't have to wait for it to get anything from the internet. When I submit a form, it pretty much just sends the data that I've submitted. Then, the server sends me back the pure data that the PQA screen requires (no HTML or graphics - unless graphics are part of the changing data). The PQA app formats this data into their appropriate fields on the screen. For all intents and purposes this, again, is kind of like a fat client (relatively speaking). Of course, it's proprietary.

Then there are things like Blazer running on the Palm OS. You can access any web site. But first it passes through Handspring's proxy server which uses it's server's CPU horsepower to reformat it into a 160x160 screen. Works decently except for the fact that most web pages are designed for an 800 pixel wide screen and no amount of artificial intelligence is going to be able to make an 800-pixel-wide screen look good on something smaller (be it 640 pixels or 160, though the lower the res the worse it gets). At least the amount of bandwidth being transmitted is better as a result, so you don't wait forever (though over a cell phone connection, it's still horribly slow, IMHO).

On the PPC, you've got IE which doesn't employ a proxy server. It uses the PPC's horsepower to shrink the screen width to 240 (which, as mentioned previously, still looks awful). Since there's no proxy server, though, you have to wait for that full 800-pixel-wide web page (big, honkin' graphics and all), to be transmitted down. Over a cell phone connection, forget it. 2.5G phones improve the situation, but the bandwidth here is still too slow (and very $$$, I might add). Of course IE on the PPC (and Blazer, etc. on the Palm OS) don't fully support all the web "standards" either (JavaScript, CSS2, etc.), so many web pages just, plain, won't work completely (or at all). I think Microsoft would be smart to copy Palm's PQA concept and make their own flavor of it for the PPC. In a sense, you could probably roll your own via eVB (i.e. - make a client-side application and have it communicate over the internet to another server-side application you've written, sending just the variable data across the network). However, it would be nice for this to be handled automagically in a RAD tool. VB.NET and the Compact Framework may do just this.

That's all well and good for PPCs, but what if I want to access data on my Palm, cell phone, WebTV, etc.? Right now I'm working on a content management system which I use to help market my web design business. My customers can update their own menus, event calendar, articles, etc. I hope to get to finishing a geek-related web site sometime in the not-too-distant future which will use this system. The method I use to allow me to create one interace appropriate to a restaurant and another appropriate to my geek site, while still using the exact same database back-end is the same method which will (hopefully, I'm still working on this), allow me to create a mobile view of my web site. The common term used is "templates". phpBB (the forum software this site uses), uses them. Like phpBB, my CMS is written in PHP, but I don't see why ASP couldn't use this same methodology, and I'd imagine there are ASP sites that do. Perhaps, again, this is part of how the multi-interface concept of VS.NET works. I think that trying to make one web site that works on a phone and an XGA-res computer is a lost cause. The result is a web page that looks/works bad on both. I think that two versions works well (one text-only, another geared for 800-pixel-wide screens), but additional versions for the things in-between is best. You have to figure it out based on who your users/visitors will be. This works well at addressing the interface and bandwidth issues, but doesn't maximize the problem of client-side vs server-side data validation, though you could probably include JavaScript in your PC-version of the site to handle validation and leave this code out of the mobile version. The server would then just need to do additional validation if the input was coming in from the mobile version). In my case, I'm not concerned about waiting for the server to do the validation since I'll have very few users updating the content simultaneously.

Anyone read all of this rambling?

Scott

[Scott R]

The thing I can't figure out is why, in an environment where the network people have complete control of my computer and regularly remotely stuff various other applications onto my computer whether I need them or not ("standardization"), we wouldn't be way ahead having a small (it wouldn't take much) Windows client that could feel like the Windows apps that everyone is familiar with, be stuffed with local error checking, run fast and could be remotely updated as needed. I can only figure we got sucked in to what had been a thoughtless trend (fad), but I hope we are seeing a turn around to doing what makes sense for a particular application.
I agree. Which reminds me of a point I left out of my post. There are definite advantages to going the browser interface route, but in too many cases, companies are dumping VB and going whole-hog into creating web apps when they don't need those particular advantages and VB would have offered a superior solution.

Scott

[Andy Sjostrom]

I knew we had serious developers around! The replies are extremely interesting and valuable to read. I would like to add that I am a pragmatic. When browser based applications fit the bill the best, then browser we choose. However, I feel currently we have gone too far in over-Webbing solutions. Thanks for all the great comments!

[schwuk]

short anecdote about management who buy into marketing and buzzwords:

at the client site i am currently based at, one of the technical architects has recently deemed that all application that are currently produced in VB will be done purely in asp.net. we quickly dismissed his ideas when after asking whether we could use c# he replied "no, only asp.net". :roll:

[Andy Sjostrom]

Don't we simply love when management tries using buzzwords... :roll:

[Perry Reed]

I've enjoyed very much reading this thread. There have certainly been some excellent, thoughtful responses!

I'm currently sitting in a week-long class on building applications using XML, and the fat/thin client debate is very much in my thoughts.

I think there are good reasons to have fat clients, and I have the following ideas regarding them:

1. They must be self-updating. Re-installing client software on 1000 machines is NOT fun (or cheap).

2. A thin-client should also be available for occasional users of the system.

3. The server should be prepared to perform any processing that a particular client cannot. In other words, if you write some fancy code to run on IE 6.0 (like say, XML data island processing), the server should also be able to do that same processing in the event someone hits the page with Netscape.

One interesting notion from the XML class I'm in is the idea of the XML data islands. Essentially, you can embed the XML data (with all the semantics) into an HTML document and let the client do the processing on it. This would also make it easier to create one server interface that could serve up the XML to either a fat client (Windows app) or a less-fat client (IE 6.0 or PPC app), or a very thin client (Netscape) (with the ability to "take over" any processing unable to be completed on the client.

ASP.Net implements a bit of this sort of idea with their validation controls. You write the validation control in an HTML-like syntax, and .Net creates client-side script to perform the validations specified. But it also performs the validations on the server-side as well.

I don't think we're quite there yet, as far as making fat clients really worth while, however I think we're inching in the right direction.

[heliod]

Andy,

This has been the best thread that I have participated in thoughts. It is the pure example on how professional are the readers of this site.

It is interesting that the same cycle that we were describing regarding the UI can be seen in the architecture of the systems: we came out of the Mainframes and into the PC, connected them into networks and invented the fat client, the exact opposite of the mainframe, which had the thinest possible client; from there we went into client/server and began tried to get the clients more efficient.

When we were almost there, the Internet came and suddenly we went back to the days of the mainframe, with dumb thin clients that know nothing but to present data. And now we are beginning to optimize again.

I truly believe that we will get to the point where there will be equilibrium; clients will have part of the functionality, servers will do the heavy jobs. Web Services are good news in this direction, since they disconnect communication between modules from development platform. And the fact that both the big groups are adopting it, Microsoft with .NET from one side and the J2EE guys from the other, makes its future very promising.

I've been one of the first downloaders of your WebLiquid WS client for Pocket PCs. Found it a very interesting tool for learning the technology. I already knew the Web Services you call, since most are from XMethods and are the same ones I build my demos on. And I think you are in the right direction.

I am counting on that, and so is the company for which I work. We surely do believe that the use of the Web in some years from now will be very different than it is today, at least in the corporate market.

[Andy Sjostrom]

Thanks, Helio.
I agree! I will revisit this thread many more times just to read though all the ideas and comments again.

Perhaps we should do more DEVELOPER posts! Regarding XML Web Services, WebLiquid and more Pocket PC applications using Web Services... check out the first page tomorrow!