Hacker News Reader

Comment by udp | Hacker News Reader

Using a # to show JS state changes in the URL isn't some huge developer cock-up like it's being portrayed to be, it's just making the best user experience out of the functionality available - see this for instance: http://code.google.com/p/reallysimplehistory/

HTML5 provides the new history.push system, which provides all the functionality hashbangs are being used for without the hashbangs: http://www.kylescholz.com/blog/2010/04/html5_history_is_the_.... The fact that a new feature has been added for it goes to show that it's something necessary - Facebook, for instance, uses history.push if present, and falls back on hashbangs when it isn't.

It's often a very important thing to be able to do, else if you have (for example) multiple tabs or other frontend navigation for your web-app, pressing back would have to take you right out of the application, rather than back to the last place you were.

View on HN

It seems that much of this consternation about munged URLs (here and in other threads) is about preserving the functionality of the "back" button.

Why do we need a back button?

The DOS and Unix command lines never had a back button. Lotus 1-2-3 and WordStar and Word and Excel never had a back button. Photoshop and GIMP never had a back button. SQL scripts and database servers never had a back button.

Many of these programs do have application-specific implementations of an "undo" function. Perhaps that is the way to go for future software, rather than trying to wedge a universal "back" function into applications that don't really map to that paradigm? What does "back" even mean when the application is a game, for example? Flight Simulator and Ultima and Doom never had back buttons.

It's nothing to do with the back button. It's about addressability - being able to link to things. Links are kind of important on the Web.

It's all about the back button in a web-app when addressability doesn't matter. The user doesn't expect to be logged out when they click back out of force of habit.

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?

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?

"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.

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.

Don't underestimate the value of the back button. In an interlinked software world where you can view your email, read a party invite, add the date to your calendar, and book a flight out there... users need a way to unwind the stack.

> It's about addressability - being able to link to things. Links are kind of important on the Web.

Of course, but not in all applications and situations. What does it mean to link to the middle of a Farmville game session? It's by definition a transient state within a process that does not need re-linkability or history. Similarly, we've been using desktop applications forever with no notion of addressability. You don't send an image with the expectation that the recipient can jump into the middle of your editing actions in Photoshop.

When a web application is fundamentally about an interactive process rather than publishing content, the notion of back and history can lose much meaning. Using Back as a universal undo button or a URL to bookmark any arbitrary slice of content does not hold up in the world of more complicated AJAX partial dynamic page updates. Should designers continue to contort Javascript and the very notion of URLs to satisfy this increasingly-misplaced user expectation, or work to educate users that sometimes "Back" or bookmarking cannot have a meaningful result?

Nobody expects a "back" or "undo" button in everyday activities like driving a car or cooking or making social conversation. How did this expectation become so irreversibly fundamental in computers?

> Nobody expects a "back" or "undo" button in everyday activities like driving a car or cooking or making social conversation. How did this expectation become so irreversibly fundamental in computers?

Wow. We're only just now getting to the point where it isn't possible to accidentally render your computer unusable with a few stray actions.

You seem to be forgetting just how unforgiving computers were even 8 years ago, any why iOS devices are so enticing to regular folks.

Undo isn't back. They're different concepts. If I send a friend request on Facebook and then click back, that doesn't cancel the friend request.

Don't conflate the two concepts. Undo good, back... not always required?

I think it's the non-linear processes that have trouble with the back button. Clicking back should go to the last modal state. If your app is fundamentally non-modal, then the last state is outside your app and clicking back should exit (after persisting all state, of course).

But most apps can be broken into at least a few states. For any document based app, like Photoshop, navigation should probably move between document views. Any modal dialogs should be closable with the back button. You don't have to use it for everything, it just has to do something sensible and non-destructive at any given time.

    You don't send an image with the expectation that the recipient can jump into the middle of your editing actions in Photoshop.

Actually, that sounds really appealing.

> Nobody expects a "back" or "undo" button in everyday activities like driving a car or cooking or making social conversation. How did this expectation become so irreversibly fundamental in computers?

People make mistakes. All people, in everything they do, at every level of responsibility.

"Back" or "undo" buttons in everyday activities like driving a car or cooking or making social conversation would be astoundingly useful. In your first example alone, literally tens of thousands of lives would be saved every year.

The expectation is irreversibly fundamental in computing because in computing, unlike reality, it is actually possible.

The back button is one of the greatest inventions in the history of usability. It's the centerpiece of the thick user agent, and the user agent is why the web took over the world.

The web is a platform for modal applications with addressable state. To meet the expectations of users, any app on the web must somehow shape itself to that model.

BTW have you ever used a navigation based app that didn't have a back button? Try the native YouTube app on iOS. It's infuriating.

...but the native YouTube app on iOS does have a back button: obviously there's something important about navigation that "stack of pages with a back button" isn't sufficiently describing.

It has a broken back button. The history is erased when you tap any of the bottom menu items.

I spend most of my time on the iOS youtube app in mortal fear of accidentally brushing one of the bottom menu items.

>it's just making the best user experience out of the functionality available

That's a pretty broad generalization. On Twitter for example I'd say they're intentionally trying to make it harder for you to have a URL to reference an individual tweet.

Reply on news.ycombinator.com