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

[Mimi Yin]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20080206/06735f40/attachment.htm