[Sum] Re: [Chandler-dev] What's our Web Strategy? Web Widgets, The Server and The Current Web UI

[Mimi Yin]

I wanted to take a moment and summarize what we've decided / learned  
from the 2 meetings we've had on Web Strategy.

Please review carefully. Is there anything that is incorrect? missing?

1. On Data Integrity

1. We should think of our starting point as EIM. Whatever is stored  
in EIM, the server can serve up to any web widgets we build.

2. Expensive items: Anything where you care about per user  
attributes. This includes things like 'Read/Unread' status and  
sharing filters (what attributes are shared/not-shared with others).

* We can probably still provide functionality around tell people  
'what's new' in their collections even without read/unread status by  
asking users to define a timeframe: Show me everything that's changed  
in the last hour OR by automatically showing users everything that's  
changed since the last time they logged in. The latter approach might  
be problematic if Desktop users are subscribed anonymously via  
tickets to certain collections. We would want to be able to figure  
out the last time the Desktop synced with the server with a Hub  
account and assume that that's the same time they synced all their  
subscriptions as well.

* We will probably still want to add things to EIM. Need to get  
further along in design to figure out what it is we need to add.

* I realized after the meeting that sharing filters: what attributes  
get shared/not shared from the desktop, fall under the category of  
expensive per-user attributes we're unlikely to support anytime soon.  
Does that mean that in order for your web widget to know about alarms  
you've set on an item, you need to share alarms with everyone else as  
well?

To partially address this problem, we could differentiate between  
custom-date alarms (shared) and alarms dependent on event-times (not- 
shared). It means that if you're using your web widget, you won't  
receive alarms you set on events like alert me 15 minutes before the  
meeting (unless you're okay with sharing that with everyone else as  
well.)

DOES THIS SOUND REASONABLE TO EVERYONE?

2. On linking to individual items
+ Yes the server can generate read-write and read-only tickets
+ We can also create a link to a particular item, within an account
+ We just need UI to display a single item. So a single-detail view  
widget that you can share with others using tickets is not an  
unreasonable feature to add to our queue.

3. On supporting items in multiple collections on the server *and*  
closing security holes
This problem appears to be on it's way to a happy ending. We will be  
able to address our security issues *and* continue to support items  
in multiple collections in a first class way on the server, which in  
turn means that the web UI and future web widgets will handle this  
case elegantly as well :D http://lists.osafoundation.org/pipermail/ 
cosmo-dev/2008-February/005696.html

4. On the current web UI and related issues like keeping OOTB  
collections in sync between Hub and Desktop

We've gone back and forth on this issue. I am of the mind currently  
that we should NOT disable the current web UI. We believe there is a  
healthy number of people happily using it as a standalone web app  
today. (Although, we don't have good visibility in how they're using  
it and what they're using it for.)

More importantly however, it is an absolutely critical piece of the  
collaboration scenarios we want / need to support in order for the  
Chandler Ecosystem as a whole to function well.

In particular the 'ticketed view' is essential for sharing worklows.

That being said, I'm not confidant that we can get away with leaving  
the web UI as is. I am working on a proposal that hopefully isolates  
half a dozen or so usability issues that need to addressed to:

1. Set expectations for how the web UI can be useful for new users  
coming to Chandler Project.

2. Help casual collaborators complete the subscribe workflow. (I  
believe that users are currently falling off the band-wagon when they  
get to the ticketed view because it's not blatantly obvious how you  
go about getting the shared collection into your iCal or Chandler  
Desktop).

2. Reduce the number of concepts Desktop users need to understand in  
order to start sharing and/or use the web UI for remote access  
scenarios.

I will be sending a proposal to the list shortly.

Mimi








-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20080212/23597b07/attachment.htm