Once again..a bit behind on the list summaries....
New Threads:
Mimi forwarded the summary from a bugzilla conversation on UI changes
to the Accounts dialog. Much of the discussion was around how to
manage testing the various email accounts and when to actually create
the special IMAP folders. Mimi and Brian closed on the following
proposal.
+ Create IMAP folders on the server as soon as users check the IMAP
folder option in the Accounts dialog.
+ Keep the separate [Test] button in case users want to re-test.
Checking option one also tests the account and will return an error
if they are not setup properly.
http://lists.osafoundation.org/pipermail/design/2007-January/006119.html
Mimi forwarded a discussion to the list that was happening in
bugzilla concerning the work item Prompt to turn on timezones BEFORE
subscription.
http://lists.osafoundation.org/pipermail/design/2007-January/006124.html
+ We are currently planning on prompting users in Chandler after they
subscribe to calendars with timezoned events so we can check in the
calendar in question contains timezone information. By waiting to
check until after users subscribe we are incurring a big performance
hit.
+ The solution is to only popup the dialog once before the very first
subscribe with an optional - don't show this again checkbox.
Davor logged a bug/enhancement for "Today's events" shown when the
Calendar app area is active.
http://lists.osafoundation.org/pipermail/design/2007-January/006128.html
+ Davor argues that since you can stamp tasks as events it would be
useful to show today's tasks in the list when you are in the task app
area - make it work like the calendar.
+ Mimi explained that when we designed the mimi cal it made sense
that when you were in the calendar you would only see "today's
events" since you could navigate easily to individual days or weeks.
+ When you are in the dashboard, you will see the events for whatever
day you happen to have selected in the mini cal.
+ We don't show this in the tasks and mail areas since we don't think
the users will spend as much time here.
+ We have subsequently decided to put a label on the preview area in
"non-calendar" app areas, so it's clear what we are displaying.
+ Any more work on this bug has been punted to future - until we get
some further dogfood feedback.
Mimi started a thread to discuss the latest No Data Loss Proposal,
nee Conflict Resolution Proposal.
http://lists.osafoundation.org/pipermail/design/2007-January/006129.html
+ Based on next actions from a meeting, we have simplified the
conflict resolution proposal to focus on the preview goal for "no
data loss". Mimi has detailed the workflows in the following wiki
page. http://wiki.osafoundation.org/Journal/NoDataLossProposal.
+ PJE pointed out that if we list out a bunch of changes, we really
don't know when and in what order the changes occurred for each
collaborator - sync, update mail sent etc. If the last change is a
deletion, that would be the final outcome if the user decides to
apply the change. He argues that it might make more sense for us to
have individual accept/reject options for each change.
+ If we can't do that, we should drop "apply changes" since it's not
clear what it means - the user might not get any of the changes and
only have the item deleted in the end.
+ Mimi feels that as long we list out the conflicts in order it isn't
misleading to users. If delete is the last one, they won't be
surprised if the item is just gone. Giving them more detail is
probably not necessary for the primary preview use cases.
+ Based on email feedback, Mimi has updated the proposal of record -
http://wiki.osafoundation.org/Journal/NoDataLossProposal#WorkflowTwo
+ PJE seems happy with the current proposal but still had some
comments on the wording of the notification regarding the number of
pending changes/conflicts. After some back and forth emails, Mimi and
PJE agreed on a wording.
Philippe uncovered a a Bugzilla hickup problem that is causing
multiple bugs to be created. He was able to re-create this and it has
something to do with using the browser features to navigate between
bugs. A way to avoid this is to use the links provided by the
bugzilla interface itself rather than the browser.
http://lists.osafoundation.org/pipermail/design/2007-January/006140.html
Sheila sent out a summary for the latest plan to migrate data between
Chandler releases. There have been no direct responses to the email
but we will hold a follow-up discussion in mid-Feb.
http://lists.osafoundation.org/pipermail/design/2007-January/006146.html
MDE sent out a summary of all the error messages we use in Cosmo.
Mimi replied with a bunch of suggested changes and specific questions
about stuff like date formats and what buttons are available on each
error dialog, the goal being to make these more consistent and self-
explanatory.
http://lists.osafoundation.org/pipermail/design/2007-January/006152.html
Jeffrey put together a summary of all the latest changes we have made
to recurrence that have been checked in - Recurrence, triage status
and the dashboard.
http://lists.osafoundation.org/pipermail/design/2007-January/006159.html
+ There is a follow-up design session to address some of the
outstanding issues - this will be in next week's summary.
Continued Discussions:
BCM replied to Priscilla's email about changes to the OSAF bundle
front page.
http://lists.osafoundation.org/pipermail/design/2007-January/006123.html
+ He suggested a separate page with instructions for administrators
setting up cosmo for the first time
+ Guiding the admin through a workflow to login and change the password.
Katie responded to the Dogfoodable flag email.
http://lists.osafoundation.org/pipermail/design/2007-January/006126.html
+ Katie agreed that the dogfoodable flag should only be used for
items that blocking users from dogfooding and that they should be
examined against other priorities due to the short-term payoff to fix
them.
+ After some subsequent emails we determined that using the severity
field might be a more appropriate tagging mechanism.
Some further discussions on the thread - Who's Triage Status is it
anyway?
http://lists.osafoundation.org/pipermail/design/2007-January/006133.html
+ Mimi clarified that when she added some use cases to the discussion
to include errors/updates (and how these change to NOW), this also
follows the same behavior when the user clicks the Triage button (to
resort so that color matches section).
Mimi responded to Hank's email requesting the ability to view by
creation/modification date.
http://lists.osafoundation.org/pipermail/design/2007-January/006136.html
+ Mimi clarified that we currently have no UI to sort and resort the
sidebar collections in different ways but likely post-preview we will
have the ability to reorder those collections explicitly.
+ Hank followed up with an example use case where he would use such a
feature. He also clarified that we was NOT referring to the sidebar
and simply the ability to see which tasks, events, items etc had been
created recently.
+ Mimi also clarified that you will have the ability to sort on date
to accomplish what he is describing and sent out Bryan Stearns date
column write-up since there are a few snags with alarms etc.
+ Davor asked if there was a way to add a column to the summary table
for a user-specified column.
+ John replied that it would be reasonably easy to implement but this
has come up before and was deferred to post-preview.
Philippe responded to Davor inquiry about integrating the address
book feature (our SoC student worked on) into Chandler. We have
deferred this until post-preview.
http://lists.osafoundation.org/pipermail/design/2007-January/006155.html
+ Although we have not finalized the design, we have certainly
discussed this before. Mimi responded with a lengthy write-up and
list of wiki links pointing to previous design discussions/thoughts.
http://lists.osafoundation.org/pipermail/design/2007-January/006163.html
Other Stuff:
We held a design session to review the Cosmo style guide.
http://lists.osafoundation.org/pipermail/design/2007-January/006121.html
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
