New Threads:
Mimi sent out a list/inventory of End-user documentation that we need
for Preview. We need to compile the complete list so we can schedule
enough time to write this and start assigning owners to work on it.
She wanted to know if there were big content items people thought
were unnecessary or missing.
http://lists.osafoundation.org/pipermail/design/2007-February/
006337.html
We held a design session for dump and reload, identify issues and a
set of tasks and owners.
http://lists.osafoundation.org/pipermail/design/2007-February/
006345.html
+ The notes from the meeting http://lists.osafoundation.org/pipermail/
design/2007-February/006380.html
+ Katie put together a set of tasks and owners which was sent to the
dev list. http://lists.osafoundation.org/pipermail/chandler-dev/2007-
February/007704.html
Pieter sent out a Cosmo enhancement request regarding time out
tickets. This involves a better UI for specifying time-out dates via
Cosmo and error handling for expired tickets.
http://lists.osafoundation.org/pipermail/design/2007-February/
006347.html
+ Since this wasn't really a primary workflow for Preview we have
logged in bugzilla and deferred to future. Chandler would also
require the same capabilities and in order to avoid feature creep and
new design projects we will pick this up post-preview.
Pieter follow-up with another suggestion for post-preview - need to
have a collection name inspector UI
http://lists.osafoundation.org/pipermail/design/2007-February/
006348.html
+ Basically it's a way to figure out who a share came from and what
the original name was since we give users the ability to change the
collection display name in the UI. If you have many calendars you
might want to access this information.
+ This has been logged in bugzilla and deferred to post-preview.
Mimi forwarded a Chandler dev thread to the list with Andi's proposal
for handling Chandler plugins.
http://lists.osafoundation.org/pipermail/design/2007-February/
006352.html
+ One issue is that when users install plugins, there may be data
loss and we will have to warn them, both when they install them and
when they uninstall.
Jeffrey posted a question about how to identify Who modified this item?
http://lists.osafoundation.org/pipermail/design/2007-February/
006357.html
+ For example, if the user has several email addresses set up and
they change a shared item, which email is used for the lastModifiedBy
and should there by a way to change this?
+ The suggested solution is a pulldown to handle this
Mimi made some updates to the stamping spec, particularly around edit/
update details - Updates to Stamping, aka Edit/Update Spec
http://lists.osafoundation.org/pipermail/design/2007-February/
006363.html
+ There was a bunch of back and forth discussions between Bryan
Stearns and Mimi to clarify the details. All of this has been
captured in the spec.
+ There was a secondary discussion around the edit/update use cases
for messages and it was decided that we would have to include an EIML
attachment for every Chandler message.
Sheila posted some formalized CalDAV tenets for Preview.
http://lists.osafoundation.org/pipermail/design/2007-February/
006371.html
Jeffrey posted a conversation from the dev list - Interesting idea to
avoid EIM conflicts
http://lists.osafoundation.org/pipermail/design/2007-February/
006366.html
+ Basically the discussion started to get into the specifics about
when the byline field gets updated and he felt the proposal might not
be in line with the design requirements.
+ After some back and forth we closed on a plan for Preview
+ Whenever the user makes a change to an item in the detail view or
the calendar view the lastModifiedBy gets set to the users' email
address and the byline changes to "edited by me on..."
+ If a change comes in via sharing or by edit/update email the
update will contain a lastModifiedBy email and modified time.
Regardless of whether or not the user has applied changes (if there
is a conflict), the byline is changed to show the lastModifiedBy
email and the time ONLY if the time is more recent than the item's
current lastModified time.
Mimi sent out a list for the Dump and Reload - Inventory - all the
settings and data we think we need to be able to preserve when a user
upgrades.
http://lists.osafoundation.org/pipermail/design/2007-February/
006386.html
+ Grant suggested several additional items - timezones, use sections,
visible hours
+ John added some additional info necessary to display items and
collections in the UI
Philippe sent out a proposal that we disable printing for Preview
since there are so many bugs that it's basically unusable.
http://lists.osafoundation.org/pipermail/design/2007-February/
006395.html
+ Mimi and Sheila follow-up up with a +1. Potentially we can get
users to help us with this.
Morgen sent out a link to the Dump/Reload Project Wiki where we are
compling all this info.
http://lists.osafoundation.org/pipermail/design/2007-February/
006402.html
Mimi forwarded a bugzilla conversation to the list - Chandler as an
IMAP server.
http://lists.osafoundation.org/pipermail/design/2007-February/
006406.html
+ Mimi wondered how much work is required to add this to the demo
menu with some explanation and setup the special Mail, Tasks and
Events folders.
+ BKirsch confirmed that the folders would be the same with an
additional one for Inbox - required by IMAP RFC. We could add a
welcome and "how to" message in the inbox.
Mimi forwarded another bug discussion to the list since we are
exploring design options - account setup information in signup dialog
possibly incorrect or in need of reorganization
http://lists.osafoundation.org/pipermail/design/2007-February/
006413.html
+ Different types of users will be coming to setup an account and
some of the info might be confusing to them.
+ After some clarifications between BCM about the requirements, Mimi
is going to follow-up with some visuals
Mimi updated the email spec and send a summary of the changes for
feedback.
http://lists.osafoundation.org/pipermail/design/2007-February/
006420.html
As part of the email spec updates, Mimi ran into some issues with
Forwarding Chandler Items around.
http://lists.osafoundation.org/pipermail/design/2007-February/
006421.html
Continued Discussions:
Mimi received some comments on the updated dashboard spec.
http://lists.osafoundation.org/pipermail/design/2007-February/
006316.html
+ This discussion was very lengthy and was mostly around clarifying
language and specific details. Mimi has since made a number of edits
to the spec based on all the feedback. See the dashboard spec for
more details.
http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/
Dashboard-0.7.html
Mimi replied to BCMs email about default attribute values for items
created by cosmo.
http://lists.osafoundation.org/pipermail/design/2007-February/
006326.html
+ Some decisions we made to deal with events and other items created
in Cosmo...
+ If you upload some file type ie: spreadsheet that Chandler doesn't
recognize, we just ignore this for now. This info doesn't get synched
to Chandler.
+ When an event gets added via Cosmo we handle some sort of auto-
triaging to NOW and will also set the last modified, created by,
edited by information.
+ In the case of anonymous users we can give them fields where they
can specify a name. If the user is logged in we can use the email
address but if they have email and sharing accounts (with an email
that is different) we would have to pick one.
+ There will be one case where the user can be anonymous but they
don't get the fields to specify this or don't want to. In this case
we just display "anonymous" in the by-line.
Discussion continued on the Hyperlinks in UI.
http://lists.osafoundation.org/pipermail/design/2007-February/
006356.html
+ To summarize the proposal...
+ tooltips to expose URL on links in the accounts dialog
+ continue to track accessibility issues in bugzilla for future
releases.
Some final thoughts on the dialog.CenterOnSCreen()
http://lists.osafoundation.org/pipermail/design/2007-February/
006358.html
+ Mimi reposted her previous question - what would happen if we
centered dialogs on the Chandler window, if the window is docked?
+ We will not center the dialogs and use CenterOnParent in most cases
ie: account preferences
+ In the case of the multiple restore dialogs, we can stagger those
so they don't obscure each other
Dan continued to ask some questions about Custom IMAP Folder logic.
http://lists.osafoundation.org/pipermail/design/2007-February/
006364.html
+ He clarified that if a message containing a .ics attachment is
dragged into the "Chandler Tasks" folder it would have mail, task and
event stamps.
Other Stuff:
Katie sent out a link to the Preview meeting notes from Feb 13th.
http://lists.osafoundation.org/pipermail/design/2007-February/
006329.html
Sheila sent out the weekly PPD meeting notes
http://lists.osafoundation.org/pipermail/design/2007-February/
006340.html
JP posted about Mylar and task-centered filtering
http://lists.osafoundation.org/pipermail/design/2007-February/
006423.html
+ JP had recently used the Elipse plugin Mylar and found it to be
useful - particularly the task filtering capabilities.
+ Davor is very familiar with this tool but didn't think it applied
to Chandler that well.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
