Since Matthew is working on the DV starting today, it's pretty
important that we come to some resolution on this pretty quickly.
At this point we have 3 weeks left before we are supposed to start
QA'ing 0.7, which leaves us very schedule constrained. With that as
background, here are my thoughts.
Assuming that the old DV and new proposed DV are roughly the same
amount of effort, it basically comes down to whether or not we are
going to have any significant amount of design discussion on this.
If we think that we can come to a consensus on this very quickly,
then let's do that. On the other hand, if people have issues that
they want to discuss, then I would prefer to defer this until after
preview. My expectation is that we will be making a number of
adjustments to the UI once Cosmo 0.7 goes into production usage, so
this is by no means our last chance to make adjustments to the user
interface.
What do other people think?
Ted
On May 7, 2007, at 10:22 AM, Priscilla Chung wrote:
This coming week Matthew is going to re-implement the details view
of the web UI in order to support stamping for dashboard. He
informed me that he will have to start from clean slate. From my
understanding, the amount of time to implement a layout identical
to the desktop and time to implement a proposal are about the same.
So we took this opportunity to look at the event details on the
desktop and see if there are ways to address some of the known
issues. How to make it behave more like a web application. Come up
with more visually acceptable solutions to incorporate all the form
elements without losing the 'Save' and 'Remove' button on smaller
screen sizes.
***Note: Please review the questions below before commenting on the
design proposal.***
We came up with a proposal which is a slight departure from the
current desktop layout of the detail view:
http://wiki.osafoundation.org/Projects/
CosmoZeroDotSevenSpec#CurrentMockUp
*The reasons for coming up with a new proposal for detail view are
the following:*
+ The current layout which is adapted to the desktop app is not
well suited to web conventions.
+ This layout better scales to handle small screen sizes and/or
additional types of stamps.
+ Right now we have only three stamps, but there is no more space
on the horizontal 'mark up bar'. The proposed layout scales for
addition stamps, including other ideas such as annotations for read-
only collections, per a previous discussion on the design list:
http://lists.osafoundation.org/pipermail/design/2007-May/
007059.html ).
+ The visual relationship strengthens the visual grouping and
association for the address, task and event stamp and their
associated capabilities.
+ The Casual Collaborator target user, is someone who does not use
the desktop every day and may need more guidance in understanding
the concept of the the address, task and event stamp.
+ It's not going to take more time to build than implementing the
layout similar to the desktop.
+ The current layout which is adapted to the desktop is very tight—
the web app may have problems with different fonts and font size.
From the very beginning Mimi and I agreed to keep the two
applications consistent, but only *where it makes sense*. This
proposal is not intending to create a unique web UI for the sake of
it. We felt the web app is a good way to try ideas out, where the
desktop app lacked in experimentation because it would longer and
be prone to more bugs.
*The reason not to move forward with a new proposal for the detail
view:*
+ Discussion on the design list may impact schedule.
+ If this proposal distracts from 'the purpose of preview', it
makes sense to postpone this discussion till post preview.
+ It's not identical to the desktop app and might cause problems
with some users, primarily desktop users who are used to using the
desktop. For preview, the target user for the web UI are Casual
Collaborator and not the 'Consultative desktop users'.
It's fine if we decide to move forward and mimic the layout on the
desktop, as long we're aware of the known issues. Trying something
new may fix some issues however it will also create other issues.
If our concern is schedule, doing something new may not necessarily
cause risk—though I lean on Ted/Matthew to confirm this.
Usability risk is unknown at this point because we don't have users
testing the proposed layout vs. the desktop layout, but
implementing two different layouts offers us the opportunity to
test and learn from our users. I understand completely if the team
as a whole does not want to take a chance on this because there are
a lot of risk factors already.
*Questions:*
Forgive my bluntness, but it seems like time is against our side,
so before commenting on the proposal, I'd first like to ask:
+ Is this proposal distracting everyone from 'purpose of preview'?
+ If so, then we should consider tabling this discussion till post
preview—where it belongs?
-Priscilla
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
