Thoughts on Structured/Unstructured and Shared Information Management
using Wiki and other emerging technologies
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.)
Instiki - Focus on Content publishing in wiki systems
Spate of recent wiki announcements - such as application-oriented wiki JotSpot. For enterprise focus, being able to create application workflows in quick way is going to be important - in such a way that you can reuse the schemas and "code", and wikis provide just the right framework for the same. We essentially need to make sure that both the skillsets and time required to introduce a new workflow within the IT infrastructure will have to be reduced significantly.
And another wiki - Instiki on the block. The key feature of this wiki is being able to publish to different URL, which is more important from content-management perspective (which is another main theme in enterprises).
Publishing is not well implemented in current set of wiki systems. What capabilities do we require (assuming content is prepared for collaboration)?
- Be able to produce good HTML, along with appropriate styles etc. Usually this means casting the content into one of the standard templates such as a news item, standard process information document and as such.
- Make it an independent document, with careful control of outgoing links. Within a wiki system, links are introduced automatically - just by refering to Camel-Case (and similar) topic names. But in published content, the links are usually minimized, and made sure that they refer to previously published information only. So the the publishing algorithm should identify and inform the content authors to make sure the links are properly resolved. (And, it is better to provide them as an appendix or notes.)
- Version of published documents (as visible to the audience) is not related to versioning provided by Wiki systems. The published versions of documents are for formal communication purposes. Usually a manual table can be included (which tracks published versions and maps it to wiki versions), but sometimes, this version information can be useful in overall enterprise content management systems. In which case, it needs to be available as metadata.
- A good and flexible interface to create and manage navigation of published content. (Usually a hierarchy.) Wiki systems only provide a hierarchy for fast collaboration, and this is not usually sufficient for organization needs for published content. Accordingly, the embedded links need to be modified to refer to the published destinations.
Instiki says it makes it easy to publish information to new hierarchy of URLs. So this needs to be watched.
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.
