When designing and building the UI for an application that uses AJAX, when do you consider graceful degradation (for users who have JavaScript disabled, or are using a screen reader)?
At the end, once the AJAX version of the site is completely finished
At every stage of development
I don't
Something else...
These days, progressive enhancement is generally preferred over graceful degradation - i.e. the exact opposite approach.
The method I'm employing so far is to write it so it works without JavaScript and then add the JavaScript on top.
It's really the reverse of graceful degradation. It's an emphasis on enhancing the page as your browser and settings allow.
Relevant article
Graceful degradation can describe two things:
It is a behaviour (normally a website or web application) that allows the site to continue functioning when certain features are disabled (e.g., JavaScript; CSS).
It is an approach that builds the application to work with bells and whistles turned on, and then afterwards fixes are bolted on to make it work without said noisemakers.
I assume you are asking whether or not to use the latter to achieve the former. I'd definitely suggest achieving 1), as anyone who browses with JavaScript off (i.e., lots of people with a computing clue; those using text-based browsers; those using disability aids) will otherwise not be able to use your site.
As for how to do it, A List Apart have a great article on progressive enhancement which is worth looking at, where you build the site to work basically first, and then you add the AJAX, etc. afterwards. I prefer this approach because it gives the app a solid foundation to work on, with decent security and functionality from the word go. Future enhancements to it can be made at the basic level and then added into the AJAX layer; without the former, it's harder to add in gracefully degrading components to the application in the future.
Anyway, enjoy the article and if you want to know more about this stuff generally, A List Apart is a great site!
Jeremy Keith sums up the argument for progressive enhancement with his Hijax article.
Typically, I use the following code to dynamically apply a class of "js" to the HTML element to target JavaScript-enabled browsers
<script type="text/javascript">if(h=document.documentElement)h.className+=" js"</script>
Related
I have been using Dojo and Dijit for more than a year to develop a browser-based IDE. Dojo is a great framework. But creating an IDE-like interface using Dojo is cumbersome and wastes a lot of time unless you are a CSS superman. I have a good understanding of HTML5, JavaScript, and CSS. Building the UI I needed required several CSS hacking that I found by trial and error. There was no systematic way to get from the UI design to the implementation and I am afraid to change the UI layout because any simple change can break the UI, mostly by adding irrelevant scroll-bars to Dijit panes where I do not need them. (the complex UI has 4-5 levels of nested panes including mostly border containers and content panes)
Recently I have come across SproutCore and Cappuccino, which have great demoes and their look and feel is more desktop-based. There has been several discussions comparing these two with each other. But none of them talk about how systematic and quick is it to get from UI design to implementation? Ideally, I should be able to implement the UI I want not more than a couple of days (Assuming that I know the framework), and changing them in the future should be easy.
The other difficulty with Dojo is that I have to work directly with DOM, to append and remove dijit widgets. While I do like to keep this flexibility, I wish I could use a higher level of abstraction to define the application UI. I have read about MVC in SproutCore and Cappuccino, but I am wondering if in practice the provided abstraction layer speeds up the UI development? or the provided layer is a fancy architecture that only increases the readability of the code? Will I lose the direct access to DOM if I build my UI using these abstractions?
Cheers,
Navid
Cappuccino is much higher-level. You write in Objective-J, not HTML/CSS/JavaScript. I personally do not recommend it as Objective-J is a niche language and you'd be stuck with something not widely-understood by everybody. You'll find it more difficult to look for answers to problems, and other people will have more difficulty in maintaining your code.
However, due to it being high level, it does shield you from the drudgery of programming in "standards" (i.e. HTML/CSS/JavaScript). Therefore, you should be able to develop UI's faster and easier, but you'll have to instead learn the ins-and-outs of Objective-J. All-in-all, not much to gain here, I suppose.
SproutCore, on the other hand, is HTML/CSS/JavaScript based, so you don't really have to relearn the basics. It follows the MVC model of separating UI and data concerns, so programming UI's should be easier.
My personal recommendation is to stick with Dojo -- 1.6 has come out, which has change-tracking, state-tracking and bining support. 1.7 is around the corner. The MVC module is improving fast. The next version, 2.0, will be quite awesome. It is being actively developed on, and so you won't be left behind.
Dojo can also be used with the Closure Compiler's Advanced Mode to make highly-compact, highly-optimized, fully-obfuscated builds for deployment. Other JavaScript-based frameworks are not as adaptable.
Cappuccino most definitely goes beyond just improving readability. If you don't want something to have a scrollbar in Cappuccino, don't give it one. That's pretty much the end of the story and one of the great advantages of using such a framework. In my experience, HTML and CSS is just an endless troubleshooting session. With Cappuccino things go where you say they should and stay there. And this is true across browsers as well (most of the time).
Furthermore you can, if you choose to, build your user interface using Interface Builder and Cappuccino's nib2cib utility. This makes it trivial both to initially lay out and to then later shuffle buttons and controls around.
Have you considered jQuery and the jQuery UI?
Many big website (google.com, apple.com, microsoft.com) are never validated. When the big shots don't do it, is there a reason why others should?
w3.org provide a page dedicated to people asking just that question, it's here.
Of course places like Google and Microsoft are there to appeal and should all be consistent across browsers. The w3 does have some good points
Using standard, interoperable markup and stylesheets, on the other hand, offers a much greater chance of having one's page handled consistently across platforms and user-agents. Indeed, most developers creating rich Web applications know that reliable scripting needs the document to be parsed by User-Agents without any unexpected error, and will make sure that their markup and CSS is validated before creating a rich interactive layer.
When surveyed, a large majority of Web professionals will state that validation errors is the first thing they will check whenever they run into a Web styling or scripting bug.
Another very important point is maintenance. A strictly valid XHTML document as much easier to maintain than a bowl full of HTML tag soup. Trust me.
We must remember that the markup is there as a data format. The way a browser renders this markup is what's generally important to a user.
Do remember: household-name companies expect people to visit because of the name and in spite of dreadful websites. Can you afford that luxury?
They are probably validated, but need to support older browsers (like IE6), so comptability-code is added.
Just because someone else doesn't, doesn't mean it's not a good thing. When you validate, you not only find out if your pages are well-formed, but you also track down bugs in your code, make the web pages easier to maintain and your code is more likely to work cross browser as well with future browsers. In addition to this, it shows that you take your job serious and that you have a good habit of trying to generate quality code.
Staying strictly within a known range of syntax (or technologies, in general) is good for optimizing maintenance costs, because all technologies you depend on (browsers in this case) are very well tested for the standard-conforming cases (subset of HTML/CSS/JS) only and are only randomly tested beyond.
I have been following the usage of JavaScript for the past few years, and with the release of extremely fast scripting engines (V8, SquirrelFish Extrene, TraceMonkey, etc.) the possibilities of JavaScript have increased dramatically. However, the usage share of Internet Explorer coupled with it's total lack of support for recent standards makes me want to drop a bomb on Microsoft's HQ, as it creates a huge amount of problems for any website.
The game will need to be pretty dynamic client-side, with animations and other eye-candy things, but not a full-blown game like those that run directly in the OS using DirectX or OpenGL. However, this might be a little stretch for JavaScript and will certainly feel extremely slow in Internet Explorer (given that the current IE engine can be hundreds of times slower than SFX; gotta see what IE9 will bring), would it be better to just do the whole thing in Flash? I know this means requiring the plug-in AND I have no experience whatsoever with Flash (other than browsing YouTube :P). It also means I can't just output directly from PHP, I would have to use XML or some other format to pass data to it (JSON is directly integrated in JS and PHP can deal with it easily).
Another idea would be to provide an alternative interface just for IE, though I don't know how (ActiveX maybe? or with Flash, then why not just provide it to all browsers) or totally not supporting it and requiring the use of other browsers, although this is plain stupid from a business perspective.
So here am I, wondering what approach to take and thus asking for your advice. How should I build the client-side? AJAX in all browsers, Flash in all browsers or a mix (AJAX for "modern" browsers and something else for the "grandpa": IE).
I recommend a plug-in platform (Flash, Silverlight, or Java) over AJAX. Having a clean layer of abstraction between your game and the client's browser is a big advantage. In any non-trivial AJAX game look forward to endless corner-cases where browsers differ in performance or implementation.
Personally, I think Flash is easy to learn if you are coming from AJAX experience. Flash is currently the most widely installed and proven plug-in for browser games. However, Silverlight and Java are both building momentum. Also, the Unity engine has become a popular choice for commercial browser games.
I think you shouldn't leave Java out of the equation. It's a powerful, fast language, and with Java applets, you can do almost anything. If you want hardware-accelerated graphics via OpenGL, JOGL can do it, even in an applet.
On the other hand, it might not be right for you. But at this early stage, I think you should evaluate all of your options, and since you have no experience with Flash but sound like you've got a bit of programming experience, you might feel more at-home with Java.
I believe the current answer is Flash game.
Alternatives:
Java Applet: getting less and less common those days and it is not commonly installed as a plugin on many computers.
SilverLight: too new and might vary and change in time. not commonly installed on many computers and it's Microsoft (whom tends to change technology every 2 years ...)
JavaScript / AJAX: Still a new kid on the block, it's on the rise it is true with many nice features, but still lack of good cross browser for IE even IE8, can not play sounds internally, still slower than the others, and you don't know where will it evolves.
Eventually probably the best solution for now is Flash development:
Cross platform. Works fast. Long time already alive and have a lot of support.
I hope this answer will change in the next year. Happy Peasach.
Check out Jmonkey. The "plugin" loads if you have Java on your machine. Once it's cached, the next time the visitor goes to the page, it your game loads very quick. Check out their website for demos and see what I mean: http://www.jmonkeyengine.com/
Oh, I forgot to say, it's a 3D scenegraph Java engine. I just tried it again, and it loaded in linux. Looks they've put in some good work.
Don't do it with javascript in the browser. And Flash really can be a pain just because it's closed source and you don't know if you've made a mistake or found a bug - speaking from experience. I'd never want to make another Flash game again.
How about using RaphaelJs , it is a Javascript library that make dinamyc images using SVG, and for IE, it try to make those images using the IE alternative: VML. Im using it on my own WebGame, but i dont really make complex graphics in it. The most complex thing done on RapahelJs was a heath map (20 * 20 tiles ) with a dinamyc opacity slider. An it work with jquery without any problem or configuration!
Suppose I'm writing a 2d tile based MMORPG.
Furthermore suppose I hate flash.
Lastly, suppose I only need my code to run in the latest safari, latest firefox, and latest chrome.
What are the limits to what I can and can't do? (Are there examples of good game engines that only require a recent web browser)?
Look into HTML5 Canvas http://en.wikipedia.org/wiki/Canvas_element
The latest versions of the browsers you mention already support it.
Check out the Unity3D engine: http://www.unity3d.com
Cross-browser, cross-platform, although your users would have to download the unity browser plugin...
There's also the Raphaël javascript library...it does a very nice job of abstracting a lot of the heavy lifting you'd have to do otherwise! The memory footprint seems decently light as well (from my small-scale playing around with it anyway).
For something that works for the user, OOBE (without add-ins etc); Javascript is probably the only unified functionality that exists between all browsers.
The browser is surprisingly quite capable (at least Chrome is), this is something that Google Chrome is attempting to promote (see http://www.chromeexperiments.com/). Notice some however, that experiments are often laggy or unworkable in other web browsers.
As for a list of things that are and aren't capable; that would take a fair while to compile.
In regards specifically to a 2D tile based game, I wouldn't say it isn't possible, but it may be quite difficult to create. As mentioned before, most browsers (apart from the stand-out; Google Chrome), suffer from limited resources. Therefore resources wise, it may be difficult to implement and would defiantly require a lot of requirement fore planning.
Java applets are also possible...
You could also move to 3D. While it does require a plug-in (although is being integrated into Chrome), the results are undeniable.
"O3D is an open-source web API for creating rich, interactive 3D applications in the browser." http://code.google.com/apis/o3d/. The video is quite amazing actually -- especially the live map editing (e.g. removing sprites).
Jeff mentioned the concept of 'Progressive Enhancement' when talking about using JQuery to write stackoverflow.
After a quick Google, I found a couple of high-level discussions about it.
Can anyone recommend a good place to start as a programmer.
Specifically, I have been writing web apps in PHP and would like to use YUI to improve the pages I am writing, but a lot of them seem very JavaScript based, with most of the donkey work being done using JavaScript. To me, that seems a bit overkill, since viewing the site without Javascript will probably break most of it.
Anyone have some good places to start using this idea, I don't really care about the language.
Ideally, I would like to see how you start creating the static HTML first, and then adding the YUI (or whatever Ajax framework) to it so that you get the benefits of a richer client?
As you've said
To me, that seems a bit overkill, since viewing the site without Javascript will probably break most of it.
This isn't progressive enhancement. Progressive enhancement is when the site works perfectly without JavaScript or CSS, and then adding (layering) these extra technologies/code to increase the usability and functionality of the website.
The best example I can give is the tag input box on this website. With JavaScript turned off, it would still work allowing you to enter tags separated with a space. With JavaScript turned on, you get a drop down with suggestions of previous entries.
This is progressive enhancement.
See also Unobtrusive JavaScript which is the bedrock progressive enhancement is built.
Going at it from the other direction is sometimes referred to as graceful degradation. This is usually needed when the site is built first with the enhanced functionality afforded by the various technologies then modified to degrade gracefully for browsers with those technologies are not available.
It is also graceful degradation when designing to work with older browsers (ancient in the Internets terminology) such as IE 5.5, Netscape, etc...
In my opinion it is much more work to gracefully degrade the application. Progressively enhancing it tends to be much more efficient; however, sometimes the need to take an existing app and make it accessible in these lacking environments arise.
Basically, if your site still works with JavaScript turned off, then anything you add with JavaScript can be considered progressive enhancement.
Some people may think that this is unnecessary, but plenty of people browse with addons like NoScript (or, with JavaScript simply turned off in their browser settings). In addition, many Mobile web browsers may or may not support JavaScript. So, it's always a good idea to test your site completely with and without JavaScript.
Progressive Enhancement is a development technique that stresses the primacy of the semantic HTML, then testing for browser-capability and conditionally "layering" on JavaScript and/or CSS enhancements for the browsers that can utilize those enhancements.
One of the keys is understanding that we're testing for what the browser can do, as opposed to browser-sniffing. Modernizr is a very popular browser-capability test suite.
Progressive-Enhancement is inherently (section 508) accessible; it provides for meeting the letter of the law and the spirit of the rule.
The Filament Group wrote the excellent "Designing With Progressive Enhancement" book on the subject. (I am not affiliated with Filament Group, though they are so freaking smart I wish I were.)
This is such an important concept and it saddens me that so few web developers understand it.
Basically, start by building a site/framework in Plain Old HTML -- structural elements, links and forms. Then add on some style and then shiny stuff (Ajax or what have you).
It's not very difficult. Like palehorse says, graceful degradation is more work.
Websites should work in any user agent, not look the same (not even look but sound if your vision impaired), just work.
Progressive Enhancement:
The plain HTML/CSS site is awesome (fully working and user-friendly).
Adding JavaScript defines a new level of awesome.