Hi,
Apologies for not responding earlier. I still haven't gotten my head
around all of the details in the thread but thought it might be
helpful to pipe in with some use case / workflow, information
modeling and information design issues relevant to the detail view.
1. Designing for the Web Issues
+ I'm not sure I understand the 'small window size' concerns. All the
attributes in the 'bare minimum' design fit in an 800x600 browser
window.
+ Scaling to accommodate more stamps has been stated as a concern.
I'm not sure how this DV will scale with 5,6,7... collapsible
stamping sections.
+ I know we were worried about the DV being up to the gills in UI
elements. Are we adding more UI elements?
+ What about the multiple scrollbars problem?
2. Information Modeling Issues
+ How do we deal with attributes that belong to multiple stamps?
+ Might it be helpful to group attributes in terms of Attribute Types?
- Who: People
- Where: Location
- When: Date/Time
- What: Topic, Subject
This is how the Dashboard columns are defined.
+ Should the byline be close to the Addressing fields? The byline
often contains information about who sent, updated message items.
+ Others have said this already, the Task stamp has no attributes, it
is only a way to mark an item as a Task.
3. Would it be helpful to show/hide attributes based on workflows and
use cases?
What workflows involve the detail view?
+ Scanning through items to find a piece of information (e.g.
Directions to a party, specific time zone of a meeting time)
+ Creating new items. What kind of new items? Scheduling an event?
Jotting down a brilliant idea you don't want to lose? Getting down a
task?
+ Editing existing items. Again, the same questions apply, what kind
of edits? Taking notes? Fixing typos? Adding more information?
Questions we might ask about each of these workflows:
+ How common are these workflows?
+ How common are these workflows for the Casual Collaborator?
+ How common are these workflows for the Desktop user verifying their
shares?
+ For each of these workflows:
- What attributes do users want to see, at-a-glance; versus
- What attributes are okay to hide until the user clicks in to edit
the item?
Previous Proposals
Some of these concerns motivated the Expando field proposals for the
Desktop and the Nice-to-have proposals for Cosmo we reviewed a few
months back.
--http://wiki.osafoundation.org/pub/Journal/
NiceToHaveProposalsForPreviewCosmoUI/CosmoUIChrome_NTH.pdf
Would it be useful to show/hide attributes based on whether or not
they were filled in, provided there were visual cues to let you know
how to get at the attributes that are hidden.
--http://wiki.osafoundation.org/Journal/ModalAddressingFields
--http://wiki.osafoundation.org/Journal/ExpandoDateTimeFields
===
I'm sure we could work through these issues, but I imagine they will
take quite a bit of time. While wxWidgets certainly imposes some
limitations and restrictions on what we can do on the Desktop, the
current DV design for the Desktop is not solely the result of what
wxWidgets can and cannot do. On the contrary, it's primarily the
result of a many, many design cycles of refinement, workflow analysis
(of the kind described above) and use. I wonder if we are being too
hasty in disregarding that work in the way we're going about
iterating on the design.
All of that being said, I don't see any serious design issues that
should block us from trying this design. But I wouldn't list: "Do the
right design now so we don't have to re-write it later" as one of the
reasons to experiment. As Ted has said and as the list above attempts
to show, there is still a lot of work to be done in figuring out the
right design for the Hub UI.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
