|
 |
Tuesday, November 09, 2004 |
Can rich Internet apps be web-friendly?.
In my October 22 column, I argued that Gmail's aggressive use of dynamic HTML qualifies it as a kind of rich Internet application (RIA). As email correspondents and bloggers pointed out, the technique has a fairly long history. Many many wonder why it remains on the fringe. The reason, I think, is partly a weakness common to all RIA technologies. Whether it's based on DHTML, Java, Flash, .NET, or just a standard GUI, an RIA has a client/server architecture. Unlike a Web application which manages state information almost entirely on the server, though, an RIA achieves a more balanced distribution of that information between client and server. The benefits that flow from this arrangement can include responsiveness, context preservation, and offline capability. To achieve these benefits, though, we have to make some painful tradeoffs.
...
RIAs are protocol-driven. A programmer who masters an application's protocols can extend it or combine it with other applications. But there are no integration hooks available to the user. In a Web application, those hooks are simply URLs. Consider what happens when you include a MapQuest URL in an email to someone. A piece of state information -- namely, the state of the MapQuest viewer when displaying a given location -- has been reduced to a token that one person can hand to another. The same thing can usefully apply to the state of a shopping cart, or an airline reservation.
...
The idea that an application wears its state information on its sleeve, readily available for users to bookmark, modify, and trade, is an underappreciated strength of Web-based software. As the RIA bandwagon picks up steam, let's honor that idea and find a way to move it forward. [Full story at InfoWorld.com] ... [Jon's Radio]
9:26:28 AM 
|
|
Can rich Internet apps be web-friendly?.
In my October 22 column, I argued that Gmail's aggressive use of dynamic HTML qualifies it as a kind of rich Internet application (RIA). As email correspondents and bloggers pointed out, the technique has a fairly long history. Many many wonder why it remains on the fringe. The reason, I think, is partly a weakness common to all RIA technologies. Whether it's based on DHTML, Java, Flash, .NET, or just a standard GUI, an RIA has a client/server architecture. Unlike a Web application which manages state information almost entirely on the server, though, an RIA achieves a more balanced distribution of that information between client and server. The benefits that flow from this arrangement can include responsiveness, context preservation, and offline capability. To achieve these benefits, though, we have to make some painful tradeoffs.
...
RIAs are protocol-driven. A programmer who masters an application's protocols can extend it or combine it with other applications. But there are no integration hooks available to the user. In a Web application, those hooks are simply URLs. Consider what happens when you include a MapQuest URL in an email to someone. A piece of state information -- namely, the state of the MapQuest viewer when displaying a given location -- has been reduced to a token that one person can hand to another. The same thing can usefully apply to the state of a shopping cart, or an airline reservation.
...
The idea that an application wears its state information on its sleeve, readily available for users to bookmark, modify, and trade, is an underappreciated strength of Web-based software. As the RIA bandwagon picks up steam, let's honor that idea and find a way to move it forward. [Full story at InfoWorld.com] ... [Jon's Radio]
9:26:14 AM
|
|
© Copyright 2005 Stephen Dulaney.
|
|
 |
 |
 |
 |
| November 2004 |
| Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
| |
1 |
2 |
3 |
4 |
5 |
6 |
| 7 |
8 |
9 |
10 |
11 |
12 |
13 |
| 14 |
15 |
16 |
17 |
18 |
19 |
20 |
| 21 |
22 |
23 |
24 |
25 |
26 |
27 |
| 28 |
29 |
30 |
|
|
|
|
| Oct Dec |
|
 |
 |
 |
 |
|
