[Design] [cosmo] [sum] Detail View

[Priscilla Chung]

First, I'd like to *thank you all* for taking the time to reply to  
this proposal today!

Let me just summarize this so we're clear what has been said. I will  
then attempt to send out another e-mail to close on this discussion.

---
*Summary: Detail View on the web UI*

Ted: It's important to have a resolution today to keep to the  
schedule. The effort for the detail view basically comes down to the  
significant amount of design discussion—it doesn't matter which  
layout is implemented, post 0.7 there will be more tweaks and changes  
to the web UI.

BCM: Prefers the most recent detail view and design if all else is  
equal. Would like to go ahead and do it.

Adam: Feels strongly that it's a mistake to forfeit the benefits of  
the web UI to make the web app look exactly like the desktop. He  
questions why if it's the same amount of work, would the server team  
create a replica of the desktop app then have to repeat the work  
again to suit convention for the web.

Priscilla: Agrees with Ted and asked everyone to comment by end of  
day today.

Bobby: Felt the design looks pretty snazzy. Leans on Matthew for an  
estimate that if it's not to much extra work, then +1.

Mikeal: Doesn't understand why we wouldn't try to put out a better  
UI. Comments that "we should have parity between the desktop and web  
interfaces" when what we should be saying is "what interface in each  
context is more intuitive to the user". There are a lot of users who  
have never used the desktop and we should provide them with the most  
intuitive experience as possible regardless of the desktop  
experience. +1 to a web centric design.

Travis: +1 to Bobby's comment.

Katie: Provides a strategic perspective. Getting something out is  
most important. 1. We shouldn't be shackled by desktop constraints  
when thinking about design for the web UI. 2. Making the release is  
the most important. The cosmo schedule has slipped and the 0.7 time  
frame is very tight. Risking the schedule further is not a good  
thing. A new design is a schedule risk, even if the implementation is  
the same. New design will require further discussion and decision  
making. If we don't pursue the new design, it's worth pursing for the  
next release. We are not stuck with every detail in the first pass  
forever, would like to seem more experimentation with the features  
post-preview.

Mikeal: Replay to Katie's second point. Comments that the new design  
is the same content and usage of the desktop, but include collapsable  
sections rather then static ones. Looking back at the desktop design  
for what all it content and field means, just the layout is changed  
slightly. All the workflow should be the same—so we don't need to  
discuss abou the semantics behind each piece. Want to understand why  
additional design work beyond what is already been done might add  
schedule risk? Adds that if Matthew could expand on this, the  
possibility for problems with different window sizes is a much higher  
risk if we follow the desktop layout.

Jeffrey: Felt it's tough to make a decision with tight timelines.  
Wants to support the server team and does not think the web UI need  
to 'slavishly' follow the desktop UI. Like the triage options all  
laid out for new users, but questions the trade-offs. Is worried the  
stamping concept might be lost. With the accordion layout stamps  
options are dramatically improved, but hard to know which stamps are  
active and may be out of view for small screens. -1 to this rushed  
process of having to come to a resolution by end of day.

Mikeal: Responds to Jeffrey's comment about 'the stamping concept  
being lost'. Agrees it's a valid point and makes a  suggestion about  
also having the stamping icons at the top as in the desktop layout.  
Comments that supporting smaller window sizes are a better trade off  
then 'the stamping concept being lost'—would rather see it as a post  
preview request.

Matthew: Responds to Mikeal's comment about expanding the  
possibilities for problems w/ different window sizes. He comments  
that 1024x768 is the screen size the team has agreed to support. In a  
800x600 screen size, if the buttons render off the screen, but a  
scroll bar appears for the user to find them, then it is not ideal,  
but considered functional. Matthew checks the current desktop layout  
of the detail view and notices it does not fit in the 1024x768  
resolution in a default Firefox install with tabs and barely fits in  
IE7. Notes this was the original driver for this discussion, which is  
to accommodate the vertical space problem.

Mikeal: Comments to Matthew browser size checks. He questions, if we  
are tight for space, should we consider it a potential risk for  
slippage when fixing issues we find down the road?

Matthew: Reply to Mikeal that anything that bugs us more space in  
detail view is a good thing, but doesn't know if it's a slippage  
risk. More a usability risk because the description field is getting  
small and people hate to type in lengthy text in tiny boxes.

Pieter: Agrees with Katie's points and chimes in with a public view  
of the project. Getting something out is the most important thing.  
Likes the new UI, thinks we should do it but only if there is not  
risk to slippage in comparison to the existing desktop UI.

Sheila: Agrees with Katie's points-should not be constrained by the  
desktop and prevented from exploring alternatives to the web UI.  
Concerned that there is now a debate on the design list which  
demonstrates what people are worried about—causing slippage to the  
schedule due to the lengthy discussion on the list. Sheila is coming  
purely from a risk and schedule perspective. Reminds everyone this is  
not 1.0, and there is room to make change on both the desktop and we  
web UI, post preview. Getting an initial version in the first place  
is what we're trying to accomplish.

Adam: Comments from a QA perspective, doesn't feel that it would take  
longer in terms of total testing time. Doesn't feel that it makes  
sense for QA to rewrite tests and would find it more efficient if QA  
just write it once then to rewrite the tests again for detail view.

Mikeal: Elaborates on Adam's comments about QA time. The the  
differences in time for writing the automation of one plan as opposed  
to the other is probably around 30 minutes. The QA impact is  
somewhere near zero for the newer web centric plan.

Ted: Reply to Adam's comment about QA perspective. Comments that  
there will be continuous iterations on the web UI. There will be  
rework in the UI. Reminds everyone that the UI will get reworked not  
only on the web UI, but on the desktop as well after preview.

Mikeal: Reply to Katie's comments. Reiterates Matthew's comment about  
dev time being very low and based on current feedback, a better UI.  
Questions why the desktop UI 'as is',  considered low risk. We've  
discussed that there are risks in the design and solving issues are  
harder following the UI based exactly on the desktop. So both design  
have risks for development and one design make usability suffer  
greatly on low resolution. Not clear on the reasoning for not going  
forward with the more web centric design. The web centric UI has room  
for iteration, and the other is essentially throw away after 0.7  
which is a huge concern for the server team.

Ted: In response to Mikeal's reply with 'more room to work in the  
detail view we have small reduction in risk'. Noting the semantics  
are not the same which is what Jeffrey was trying to point out. the  
preview release is a number of experiments around the ideas that are  
the essence of Chandler, such as triage, dashboard, stamping,  
sharing. Feedback on the concepts of these ideas are important to  
Ted. The new design weakens the ideas of stamping in order to cater  
to small screens. Questions what if the later revision is to move the  
detail view horizontally across the bottom as it has been proposed?  
Then the concern is that the design is back to square one.

Mimi: Asked a bunch of use case/workflow questions and forwarded  
links to the history of parts of the existing desktop design. She's  
concerned that the server team might be too quick in adopting a new  
design. That said, she didn't have any specific objections to trying  
out this new proposal. In addition, she noted there is no 'right  
design' and plans to continuing iterating on the design post preview.

Did I capture everyone's comments fairly? Or am I missing anything?
-Priscilla




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070507/695b3204/attachment.html