|
|
|
29 Nov 2004
MicroContent Client
In a comment on one of my entries of the MicroContent client Marc Canter says:
you talk very specifically about the ‘micro-content item panes’. But remember - there might be popular or successful micro-content interfaces but there will never be just ONE micro-content interface.
I am not sure whether he read any of the other entries, but it made me think again about the conclusion I seem to be heading to with my analysis of MicroContent-clients. I agree and do not agree with Marc Canter. ONE micro-content interface is good enough.
MicroContent can be any structured content. You only have to look at the possibilities provided by Qlogger. It will be impossible to create a client for each MicroContent type that exists. There will be a generic MicroContent client that can handle all possible MicroContent types. As my analysis has shown (read the previous entries) there are many similarities between the clients of different MicroContent types. This similarity has to translate itself in uniformity of the interface and common object libraries. Such a generic MicroContent client will be a bit like a web-browser: very generic.
But there will be specialised and independent MicroContent clients for a single MicroContent type. Specific MicroContent types might need specific functions or interfaces.
Anyway it will be an interesting exercise to see what makes the various MicroContent clients that I discussed different. Was there really a need to create a different client?
Categories/tags:
client
PermaLink
•
Comments
•
TrackBacks
07 Nov 2004
Microcontent Client
If you follow the principles of DataLibre, then you should own and publish your content yourself. Many participants over at their discussion list seem even to imply that this implies creating your own web-server or at least use your own hosting service. But certainly do not use an aggregator. The risk with any third party is that they may go down and your data with it. One solution is to make regularly your backups or to keep your MicroContent on your PC (and make backups as well).
But if you do something locally you do not have the advantages of a slick web-interface, so another solution is needed. This where the MicroContent client comes into play. Such a MicroContent client can have multiple functions:
- Creation - the client must allow you to create a new MicroContent item. As MicroContent is structured data (and metadata), the appropriate fields must be presented, to be filled-in or changed by the user. What the relevant fields are depends on the MicoContent type;
- Viewing - the MicroContent client allows a user to view the items that he has created;
- Updating - the MicroContent client allows a user to change any item that he has created;
- Deletion - the user should be able to delete any item he has created;
- Publishing - the user should be able to publish an item. This might be on his own server, a hosted server or maybe a third party. This is by the way a fundamental requirement. MicroContent is all about publishing;
- Synchronising - when a new item is added the published information must be changed as well (synchronised);
- Retract - a user might retract an item that he has published;
- Categorize - a user can categorize items into lists, sublists, etc. This will allow a user to filter the items;
- Subscribing - the user can view and subscribe to MicroContent items published on Internet;
- Importing - not all MicroContent will be in the format stored by the application. So ways the convert from public format to internal format must be available. It would be even better when third parties could create the necessary translators;
- Exporting - this is similar to publishing, but it creates files in XML or HTML-format and can be published by hand;
- Saving - it must be easy to save publicly available MicroContent, which is in the internal format;
This is a first list of functionality that I like to see in MicroContent clients. I will update list as I continue to analyse possible MicroContent clients.