http://wiki.osafoundation.org/Journal/NoDataLossProposal#WorkflowTwo
I have updated the wiki proposal with a Workflow write-up and comp of
pje's proposal. One funny thing I noticed was that 'Finish later'
looks funny if the user hasn't started Applying or Discarding pending
changes. So the button should probably start out as 'Decide later'
and then change to 'Finish later' when the user has committed their
first 'Apply' or 'Discard'.
This design will probably hold up admirably in the Preview timeframe.
However, looking at it in the comp, I think it will start to get
increasingly overwhelming as the number of pending changes climb
beyond 5.
I am also using a 'smaller' size button for the Apply and Discard
buttons. I'm not sure how much control we have over this in the
dialogs. We have a similar size issue in the Accounts dialog.
Please review and reply with comments and questions.
Thx,
Mimi
On Jan 24, 2007, at 4:22 AM, Mimi Yin wrote:
Here is a sketch that is actually what you wrote, rather than what
was in my head :o)
1. Notes: xxxxxx [Apply]
[Discard]
2. Start time: xxxxx [Apply] [Discard]
3. Start time: xxxxx [Apply] [Discard]
[Finish later]
Now that I finally understand what you're saying, I agree that this
is the right design to try. Users can always copy and paste from
the dialog into the detail view if they want to hand-merge complex
fields like the Notes field and then Discard the pending change in
the dialog.
We should probably have some text that warns people that 'All
pending changes must be resolved before you can send Updates.'
Thx Phillip
This is why I still think we should have individual "apply/
discard" buttons for each pending change, so that you individually
apply changes, causing them to be immediately removed (or greyed,
crossed out, etc.) from the list and updating the detail view, so
that you can interactively apply selected changes.
The changes from the above proposal would be minimal:
1. Each change would include an "apply" button, and a "discard"
button
2. When a button is used, both buttons for the item would
disappear or become disabled, and the rendering of the change
would be different (change color, icon, text style, whatever) to
indicate its applied-ness or discarded-ness. If the change were
applied, the summary and detail views would be immediately updated
to reflect the change(s). (If discarded, no such updates would
occur.)
3. The dialog would have one button, "Finish later", which would
change to "Done" when all changes have been either applied or
discarded.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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