Jon Richards <richards@inreach.com>, 2007-01-19 09:10 -0800:
> I've been part of a start-up that ties to address this exact problem. How to
> centralize applications by creating a rich client that interacts efficiently
> with apps running on a server. No data on the client, all on the server.
> This type of solution is not appropriate for applications like Photoshop,
> but very applicable to data entry and sales force operations.
I'd wonder how far the "no data on the client" feature of that
application extends. I mean if one of the functions of your
application UI is to give users a way to get different views of
the same set of data (for example, sort it or get some filtered
view of it) without downloading that data to the client side, then
it might be argued that it can't ever really be particularly
efficient to keep all that data strictly server side and require a
call to the server for every single instance where the only thing
that user wants to do is get a different view of the data.
> We've met several barriers to the rich client approach to centralizing
> applications. The biggest is that a large majority of developers in this
> area (at least for the desktop) are of a mindset that everything has to be
> shoe horned into a browser.
I guess one reason that many developers targeting desktop PCs have
adopted that mindset is that they want to make their apps as
widely available and as easily deployable as possible: At the very
least, they don't want to have to build and test N different
native versions of their apps for N different OSes/platforms, and
beyond that, don't want to require their users to download and
install anything, nor have to deal themselves as developers/
vendors with problems of trying to get updated versions of their
apps out to users when they make bug fixes or add new features.
> The result of that is that you get very inefficient apps that
> are a bear to write the server code for, and that don't operate
> very well in a browser, but limp along. The browser is great,
> but not for ALL things.
Well, yeah, a browser-based solution is probably not very good
approach for (as you mention) an app like Photoshop. But for the
other classes of apps you mentioned as examples (data entry and
sales force operations), it doesn't follow at all that browser-
based apps are inefficient or hard to code.
> Another barrier is that the investment community does not recognize that
> bandwidth is a problem. The VCs tended to think that since their DSL at home
> is pretty darned fast, all the Internet is fast and bandwidth issues to not
> exist. So in their view there is no need for software to deal with bandwidth
> problems. I believe that the VCs (at least the ones we spoke to) also
> extrapolated this into the mobile world, because 3G promises so much.
Mobile browsers that have Javascript and asynchronous XHR (Ajax)
support provide a solution that helps to mitigate the bandwidth
issues; for apps that give users a UI for inputting/manipulating/
viewing a particular set of data -- common examples are
spreadsheet-like apps that have functions for dynamic resorting,
apps that let users navigate through a tree structure of data
using collapsible/expandable nav menus, and apps that walk users
through form-based data input with conditional branching based on
what they select in some earlier part of the form -- those apps
are often way more thrifty with use of bandwidth because much of
the display work on the data can be done on the client side, using
DOM manipulation, and with much fewer calls calls back to the
server than would be needed if the browser lacked XHR support.
--Mike
--
Michael(tm) Smith
http://people.w3.org/mike/
-- No attachments (even text) are allowed --
-- Type: application/x-pkcs7-signature
Received on Tue Jan 23 12:32:42 2007