[Design] [Proposal] Unified Activity Log UI

[Mimi Yin]

Assumption: We have a "collection" in the "sidebar" or some "sandbox"  
area in the sidebar that is a unified Activity log.

What might quality as an Activity?
+ User creates a new item
+ User edits an item (1 log item per attribute changed? or per item  
editing session? How do we define item editing session?)
+ Sharee creates new item
+ Sharee edits item
+ Conflict on an item
+ Subscribe and Publish
+ Pull down mail, Send mail
+ Sync status for Email and Sharing (Do we have a single Activity  
item that summarizes the entire Sync session? And then individual  
Activity items for each individual edit?)

High-level categories of Chandler activities:
+ Sharing / Email / Personal activity
+ New item / Edits / Conflicts / Reminders
+ Activities for each collection OR each Collection/App area  
intersection (ie. What's changed on my OSAF calendar?)

Interaction ideas:
+ 1 collection that unifies all Activities into a single view.  
Activities can be sorted by the Categories listed above. (ie. Show me  
notices for "New items". Show me stuff that I did versus stuff the  
server did, etc..) OR
+ Several collections that divide up the Activities into different  
Categories (ie. Sharing activities, Email activities, Local activities)

+ Super status bar where Activity log messages scroll by. Click on  
the message in the status bar to go look at it in the Activity log.  
OR The Status bar expands itself to turn into the Activity manager  
(not in 0.7).
+ Can we have a link to the item-in-question in the detail view of  
the Activity log item (ie. Lunch with David was moved from noon to  
1PM...Click here to go to this event on your calendar.)

Open Issues:
+ When are Activity items marked as read?
+ How long do Activity items live in your repository?
+ Can users manually delete Activity log items?

Mimi

On Feb 1, 2006, at 6:21 AM, Morgen Sagen wrote:

>
> On Jan 31, 2006, at 9:26 PM, Davor Cubranic wrote:
>
>> Morgen Sagen wrote:
>>
>>> (B) User Notifications: [...] Mitch proposed the idea of  having  
>>> a sidebar collection which acts much like an RSS feed of   
>>> changes.  We could add a new Kind to the domain model named   
>>> "UserNotification" (or some name to distinguish it from any  
>>> internal  notifications). Changes made in the background during  
>>> syncing would  get a corresponding UserNotification item added to  
>>> the Changes  collection.
>>
>> Kind of like Emacs's "*Messages*" buffer? Neat.
>
> Not being an Emacs user I went to go look up [1] what you were  
> talking about.  Apparently Emacs has an "echo area" where messages  
> appear briefly, and those messages are appended to a buffer that  
> stores some (configurable) number of past messages.  Tying this in  
> with Philippe's comment about having these notifications reviewable  
> in a specific panel/drawer got me thinking about a super-status bar  
> at the bottom of the application: in normal mode the status bar  
> would simply display the latest notification; a toggle button could  
> turn that single text box into a scrolling list box which would let  
> you review previous messages.
>
>> But I hope what the user sees will be a friendlier name than  
>> "UserNotification".
>
> The term "UserNotification" is just an internal name in the domain  
> model.
>
> ~morgen
>
> [1] http://www.sunsite.ualberta.ca/Documentation/Gnu/emacs-20.7/ 
> html_chapter/emacs_4.html#SEC8
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060206/ffe09aac/attachment.html