Archipelago
I just deleted a number of trial posts to this weblog I made using Archipelago a client-side weblog editor. Right now, the only thing I use Internet Explorer for is writing to winterspeak.com, and I would like to no longer need to do that.
What was interesting was how my initial stupification with Archipelago matched by initial experience with Radio. Getting everything set up was confusing, and I had no idea what any of the menu commands did. I don't mean to pick on either program's authors-- creating good software is hard, especially in a new design area where there aren't many norms.
Both Archipelago and Radio cross the divide between client and server. This is similar to the Lotus software I worked with at IBM over the summer. Simple menu commands like "save" and "new" are confusing in this new context. Is "save"ing something on my desktop the same as "post"ing something on Blogger? Or is the same as "publish"ing something on Blogger? Or is it the same as "save"ing something in Word, with a seperate "publish" coming later to get it all on the site. And given the agony of synchronization (a daily struggle at Lotus) how can you seperate/integrate data between client/server so the user doesn't go home and freak out because all his email has vanished (easy to do on IMAP if you haven't set things up correctly).
People moan about web interfaces all the time, but web apps are often *much* easier to use than their desktop counterparts. It's easy to forget how bad things were before, just as it's easy to forget how good Microsoft software is compared to what it has replaced (check out SmartSuite if you don't beleive me).
I haven't thought this through, but here are my rough and ready rules-of-thumb for these client/server type apps:
1) What people want is essentially the web functionality, but with the fast client-side responsiveness and free of the necessity of having to be online.
2) This does not mean you need to look like a webpage. Focus on the *simple* functionality of the webpage and deliver that in the best way possible.
3) Don't worry about seamless synchronization. If snychronization makes the easy, core stuff harder, drop it.
4) Focus on delivering the web functionality, but faster and easier.
The poster children I see for this is 1) POP email, 2) Watson, and 3) Napster.
With POP email you write your message, connect, and send the message. There is no complication with editting your email once it's sent. Your email lives on your client or on the server -- getting some setting wrong does not mean everything vanishes the minute you disconnect from the Internet. Now I know all the drawbacks of POP, but it delivers a simple experience when bridging the gap between client and server.
Watson simply brings key web application functionality (eBay, Amazon) to a desktop app. Yes, you need to be online to use it, but that's OK. It takes a website and makes it simpler.
Napster did the networked drive this really well. Pick a folder on your hard disk and call it the network drive. Drag something to that, and it's shared. Delete it, and it's gone. If you copy it to another local drive, it's now in two places. If the two go out of synch, they go out of synch. This model of network drives (with lots of gunk) is essentially what Ray Ozzie is trying to do with Groove now that he's done with he synch-happy Lotus Notes. Other network sharing systems require you to go to some website and upload stuff. This is like forcing the user to *save things twice*. Predictably, the user refuses to do this, keeps stuff up to date on his local drive, and then emails it to everyone once it's "kind of" done. The whole notion of "place" does not work because networked places are harder to get to than local places if you need to access a remote server through a web interface.
My ideal desktop weblog editor would be like POP email. I compose the post offline, see how it looks "online" offline, edit, and then post whenever I connect. If I want to edit it, I fire up I.E. and do that through the Blogger UI.
What was interesting was how my initial stupification with Archipelago matched by initial experience with Radio. Getting everything set up was confusing, and I had no idea what any of the menu commands did. I don't mean to pick on either program's authors-- creating good software is hard, especially in a new design area where there aren't many norms.
Both Archipelago and Radio cross the divide between client and server. This is similar to the Lotus software I worked with at IBM over the summer. Simple menu commands like "save" and "new" are confusing in this new context. Is "save"ing something on my desktop the same as "post"ing something on Blogger? Or is the same as "publish"ing something on Blogger? Or is it the same as "save"ing something in Word, with a seperate "publish" coming later to get it all on the site. And given the agony of synchronization (a daily struggle at Lotus) how can you seperate/integrate data between client/server so the user doesn't go home and freak out because all his email has vanished (easy to do on IMAP if you haven't set things up correctly).
People moan about web interfaces all the time, but web apps are often *much* easier to use than their desktop counterparts. It's easy to forget how bad things were before, just as it's easy to forget how good Microsoft software is compared to what it has replaced (check out SmartSuite if you don't beleive me).
I haven't thought this through, but here are my rough and ready rules-of-thumb for these client/server type apps:
1) What people want is essentially the web functionality, but with the fast client-side responsiveness and free of the necessity of having to be online.
2) This does not mean you need to look like a webpage. Focus on the *simple* functionality of the webpage and deliver that in the best way possible.
3) Don't worry about seamless synchronization. If snychronization makes the easy, core stuff harder, drop it.
4) Focus on delivering the web functionality, but faster and easier.
The poster children I see for this is 1) POP email, 2) Watson, and 3) Napster.
With POP email you write your message, connect, and send the message. There is no complication with editting your email once it's sent. Your email lives on your client or on the server -- getting some setting wrong does not mean everything vanishes the minute you disconnect from the Internet. Now I know all the drawbacks of POP, but it delivers a simple experience when bridging the gap between client and server.
Watson simply brings key web application functionality (eBay, Amazon) to a desktop app. Yes, you need to be online to use it, but that's OK. It takes a website and makes it simpler.
Napster did the networked drive this really well. Pick a folder on your hard disk and call it the network drive. Drag something to that, and it's shared. Delete it, and it's gone. If you copy it to another local drive, it's now in two places. If the two go out of synch, they go out of synch. This model of network drives (with lots of gunk) is essentially what Ray Ozzie is trying to do with Groove now that he's done with he synch-happy Lotus Notes. Other network sharing systems require you to go to some website and upload stuff. This is like forcing the user to *save things twice*. Predictably, the user refuses to do this, keeps stuff up to date on his local drive, and then emails it to everyone once it's "kind of" done. The whole notion of "place" does not work because networked places are harder to get to than local places if you need to access a remote server through a web interface.
My ideal desktop weblog editor would be like POP email. I compose the post offline, see how it looks "online" offline, edit, and then post whenever I connect. If I want to edit it, I fire up I.E. and do that through the Blogger UI.
posted by winterspeak at
6:51 AM
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home