John Milan: ReadWriteWeb is currently running a poll asking which web apps should also work offline. Shouldn't we be asking the equally valid corollary as well: which desktop applications would you like to see work online?
Fundamentally, what is the difference between a web app that works offline and a desktop app that works online? Could it be that the web and desktop application communities have accidentally merged and are violently agreeing what the next version of productivity applications will look like? Or are there still intrinsic differences between web and desktop, regardless of how well they work offline or on?
The obvious differentiators are the Web's simple delivery and the desktop's rich UI experience. Online/Offline has been the elephant in the room and Zimbra's announcement means that the elephant has finally been recognized. In fact, while they framed it as a web app that works offline, a more accurate portrayal is a basic desktop app that works very well online - an acknowledgement that this architecture is better able to meet users needs. For example, by introducing a desktop component, Zimbra will now be able to attach more than 1 email at a time to an 'online' email message.
]]> The 'web only application' architecture has run its course. The simple web apps that early adopters have been willing to put up with, are transforming as mainstream requirements dictate a healthy desktop presence. Regardless of its origin, the future is desktop applications taking better advantage of online features and bringing richer offline (and online!) experiences.Richard: John's argument is basically what Microsoft and Adobe are aiming to achieve - a world where 'rich' desktop apps have online functionality. Let me take the position of two of their main competitors, Google and Yahoo. They would argue that the browser is still the 'lowest common denominator' for applications - i.e. the browser is where the largest user base is (by a very long shot), the browser is where the most popular Web activity search is carried out, and the browser is the most user-friendly and hassle-free environment for applications. There's no download required and users can access their data on any computer or device.
So who's right? Microsoft or Google? Adobe or Yahoo? Well, since nobody has 'won' the desktop app vs browser app argument definitively yet, we're now attempting to tackle it from a different angle: is it better to have an offline web app, or online desktop app? I hate to say it, but I think it all comes down to the user base again. The Web browser is the primary Web platform and so, more often than not, it is both more convenient and more usable to run a web app than it is to download a desktop app. It's horses for courses too (of course). For example with word processing, I generally want to use a desktop app. But for email, I want a browser-based app. In fact for most applications involving Internet connectivity, I prefer browser-based apps - so that I have most of my apps running in the browser and accessible whichever computer I happen to be on (and I run two in my home, for starters - one at my desk and one in the lounge).
Which brings me to my pièce de résistance: today my Gmail account was down and out for a good 6 hours. Yikes! I wasn't happy, as I had neglected to do backups and so the majority of my work was in that Gmail account. Now if only I'd had offline access to my Gmail.... then while I was waiting for my current email messages to arrive, I could have at least dug out yesterday's emails and did that work.
To sum up, I think offline web app functionality is more important than online desktop functionality. Too many of my day-to-day applications run in the browser now, so offline access to those web apps is critical to my business.
John: Two things stand out for me in Richard's response: 'lowest common denominator' and, of course, Richard's Gmail experience (I guess after 3 years it still is a Beta). Furthermore, if the browser is the 'OS' for web apps, then the largest user base comparison would be with Windows - and it's hard to imagine Windows lagging too far behind in this race. Or if Adobe is successful with Apollo, its user base could (theoretically) be equivalent to the browser's user base by virtue of being cross-platform.
To Richard's point of being mobile, he is absolutely correct - a web browser has a significant advantage over the the installation of desktop apps. This isn't totally hassle-free, however. Over the course of a day, you've probably downloaded more bytes over your pipes to service a web application than if you downloaded and installed a desktop. Furthermore, all these bytes do not mean a richer user experience, just one that is more transient. But as far as mobility is concerned, this is an absolute advantage, as long as your work is also isolated.
This would be the other elephant in the room. A mobile toolset may be nice for business, but at some point integration will be required for business systems. For example, my company is using a certain web application for sales force management. It is very comprehensive, but I currently have an open support issue regarding integration with my critical business infrastructure. If it was a desktop application with a nice scripting language, we could have done it in-house. Instead, it is a web app and we have been blocked for over two weeks now - and we're powerless to move things faster. Unless a business is willing to put everything online - and given the value of the data and the cost of an outage, that is an extremely unlikely proposition - then web applications will in fact be forced to stay in a supporting role instead of becoming dominant.
Which is a very odd argument to be making, and shows just how gray and smudged the web app vs. desktop app battle lines have become. Richard has more or less made the argument that web apps are superior for more autonomous workers, because of their superior mobility. I have just made the argument that desktop apps are better for businesses, because it's the only way groups can coordinate their activities with critical business infrastructure. The web for the individual and the desktop for groups?
Perhaps mobile devices can clean up this messy affair.
]]>And it is this: desktop apps are OS-dependant. Online applications are cross-platform. Furthermore, as Tim O'Reilly often points out, online applications use web as the platform. This approach gives them a number of features/capabilities which desktop apps cannot emulate. More on this can be found if you dig through my site and read a recent post on Web 2.0.
This is the answer to John's question: "Or are there still intrinsic differences between web and desktop, regardless of how well they work offline or on?". Yes, there are. Why is Flickr such a success? Because you can browse through other users photos, and you can remix that data and create an RSS feed that shows one Flickr image for every story on NYTimes. Could you do that with a desktop app? Nope. That's what Web 2.0 is about.
]]>"at some point integration will be required for business systems",
I really think we should factor in the kind of web app we're talking about in this debate, the two main categories being business apps or personal/productivity apps.
]]>thank you for infos
]]>With browser applications you have a security sandbox: the browser. And browser based web application can not access your hard drive data (easy).
And your Mom can start using these application without calling you for helping her install it.
The Google desktop app that most people know is their desktop search. However, their best example of an online connected desktop app is Google Adwords Editor (which is awesome, by the way). It allows you to download your campaigns, easily make all sorts of changes, and then post the finished product (or you can archive it, or share it, or review it, or whatever).
What's funny, in all of this, is that this app provides better functionality (especially when it comes to making bulk changes) than the original Adwords (which is a pretty amazing, but online only, app). It's being pushed by Google in order to ease the burden put on their customer service reps to help people make those sorts of changes.
My point is that it's not accurate to say that there's some kind of online v. desktop war going on between those companies. Microsoft is working on online only apps (foolishly IMO). Google has an online desktop app (or two). Though Adobe is rolling out their online-desktop thing, they still happen to own Flash which you may have seen in a lot of online apps (Google Analytics for example).
]]>We are working on one such model we call peer to web. We already have the first p2web application deployed BoxCloud that allows users to share large files from their desktop using drag-n-share without any uploading or emailing. Once shared, the recipient accesses the file over a browser. The file resides locally on the sender's desktop.
We believe there are many more apps that can leverage this model - iCal, Photoshop, etc. for enabling web-like sharing. We *too* are launching a framework for building p2web apps code named CloudStack.
Cheers
]]>@Stoicho -- Security is always an issue, for browsers too. My Firefox just updated itself to 2.0.0.3 because of a security issue. I don't think security is intrinsic only to desktop or to web.
@Rational -- Microsoft is working web on properties, it just takes them a couple iterations. It is foolish to think MS doesn't *get* the web. Yes, they would like to drive people toward richer desktop apps, just as they drove command line users to richer UIs.
In my opinion, the only thing stopping them is, as Richard pointed out, mobility. Coming from the desktop world, they haven't (or haven't figured out) how to address this with desktop apps.
The advantage Google enjoys today is, after 6 months of testing, they can release a new application to everyone immediately.
Microsoft, on the other hand, after several years of testing (and in the case of Vista) can release the new OS only as new PCs are rolled out.
This status quo will not last. But if Microsoft (or anyone, maybe Adobe) figures out how to make the distribution of richer pieces transparent (like a web app), then their spot will be secured for another decade.
]]>Apollo lets you build a web app, which if accessed via a browser does what web apps do now. This is great if you might not be using the same machine next time.
If accessed via Apollo the same web page becomes a desktop app with all the benefits, such as richer experience and file system access, that come with that. Great if you are using the same machine for long periods.
If accessed via a mobile device you get the function set would be most appropriate for use on the move. Again possible to provide by the same site.
I guess this is an argument for an offline web app, but I'm not sure the future will be that simple, or indeed that basic.
]]>@Stan... I think you and John are talking about different things... web ONLY apps will alway exist since some apps don't really beenfit from an offline component that much. Flickr might be one... or not (I could see wanting offline access to my photos).
I think the continuum will look something like this:
Web Only. No offline component
Mostly web... minimal offline features
mostly desktop, minimal web features
Desktop only. No online features
Now, if the number of apps in each category roughly follows a normal distribution, then many of the apps we'll use in the future will fall into the categories of
* More web, but with some significant offline features
* more desktop, but with some significant online features
one thing that the above post doesn't address is that desktop apps (tradiitonal ones) share UI similarities - button styles, window behavior, etc. What of Apollo or other apps created with non-native (OS native) UI frameworks? I can see it being very annoying to have window controls vary from app to app, etc. I'm on a Mac... I know where the maximize, minimize and close controls are on app windows... as a user, I get conditioned to these and other conventions... The same happens on Windows. Having these change uniformly would be disconcerting, but manageable, but having them vary from app to app based on the developers whims could be incredibly annoying.
]]>So I get the advantage of the feature rich UI of my desktop app when I am on my own computer, and the convenience and "access anywhere" capabilities of an online app as well.
This would be even easier for Adobe to do with the online Photoshop they are developing. It should be easy for the online app to be able to save PSDs you're working on to the desktop. The missing component would be the relatively simple step of adding a way for desktop Photoshop to automatically fetch online PSDs from your account and save offline ones to your online storage.
]]>But this could certainly change. Just like Firefox pushed MS to update IE, perhaps MS will be pushed to update the desktop UI. I'm sure Apple has its opinions about that sort of thing as well.
But I almost think that, though annoying when controls start varying, it is a sign of change and innovation-- which is sorely needed on the desktop. In fact, you might even say its a healthy development.
]]>* Web Only. No offline component
* Mostly web... minimal offline features
* More web, but with some significant offline features
* more desktop, but with some significant online features
* Mostly desktop, minimal web features
* Desktop only. No online features
I keep thinking of a graphics program called Kai's Power Tools... very non-standard UI on the Mac, beautiful... but annoying unless you used it regularly since it was different from the OS. There's a tension between innovation and ease of use that will be interesting to watch, but I think that if each new Apollo/Slingshot/whatever application is very different from every other one and from OS apps it will present a barrier for general users. Apollo et al have to answer the twin questions of "Why is this better than a browser application?" and "Why not use a OS native application that looks and feels like I'm used to (but with perhaps better online integration?"
Oh and Richard - your Gmail use case (ouch!) doesn't require an offline version of GMail... any email app, e.g. Thunderbird, would do fine for that. Of course that introduces the issue of precisely what we want available offline.. data? UI? both?
]]>This would require something more than Thunderbird.
]]>Perhaps they'll be using Apollo for this, I don't know.
To AL's point, this exampe falls into both categories it's both a business app and a personal/productivity app.
The most important thing that must not be forgotten, as Richard's Gmail experience (and every other Gmail user experienced) is that for most people, they don't really care if it's an offline web app or an online desktop app. They just want to be able to do whatever it is they need to do. And not worry if information will be lost or be irretrievable. It's about the users.
]]>An offline Web application is to take a part of social activities to a private space; and an online Desktop application is to take a part of private bahaviors into a social domain. In our real life, we see both of these phenomena regularly. Most of the time, which one is better does not depend on the method itself. In contrast, it is more about WHO makes the decision. Some people like to let everyone know their privacies; they will definately like to use online Desktop applications. Some other, however, like to hide their soical activities as many as possible to be private information; and they will definately prefer to having offline Web applications. So which one is better? It does not depend on either researchers or developers. The answer can be very much different from one person to another. This is why both strategies have their customs.
]]>Yeah, all of that would be nice. Can you have it out next week for me? :)
One reason I use GMail though is to avoid all of the sync hassles. I winced when I read about Richard's outage. the problem with an offline component though is that it has to be able to be used on-demand... If GMail had an offline component I'd rarely use it - I'm almost always online if I'm at my laptop. But if there's an outage... I just want my stuff to be there. If, to get that, I have to use program outside of my browser all of the time it won't work - I'm just not going to launch a separate program for web email all of the time on the off chance that the service will die once a year.
]]>2."There's an instantly identifiable flaw in John's reasoning. . . . And it is this: desktop apps are OS-dependant. Online applications are cross-platform."
Q. Who actually wants cross-platform solutions? With due respect to people using a Linux desktop, what you're really talking about is Windows and OS X. Do Mac users WANT cross-platform apps? Or does it solve more of a problem for developers - 'write once'.
>Furthermore, as Tim O'Reilly often points out, online >applications use web as the platfor
>This approach gives them a number of features/capabilities > and you can remix that data and create an RSS feed that >shows one Flickr image for every story on NYTimes. Could >you do that with a desktop app? Nope. That's what Web 2.0 >is about.
You certainly could. But the crucial point is the barrier for entry - it's certainly going to be quicker to develop using 'web' skills. But to turn it round, look at an app like Garagesale that uses the ebay APIs, with a desktop interface. It's a LOT harder to implement something like that in Ajax than Obj-C. Especially as you won't get the local caching of all the category data, etc.
>But I almost think that, though annoying when controls >start varying, it is a sign of change and innovation-- >which is sorely needed on the desktop. In fact, you might >even say its a healthy development.
Up to a point, Lord Copper. On the Mac MOST text fields use the core text class which means you have access to built in dictionary for spell-checking in all apps, text-to-speech, Google search, etc. More importantly it meant that they picked up improvements in 10.4 and will in 10.5. As soon as you move to custom classes, or something like the Apollo runtime, you don't get that.
I like the fact that there's a common colour and font-picker to a lot of apps - or I can plug in a replacement.
Equally there's a lot to be said to consistency between programs. Learn how to use one 3-pane program and you know how to use them all.
It's well worth reading Joel Spolsky's 'User Interface Design for Developers' too, which gives a lot of reasons for doing things the way users EXPECT them to work saves them time. Instant familiarity is good.
On the other hand, Apple are increasingly moving away from their own HCI - the trends I'm increasingly noticing are a move towards applications having full-screen modes with float-over controls - which I think matches the way a lot of consumers use applications - one at a time - compared to the way we work in an office.
]]>Unlike Apollo, Flex and PHP, you can build these apps with full interactive capabilities, business systems or consumer technology integration via local APIs, while taking advantage of web services to leverage data and functionality from a central server. Unlike Apollo, Flex and PHP, you have the choice of true strongly typed development in WPF or dynamic typing in WPF/E.
The convergence is here.
]]>thank you for infos
]]>