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.
Related
Wordpress kind of sets the standard for great interfaces for end-users. Drupal is a little more mixed: it is a great experience if the developer updates the UX when they update the site functionality. Concrete5 and other CMSs basically exist soley on the merit of their end-user experience.
Where does ExpressionEngine fall into the mix? How much control does a non-developer admin have with EE, and how pleasant is that interaction for them?
That's really up to you. The backend of EE is completely customizable. It's a blank canvas by default, so you get to build your own backend that is fully customized to fit the exact needs of the client. You can give them more or less control as needed, and you can create different user groups that see different things (including different modules, different menu items, different channels, even different fields within a channel, etc.)
If I'm working with a client that needs a fairly straightforward site (read: brochure site/portfolio site with or w/o blog) and they're not terribly computer savvy, I almost always go with EE because I know I can make it dead simple for them to update their content. For users with a little more knowledge, I tend to give a little more flexibility. It's really up to you how you set it up for them.
I've never had a client complain that EE was difficult to use, and most are actually really surprised at how easy (and some use the word "fun") it actually is.. great confidence boost for people who have always had difficulty updating their site in the past or had to rely on others to do it for them.
Hope that helps :)
I've been asked to research what the best practices are when building the international version of your site.
The main question being asked of me is how we handle Chinese and Arabic.
For example, when the user selects Arabic as a language, should only text be right aligned or should our nav, logo and general layout also switch around?
When comparing to other large corporations, Apple and IBM don't change their layout but Microsoft switches almost everything around.
My good friend Google hasn't been much help so I was hoping someone here could help me out. Does anybody have answers? Some tips and/or resources?
This is a very broad topic, but you did mention that Microsoft "switches everything around," so I'll talk a little about that.
There are a few components to supporting many cultures with your application. Some of the considerations might be:
According to the W3C, internationalization refers to preparing your application for other cultures by removing hard-coded strings and making other kinds of resources, like images, localizable. This should be part of your software design/build/test process from the beginning.
Localization can be broken down into two specific areas:
Language localization is the focus of most international software. Strings and images are converted to another language and loaded dynamically using the current culture.
Cultural localization (something for which Microsoft is famous) is the practice of changing UI elements to better-fit other cultures. For example, in the US, red implies an error or unfavorable message. In other countries, this is not always the case.
For software to genuinely be cross-cultural, you need to address both types of localization. For your web site, though, it's probably sufficient to localize the language strings and images as appropriate; you probably don't have the resources to have user interaction designers working on laying out your application for different cultures.
As ever in UI design, "it depends."
In this case the things you want to check include:
What kind of users are you expecting? What technical level?
What Web experience are they used to?
What resources do you have for the localisation?
Technical users (e.g. developers) will most likely prefer the same layout on the site as other content.
For Arabic, while Web-savvy users are reasonably familar with left-to-right usage, it feels "wrong" and so your site will need to be quite compelling to make sure people stay. If you can change your layout then do.
For both Arabic and Chinese there are many customs and idioms that are quite different, especially when it comes to graphic design. Popular sites in particular look much "noisier" than is usual in the West: a site like stackoverflow.com would be very minimalist in these cultures.
Similarly be careful with things like lucky and unlucky numbers, colours with traditional associations, and suchlike. (This naturally goes everywhere: I could mention the comments we had from Northern Ireland about a very orange-branded theme that was once chosen for a site I worked on...)
What I'd recommend is that you allocate some of your translation budget to a local native-speaking UI consultant. They'd be able to give you proper advice on what bits of your site need to be localised as well as translated.
This guy has a raft of information. Beyond that, my problem is that I'm used to helping people do this via a multi-day consultation, and I'm not sure how to summarize into a post that fits here. That really isn't our business any more, so, honestly, I'm not shilling for work.
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>
My company makes its money off of a great user experience using IE6, 7, Firefox and Safari. 90% of our traffic ends up IE and probably 60% of that traffic is still IE6. IE6 has a bunch of known gotcha's such as accessing DOM objects while they are still being inserted crashing the browser. Almost none of these issues surface during routine testing, they almost always include some odd timing race condition that only affects our most important client of the week.
What process or tools do you use to ensure that known patterns that crash IE are not present in your code?
Added: For those suggesting sticking to 3rd party libraries: I agree that it will help a lot, but you still have to glue those APIs together with Javascript. Is there anyone that is not just crossing their fingers and waiting for someone out in the wild to let them know that there code has just crashed their system?
We don't worry about it. Instead, we use a third party tool like jQuery (well, EXACTLY like jQuery in our company) to ensure cross-platform idiosyncrasies are handled.
I recommend you rely on as many popular 3rd party frameworks as you can. They've undergone far more revisions and testing than you can ever perform. Obviously this means you should be using jQuery for all your JS related work.
Unfortunately there is no silver bullet for these browser bugs, as long as you go with JS & HTML you will continue to have these gotchas. At best you can compile a list of them, publish them on a blog, let the community discuss them and make sure all your devs learn them.
This is an example why Flash and SilverLight exist, which may seem like shocking suggestions considering you've spend an unmeasurable amount of time developing your UI, but if you want to be free of browser/OS bugs, going with a 1 company delivery package is the only way to break the 99.9% barrier for web bugs.
I do a try on window.event.srcElement (which'll only work in IE) and put the non-IE stuff inside the catch, and tie stuff up in my finally.
All other browsers seem to throw an exception with window.event.srcElement so I use that line first and if it gets passed that line it'll obviously be IE so I place my IE code there, if it ever goes to the catch it's clearly a browser that is a bit more standards compliant so I put the alternate code there.
This has saved my ass a lot when it comes to writing Javascript events dynamically using server side code that involves mouse events.
Hope that helped, gives you a way of supporting multiple browsers with different code without server-side detection.
Beleive it or not some of jQuery (and other libraries) functions don't work on all browsers.
Beleive it or not some of jQuery (and
other libraries) functions don't work
on all browsers.
Ofcourse, if you relate to IE5 or NN4, jQuery may not be the best pick. Otherwise, you won't have a problem with this.
I use jQuery for a HUGE site and i don't have problems with library. I have problems with plugins, but this is a different story.
And btw, i have less than 10 lines of pure js in my files. If you learn to use jquery efficiently, you won't need any js knowledge (sounds weird, but... this is my case :P )
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.