So I've been doing a little research on the different methods to achieve having a player (or any element for that matter) persist across page loads like this and it seems like there are two options. Both of which I will be creating my site to harness AJAX loads:
Hash bang - This seems to have a lot of hatred across the web but should work in all browsers as of right now. It also seems to be very easy to implement.
HTML5 History - From what I've read this is the "proper" way to do this, however, it has very limited browser support at this point. For browser that aren't supported full page refreshes will occur (History.js).
So my question is: Is there a third option? Or can someone please weigh in on the above two? It seems like HTML5 History is "better" but if I need the site to work correctly in all browsers then Hash bang is my only option. Is this true?
Use history and onpopstate as the first option, but when that fails, set the hash bangs. Then make sure that your routing can handle both the hash bangs and the pretty onpopstate URLs, so that users can follow either bookmark.
I've used this configuration once myself, and it wasn't a whole lot of JavaScript. It was annoying to get it all right, but it was doable and worth the effort to deliver the best experience in all browsers.
I'd love to hear a second opinion on this if there's a better solution.
Related
This question has been asked before, but I would like a little more detail from this one, more about the audience and why.
I was never a Javascript fan, if I could avoid using it I would... but now jQuery has evolved, I've found myself using a lot of it, and really enjoying it. But I now feel I could get carried away and use too much.
1) How many people actually have JS disabled? Does anyone have precise visitor statistics/analytics that proves what percentage of visitors are disabled? If it's only 1 - 5%, should we really be caring about them?
2) What's the reason for disabling JS in the first place, seeming as it's enabled by default on all browsers? I don't understand why the browser gives us that option. I've never found a reason to switch off my JS, unless it's for testing purposes.
3) Do you think that JS will ever become a permanent browser language, by disallowing users to switch it off? Websites would be amazing (and secure) if scripts were permanent.
M application, a secure login only site, is rich with AJAX, overlays, tooltips and elements fading in and out - so much that it wouldn't work without it. But this isn't a problem for me as my users are warned at the point of registration that JS is a 100% requirement and my particular visitors actually need my application. I also have a <noscript> redirection back to the login page.
I'm asking the above questions because I'm about to redevelop the home-page to my application, which is public, but I'm unsure about how much to use and how big the audience is that would miss out on the jQuery goodness.
Thanks
1) I found this blog post from Yahoo that states that around 0.25 and 2% of their visitors have JavaScript disabled.
2) I think this is a leftover from 10 years ago. There is no reason to disable JavaScript as the usability hit you take on many websites (with some not even being usable) is a lot more than the little security you gain. I always stretch that if non JavaScript users are that important to you then create a separate version of the page.
3) I don't know what you mean with permanent. JavaScript already runs in a Sandbox so you e.g. can't access local files. Other security issues are more things like secretly submitting forms or redirecting to a malicious page.
It depends. If I'm making a 'general' website you should account for no JavaScript, slow JavaScript and poor JavaScript (like IE6). Another thing to keep in mind are mobile devices.
If I'm making a JavaScript application with heavy use of AJAX and other modern web techniques I don't even bother.
In some situations it's easier to demand availability of JavaScript.
1) The more important figure is what percentage of your users/visitors don't have javascript, and whether or not you think the extra development cost (if there is any) of any fallbacks you might need is worth it. As said earlier, it depends on your situation
2) To stop popups, annoying scripts that change browser behaviour (such as disabling the right mouse button), and such
So head to www.jabsy.com, with Javascript turned off.
Basically, I use some JQuery UI Dialogs, I use Javascript for all the bindings on the page...I pretty much use it for everything. Is that really a bad thing though?
Nothing really works without Javascript. Not even the Google Maps API.
Should I go out of my way to try and make the entire page work without Javascript? Is that even possible with my site? I wouldn't even know where to begin as I use Javascript for everything, so could I get some points? How many users actually turn off their Javascript these days?
Would it help to let the user know if they have Javascript turned off and make them turn it on before accessing it and provide them with directions how?
Yes, if your site requires JavaScript you need to let the user know that it is required.
For example:
<noscript>
<div>
You need to have JavaScript enabled to use this site.
</div>
</noscript>
You can provide more description as appropriate. A savvy user that sees this text is going to be able to then go in and turn on JavaScript for your site. A non-technical user might have trouble, but I would think most of them would be running with JavaScript enabled anyway (?).
According to data collected in 2007, about 3% of users in the US have JavaScript off. I'm sure that number is lower today.
It really depends on how critical the sections of your page that require JavaScript are. If there is a form that is mission critical, but controlled completely by JavaScript, you probably want to engineer a way for that form to do the same thing with JS on and off.
However, you have animated snowflakes on your background (for the love of God, don't really do this), it's not going to negatively affect someone visiting your site with JavaScript off.
Really, it all comes down to how important the information or actions are to your site. Turn off JavaScript and note all the things you can't do that are absolutely vital, then make them work.
Keep in mind there are several audiences that will not render your JavaScript:
Screen readers/accessible browsers
Console-based browsers (Text based browsers)
Search Engines (Google)
Your specific service (location-based messages) will be way too cumbersome to use without JavaScript (and its content is dynamic). Therefore, I see no problem requiring it. You should, however, point out that JavaScript is necessary to use your site (Preferably at the top, in really large letters). You can do that by including the alternative no-JavaScript content in noscript tags, i.e.
<noscript>
<div style="font-size: 200%;">You need JavaScript!</div>
</noscript>
However, most websites are content-based, like a company's homepage, stackoverflow or Wikipedia. These websites should be usable without JavaScript. Nowadays, even smartphones have excellent JavaScript support, but Kindle and regular phones are still too slow for JavaScript.
There is a line of argument that says sites should work without JS. Personally, I think that is tosh, unless you have a clientelle for whom this is liable to be an issue. JS is a reasonable thing to expect for many sites.
However, it is polite to let people know that this is a requirement, and inform them rather than just letting it not work. If your site is heavily JS dependent, then you may have made some mistaken design decisions, but it is probably not worth re-working it. If you monitor the number of people who get the "you need js" message, you will identify if it is proving a turn-off. I suspect it will not be an issue.
So build based on what you need, BUT tell people if they need to have things set.
You can use the <noscript><!-- html here if no Javascript --></noscript> tags and place content to be rendered in between if javascript is turned off.
I don't think there are many sites that will work with these days without it. It's more or less mandatory.
I'm trying to wrap my head around jQuery Mobile. My aim is to build a very fast application with a look and feel as close as possible to a native app (at least for modern devices).
I understand there are two ways of navigating between pages:
Loading each page as a separate page and linking to other pages with regular html anchors.
Putting all (or many) pages on one single web page and navigating between them by means of javascript ($.mobile.changePage (method) and similar api functions.
The first approach should work on all browsers, but performs quite poorly since there is a delay between each page transition.
The second looks like it should be much faster, so I would definitely prefer this approach. But how would that work for mobile device browsers without javascript support? It certainly seems to violate jQuery Mobile's aim to provide a gracefully degraded experience for C-grade browsers.
It looks to me like I need to implement my app twice, once optimized for browsers with javascript support, once for browsers without? Using may be another option, but that looks even more messy.
What's the recommended way to approach this dilemma? Is there anything I have not noticed?
Thanks,
Adrian
First of all: Your point2 is wrong.
See Local, internal linked "pages" in here and read it carefully. A link href="#pageelementid" will work just fine AND will work in any HTML4 capable browser too [might require <a name="pageelementid"> in some cases, I'm not sure anymore] with the only difference being that all the pages are visible at once.
Second thing is that if you use the way number 1 it will look quite nice too. It will load, yes, but in javascript-enabled browsers it's loaded with AJAX and there's no nasty blink between pages. Also - a "loading" popup shows up.
jQuery Mobile is supposed to let you create an application with some pure and simple html without any JS. JQM itself takes on the enhancement of the page so that it looks good and uses AJAX. Try to create an application that would work in every browser possible (my inspiration: lynx) and use JQM markup for that. Any javascript you are willing to write should work as an enhancement - making it better instead of making it work at all.
good luck with that!
The current thinking on supporting lesser browsers is to not degrade gracefully, but to enhance. If you build the website from the ground up to work without javascript then enhance it afterwards, then you pretty much know that the site will work (rather than having to fix it or build a secondary site).
As regards the two options you've specified, number one would be my preference as a mobile user if I had a limited bandwidth and also a lot of people have a restricted download amount per month.
Lumping all the pages into one large file may seem like a good idea (downloaded already), but you may well run into memory limitations on certain phones. And what if all they want to do is visit two pages, why should they be forced to download the entire website to do so?
I am in the process of building a video sharing CMS that uses lots of jQuery and ajax for everything from rich UI effects to submitting and retrieving data to and from the database. When JavaScript is disabled it everything falls apart and 90% of the functionality doesn't work.
I am beginning to think its ok to not degrade gracefully for certain types of sites like this one which uses a flash player to stream the main content - the videos. So what would be the point of going to great lengths to enable dual support on everything else if the main content of the site can't be viewed. Even YouTube breaks with JS disabled.
I'm planning to release the CMS under open source license, so the question is:
For mass distribution (and for this type of site) is not degrading gracefully a good idea?
As long as you make it clear to the users that they need JS enabled, it is ok for it to "fall apart" without JS. However, if you give no indication that it shouldn't work without JS, then people will get angry. Most people nowadays expect sites to require JS in some aspect of their functionality.
For something as complex as a CMS with videos, it is the users fault if they don't enable JS. They shouldn't expect something like that work without JS, and even if they do, it's probably not worth your time maintaining two versions of your site: JS and non-JS, especially for something that is open source.
Seeing as your application relies on javascript for its entire purpose, it is impossible for you to degrade gracefully. As long as your site clearly tells the user to enable javascript to get all of your awesome functionality, and maybe some links as to how to do so in different browsers, you should be fine. :D
You are essentially choosing an audience. It's not unlike deciding whether to support IE6. It's not right-vs-wrong, it's simply a question of what percentage of your audience you are willing to lose, in exchange for ease of development on your end.
That said, I find progressive enhancement (of which graceful degradation is an outcome) to be an efficient and safer way to develop. Do the HTML first, make it work, then add JS as sugar on top.
It's not likely that one of your users is not running Javascript. What is likely, speaking for my humble self, is that you will have some small JS error which kills everything. (JS tends to just stop on exceptions, you may have noticed.)
It's nice to know that, in the event of such an error, your users can still use the site. That's what graceful degradation is for, in my opinion.
Graceful degradation doesn't mean "everything works fully in every browser", it means "if your browser can't handle something, you see something sensible instead of broken junk".
In your case, simply detecting that the site will not work and displaying a nice error page explaining what is required would be an acceptable form of graceful degradation.
If you're a perfectionist, there's nothing wrong in letting people w/o JS know what's going on, as opposed to just letting the website break. Here's a quick how-to: How to detect if JavaScript is disabled? .
I want to use google gears, not for functionality but for optimization.
I.e. if gears is detected in the browser side, then we will silently use it to do some optimizations and caching in the client side.
If it isn't installed we silently work against the server only.
Somewhere in the FAQ or help pages of our website we will tell the users that our site recommends gears for best performance - but it is not a must, we will not use "offline features".
Do you think this is a valid google-gears usage scenario? Do you recommend for it / against it?
Sounds like a valid usage scenario to me.. just realise that you won't be able to do it 100% transparently as the user will have to tell gears to allow your site to use it. With that in mind you should definitely make it an opt in thing (as described in the gears faq), rather than just attempting to use it if you find it installed, otherwise you'll annoy your users more than the slightly worse performance ever would have.
I think its a good possibility, but why try to hide it? As mentioned in other responses, the process can never be truly transparent, since some initial setup will be required at some point. Instead of hiding the feature, (depending on your project) you could use it to generate some positive press regarding your application.
Maybe by default you serve content from the main server, but along the bottom or top, include a highlighted link (think of "What's New" in Gmail). It could say something like "Improve performance by 50%" etc. The next page might contain a quick summary of whats going on, and why a user would commit to Gears. Similarly, when this launches, you could use the opportunity to show off "what you're spending development time doing."
I understand why you might want Gears to be unobtrusive, but don't make it hard for the user to get the best experience on your site.
Wordpress also promotes use of Gears in part to speed up actions - and Gmail in offline mode (or at least with active offline support) is also (IMHO) faster to use.
I say go for it - and if you can add offline support - and it makes sense - do that as well!