1) How do you think in-place-editing will affect Rails development?
The current implementation has minor flaws; the editor requires a model, for example. These will smooth out.
I mean, it's not along with well established conventions, like having
RESTful controllers with strict set of actions.
That is a usability question. The Web 2.0 movement might sometimes require professional usability experts - not feature-zealous programmers - to establish use cases for our software.
Maybe it would be better if we could send the whole form after one field
change, so standard update action could be used, just with new
respond_to entry.
That will be among the details that are smoothed out.
2) Will in place editing end up as a substitute for standard modify
page? I think it's rather complementary approach and only in some cases.
Start the question with the user's experience. They know, by now, the difference between the pages that submit and refresh, and the pages that change one element at a time. If a given website uses one technique for certain situations, it shouldn't jump to the other technique for similar situations. Giving the user the option to refresh a whole page will return control to them.
3) Could you recommend any article on in-place-editing usability
guidelines?
Books like /Pragmatic Ajax/ suggest that websites must support a Back button and the Favorites bar. Neglecting these would take our usability back a couple decades.
My O'Reilly Short Cut shows how to write unit tests for every detail of any in-place edit field. My resulting usability, however, is a cautionary tale!
Books like /Pragmatic Ajax/ suggest that websites must support a Back button
and the Favorites bar. Neglecting these would take our usability back a
couple decades.
I'd say what's is true for content-based web is not always true for
web applications. Back button is essential for navigation, is it so
essential for the web applications? Or take, for example desktop apps
- how many of those do have back button? Help viewers? That's
navigation again. Web application might need a good "undo"
implementation, instead.
I don't use back button in Gmail and I still think this is the most
user friendly email app
so far...
Books like /Pragmatic Ajax/ suggest that websites must support a Back button
and the Favorites bar. Neglecting these would take our usability back a
couple decades.
I'd say what's is true for content-based web is not always true for
web applications. Back button is essential for navigation, is it so
essential for the web applications?
"Principle of Least Surprise". If the user feels like they just switched pages, Back should take them back. A site should not abuse Ajax to repaint an entire page, as if the user had switched pages.
Or take, for example desktop apps
- how many of those do have back button?
The great thing about web browsers in general is they forced programmers to follow at least a minimal subset of good usability features. All programs with pages should have a Back button concept and a Bookmark concept. Programmers traditionally didn't bother with these things because an Event Driven Architecture is slightly harder to program than a Procedural Architecture. Web browsers only work with Event Driven Architectures.
Help viewers? That's
navigation again. Web application might need a good "undo"
implementation, instead.
In theory (_my_ theory!) all computers should have a system to Undo any keystroke. I am capable of some amazing fat-finger events, right when I'm inspired and not in the mood to be interrupted by figuring out what I just did.
And this is why I type very delicately on Ajaxed sites!!!
I don't use back button in Gmail and I still think this is the most
user friendly email app
so far...
GMail locks down its top banner and navigation bar. That helps you feel like you are always on the same web page, so you are less likely to accidentally think that Back and Favorites will work.
The biggest reason to support the back buttton is not so that users do use it… it’s to make sure nothing bad happens when a user TRIES to use it. I think back to Flash-based sites, where instead of going back one page in the process, I went back a whole site in my history
The back button is most used button in a web browser, it gives the
not so confident use some reassurance/safety. One thing to remember
with ajax vs usability is that there is a time and place to use it,
just because its their and its the in thing, most users expect certain
things to happen on pressing a button, changing this nature 'just' to
use ajax is not a good idea.
The back button is most used button in a web browser, it gives the
not so confident use some reassurance/safety. One thing to remember
with ajax vs usability is that there is a time and place to use it,
just because its their and its the in thing, most users expect certain
things to happen on pressing a button, changing this nature 'just' to
use ajax is not a good idea.
We have moved the rhetoric from "My site must Back-button gracefully,
because I must refresh pages just to redisplay them" to "how can we
use the Back button to the best effect, and give the user cues it
works the way they expect?"
This is a very good thing - it's programmers taking back control of
our environments.
Just thought I’d mention GMail does actually support the back button, atleast in Firefox. Im able to use the back button to back out of threads to a label, back to the inbox, and I don’t leave the site.
Some projects that enable back button use in Ajax apps:
