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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
