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:
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.
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.
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.
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.
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.