[Design] [Sum] Nov 6-12th

[Sheila Mooney]

New Threads:

Mimi sent out a proposal that we simplify the manage share dialog and  
NOT allow users to share partial collections (only tasks, no events  
or mail). We have found a bunch of bugs with this and it was  
introduces mainly to allow us to focus on just calendar back in 0.6.  
We don't really need it now.
+ There were a number of +1s associated with this proposal. Mimi  
followed up with a Last Call on this proposal.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005638.html

Katie forwarded a mail with some concern over the lengthy discussion  
around offline mode for email "is offline mode feature creep?". She  
had a good point and as detailed in a previous summary we have  
decided to table and work on an end user solution for offline mode  
until after 0.7. We accomplished our goal and adding in the  
capability for devs to turn this off for testing purposes.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005643.html

Katie took the offline email thread a step further and asked if we  
should consider proxy support in Preview.
+ As of yet, there are no responses/comments on this.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005649.html

Mimi forwarded a link to a page she started to keep track of  
brainstorming Cosmo UI elements we think we want for Preview. She  
wants people to add questions, comments etc. The plan is to review  
this with Matthew at some point in the near future.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005654.html
She followed this up with a subsequent reply explaining our goals  
with this list.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005655.html

Sheila finally got around to updating the 0.7 planning page and all  
the subsequent milestone detail plans.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005656.html

Mimi forwarded some detail about an update to the dashboard spec.
+ She wanted to clarify that when updates happen only the people in  
the addressing fields receive the item at the top of their dashboard  
(along with the notification). Other sharers just get the new item  
and will see it's change. It's about only notifying those who really  
need it.
+ Although this is the desired behavior, to keep it simple for  
Preview we can certainly live with EVERYONE getting the update.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005657.html

Dan posted an email asking what it meant to "never share" an item  
after it's been shared.
+ It seems as if there is a bug and this is not working properly.  
When you make an item "never share" you are removing it from the  
share entirely and any changes are just local.
+ It might be easier just to have the "never share" option before you  
actually share the collection.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005660.html

Mimi sent a bare minimum proposal for Preview casual collaborator UI  
to the list. The Cosmo team thought it looked good and had only some  
minor questions/clarifications.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005658.html

Sheila sent out a link to a wiki page with very old Calendar dogfood  
bugs. We had initially been keeping track of all dogfood feedback in  
this page and prioritizing all the items for a particular milestone.  
To date we have fixed all bug a handful of the high priority items.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005666.html

Brian Kirsch forwarded a discussion that was happening in bug 6857 to  
the list about In Out collection logic proposal refinements. In and  
Out collections should compute their contents based on the sender or  
recipient of an email, not the isOutbound attribute but this gets  
into a few tricky design issues which Brian brought up.
+ Brian basically summarized how he will determine whether an item is  
in the IN collection vs the OUT collection.
+ He brought up some good questions about what happens when the user  
tries to create or delete items in these collections. There were  
suggestions to make them read only.
+ Mimi proposed hiding them for Preview to avoid dealing with the  
thorny design problems that Brian outlined. We still need all the  
logic for displaying the right In/Out communication affordances in  
the table.
+ Brian didn't think that was necessary and convinced Mimi to  
reconsider. She doesn't want to restrict them to be read only.
+ We decided to compute the In/Out-ness based on Brian's proposal as  
well as allow users to create items, delete, dnd to those collections  
for Preview. We don't need to worry about all the details, instead we  
will wait to see how people will use them.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005668.html

Continued Threads:

The discussion continued around the Cosmo login-related workflows for  
0.6. Most of the issues around the spec have been worked out and  
further discussion really centers around 2 issues (which should have  
been separate threads.
+ The user experience for the home collection browser feature.
+ Timezones (next summary).
This feature will be used by users interested in file sharing. The  
subsequent threads in this discussion really explore whether or not  
there are really 3 different types of users - casual collaboration,  
admin, file sharing user and how we access the appropriate UI  
elements. Are these the same people? Is there overlap in the features  
they will want access to.
+ The developers feel that this feature is important and has to be  
accessible to all users. Ted pointed out that it's useful for users  
to help debug problems.
+ The design team feels that the file sharing user and the casual  
collaborator are 2 different types of users and would like to add a  
link to the file browser in a settings UI OR have the user make a  
choice when they login somehow (login as admin, login as file  
sharer). We don't feel it belongs as a link on the main casual  
collaborator UI.
+ We explored the idea of having sub domains for each type of user  
but that's not something we can do. ie:osaf.us/cosmo or admin.osaf.us/ 
cosmo.
+ We could separate out the repository browsing UI into a separate  
web app integrated into snarf but a couple of developers had some  
concerns about the work required to support this and if it's really  
necessary.
+ Another compromise that we could just have people go to cosmo/ 
admin, cosmo/pim, cosmo/filebrowser...something like that.
+ As of now we still don't have a resolution for this problem but  
should be the end of this week - Dec 1.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005627.html

The Cosmo login-related workflows also spawned a timezone related  
discussion since that functionality has been spec'd out for Cosmo 0.6.
  login-related workflows
+ Mimi had a few questions for Priscilla based on the spec. Priscilla  
implied that the sharee sees the calendar in whatever timezone the  
sharer published it in, we don't store that information currently.  
Also, how does the user's default timezone get set?Do we by default  
start out with floating timezones like Chandler?
+ Whether or not users see timezone information depends on whether or  
not timezones are turned on. If you view a calendar without logging  
in, you do not see the timezone information.
+ After a bit of back and forth is seems like Cosmo will simply  
handle timezones the way we do in Chandler. It's a setting that users  
have to turn on.

Other Stuff:

Priscilla forwarded her Chandler dogfooding feedback for November.
+ Something Priscilla brought up was the notion of recurring tasks.  
Grant responded with some ideas about how to implement this.
+ Subsequent replies validated that others would find this feature  
useful as well.
http://lists.osafoundation.org/pipermail/design/2006-November/ 
005635.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20061126/4501ebdb/attachment.htm