Comments inline

On Sep 26, 2006, at 10:50 AM, Mimi Yin wrote:

After many rounds of questions and answers and a lot of patience on bcm's part, I think I finally have a first pass at end-user usage scenarios that would be supported GData and Atom.

While in the short-term, the primary users of GData will be developers looking for easy ways to move data around, we envision that in the long-term, the Cosmo development community will create interesting end-user applications for this technology. This is a thought exercise to explore how some of those scenarios might pan out. This is by no means a complete list, but it starts to paint a picture of real-world usage.

BLOGGING
+ I write about obscure, suburban and rural teen and pre-teen lifestyle trends.
+ I write a travelogue about traveling to towns where UFOs sightings have been reported.
+ I write about gadgets smaller than a breadbox and bigger than a thumbnail.
+ I write about cooking shows that use mail-order kitchen appliances.
+ I write about cultural cross-over celtic/cantonese rap groups.
+ I write about the art of nano-origami.

I use a blogging client to organize and publish my research, media (pictures, video clips, audio), and writing. The client speaks GData/Atom and publishes my writing to a variety of websites, all of which pull my writing from my Cosmo account, where the data actually lives.

(Someone could write a parcel so that Chandler could be this client. OR, this client could be developed completely independently of OSAF.)

Additionally, whenever I refer to specific products, tv shows, towns, books, albums, or people, my client is able to encode that information as pre-defined types so that other clients who can understand these types can pull them down.

+ Someone can add the tv cooking shows I review to their "tv shows" calendar.
+ Someone can add the products I review to their wishlist manager.
+ Someone can add a town I write about to their travel planning app.
+ Someone can add the people I write about to their people manager.

They would either do this because my client identifies data as events, contacts and Cosmo is able to spit out standard file formats (e.g. .ics, vCard). OR Cosmo is dumb about the data types and the client on the other end can understand the GData types defined by my blogging client.

LOW-TECH INFORMATION MANAGEMENT
+ I am a entomology enthusiast. I keep track of and archive interesting research, articles in the mainstream media and blogosphere about butterfly migration patterns in the Northern Hemisphere. I have an app that helps me organize all of the materials I find, keep track of citations and sources and publishes my archive to a website I maintain. I want to make the materials I collect available to others interested in this research in a standard data format with citations intact, topic tags and comments. My archive app publishes my material as 'research' data to Cosmo. Cosmo doesn't necessarily understand the 'research' data type. But other 'research organization apps' do.

PERSONAL INFORMATION MANAGEMENT
+ I use a travel planning app to plan my vacations. Flight schedules, hotels, walking tours, safaris, museums, restaurants, shows, shops, etc. However, I need to be able to access this information, not only through the travel planning app, but also through my desktop PIM, my mobile device, my web calendar. I also want my family members to be able to pull down this information into the various PIM apps they use.

Follow-up Questions
1. How do these usage scenarios fit in with our stated organizational and poduct/service goals? There are clear applications in the realm of small-workgroup collaboration.

The long term goal for Chandler has always been to be an extensible system, and we have lots of extensibility capability already built into the desktop.    Building out all the client code that would implement the scenarios  you listed above is probably beyond what could be done for preview.    But building the infrastructure to allow someone else to build those clients is definitely doable, and in the same spirit as the extensibility mechanism for the desktop.    As far as service goals, if people build apps like the ones that you have describe above, there will be more users of the service, which means more users that Chandler users can potentially collaborate with.


2. How does this affect planning on the desktop client side? Where can Chandler desktop play a role in these scenarios?

What you have described above are plausible scenarios for how people might use a GData/Atom API if we had one.   That doesn't mean that people will actually implement any of them.   I think a perfectly reasonable position would be to see what usages actually appear and then figure out how those relate to desktop capabilities.   Otherwise we're trying to plan in what is essentially a speculative space.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Reply via email to