[Design] [Sum] Dec 9-24

[Sheila Mooney]

The design summary for the last couple of weeks.

New Threads:

A new Cosmo thread Subscribe/download .ics 'teaser' was started  
summarizing the behavior in the Cosmo UI for both downloading and ics  
file as well as directly subscribing to a calendar using another  
calendar app. Since this was a very lengthy thread, I will simply  
summarize where we stand now and the issues rather than each  
argument. There was much debate and discussion around the naming and  
affordances for these 2 separate operations. There was also some  
discussion around what URLs we should be supporting/generating and  
displaying to users. We also got into the specifics for cutting and  
pasting a URL.
+ Priscilla and Mimi iterated on a few solutions and got a wide range  
of feedback.
+ Priscilla summarized the latest proposal in the following email.  
http://lists.osafoundation.org/pipermail/design/2006-December/ 
005983.html
+ If the user is NOT logged in (ticket view), there will be a drop- 
down of subscription options in the top right hand corner of the  
browser. Selecting any of these options, except for the download ics  
file one, will bring up the collections detail dialog with the option  
pre-selected in the list. We will not launch the desired app but  
display the URL and allow the user to copy and paste.
+ If the user is logged in, they click on the "i" next to the  
collection name to bring up the collection details dialog with the  
pulldown of subscription options. The remaining steps are the same as  
above.
+ If the user selects download ics file, either from the ticket view  
drop-down or the drop-down in the collection details dialog, simply  
downloads the ics file to the desktop.

Adam started a thread on the Cosmo username conventions. He indicated  
that we need to make a decision whether or not usernames are case  
sensitive and whether or not capitalization is preserved.
+ Jared responded that Cosmo is case sensitive. He also feels that  
users expect capitalization to be preserved. Things get complicated  
however because 2 users can have the same name with varying  
capitalization. We could add a check to fail if a different user has  
the same name but different capitalization.
+ The consensus is to go with Jared's proposal for Preview.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
005880.html

There is another thread titled Subscribe pulldown behavior that  
overlaps with the Subscribe/download.ics 'teaser' thread put  
addresses specifically how the pulldown of subscription options will  
work. Mimi sent out the original proposal.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
005955.html
+ After a number of comments, Priscilla sent out a last call summary.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
005984.html
+ There were some minor adjustments to the wording but everyone  
seemed to be on-board with the latest proposal.

BKirsch sent an email clarifying the behavior/design for the Chandler  
Custom IMAP Folder logic.
+ Brian wanted to clarify that if the message contained attachments  
that Chandler can proces, we stamp this accordingly regardless of the  
folder the user added it to ie: if we drag a mail to a task folder  
and it has an ics attachment, it's stamped as mail, task and event.
+ Mimi confirmed this is indeed the behavior.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
005993.html

+ Matthew posted about the Read-only-ness in the Cosmo UI. Since  
users will be able to click on read-only URLs we need to define how  
this will implemented in the UI.
+ The lozenge will be clickable and the same color and normal read- 
write lozenges.
+ The cursor changes
+ You can still edit the form elements but the Save and Remove  
buttons will be disabled. If we disable the form elements you can  
scroll to see all the text. We probably don't have time to deal with  
this more elegantly for Preview.
+ Priscilla suggested removing the Save and Remove buttons entirely.  
She also proposed a read-only message when the user tries to edit  
certain fields.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
005997.html

Matthew also posted a note about "Add to your account" and new  
account creation. This basically means, what happens when you click  
on the + (plus) sign next to your collection name. It prompts you to  
enter your account information or sends you to another dialog to  
create an account. Since we are using account activation emails, this  
creates a wrinkle in our workflow. The user won't be able to add the  
collection immediately when they create a new account, until the  
account is activated, which they have to do via the email. He is  
proposing...
+ Allow people to subscribe before the account is activated.
+ Force users to activate the account from the email, then go back  
and redo the steps to add the subscription to their account.
+ There was only one response to the post so far, BCM didn't see any  
security issues really.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
006001.html

Mimi sent out a proposal for a conflict resolution UI.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
006003.html
+ Mitch replied with some thoughts on how he thinks conflicts should  
be handled in Chandler. He was concerned about both data loss and  
handling conflicts as errors (they aren't the same).
+ Mimi replied with a summary of necessary information in order to  
determine how to handle the conflict appropriately.
+ PJE had some concerns about using the notes fields to display  
conflicting information.
+ Mimi send a subsequent email with visual mockups for the conflict  
resolution UI. http://lists.osafoundation.org/pipermail/design/2006- 
December/006007.html

Continued Discussions:

Further discussions continued around the "Add to iCal" thread. There  
was some confusing around the meaning of the current icon. Several  
people didn't realize it meant "subscribe to this calendar using  
Apple iCal". It led to a whole other conversation about what clients  
and formats we should support.
+ Priscilla and Mimi made the decision that for Preview we should  
focus on supporting Apple iCal in a first class way. Clicking on this  
link would then mean that we subscribe to the calendar with Apple iCal.
+ Power users may realize they can use the same URL can be used to  
subscribe with CALDAV clients for other but we will not add links on  
the main page for all these clients.
+ We are going to add another option for downloading both tasks and  
events as an ics file.
+ There seems to be consensus on the team that handling the link for  
downloading to a ics is very easy and should be added to Cosmo Preview.
+ Vinu sent some links that discuss the guidelines around some of  
those small icons.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
005896.html
+ The decision for Preview however is not NOT have icons. We will  
simply have text and will address this issue again Post-Preview.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
005944.html

Jared responded to an old thread about the Cosmo login-related  
workflows. He basically provided some feedback on the proposal  
Priscilla had sent out for Cosmo 0.6 UI work.
+ We should remove "it's free" from the login page. Other people  
running Cosmo won't necessarily have a free service.
+ In relation to the above thread, he found the links for subscribing  
using other clients confusing.
+ He weighed in on the issue around access to the admin and file  
browser features. He doesn't feel we need direct access to these from  
the login page.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
005897.html

Mimi replied to the lengthy timezone on Cosmo UI thread. She  
basically outlined 2 proposals for addressing the confusion when  
sharers publish calendars that may or may not have timezone info and  
reconciling this with what users see when they subscribe. Floating  
timezones lead to some weird situations.
+ Proposal #1: When users who don't have timezone support turned on  
subscribe to shares that have timezone information, we will prompt  
them visually in the UI. This behavior will be the same for Cosmo  
users (with or without and account), as well as other Chandler users.
+ Proposal #2: The first time a person subscribes or views a share,  
they somehow inherit the timezone that the sharer was using to view  
this share when they published it. This is not necessary for Preview  
and should only be considered if it's really trivial to implement.
+ We are proposing that we will handle #1 for Preview only.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
005904.html

Comments on Mimi's proposal for the alternate way to access homedir  
browser intersected with the timezone discussion. It introduced the  
issue when users turn of timezones in one app (ie: Cosmo) and  
timezone support isn't automatically turned on in Chandler. This  
started a discussion about how to keep timezones in sync between  
Chandler and Cosmo.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
005918.html
+ Specifically Mimi is worried about the case, where I turn on  
timezones in Cosmo (PST) but don't in Chandler (floating). I then  
share the calendar and the sharee is looking at EST.
+ We are really more worried about the case when users don't have  
timezones turned on.
+ This is really not our target use case for Preview - Chandler users  
also using Cosmo.
+ The timezone prompt when you describe will help address this issue.

Other Stuff:

Philippe sent out a link to Wrike, another web organizer.
http://lists.osafoundation.org/pipermail/design/2006-December/ 
005928.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20061229/7c19776d/attachment.htm