Koranteng's Toli: On GMail and DHTML architecture again
From Koranteng's Toli: On GMail and DHTML architecture again:
The pattern is simple:
Database <-> XML (Optional) <--> JavaScript Object Bindings <--> UI Bindings (HTML) + UI management code
Wiki systems should map macros to make it easy to add some of the UI capabilities (such as adding an element to the already displayed list). Usual wiki renders everything in a page from scratch. In this model, you request only incremental info (using versions), and integrate that with what is displayed on UI.
But that would mean that all elements of wiki topic need to be accessed using structured approach. And perhaps we require fine-grain addressing of individual data items within the topic.
Tab (Notification) Framework - Usecase
Suppose you get an email from your organization survey system (requesting your info related to company-organized party). How do we optimize the interaction with the app?
The very first thing: This poll calls for notification mechanism - typically by email. Hopefully that would have a URL in the email body that directly takes you to the right app and topic (assuming you are online). (A grave mistake if there is no URL - you are forced to navigate with multitude of clicks!)
But there are problems: I might not attend to it right now. May be I need some other info. May be I want to process it at specific time only - along with many other such emails in the same group. So either you end up bookmarking it, or marking the email for later processing. In essence, you now have to manage it i.e. create a personal workflow for yourself.
So it greatly adds to email overload.
What is the solution? Suppose this email integrates into the PIM application - as a task, with what I call as Active Bookmark, then it would be very easy to process all the tasks. The active bookmark will not only have URL, but it will primarily notify the state of the app - much like presense information in IM systems. Green = You still have time to respond, Yellow = You ought to interact very soon, and RED = Urgent. And some color for "Dead" - where you failed to provide the info in time and it is recorded by your boss :-(.
Now these active bookmarks are basicaly "Saved tabs" i.e. it would be very nice to have this as end-user functionality, so it doesn't depend on the application. Users can then manage how they want to process long-term information.
-Vinod
Designing for tabbed browsing - the "Tab Framework"
One thing I hate about Bloglines is that I can't open the sites into new tabs directly - because each link is basically a javascript and not a URL per-se. In the same breath, I also like the fact that individual articles can be opened in independent tabs.
With tabbed browsing becoming such an important part of life, how should applications be developed so as to give best experience to user?
- Use REST principle. Typically each tab should stand for independent object which is getting inspected by the user - in case the site is information oriented (such as amazon, bloglines etc.)
- Alternately, if the site is workflow oriented (which most enterprise sites do), the tabs would probably stand for an initiation of workflow. And perhaps a small icon representing the "Data is now available" condition so as to get our attention when a delay-causing condition happens.
- Similarly collaborative sites could incorporate some mechanisms: Has user become alive again? Is there a new discussion?
Second big problem is: How do we manage so many tags? For a moment, consider tags to be bookmarks.
Each tag vies for our attention. While in most cases tags are temporary "handles" for helping us react to large amount of information, the actual attention span required might be quite large.
For example, workflows might involve a sign-off from co-worker, and all this while, you might want to keep the tab open (rather than remember to open the application again, or get notified by email.)
Some contexts might be really long-term: I might want to track a discussion, or wait to see if someone is selling that iPod at pricepoint of interest to me.
So as we don't have a decent notification system in place, I think tabs should get an important status.
Or perhaps
merge PIM systems and tabs. Let one flow into another. And did I say that Email clients will greatly be helped by tabbing too?! (Incidently there is a slashdot discussion: Firefox as Platform. )
-Vinod
The article How To Use Instiki As CMS in Instiki covers some important aspects of wiki and publishing (that I referred to in my previous blog entry.)
Desktop proxy needs to become standard service
In Firefox history in Google Desktop Search, Jon Udell suggests use of local proxy to help store browser history, so google can search it. Well, this is only one of the reasons for proxy, there are many others:
- Manage roaming IP addresses. Desktop proxy can do whatever possible to automate identification of network, so no need to change proxy addresses for all your desktop applications such as all those native blogging clients, IM apps, VoIP apps and so on.
- Supports virtual machines such as colinux. I run colinux on windows to get linux via cygwin/X. But colinux needs to connect to external world. Proxy that provides NAT support is of course a first priority.
- Hide those browser connection timeouts.When you switch networks frequently (i.e. when mobile), the TCP/IP timeouts tend to be very distracting. Browsers tend to hang (and later, give a "can't connect" alert box which you are forced to click on.) With proxy, you have easier approach: The proxy can give latest status and request you if you need to be notified nicely later on.
- Cache content. Mechanisms to cache content in intelligent way, so it is available when offline.
- Local virtual views on content (This is more related to wiki concept.) It is mich easier to organize content with help of a native app. Integrate it with locally running wiki to give access to your older content.
- Selectively share information with friends. Since proxies run as http servers, it is easier to share content with friends - at least within the organizations. When you want to share across firewalls, an independent server can make the task easier.
- Last but not the least, a good search interface.As suggested by Udell, the search integration can happen at proxy level. We require control over desktop/intranet/internet searches. For e.g. address searches can be directed to intranet, but the interface for it needs to become more intutive (select buttons? a leading string such as 'addr userA'?) More importantly, the proxy can identify the context and make sure the intention of search is better understood.
But we have these functionalities in bits and pieces. With focus on mobility, I guess there is scope for some good product on these lines.
