4 ms·

So many issues with such a short comment! * If the back button behaviour is important, perhaps not breaking it in the first place is an appropriate approach *

So many issues with such a short comment! * If the back button behaviour is important, perhaps not breaking it in the first place is an appropriate approach * The addressability of resources is one third of the fundamental basis of the Web. Ignoring it is essentially non-web, so I suggest the label "web-app" is incorrect. * The user-expectation of clicking the back button but expecting to remain on your one-page website sounds like a usability problem brought about by applying a non-web-like interface inside a web browser. Perhaps a better user-experience is not breaking the well-understood web-navigation model, and thus not be confusing to the user. Or perhaps these "web-apps" need to make it clear to the user that they deliberately don't follow the characteristics of a web resource?

udp 16y ago
Let's take a look at the alternatives to breaking the back button, then: - The web application could serve static pages and then update them with AJAX What if the user clicks back /then/? All the AJAX updates would be lost, and they'd go back to an older version of the page - they'd then see the data on the page "jump" to the updated version. - The web application could not use AJAX at all, and serve everything as static pages, without automatic updating Some web-applications can't work like that. Mine has instant messaging, and I want the IM windows to be there when it loads. Besides, most users /like/ AJAX. They're not thinking "oh no, this application ruined the web", they're thinking "nice, the page updated itself". - The web application could use Flash or some other plugin, instead of the native HTML/Javascript Which of these are you suggesting developers do instead? Why is the HTML5 history/hashbang URL model not better than all of these?
- deleted 16y ago
  [deleted]
- Isofarro 16y ago
  "Some web-applications can't work like that. Mine has instant messaging, and I want the IM windows to be there when it loads." There are already internet protocols for real-time notifications, like XMPP and a whole host of non-open protocols. Re-implementing messaging on a platform that isn't by it's nature a push platform will always be inferior to the real thing. Wouldn't it make more sense to implement a web-like application on-top of a real-time messaging platform instead of the other way around? (Though, it's not clear what a back button should be doing in an "instant messaging" interface - will it undo the a conversation? Does a user bookmark a message or a conversation so they can edit/refine individual messages later?) "Which of these are you suggesting developers do instead?" I'm suggesting developers use the right tools and platforms for the job.
  - udp 16y ago
    So you're suggesting there shouldn't be any (for example) instant messaging in the web browser, it should be in a separate application. Well, it's pretty clear what you mean now, and I guess we'll just have to agree to differ. Real-time AJAX applications in the web browser are the future, and I know I'm not the only one who thinks so. Also, if you think I'm trying to say the back button should do anything to an IM conversation, you're misunderstanding the whole issue.

udp 16y ago

Let's take a look at the alternatives to breaking the back button, then: - The web application could serve static pages and then update them with AJAX What if the user clicks back /then/? All the AJAX updates would be lost, and they'd go back to an older version of the page - they'd then see the data on the page "jump" to the updated version. - The web application could not use AJAX at all, and serve everything as static pages, without automatic updating Some web-applications can't work like that. Mine has instant messaging, and I want the IM windows to be there when it loads. Besides, most users /like/ AJAX. They're not thinking "oh no, this application ruined the web", they're thinking "nice, the page updated itself". - The web application could use Flash or some other plugin, instead of the native HTML/Javascript Which of these are you suggesting developers do instead? Why is the HTML5 history/hashbang URL model not better than all of these?

deleted 16y ago
[deleted]
Isofarro 16y ago
"Some web-applications can't work like that. Mine has instant messaging, and I want the IM windows to be there when it loads." There are already internet protocols for real-time notifications, like XMPP and a whole host of non-open protocols. Re-implementing messaging on a platform that isn't by it's nature a push platform will always be inferior to the real thing. Wouldn't it make more sense to implement a web-like application on-top of a real-time messaging platform instead of the other way around? (Though, it's not clear what a back button should be doing in an "instant messaging" interface - will it undo the a conversation? Does a user bookmark a message or a conversation so they can edit/refine individual messages later?) "Which of these are you suggesting developers do instead?" I'm suggesting developers use the right tools and platforms for the job.
- udp 16y ago
  So you're suggesting there shouldn't be any (for example) instant messaging in the web browser, it should be in a separate application. Well, it's pretty clear what you mean now, and I guess we'll just have to agree to differ. Real-time AJAX applications in the web browser are the future, and I know I'm not the only one who thinks so. Also, if you think I'm trying to say the back button should do anything to an IM conversation, you're misunderstanding the whole issue.