Thoughts on Structured/Unstructured and Shared Information Management
using Wiki and other emerging technologies
Google can enable access-controlled searches!
With the current infrastructure, google is in inevitable position to enable Access controlled searches.
What is meant by access-controlled search? Basically I would like some of my own content to be searchable by some of my friends. This is probably something that most social sites want to add; but can't add because most of such information is in emails (or in desktop).
Why is google (through gmail) in a good position to implement this? Here is the recipe:
- Allow labels to group the contacts. (This in itself is a major value addition - see more notes below.)
- Emails get the labels from contacts (in addition to labels associated directly).
- Mark labels with "Allow this content to be visible from the associated contacts"
- Modify gmail search box to search among contacts. (This search will give results from contact's mailboxes assuming they have labelled the content.)
In essence, to me it looks like best possible UI for access controlled search based on contacts: Associate labels to contacts and mark the label with read permissions. One could even mark it as "public" and let it be searchable by google - after masking off From/To/Cc and dates.
In any case, the real problem is: "How do we label the content efficiently?" Labeling contacts is easy and done only once (such as "Family", "My School Friends", "My new startup biz contacts", "VCs".) This in turn allows emails from those contacts to have same label and this is good thing.
This might as well be a killer feature for google.
-Vinod
Domain specific languages express software refinements (June 2004) elaborates on:
- Need for DSLs - a vehicles that allow layering in software specifications, in turn helping in isolating implementation details from the upper layers.
- To what an extent XML can be used for this purpose
- The requirement for ease of hand-coding (or at least use of standard tools) - -- I hold the same view, see one of my earlier posts on this topic
On the last point: We require a very standard (= available in all plugins, open source, small enough to download/install etc.) graphical visualizer for XML to ease "handcoding" of XML and some basic reporting from it.
-Vinod
XML structure without XML markup (Alternative markups)
A old post - madbean.com: On verbosity, Ant's syntax and XML takes an ANT specification (in XML) and specifies the same into SOX and SLiP formats.
Other formats include YAML
Pyxie and SXML.
Counter rants for wiki rants!
JimmoWorld: rant: Why I Hate Wiki/Twiki/SnipSnap/etc..:
- They are overused, often for no better reason than "because we can". As a side effect, wiki nazis are starting to crawl out of the woodwork and harangue people who don't use wiki for their own pages.
- I'm used to hand-authoring html and css. I hate the lack of fine control over my layout and structure.
- Ugly to look at, often horrible to navigate. I've seen some truly incomprehensible sites with hideous layouts where it's hard to find the information you're looking for, if it even exists at all (not that this is unique to wiki-like resources)
- Yet another grungy, nasty syntax to learn. Yeah I could learn it but I'm bored and fed up with learning new ways to do things slower and uglier than before.
- Come on, be honest. How many wiki pages have you seen where little or no collaboration actually takes place anyway? Yeah. Loads.
- Contradiction in terms though it may be, snipsnap both sucks and blows.
As I am writing this, I had to open the source of the page, navigate through lot of CSS, javascript etc. and then copy the relevant "block" that is blockquoted above. All because my browser-based editor doesn't allow me HTML cut-paste.
But then, this is exactly where wiki would have helped. Within a wiki system such as twiki, I would have just viewed the source, which is usually very very clean. I would have cut-paste plain text, and basically don't have to bother about the HTML markup. The "real" wiki markup tends to be some 5-10 concepts (lists, paragraphs, tables, head ...), so you shouldn't even say it really takes time. (Especially when the help is just below.) It is, in some sense, like learning email/news etiquettes!
Then the next point is ugliness. Since everyone has to use common denomitor, the wiki topics tend to be very bland. But many wiki systems allow templates, skins and inline CSS styles, which can be easily used to give a deadly look and feel. (Unfortunate thing is that there are no good tools, so usually one person in team takes responsibility for right templates, good colors etc.) And web-based publishing is itself a skill.
Then comes the navigation. Wiki topics tend to be graphically connected (as opposed to hierarchy), and so it might indeed be a bad experience. But it is also possible to provide special gateway topics, category topics etc., and you can still navigate easily. (Having a "Related topics" entry helps here.) At the end of the day, it is just a matter of good practice that everyone has to adopt.
At the end of the day, we should realize that managing information on web is as important skill as email, and is already a required skill in many teams which depend on collaboration. The existing skills such as managing information in a file folder or email are individual-oriented, and can't be useful in collaborative environments. And you can't always dedicate an expert to manage web-based published information.... Blogs have helped in "opening" of information, and wikis will help in organizing that information.
One issue is a good notification infrastructure: How can I track 15 odd topics that I would be interested in? RSS interfaces to wiki systems are solving that problem.
So I would say wiki systems are a necessity, and if anything, let us hope that good tools will evolve to make the experience smooth.
Eclipse: Write Once, Run Everywhere Platform gives a good overview of how Eclipse is being used not just as IDE, but for variety of independent uses, including Rich Client App framework, Testing framework etc.
A Distributed Rich Client Application using SWT (eclipse component) ...
Qanyon World Factbook - A Distributed Rich Client Application is a good starting point for those who want to create native cross platform apps.
One of the key requirement is that the download size of developed app needs to be as small as possible, and with a single click install capability.
Seems that this app meets these constraits rather nicely! A good choice for offline / mobile apps.
In the same go, the same site (http://www.quanyon.com/) has eclipse plugin for converting various file formats (such as excel) into XML for use in eclipse plugins.
-Vinod
publish-subscribe on the web ...
Discovered mod_pubsub homepage today. Obviously very useful for mobilf/offline apps.
Simplicity in interfaces?
In KISS and The Mom Factor, Adam Bosworth brings reality to surface: People like simple things. In this context, he explains how simple XML as part of HTML body solves most of the problems for most of the people - as opposed to SOAP/Web Services etc.
Readability, being able to hand-code the protocol strings (for a quick testing) etc. are very essential. Perhaps ideal approach is to makeprotocols and specs simple for hand-coding use and progressively becomes complex as you use more and more involved features.
This is specially true for wiki interfaces where markup is almost always handcoded. For e.g. a simple table with few rows and columns is a breeze. In TWiki, you can manage more complex tables by adding a macro (with handled it via special UI). But this approach is still limited because the simple markup characters such as "|" can't be used in cell's text (in which case, they mess up the complete layout). It is, in theory, possible to encode these characters and make each cell more complex (additional markup for protecting special chars etc.,). But since it helps only 5-10% of use cases (perhaps much less!), I guess no one will bother.
Use of tools can allow more complex markups, but then the fundamental premise is altered. I guess no one will truly feel at home with tools unless they know they can manage the generated code. For example, many CSS tools generate very good markup. And some of the CSS plugins in Firefox allow you hand-edit this type of CSS and see the changes live. (But not sure whether such manual changes will be read again properly by tool; in CSS it seems to be easy.) I used to hope for such an approach in TeX world, but it never happened.
My colleague also pointed out this old article from Michael Fitzgerald explaining why RELAX NG might be preferable to XML schema.
A good article from eweek on Expertise management: Voluntary vs. automatic approaches to find experts: Expertise Management: Who Knows About This?. It is very important difference and has cultural aspects involved (apart from Privacy issues).
