Slowly catching up on the design list summaries...
New Threads:
Jeffrey posted a thread about Chandler Remove Behavior. Jeffrey has
been working on a number of remove bugs and ran into some ambiguity
with the design. http://lists.osafoundation.org/pipermail/design/2006-
December/006010.html
+ Specifically, Jeffrey had a question about the behavior of Delete
when you select an item in the Dashboard. We only allow delete when
an item is in the dashboard and also in another mine collection. We
don't allow users to remove the item from the Dashboard and leave it
in the mine collection. Jeffrey suggests that we could pop up a
dialog explaining that removing from the dashboard really deletes the
item and giving the user the ability to cancel.
+ He asked a second question - about what it meant to remove items
from other out of the box collections like In/Out
+ Mimi replied indicating that some tweaks to the wording in the
popup dialogs is a good idea. She made some suggestions including one
for the new popup that Jeffrey suggested.
+ She said that deleting from In/Out should be treated the same way
as deleting from any user-defined Mine collection.
+ Davor replied that he sometimes has items he wants to show up in
other collections but not in the dashboard. Mimi replied asking for
specific examples.
http://lists.osafoundation.org/pipermail/design/2007-January/006022.html
+ Some of the items in Davor's list are bugs we know about and will
get fixed in Alpha5. Other things fell of the list for Preview or
there is some associated work around.
Jared started a thread about other people's alarm's on shared
calendars. He has subscribed to several calendars and has found that
having other people's alarms popup is a bit iritating.
+ It was first thought that this might be a bug. The sharer has to
explicitly share the alarms on the collection.
+ We verified and there isn't a bug.
+ We are missing however, the ability to opt out of the alarms when
you subscribe to a share (even if the sharer has shared them). Morgen
will be implementing this as part of the new sharing work.
http://lists.osafoundation.org/pipermail/design/2006-December/
006011.html
Priscilla sent out a link to the latest Cosmo 0.6 spec.
+ Mimi replied with quite a bit of specific feedback. Priscilla plans
to update the spec and walk-through a formal review with the team.
http://lists.osafoundation.org/pipermail/design/2006-December/
006013.html
Bobby posted a question about something in the Cosmo 0.6 spec.
Specifically, he was asking about the Collection Detail (and other)
Help Pages. There is a section of the spec that makes reference to
help links but didn't specify where these were. Bobby wanted to know
exactly what we were linking to.
+ Priscilla: using Chandler as an example, we have a help menu that
points to a FAQ. She was suggesting something similar for Cosmo for
Preview.
+ BCM: Thinks we should have a bit more information - have it link to
a help portal with FAQs, end-user and admin documentation and other
stuff.
+ Bobby thinks that the URL we point to should have some version
number so the user can make sure they are getting directed to the
help docs for a particular version.
+ Jared replied with some alternatives we could use but overall this
didn't seem like an issue.
+ Decision: For 0.6 we will use a placeholder message and link that
just redirects to some wiki pages. In the meantime, we will figure
out what kind of help hierarchy we want to have for preview.
Priscilla currently has a task to work on this.
http://lists.osafoundation.org/pipermail/design/2007-January/006026.html
Mimi started a new thread titled Collection Browser? that basically
asked what we should call this thing we were referring to as "Home
Directory Browser". She cut and pasted in some dialog from an IRC
discussion. Some suggestions that came up
+ Account browser
+ Database browser
+ BCM took a crack at listing all the things this browser could do to
see if that helped with naming ideas.
http://lists.osafoundation.org/pipermail/design/2007-January/006031.html
Priscilla sent out a proposal for the Advanced features in Settings
Dialog. This area provides access to the admin and file browsing UIs.
http://lists.osafoundation.org/pipermail/design/2007-January/006033.html
Priscilla sent out a list of updates to the Cosmo 0.6 spec.
http://lists.osafoundation.org/pipermail/design/2007-January/006036.html
Travis started a Cosmo design thread titled Account activation redux.
He wanted some design input on the account activation workflow.
Specifically which step in the workflow, should the actual activation
occur.
+ Basically, when the user signs up for an account, they will receive
an activation email with a link. Clicking on this link brings up a
page and the user clicks on activate account. The user then gets
redirected to the login page.
+ Priscilla and Mimi then asked about some future post-preview
functionality. Specifically if the user is trying to subscribe to a
collection and goes through the sign-up workflows clicking the
activation link automatically logs you in and defaults to this
collection. They aren't subscribing there is some blank collection.
+ There were some concerns about this "empty" cosmo collection.
+ Mimi followed up with a list of the Preview workflows that would
justify having an OOTB collection on Cosmo.
+ The decision was to stick with the plan of record for 0.6 and
revisit this issue after that release.
http://lists.osafoundation.org/pipermail/design/2007-January/006039.html
Mimi sent out a proposal for the Cosmo 0.6 signup worklfows.
http://lists.osafoundation.org/pipermail/design/2007-January/006053.html
Vinu is working on User Interface for Group management in Cosmo and
was looking for some input on the design. He summarize the
requirements and the basic functionality.
http://lists.osafoundation.org/pipermail/design/2007-January/006056.html
Continued Discussions:
Discussion continued around the specifics of the read-only ness in
the Cosmo UI. Priscilla suggested that instead of disabling the
Remove and Save buttons, that we don't have them appear at all.
+ Matthew thought removing the buttons might appear like a bug. He
suggested a pop-up when try to edit the form fields.
Philippe replied to Mimi's email proposal for the Conflict Resolution
UI. He has concerns about the complexity and edge cases, as well as
the amount of UI work that's required. He is questioning whether or
not we can really find a solution that doesn't involve real versioning.
+ Mimi responded with some clarifications and answers to Philippe's
questions.
+ Current Status: We are still iterating on the design and
implementation details but confident that we are close to a solution
that is doable for Preview and meets the fundamental requirements for
no data loss.
http://lists.osafoundation.org/pipermail/design/2007-January/006035.html
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
