[Design] [Sum] May 29 - Jun 4

[Sheila Mooney]

New Design Discussions:

Mimi posted a new proposal for the lozenge design to address an  
oversight. In the current design, there is no way to distinguish from  
an All-day and 15 minute FYI events & @time and Anytime events.
	+ All-day FYI events and Anytime events look the same: dark border,  
white inside
	+ 15 minute FYI events and @time events look the same: dark border,  
white inside
The proposal for addressing this is....
	+ Use dashed lines from Tentative events, combine them with the  
white-fill FYI look for @Time and Anytime events.
http://lists.osafoundation.org/pipermail/design/2006-May/004780.html

Based on the stamping spec discussions, Mimi started another thread  
about how to determine the user's perspective when sharing.  
Perspective doesn't change the underlying data but does change how  
you see it. This is really about determining if I see items from
	+ My own perspective: Communications from me are outbound.  
Communications to me are inbound.
	+ From the sharer's perspective: Communication from them are  
outbound. Communications to them are inbound.
	+ From a group perspective: Communications are inbound if they are  
TO: the group. Communications are outbound if they are not TO: the  
group.
	+ From a neutral perspective: No notion of inbound or outbound.
http://lists.osafoundation.org/pipermail/design/2006-May/004778.html

Priscilla posted some mock-ups for 0.2 Scooby visuals. She provided a  
mock-up for how Scooby will look in 0.2 and some potential visual  
directions we are exploring for later releases.
http://lists.osafoundation.org/pipermail/design/2006-June/004792.html

As a results of the dialog emerging about the stamping spec, Mimi  
posted a proposal for simplifying the Communication status and the  
Who column. This includes the full list of rules around what displays  
in the Who column given a specific context. Mimi also points out that  
sorting on Who doesn't make sense. We would more likely sort on a  
specific attribute ie: from, to, cc, bcc, updated by, editing by etc.
http://lists.osafoundation.org/pipermail/design/2006-June/004797.html

Mimi sent a proposal to the list questioning whether or not we needed  
traditional sort, particularly for the who column. Her point being  
that there are other ways ie: sections, filtering etc that would  
satisfy the basic sort use cases.
+ Jeffrey responded in favor of this but pointed out that behind the  
scenes we would still do this work, it would just imply a different  
interface design.
+ Ashkan pointed out that sort tends to be useful for some vague  
queries.
+ Dennis Lynch responded that sort is critical and outlined several  
detailed use cases.
+ Mimi responded and clarified that she wasn't proposing getting rid  
of sort but challenged it usefulness for some attributes like who and  
date and exposed some tradeoffs we would have to make since there is  
some significant implementation cost here.
http://lists.osafoundation.org/pipermail/design/2006-June/004799.html


Continued Threads:

Discussion continued around the stamping spec.
	+ Philippe responded that he didn't see the semantic different  
between receiving an item the first-time and receiving an update. The  
update could be a complete re-write of the item.
	+ Mimi explained that this distinction is necessary in order to  
separate who the invitation was from and who updated it. When you  
receive something the first time we want to know who sent it so the  
FROM: and TO: values are important. When we receive an update, we  
want to know who modified it so in this case, the EDITED and UPDATED  
fields are important.
	+ There is a secondary case where a small group are collaborating on  
the item before the official "first item" is sent out to a wider  
audience where the final To: and From: is specified. In this case,  
the user can mark it as a draft and sent to reviewers first without  
sending it to the final To: and From:. This case is probably a bit  
too complex to handle in the Beta timeframe. Users can emulate the  
same workflow by entering placeholder text in the From: and To:  
fields until they are ready to enter the email. You would enter valid  
email addresses for those who should review the invitation.
	+ A "nice to have" would be the ability to right click and send an  
item as a draft. Recipients can see it's status as a draft then.


Callum Macdonald pinged us since nobody had responded to his post  
about calendars that track people and locations. Grant responded on  
some thoughts around the implementation complexities and the reality  
of addressing anything this ambitious in the 1.0 timeframe. He did  
suggest however that this might be of interest to a third party  
parcel developer.
http://lists.osafoundation.org/pipermail/design/2006-June/004784.html


Other discussions:

Jim Sowers posted to checkin on if we had made any changes to the  
name we use for the calendar on the server since he found this  
confusing when using multiple machines to share his calendar. Sheila  
responded that we were going to be making some changes that would  
affect this for Alpha4 and to check back if that doesn't address the  
confusion.
http://lists.osafoundation.org/pipermail/design/2006-May/004781.html

Davor sent a link for an article about RedHat's new "social  
networking" service/framework.
http://lists.osafoundation.org/pipermail/design/2006-June/004786.html

Katie posted the notes from our Tues design discussion. Grant  
presented on the domain model, stamping for the benefit of the Scooby  
developers and others who were interested.
http://lists.osafoundation.org/pipermail/design/2006-June/004789.html

Mimi posted that Gmail has something stamping-like for outbound  
invitations.
http://lists.osafoundation.org/pipermail/design/2006-June/004800.html

Priscilla posted her Chandler dogfood feedback for May.
http://lists.osafoundation.org/pipermail/design/2006-June/004807.html


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060607/89bbc436/attachment.htm