 |
Musings on Web 2.0
Posted by javakiddy on December 07, 2006 at 03:06 PM | Comments (17)
David Van Couvering wrote an interesting blog entry recently which caught my attention. He gave a 'heads up' to a discussion stemming from a recent Tim O'Reilly blog entry (which in turn referenced other blogs, go check the original for details) debating the merits of the term "Web 2.0". The debate bounced back and forward across a couple more blog entries (and some private emails, by the sounds of it) and ended with Tim seeming to agree that the term Web 2.0 was misleading, as it suggests a HTTP/HTML centric approach.
David brings the rather long discussion into focus, by asking whether the web (HTTP/(X)HTML/CSS/Ajax/etc.) is really an ideal platform to deliver the promise of Web 2.0, and ponders what is stopping other platforms (JWS, for example) from gaining traction in this space.
As you may recall from a blog entry some time back, I'm no great fan of the web browser as an application delivery platform. Proponents coo and whoop every time someone manages to bludgeon a rebellious HTML rendering engine into mimicking a user interface 'effect' we had on the desktop two decades ago! Sometimes it feels like UI software development suffered a massive stroke sometime back in the late Nineties, and is having to slowly relearn how to do basic things like menus, lists, text highlighting and cursor tracking.
I broadly agree with David's blog (although one comment about Derby makes me wonder if he subscribes to the belief that relational databases are appropriate on the desktop when one merely wants data storage.) I'm not going to rehash his arguments here. Instead I want to throw out some random ideas about as to what a desktop Web 2.0 platform would require.
About six or seven years ago I started to get seriously p*ssed off about having to put a web interface on everything I wrote. Ninety percent of the development time seemed to go in finding work arounds for user interface techniques which were standard on desktop UI APIs, and then making them work in the ever-shifting quagmire of browser bugs, incomplete W3C implementations and user settings (JavaScript on, JavaScript off, JavaScript on, JavaScript off...)
The situation was neatly summed up by one comment to Tim's blog from someone called Steve: The browser exists because of Windows and people being frightened to install new software. The browser and all of its extensions provides one of the most hideous and limited development environments that barely, and only by dint of amazing amounts of effort, qualifies as cross-platform.
At first I thought the problem could be solved by complimenting the usual HTML form elements with a new plugin element, which would allow the likes of Java applets and Flash to participate in web forms just like 'native' components via a simple software interface. There would be event callbacks to inform the applet when the form had been reset, to request a string representation of its state for when the submit button was clicked, and so on... Eventually I realised that this wasn't sufficient. What was required was a complete sacking of the web browser, and the building of a new platform which catered specifically for the needs of dynamic online applications.
I called the project SNAP (Secure Networked Application Platform) and began experimenting with just how much of the web browser 'motif' I could move over into this new type of browser. The basic idea was that the new browser would allow thin client applications to flow across the internet with the same ease as traditional web browsers had allowed hypertext documents to do the same. The application arrived via a URL as an XML file which detailed the user interface, including references to UI components (buttons/scrollbars/textareas/media players/whatever), from libraries which could be downloaded on demand. Scripts inside the XML would bind these components together by manipulating a DOM which exposed their properties and functionality, to form a coherent user interface. Seasoned coders would write libraries of heavyweight components, and less experienced coders could tie them together with scripts.
There was also a server side XML which detailed the objects which needed building, or locating, remotely whenever the application ran. One no longer saved a file, but 'bookmarked' your work against the primary server. Taking that bookmark to a totally different computer would then reload the application and your work, in the same state as when 'saved'. SNAP used web service like calls to transparently import a server side object model onto the client, allowing the thin client scripts to kick off processes which could survive after the client closed down. This meant that one could begin a long winded process at work, then go home and check in to see how far it had progressed by simply taking the bookmark with you.
If that all sounds like too big a mouthful for one person to bite off, well, quite clearly it was! I managed to get a basic prototype up and running which trialed some of the client side stuff, but it was blindingly obvious from the start that my ambition was well in excess of what I could realistically devote to such a project in terms of time and resources. And, remember, back then I was the only person in the World who had realised that the traditional HTTP/HTML model was seriously broken (or did it just seem that way?)
Getting back to the point: as I understand it, David's blog entry suggests that the demands of Web 2.0 require a new type of client side platform. A thin client platform, which allows the server to get on with processing data, freeing it from the requirement of servicing the client side user interface. A yin and yang type affair, where the new browser (let's call it Desktop 2.0) allows 'location-less' (everywhere yet nowhere) applications to dovetail into 'location-less', community built, sources of data.
Since my jottings on the back of various envelopes in aid of my doomed (but highly educational) SNAP project, things have moved on. Many technologies have matured which would have slotted right into Snapdragon (my experimental browser) — indeed today Snapdragon would be more a case of assembling the off-the-shelf pieces, rather than building something from the ground up. But if the software landscape has shifted, how about the original goals? Could a completed Snapdragon have served as a suitable Desktop 2.0? What would be required by such a piece of software in today's Web 2.0 climate?
If I was to re-write Snapdragon today, with one eye on the promise of Web 2.0, here's a wish list of what I might try to include:
- Not just a Web 2.0 thing : Any Desktop 2.0 client must also be a replacement for Ajax. Strictly speaking GMail isn't a Web 2.0 application, but it should benefit from a Deskop 2.0 remake.
- Low barrier to entry : A combination of lightweight scripting, coupled with heavyweight UI components, giving ease of development for the majority while not tying the hands of power users.
- A consistent model for accessing data held locally and remotely : Ideally we should spend our time thinking about how to use the data, not worrying about where it physically lives.
- Security on a per-datum level, not a per-connection level : Instead of denoting network connections as secure or not, we should be able to mark bits of data as sensitive, and the platform should promise to do any necessary encryption whenever said data travels via an 'accessible' channel.
- An expiry date for data : We are used to information on the web carrying an expiry date, it comes with the HTTP territory. Such concepts are rare in traditional desktop software, but if data is to be cached as it travels around any application we develop in Desktop/Web 2.0, it needs to come with some kind of use-by date.
- Standardised mechanisms for common collaborative working patterns on the client and server : With applications in which several people can work on the same data, certain bits of functionality appear over and over, such as the locking and/or checking in and out of data. If the client and server had some kind of recognised protocol for doing this, it would make life a lot easier for developers, as well as reduce the opportunity for bugs.
- Some kind of standard vocabulary and UI motifs for representing common collaborative actions : Just as the GUI brought a simple, predictable and intuitive means of interacting with software, we need a consistent and unambiguous means of representing common collaborative working techniques (locking, merging, updating, etc.)
- A standard, simple, vocabulary and UI motif for representing security : With applications living 'across' the internet, security is a priority. The problem with concepts like certificates and signers is that one has to understand the mechanics in order to truly understand any given risk. We need to devise a means by which the average user can make informed decisions about what to trust, perhaps by employing recognisable concepts from 'real life' as a means of explaining some of the more abstract concepts in computer security (just as the desktop uses familar concepts like 'folders' and 'trashcans'.)
There's been a lot talked about Web 2.0 since the term was first coined. As I understand it Tim (and presumably David) seems to think it has little to do with flashy web site design (as many think it does) and a lot to do with "user generated content" and "harnessing collective intelligence".
The above is not an exhaustive list, naturally, but it serves to put some flesh on the bones. If Web 2.0 is destined to move away from the confines of the humble web browser, onto a desktop client truly designed to accommodate it, then I suspect something like the platform I've begun to outline above would be necessary.
Or perhaps I'm getting confused with Web 3.0 ??? :)
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
It sounds to me like you are describing the Java VM and core libraries. Afterall, isn't the JVM really just a "Super Browser" once installed? Sure there might be some extra layers needed on top to simplify some things, but even those pieces seem to be already in development as part of various OS projects now available.
Posted by: evickroy on December 08, 2006 at 06:50 AM
-
Nice article, Simon! But I would agree with Erik: do we really need one more "platform" while we already have J2SE?
Instead of developing a support to store and transfer UI as XML, I'd concentrate on providing tools for simple UI building. F3 looks promising. Also wondering if Joshua Marinacci's SketchPad can turn to be very useful here.
Alex
P.S. Before I read David's post I thought that I was the only person who realized that browser-based model is broken :)
Posted by: alexter on December 08, 2006 at 08:29 AM
-
I've occasionally toyed at a project with a browser-like UI but full application support rather than being a document browser. I've toyed at just direct Java support or some other kind of language that would be cross-runtime. These days probably just go plain Java (especially now that it's on the open source path). Binary diffs for incremental updates would be nice. Also hashes to avoid redownload of common libraries across different sites. One big trick (that browsers and desktop environments also face somewhat) is key bindings. The "browser" hotkeys need to take priority, but you don't want to take too many. Got to leave some to the apps. Another issue is the whole searchability/hyperlink issue as mentioned in comments to David's article. Security is best achieved by making it clear when user data will be transmitted on the internet (and default deny). I had some specific thoughts on this, but I haven't thought about this project idea for a while.
Posted by: tompalmer on December 08, 2006 at 09:02 AM
-
the browser is not broken. it is just currently geared towards simple apps. maybe what is needed is a browser 2.0, but i don't think pushing items back onto the client is really going to solve anything. the web wasn't meant to solve application development headaches. the concept of browser could use a significant upgrade, but in reality that's just browser 2.0, not web 3.0. i think specifications like xforms are the future; too bad they're getting little traction.
Posted by: ilazarte on December 08, 2006 at 09:11 AM
-
Tom, I think jardiff can be thought as the first approximation of binary diff. The situation with sharing libraries is a bit worth: JNLP extensions located on different hosts are required to be trusted and signed, even if they don't require anything more than a sandbox. Currently the URLs are used by WebStart to manage caches so even the same extension will be downloaded again if it is located on different host. However this tends to be impoved when this bug will be fixed. I wouldn't say searchability/hyperlinks is an issue; it's rather a thing to deal with. I feel about to understand how to do that with current technologies.
So I'm persuaded that we are all set to develop rich client instead of inventing new technologies and frameworks :), though agree that these technologies must continue to evolve.
Alex
Posted by: alexter on December 08, 2006 at 10:12 AM
-
Web wasn't meant to solve development headaches, but web applications were (namely, the deployment problem). While web remained a set of cross-linked documents with browser being a universal tool to view these documents there was nothing broken about it. But it seems to be becoming a set of applications working with remote data. What is the reason to keep these applications inside browser? Nobody means to move everything back to client side. But some things really press to be there (in fact they already are, but they just run inside browser).
When I say "browsers are broken" I say it as a user, not as a programmer.
Posted by: alexter on December 08, 2006 at 10:29 AM
-
For avoiding redownloads, my simple idea is to use an HTTP header and/or URL convention to provide a SHA-1 hash of an resource. Then, if the base name (not full path/uri) match and if the hashes match, then there's no need to redownload. It really shouldn't matter where it was downloaded from originally or whether it was signed (just that the current - not prior - site would need to be able to provide the hash). And it wouldn't be any less secure (if my analysis is right) than anything else on the web today. Browsers should be able to use tricks like this for cross-site caching of js, too.
Posted by: tompalmer on December 08, 2006 at 12:06 PM
-
alexter, thanks for the jardiff info.
Posted by: tompalmer on December 08, 2006 at 01:29 PM
-
Perhaps what's needed here is a way to build JWS applications by dragging and dropping UI components while using scripting to provide the event handling code? Don't get too hung up on the deployment mechanism: whether the client arrives as an XML definition or a Jar makes little difference: ultimately the result is the same.
I stand by what I said about security, handling remote objects and encryption though.
Posted by: javakiddy on December 08, 2006 at 03:02 PM
-
Hmm. Looks like you are looking for REST with a bit of auto-GUI binding?
Posted by: tompalmer on December 08, 2006 at 04:40 PM
-
I suspect Web 2.0 amounts to more than just REST with a nice GUI.
Posted by: javakiddy on December 08, 2006 at 04:47 PM
-
Simon, I agree that the deployment technology doesn't make a big difference; just saying that there's already one that is reasonably good.
With regard to UI building, looks like we are confusing things a little. As I understand, the basic idea behind "Web 2.0" name is user-generated content. The applications that handle this content are difficult to build and host even today (as far as I can tell it's already easier to develop a good modern Swing UI than a good modern "web" UI). So I'm starting to doubt that easy UI building is vital for rich clients to become a Web 2.0 technology.
Easy UI building jumps into the game once we think of the role rich clients could play in regular "Web 1.0". There are a lot of sites that are developed by small companies and individuals and some of them could benefit form having a rich client too (given that it will be as easy to deploy as a web page). One example of such a site is online shop.
P.S. "Desktop 2.0" is a nice term. I was advertising similar concept to people as "desktop-web" :).
Posted by: alexter on December 09, 2006 at 05:15 AM
-
I think we're trying to solve two problem here, which I realise I didn't make clear in my original blog. Firstly, there's been an increased interest in a UGC way of working -- yet each Web 2.0 application has had to re-invent the wheel when it comes to the basic mechanics of allowing several people to manipulate the same data simultaneously. Secondly, there's a recognition that HTML rendering engines make poor substitutes to traditional UI-rich desktop applications.
There's also another issue which I'm interested in addressing, which is that post Web 1.0 (note: 1.0, not 2.0) people have become accustomed to having their applications follow them around, via a URL.
It is true that one can point to disperate bits of functionality, across many far-flung APIs, which can be used to solve the problems I hint at above. But if the success of the Web and Java has taught us anything, it's that having the ability to do something doesn't guarantee its adoption, until you package all the necessary 'abilities' into one neat, coherent, 'product'. After all, there was nothing new about the Web, or Java -- all of the concepts and functionality which underpinned them had been around for years (decades even) strewn across various technologies and APIs. The reason why these two specific technologies found such overwhelming success was that they packaged a lot of pre-existing ideas and functionality into a single, unified, standardised, 'ready-to-go' platform.
At the moment JWS is far from a 'ready-to-go' platform, particularly when you consider the work involved in meeting the needs of Web 2.0 (or Desktop 2.0) applications -- and especially if you want to lower the skills barrier to entry so that those more at home with JavaScript, as opposed to Java, can join in too.
Posted by: javakiddy on December 09, 2006 at 06:47 AM
-
Simon,
I always love your blogs... they get my little brain cells going, so please accept my dissent in the spirit in which it is offered.... I'm smiling, and I hope you are too.
The term "Desktop 2.0" implies coupling between a user and a desk... the pre-eminence of a "personal workstation" with a keyboard and big screen at which the user does most of their work.
I think that the era of the personal computer/workstation is on its way out.... and we're moving on to pervasive devices of many sizes, shapes and capabilities. Look around and you see applications showing up on cell-phones, game boys, iPods, TVs, etc.... and you see the keyboard and mouse paradigm slowly giving way to speech and gesture recognition.
No doubt about it... Thin GUI clients can and should be improved... but "Desktop 2.0" is not really going to propel us to the next frontier of UI. It's just doing something we've already done before a little better.
Keyboard and mice were fine for the 20th century... but what do we really need here in the 21st century?
Thanks for posting,
-JohnR
Posted by: johnreynolds on December 09, 2006 at 06:45 PM
-
Simon, I have to agree completely with your last note. I'm trying to gather some of the possible techniques of building "Desktop 2.0" apps in a couple of simple demos and I'm getting really overwhelmed with all the technologies/APIs/standards I have to study before writing every single line of code.
Posted by: alexter on December 10, 2006 at 05:36 AM
-
@JohnR: This is a big topic, and it is obviously impossible to cover all the ground in one short article. Suffice to say I broadly agree with you -- although I'm not sure about ditching the keyboard as an input device. :)
One of the 'dreams' I had when I was experimenting with SNAP was that there would be different clients for different types of device. That's why I was trying to make it so easy (and transparent) to push as much of the app onto the server side as possible, making the client as thin as could be (while still offering a rich UI experience, maximising the individual capabilities of the device it was running on.)
Posted by: javakiddy on December 10, 2006 at 12:58 PM
|
java.net RSS Feeds
