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
