Multipage vs Single Page and Unobtrusive Javascript

Question

I have a section of a site with multiple categories of Widget. There is a menu with each category name. For anybody with Javascript enabled, clicking a category reveals the content of the category within the page. They can click between categories at will, seeing the DOM updated as needed. The url is also updated using the standard hash/hashbang (if we are being Google-friendly). So for somebody who lands on example.com/widgets, they can navigate around to example.com/widgets#one, example.com/widgets#two, example.com/widgets#three etc.

However, to support user agents without Javascript enabled, following one of these category links must load a new page with the category displayed, so for someone without javascript enabled, they would navigate to example.com/widgets/one, example.com/widgets/two, example.com/widgets/three etc.

My question is: What should happen when somebody with Javascript enabled lands on one of these URLS? What should someone with Javascript enabled be presented with when landing on example.com/widgets/one for example? Should they be redirected to example.com/widgets#one?

Please note that I need a single page site experience for anybody with Javascript enabled, but I want a multi-page site for a user agent without JavaScript. Any answer that doesn't address this fact doesn't answer the question. I am not interested in the merits or problems of hashbangs or single-page-sites vs multi-page-sites.

Blip

somesite.com is an existing domain; do not use such domains unless you really mean them; example.com is reserved for use as a dummy example domain. – Villon

I have replaced with example.com – Blip

This blog post provides some insight which could offer some further thought to a solution jenitennison.com/blog/node/154 – Gog

@Gog Thanks. That was a great post. – Blip

I think the major question should be "What happens if someone with JS disabled lands on example.com/widgets#two"? – Peltz

They would arrive at the root page. I don't see any other way around that other than not using hashes which then detriments any users on IE9 or less. – Blip

@Pedr it sounds like you're looking for somebody to tell you to redirect them to the javascript page as you've commented on rejecting the opposite suggestions of that. I'll spin it for you a different way, your question is not a scenario in a properly coded website with proper detection and redirection. – Organology

@Syn123 So paint a picture of a 'properly coded website with proper detection and redirection' for me that satisfies my parameters. I rejected that answer because it doesn't solve my question. I want anyone arriving with Javascript enabled to get a single-page experience where they can shuffle between pages without full page load. I'm not looking for someone to tell me anything in particular. I'm interested in discussion of the scenario and approaches for solving it. – Blip

why would a javascript user ever be re-directed to example.com/widgets/one in the first place? – Organology

@Syn123 It is quite possible that a non-javascript user might pass around a link to example.com/widgets/one which could then be followed by a javascript-enabled user. And of course anyone following the links indexed by Google. – Blip

I guess, so the obvious solution is to do a redirect on the non-js page to the js page with detection, but... why don't you code everything into 1 page and present it to js users via the <script tag> and the same way to non-js users using the <noscript> tag? Not sure why you need two pages to do this, outside of cleaner code, but if you're concerned about linking js users to non-js pages, this single page approach may be the way to go. – Organology

@Syn123 A single page site will be useless for search spiders and for people without JavaScript enabled, however it will be a massively better experience for anyone with Jab=vaScript enabled, so I need to find a way to support both. – Blip

Ok, I give up lol, I recommend taking a class on how the web works, we're going in circles here. Pro-tip: search algorithms don't give you credit for duplicate content. – Organology

@Syn123 Maybe you could could send me a list on the courses you've done, so I can make sure I don't take any of those. Any have you thought of setting up a blog or maybe writing a book to collect together any more 'Pro-tips' you might have? – Blip

@Syn123 Great, well that link would have cleared everything up. If I'd asked a completely different question. Maybe you could just leave a few more 'Pro-tips' in these comments though. I'm pretty sure it would quickly become the go-to resource for professional programmers like yourself. – Blip

Answer 1

This is how I would structure it:

Use HistoryJS to manage the URL. JS pushstate browsers got full correct URLs and JS non-pushstate browsers got hashed urls. Non-JS users went to the full URL as normal with a page reload.

When a user clicks a link:

If they have JS: All clicks to other pages are handled by a function that prevents the default action, grabs the HREF and passes the URL to an ajax request and updates the URL at the same time. The http response for that ajax request is then parsed and then loaded into the content area.

Non JS: Page refreshed as normal and loads the whole document.

When a page loads:

With JS: Attach an event handler to all your links to prevent the default so their href is dealt with via Ajax.

Without JS: Nothing. Allow anchors to work as normal.

I think you should definitely have all of your content accessible via a full, correct URL and being loading it in via ajax then updating the URL to reflect the address where you got your content from. That way, when JS isn't running, you don't have to change anything.

Is that what you mean?

Gunnar

So what do you do when a client with Javascript enabled but a browser that doesn't support the history API lands on example.com/widgets/three? – Blip

If someone with JS but without history state visits example.com/widgets/three they should just get a full page. As far as the structure of your site is concerned all of yoru content should be accessible via full URLs, you just choose to load them via ajax. Does that make sense? – Gunnar

Can you clarify what you mean by 'full page'? Do you mean they get a single page in the same way someone landing on the page with JavaScript disabled would? – Blip

Yes, they would get the same as if they landed on it without JavaScript – Gunnar

See, that feels like a cop-out to me. That's exactly why I posted this question. All of the links that Google will index will be to these full pages, so all the people who follow those links with JavaScript enabled get the shitty experience that people without JavaScript would get. Don't get me wrong. This seems to be how a lot of people do things, but it means that the only people who get a modern, single-page JavaScript-rich experience are those who happen upon the index page. – Blip

That's not what I mean - When a user lands on ANY page you should have some JS that runs and sets up your single-page-like experience. You shouldn't be doing that set up ONLY on the index page. Otherwise you are limiting your experience to people who visit the index page first. If you have JS and you land on any page your app should be able to set itself up. I hope that makes sense, it's a big topic and very hard to get across via comments. – Gunnar

Sure. Certain aspects of the internet experience are ridiculously dated. In a world where we can talk in near-realtime to astronauts, we are engaging in a text-driven conversation with 1 day between responses. Kind of like playing chess by mail or talking to someone on Mars ;) Makes sense. I think we are coming from the same place. – Blip

Absolutely. Basically, I think all your pages should be capable of loading in any other pages via ajax into a container. The first time you land on that site some sort of set up is done to initialise HistoryJS, bind event handlers etc but after that the site acts like a single page app. Hope you solve the problem and I wish I had time/resources to put together a better example. – Gunnar

Answer 2

Apparently your question already contains the answer. You say:

I need a single page site experience for anybody with Javascript enabled

and then ask:

What should someone with Javascript enabled be presented with when landing on example.com/widgets/one for example? Should they be redirected to example.com/widgets#one?

I'd say yes, they should be redirected. I don't see any other option, given your requirements (and the fact that information about JavaScript capabilities and the hash fragment of the URL are not available on the server side).

---

If you can accept relaxing the requirements a bit, I see another option. Remember when the web was crowded with framesets, and we landed on a specific frame via AltaVista (Google wasn't around yet!) search? It was common to see a header saying that page was supposed to be displayed as a frame, and a link to take the user to the frameset version.

You could do something similar: when scripting is available, detect that you're at example.com/widgets/one and add a link to the single-page version. I know that's not ideal, but it's better than nothing, and maybe better than a nasty client-side redirect.

Cle

This feels like a poor solution to me, because it involves two separate pages being loaded. If it was possible to detect the user agent's JavaScript capabilities on the server side it would be fine, but given that the redirect would have to be client-side, it's nasty. Don't get me wrong. You are most probably correct. I am asking the question because I think it is an interesting one, not because there is necessarily a perfect answer. Quite probably this is the reality of the situation. – Blip

I understand, and updated my answer with another suggestion. I hope other alternatives exist, let's see if anyone comes up with something else. – Cle

@Pedr Do your anchor hrefs actually include the hash fragments? I'm thinking about another option (one I'm currently using on a site I'm developing, actually). If your links point to stuff like /widgets/one, you can manually add the hash to the browser with js when available. Then both versions of the page would look the same, although one would use js/ajax to load content, while the other would be normally requesting new urls. That may be the best option, actually. – Cle

I'm planning on using a lib that uses the History API and falls back to using hashes only if the browser isn't capable (IE8 & IE9). So at the very least these browsers will need a clientside redirect back to example.com/widgets. For History API capabale browsers, landing on example.com/widgets/one will look no different URL-wise than if they landed on example.com/widgets and navigated to example.com/widgets/one. – Blip

Answer 3

Why should you need to redirect them to a different page. The user arrived at the page looking for an answer. He gets the answer even if he has javascript enabled. It doesn't matter. The user's query has been fulfilled.

But what would happen if the user lands on example.com/widgets#one ? You would need to set up an automatic redirect to example.com/widgets/one in that case. That could be done by checking the if javascript is enabled in the onload event and redirect to the appropriate page.

Assistant

I'm a little unclear about your answer. Are you suggesting that he is served the unenhanced single page? If so, you've failed to understand the question. – Blip

You added the part about multipage vs single page experience later.. How is one supposed to understand your requirements without you giving out the full details? Obviously, if that's what you desire, the user should be redirected to the javascript enabled page.. What is the question then? – Assistant

No. That was there from the beginning. The clarification at the end was added. – Blip

Answer 4

One way for designing such pages is to design without javascript first.

You can use anchors in the page so:

example.com/widgets#one

Will be a link to the element with id 'one'

Once your page works without javascript, then you add the javascript layer. You can prevent links to be followed by using the event.preventDefault.

(https://developer.mozilla.org/fr/docs/DOM/event.preventDefault), then add the desired javascript functionality.

Shotten