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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
