Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Who Killed the Desktop Application? (codinghorror.com)
13 points by danw on June 11, 2007 | hide | past | favorite | 8 comments


It's 2007 and smart people stopped separating "desktop" and "online" applications a long time ago, because it is pointless: the best approach to solving any problem is always picking the proper balance of server/desktop horsepower/capabilities.

Desktops are very powerful. People forget (or never realize) how powerful their computers are. For a long time only games have been taking advantage of all those millions of transistors. I really hope that next generation of browsers will start moving towards that direction.

For instance: if you have a flash movie occupying 100% of the page, it becomes simply unusable if a user maximizes the window, even on 1280x1024. Isn't that ridiculous? At our age and time, a simple 2D vector graphics plays at pathetic 5-7 frames per second... (even if he's got a $700 video card) And something tells me it's not entirely Macromedia/Adobe's fault.

It's changing, though. And Google/Microsoft are moving towards that direction. Good (early) example can be iTunes or apps built on GoogleGear platform.


Good point.

And I think the number one killer of desktop applications is Microsoft, however controversial it may seem at first.

It was Microsoft who convinced developers that a commercial application along with its installation procedure must look and feel heavy, so that users feel comfortable with the money they paid for it. The heavier the better. It is so rare in the commercial desktop world that developers strive for simplicity.

Without Google though, the Web world could have adopted the same complication syndrome. Look at the MSDN web site, for example.


I don't think Microsoft had any part in convincing anyone that apps need heavy installation procedures. It evolved as a generic way to do some basic things: moving the executable to a place the user wants, and setting up some registry values. Isn't that a reasonable solution for desktop applications?

There is nothing wrong with the MSDN site. When you're storing millions of pages of documentation, things may get a little bloated. If you need to look up anything about the Windows APIs, or any information about .NET languages, you'll quickly see that MSDN does the job well.


One more point: you can set your registry values when your application runs for the first time. It's a common practice especially on UNIX and MacOS to generate configuration silently, when needed instead of focusing user's attention on that during installation.

Other than that, installation is essentially copying. The proper place, file-type bindings, version checks etc can be done by the system automatically, again, without annoying the user (and the developer, too). And that's exactly what MacOS was doing since version 5 in 1980's.

(Besides, Windows Registry is one of the main sources of complication).


Have you ever worked on Mac? Basically there is no such a thing like "installation" on MacOS. PC users usually don't believe it until they see it themselves.

Simplicity requires some effort and thinking, and on the contrary, it is relatively easier to design bloated software.

And I'm sure, when some Microsoft installer pretends it's "analyzing system configuration" and freezes for a dozen of seconds with no disk or CPU activity - I'm sure it's just a trivial call to Sleep().


And, just to disagree with author, I'd recommend comparing Google's Picasa to itself.

That would be a fair comparison, because it is virtually the same application, with same set of features, done with online/offline UI's... slowly merging together.

BTW: as far as PC "desktop" software is concerned, Picasa is probably my favorite application. Even though I don't use it that much, but as an engineer concerned with usability, I always try to point our "desktop people"'s attention at it.


Picasa is great, the only reason I still have a windows PC.


What makes it so much better than, say, picturesync?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: