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