A couple of thoughts from a strategic perspective:
1. The design looks promising. In general, we shouldn't be shackled by
desktop constraints when thinking about designs for the Hub UI.
2. Getting the release out is most important. The cosmo schedule has
slipped -- the 0.7 timeframe is very tight. Risking the schedule further
is not a good thing. A new design introduces schedule risk, even if
the implementation is the same, as a new design will likely require
further discussion and decision making.
Getting something out is most important.
FWIW, if we don't pursue this design now, I think it is worth pursuing
it for a 0.8 release. At the end of the day, the dashboard design is
going to be hobbled in 0.7, because we thought it was most important to
get *some* first version of it up, with the correct infrastructure
behind it. This doesn't mean we are stuck with every detail in the first
pass forever. I hope to see us experiment with dashboard and detail
features post-preview.
Cheers,
Katie
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
