1) How do you think in-place-editing will affect Rails development? I mean, it''s not along with well established conventions, like having RESTful controllers with strict set of actions. 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. 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. 3) Could you recommend any article on in-place-editing usability guidelines? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Piotr Wlodarek wrote:> 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! ;-) -- Phlip http://www.oreilly.com/catalog/9780596510657/ "Test Driven Ajax (on Rails)" assert_xpath, assert_javascript, & assert_ajax --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
<...>> 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... Regards, Rimantas -- http://rimantas.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Rimantas Liubertas wrote:>> 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. -- Phlip http://www.oreilly.com/catalog/9780596510657/ "Test Driven Ajax (on Rails)" assert_xpath, assert_javascript, & assert_ajax --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 :) On 4/20/07, Phlip <phlip2005-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Rimantas Liubertas wrote: > > >> 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. > > -- > Phlip > http://www.oreilly.com/catalog/9780596510657/ > "Test Driven Ajax (on Rails)" > assert_xpath, assert_javascript, & assert_ajax > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. On Apr 20, 11:59 pm, "Brian Hogan" <bpho...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> 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 :) > > On 4/20/07, Phlip <phlip2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > Rimantas Liubertas wrote: > > > >> 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. > > > -- > > Phlip > > http://www.oreilly.com/catalog/9780596510657/ > > "Test Driven Ajax (on Rails)" > > assert_xpath, assert_javascript, & assert_ajax--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Camo wrote:> 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. -- Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 4/20/07, Phlip <phlip2005-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > > 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. > >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: http://developer.yahoo.com/yui/history/ http://www.unfocus.com/projects/?page_id=3 -- Scott Becker Electro Interactive, Inc. Office: 813-333-5508 http://www.ElectroInteractive.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---