For the past month, we've been batting around ideas for new modular
web widgets. We've already started a 'pilot' widget for quick entry
as a proof of concept. In the meantime, I think it'd be good to back
up a level and think about our web strategy as a whole. In particular:
1. What web widgets will provide our users and the project the most
value?
2. What role does the server play? How much 'Chandler-semantics' and
'Chandler-logic' does the server support / understand? What does it
understand today? Going forward, does it need to understand more /
less given the web widgets we want to build?
3. How does the current web UI fit into this new Chandler ecosystem?
At the end of the day, I think we're optimizing for delivering the
most amount of useful web functionality in the least amount of time.
To do that effectively, we need a better understanding of what
functionality would be useful and how what we have today is capable
of supporting that functionality.
===
I. WIDGET IDEAS:
+ Quick entry (Already on the list.)
+ Single editable detail view
+ Mini-cal + Preview pane
More ambitious ideas:
+ Search box + Results list + Preview detail view + Editable detail view
+ Single collection Dashboard list + Preview detail view + Editable
detail view
+ Multiple calendars + Week view + Overlays
+ Whole enchilada widget
- Pulldown to navigate between and overlay multiple collections
- Jump-to field with pop-up mini-cal for quick navigation to a future
date
- Both List and Calendar views
- Preview detail view
- Editable detail view
Notifications via IM/SMS/Email
+ Fetch individual items
+ Get report on 'items that have popped into NOW' (per collection)
+ Get report on all NOW items (per collection)
Stuff that showcases sharing:
+ Rolling account history - who's doing what in which collections,
when with clickable links to individual items and collections
+ List of Hub contacts + pictures
+ Poke a subscriber - some way to 'notify' another subscriber about a
particular item / collection
II. LIST OF QUESTIONS RE: WHAT SERVER/WEB APP SUPPORT TODAY
1. What are the biggest data integrity issues? When will people see
inconsistent data between desktop / web app / web widgets? I don't
think we need 100% data integrity across all Chandler access points,
but depending on what web widgets we build, the design will require
different degrees of data integrity.
More specifically, can we maintain consistency wrt the following
Chandler behaviors?
+ When shared items pop to NOW because they were newly created or
edited by a subscriber
+ Auto-triaging to NOW based on event date and alarm date?
+ Manual override of triage status
+ Byline
+ Read/Unread status
Less important behaviors to 'get right' across Chandler access points
+ What appears in Who / Date columns
+ Knowledge about items living in multiple collections
+ Triage Status ordering?
I know there are also issues wrt recurrence and time zones, but I
don't understand them well enough to formulate specific questions.
But again, I'm most interested in preserving data integrity across
access points.
2. Can we link to individual items? Do we need to be able to do that
to do the detail view widgets? What if you want to share individual
detail views? Is that different from accessing a detail view you
created or subscribed to in a shared collection?
3. What happens if we sync ALL Desktop collections to the Hub? How
will the OOTB (Dashboard, In, Out, Trash) collections interact with
the OOTB HUb collection? Will the server /web app/web widgets
understand about how adding items to 'MINE' collections automatically
adds the same item to the OOTB collections? What about deleting items
and putting them in the Trash collection?
4. How hard is it to get the 'behavior model' right for sharing read-
only and read-write items and collections? From the cosmo channel
conversation we had today, it seems like it'd be a lot of work.
http://chandlerproject.org/script/getIrcTranscript.cgi?
channel=cosmo&date=20080205&startTime=1411
The 3 design requirements I was finally able to articulate were:
+ Allow for individual items to have different permissions than the
collections they belong in
+ Understand when read-write access overrides read-only access and
vice versa on individual items
- If you create an item, you always have read-write access, even if
you receive it read-only later on
- If you receive an item read-write and read-only, you have read-
write access
- If you receive an item read-only and add it to a read-write
collection, you do *not* gain read-write access
+ Silo items that are published to server without explicit read-write
or read-only access as copies stored in a separate collection
III. HOW DOES THE CURRENT WEB UI FIT INTO OUR NEW ECOSYSTEM?
What do we do with current web UI?
+ Keep it around for existing users
+ Do we stop directing new users to the current web UI? (i.e. Remove
the Log in link from the account confirmation page?)
+ Do we port the current codebase to Dojo 1.0?
+ Do we continue to maintain it? (i.e. The task stamp on the Desktop
is now going to be a star stamp. Do we update the web app to reflect
that change?)
+ At what point do we offer up a an alternative web widget UI and/or
a gallery of web widgets when users log in instead of the current web
app?
Another way I've been thinking about the web strategy is: What needs
to be consistent with what?
+ Web widgets + Desktop?
+ Web widgets + Web App?
+ Web App + Desktop?
+ Server and all of the above?
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
