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