Right.
And we made the decision early on that we only needed one level of
undo for our current implementations of simple text edit. The
multilevel undo really comes into play with document-style (word
processing) editing where a user may make many different changes on a
page rather than just changing a single text field. I probably
shouldn't have mucked up the icon versus text discussion with the
aside. Sorry about that :).
-Daphne
On Aug 27, 2008, at 10:29 AM, Eli Cochran wrote:
While I'm not saying that it's the right thing to do, I would like
to point out that very few web applications even attempt to
implement multilevel Undo.
gMail only allows you to undo your last activity and once you do
anything else, you lose the ability to go back at all.
Some apps are getting more sophisticated but it's still a new model
on the web... actually bleeding edge given the technical hurdles.
- Eli
On Aug 27, 2008, at 10:15 AM, Daphne Ogle wrote:
These do seem the best of the choices we've seen so far and I think
they work well in their context. But I agree with you Eli that
displaying them as a set adds to their clarity. On top of the
real estate issue for displaying both, our undo and redo are a one
time action so I don't think they are ever available together.
The additional challenge and vagueness for us in contexts like
section info is that the proximity of the icon ends up being closer
to the next field then the text that was edited if it's shorter
than the text field itself. If we use text now for testing we can
get a feel for whether or not users get our undo and redo. We can
easily get feedback on icons later without running an entire test.
As a total aside: We could rethink them and implement true undo
and redos (not restricting to undoing only last change). We
wouldn't want to make the change just so we can show them together
Allison and I have been discussing exploring true undos and redos
-- particularly if one of the Sakai UX or uPortal announcements
context require it. True undo complicates the interaction for the
user with much more memory load but we could build in reminders of
the previous edits and let them choose which one to go to.
-Daphne
On Aug 26, 2008, at 7:12 PM, Eli Cochran wrote:
The icons in MS Word are really good. (enclosed)
One thing that I really like about them is that they are two
different colors. But the other thing about them which helps make
them clearer as to their purpose is that they are always seen
together. I'm not sure that we would want use so much room.
<pastedGraphic.tiff>
- Eli
On Aug 26, 2008, at 6:19 PM, Allison Bloodworth wrote:
Hi all,
In an ideal world we'd have the icons we wanted picked out, and
could rely on the tooltip to give folks the information about
what exactly they were. I do believe it would be best to to use
the sort of standard, mirrored arrow-type Undo and Redo icons
(e.g. a la Microsoft Word, see the Undo & Redo icons on this
page: http://www.readyicons.com/iconset-preview.php?id=11), but
wasn't able to find a free version that I liked when I looked.
If we are just uing Undo, I think the icon we have is OK for now.
If we are also testing Redo, it would be better to have text if
we can't find better icons. I can take another look around for
some tomorrow.
Allison
On Aug 26, 2008, at 2:05 PM, Daphne Ogle wrote:
I'm voting for a text link rather than icons.
-Daphne
On Aug 26, 2008, at 2:03 PM, Eli Cochran wrote:
Daphne,
I agree with you that there will probably be some confusion
around Undo and Redo. I'm not sure I understand what you are
suggesting. There is already a tooltip for Undo/Redo (at least
there is in FF, I just used the title tag). Are you saying that
you would also like a label next to or under the icon?
Let me know. I'll revisit this tomorrow.
- Eli
On Aug 26, 2008, at 1:51 PM, Daphne Ogle wrote:
Looks good Eli! Nice work!
A couple of things:
- Until we come up with a meaningful icon I vote for using
text to make it clear what the user can do. The addition of
undo adds some challenge for the user to not only figure out
what one icon does but what 2 siimilar only mirrored icons
do. Because of their similarity its also more difficult to
distinguish between them and when they change.
- Just an FYI for everyone -- there is still a debate about
the usefulness and need for redo in the simple text field edit
context here. We are hoping user testing will help us better
understand the tradeoffs of adding the complexity versus how
often redo is actually needed.
-Daphne
On Aug 26, 2008, at 12:52 PM, Justin wrote:
Hi Eli,
I've been checking it out today. It looks good.
I've added it to the Inline Edit QA test plan. Now we will be
able to do QA testing on the undo/redo functionality.
Thanks
Justin
On 26-Aug-08, at 3:34 PM, Eli Cochran wrote:
Hi folks,
The Section Info based inline edit sample is pretty much done.
There is a little bit of accessibility work to be done with
the Undo/Redo, Undo/Redo is in the wrong tab order because
I'm floating it right. I'm doing this for formatting reasons
and I can fix it with a little more sophisticated markup
when I get a chance. Also when you activate Undo or Redo,
the focus should stay on the Undo/Redo link.
But other than that, I think that it's in good shape.
Certainly good enough for testing and for beta.
Inline Edit and the Undo code are very fun to work with.
Kudos to those who developed on the code. Very easy to
implement. Well, I had a little trouble with Undo, but once
Colin helped me with an undocumented and slightly confusing
API change, it worked like a charm.
Please check it out:
http://build.fluidproject.org/fluid/sample-code/inline-edit/section-info/section-info.html
- Eli
. . . . . . . . . . . . . . . . . .
.
Eli Cochran
user interaction developer
ETS, UC Berkeley
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED]
cell (510)847-0308
. . . . . . . . . . . . . . . . . .
.
Eli Cochran
user interaction developer
ETS, UC Berkeley
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED]
cell (510)847-0308
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
[EMAIL PROTECTED]
. . . . . . . . . . . . . . . . . .
.
Eli Cochran
user interaction developer
ETS, UC Berkeley
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED]
cell (510)847-0308
. . . . . . . . . . . . . . . . . .
.
Eli Cochran
user interaction developer
ETS, UC Berkeley
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED]
cell (510)847-0308
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
