How should we incorporate W3C's recommendations into our Web development?
The W3C specifications are sound; in most cases, but they are incomplete. Therefore, there exists a lot of room for interpretation when it comes to Web site development.
Allow me to start with a common recurring issue; with respect to today's W3C specifications and whether or not they are in-line with how we want our Web documents to function, it is all part of natural progress. For instance, tables for layout were okay to use in the 90s because they did the job at the end of the day (relatively speaking), however, today, depending on needs, we most likely can't say the same for table based layouts. Today, floats for layout is considered to offer the most viable solution. However looking at where CSS3 is heading and even the Markup structures, float based designs most likely will not be 'the' layout solution for tomorrow's Web.
If the Consortium's recommendations are always in an evolutionary process, how then are we to develop sites? Let me put it this way; today's competitive sites - in the interest of getting attention - are constantly in change. Whether they are presenting cutting or bleeding edge technologies in the field or simply even on the Web to have presence, to some extent, they require updates and maintenance. Realistically speaking, those sites that fall into these categories are in need of an update at most every 3 years (take this number with a grain of salt) by today's standards.
So then based on this important bottom line, can we raise the following conjecture; design for today and the very near future if resources allow as such.
Now you may be saying, what about... ya but.. so? The point is to accommodate for today's needs and not to worry about the tidbits of development as if it were to be a one time solution for the next 10 or 100 years to come. If you are in the Webdev business and interested in this field for many years to come, then allow me to suggest; do not worry. The Web is constantly evolving and at this far in the game, the Web as you know it will not be the same in 5, 10 or any x number of years. I am perhaps stating something very obvious here, yet it is apparent that it is widely overlooked. On the other hand, it is essential to keep this in mind: how costly will it be to bring today's documents up to speed in 5 years - facing extensibility? The answer is hidden within compromising among possible solutions from the marketability standpoint.
If you love this art form, do know the specifications well as it suits your needs, yet at the same time do acknowledge its shortcomings and the very nature of Web's evolvement. I tell you, this is the compromising I speak of when you have to get things done. These technologies are merely tools, and they are here to help us with our work. One must not go the other way around by altering the requirements of their projects just to satisfy incomplete specifications.
There is a good chunk of developers out there that takes pride in doing things the right way. The very nature of this mentality exist for two reasons. First being the separation of the level of their competency from the rest of the developers that do not or in-need to follow the best practices. This can essentially open up many opportunities as they may seem to better fit to take on projects then the other developers. Who is to question then for such accomplishment if they are certainly more equipped to do the job well? However, there remains one important point; being technically savvy is not always in positive correlation with having good business sense.
Secondly, there seems to exists a rush to being the purist when it comes to the W3C recommendations. The Standards developers can then only show their competency among other developers whom already follow the good practices. By this, there exists a perception of being more competent then the average good developer, yet overlooking the core project goals. For instance, many Web standards designers can push their knowledge and proper way of applying the W3C documents, yet neglect to apply them in the right places. For small scale, personal, focused target audience sites, this idealistic approach will do wonders and allow them to achieve the most respect within the community, yet the same practices in which they preach of do not necessarily play well with all the complexities of sites where the user base, scope, and the goals of the site vary.
May we remind ourselves that the W3C's specifications are only recommendations? Perhaps it should have been termed differently like; rules or laws, in which the resulting practices would possibly have been different. I personally tend to think of them as good guidelines. If they make sense to you for your real-world development then who is to stop you from using them? Not to mention most of the established specifications have been through a lot of revision by many people, groups, and organizations to push them forward to suit the needs of today's and future's Web. A lot of resources have already been allocated and used on establishing such practices and it would be foolish in my opinion to not take advantage of this but to integrate them in our work. In most cases, they are beneficial to us.
What I'm trying to say is, use your best judgment when it comes to W3C and other Web technologies, and make the best out of what's suitable to your needs. Thank you for reading.
With experience, professionals gain more and more knowledge about doing things, which their peers consider "right", and other things their peers consider "wrong".
In time the list grows and you have the option of being realistic and pick what is "right" and "wrong" and what is just "ok" on a strictly per-project basis, so that you meet your project requerements.
Or you have the option of thinking in absolutes where every project "must absolute follow all these with the punctuation and the spaces" and religiously defend your best practises at the cost of project deadlines, expenses and common sense (and claming otherwise anyway).
Web standard "zealots" fall into the latter group. Standards are here to help us develop, not help us find reasons to call our peers "stupid" for not being religious enough about putting a legend tag in their forms.
We have modern English because human language was not set in stone as a standard couple of hundred thousand years ago: instead people left it develop and transform in a natural way to conform to the changing requirements of the society. Not that there are no linguistic experts to mock you for using a dialect form of a word, which is basically their manifestation of "standard zealots", but the other folks realize this is not actually so important, as long as we can convey the meaning and data we want to, in speech and writing.
Web development has come a long enough way, so that it has segmented into different "sub professions" - like server side development, server administration and management, graphics site design, HTML/CSS design and so on.
To see how shallow our religious arguments seem in the real world, it's enough to see how much that ALT tag missing from the navigation images seem to a PHP developer, who on his own is fanatic about using single quotes instead of double quotes in his code string literals, because they are 0.001% faster (that's true btw), and he doesn't care about HTML "properness" at all, as long as it looks right and is secure on his side.
In the same fashion the color scheme balance or how soft the shadows under those icons mean nothing to a usability expert who only wants that the text is large and readable, the navigation easy to access and the page is light.
That same site to a graphics designer would look like a "wrongly done" site, since noone would enjoy to visit and use it, because it looks like a home page attempt from the 90-s (I'm looking at you, Jacob Nielsen). And this graphics designer would proceed making the site "right", using techniques that would make a usability guru pull his hair out.
To a copywriter, neither design nor accessibility or server security would matter, but he'll start making fun of me if I skipped a comma or had a typo in this post, for example.
But even more, to our end user, who in most of the projects is just your average folk, who won't judge for your site by the presence of the XML prolog in the source, completely different stuff matters: "is it good enough", "is it usable enough", "is it accessible enough", "is it nicely looking enough", "does it work well enough on my device".
Surprisignly, the barriers a regular user uses for considering your product (ex. a site) "overall good enough for me, so I pick it" is a lot less a function of being extreme in any of those disciplines, and a lot more about having a smart balance and compromise between all of them.
And this, zealots will never tell you about.
I believe that standards are a very important aspect of any business. While more important in for instance construction since not adhering to standards could lead to a loss of life. They are still important web development. It's these standards that application developers follow when producing products designed to parse html (such as web browsers). If the standards are also followed by the website developers it's more likely that the site will work in untested browsers.
Before tables were invented (with the ability of not having borders) the layouts were basic, then tables came along and it didn't take long before people discovered that they could use tables to create much fancier looking websites. Broadband then arrived and amount of graphics on websites went up, however at that point no one really gave much thought to accessibility since IE was still pretty much all that was used to browse the web. We've now entered a time where many different devices and so different browsers can access the web, portable devices etc. Due to this there is a push away from using tables and to using HTML the way it was originally designed for (marking up paragraphs as paragraphs etc). CSS is then used to add style however the designer wishes. Unfortunately CSS that is supported is still in a relatively infantile state many of the issues and complications that are involved by using CSS are fixed in CSS3. For example instead of using floats for layout which like tables were not really designed for the job, we have CSS3's Advanced Layout Module which is designed for the job.
Basically what I'm saying is that web development is no different to any other business. Standards should be followed and techniques will constantly evolve. It is the job of the web developer to keep up to date with these techniques. No site designed today will be good code in 15 or so years when CSS3 is usable. Just as computers, cars etc made 15 years ago tend not to be considered all that great.
Everything in moderation... going zealot doesn't help anyone. All you end up doing when you become a fanatic is lose focus and take the purpose of web development way out of context. Real web development isn't building blogs that validate. Real web development is meeting your clients requirements in the best way possible. That includes not only conforming to standards, but making sure you also fall within budget, deadline, and user base constraints. You can't just drop your head and run headlong toward "web standards, web standards, web standards" and trample everything else in your path. You need to think "business" as well as "conformance".
Besides, who ever said the W3C recommendations were gold? If anything, technical specs should NEVER be left open to interpretation. What kind of silliness is that?
The order of how you should design a page is:
- Figure out what your site's reason for being is.
- Who is your audience
- What is the life cycle of your audience - do they have different needs at different times? If so treat them as different groups.
- How can you do #1 for everyone in #3
- Layout an architecture that makes sense and servers everyone in #3
- Get meaningful content for everyone in #3 that can be refreshed on a regular basis (i.e., give them a reason to come back)
- Create an interface that everyone in #3 will understand - i.e., where they always know what page they are on through perhaps a breadcrumb, page title, consistent and highlighted navigation, etc.
- User testing on sample audience of #3 to see if your layout works.
- Now build your site using standards
As you can see, a site that works - that actually thinks about it's audience, goes through at least 8 steps before getting to the web standards issue.
Web designers spend too much time thinking about how a site will be built, and how it will look - and not enough about thinking about who a site serves, how it serves them, and give them a reason to come back. Users come back to sites that serve them what they want without a lot of hassle - not one that was built on standards.
Standards are very important - but a designer should get the first 8 steps right first.
Sarven, greeting, good points in this article.
Especially this one:
The Standards developers can then only show their competency among other developers whom already follow the good practices. By this, there exists a perception of being more competent then the average good developer, yet overlooking the core project goals.
I would love to hear more about your ideas on project goals being overlooked. I'll talk to you soon.
"Design for today" is a good point but it leaves a lot of space for interpretation. Some think that tables for layout is "today" and some think not. Determining this is not something we can get help from the standards bodies with, they are busy with CSS4.
Instead I think a good way is to read and talk with a lot of real web developers and ask them what's the best way of making a website is. Today I wouldn't say that they would answer "tables for layout" any longer.
I also have to disagree with suv4x4: The use of technology have very little to do with whether someone picks your product or not. Suv4x4's comment about breaking away from current best practices for the best of the customer have never been more false.
I'm still waiting for the day when what you design in photoshop or some equivilant is exactly what shows up in EVERYONE'S browser. Hopefully bandwidth with no longer be any relevant issue in the next 10 years. I'm all for standards... but it's sad in todays 'web tech' fields... web standards has become an oxy-moron.
Yes, you make a really great point here! Its great to have pure w3c complient code but it can take a lot longer to implement complex designs under tight timelines and budgets.
I do tend to largely blame internet explorer and its pathetic support for web standards, which has greatly obstructed the progress of the web over the past 5 or so years, not to mention costing developers countless headaches / hours of extra work and clients billions of dollars. Hmmm we can dream though... universal CSS4 support!
Regarding "design for today": most definitely things will change in the future and no web site will be everlasting. However, different parts will change in different ways.
I can't think that, as long as we use HTML for the content, that it will move away from proper semantics (e.g. from h1 to a div with). So, in the future when a web site needs to be updated, you will probably only have slightly modify the HTML but then apply a new CSS with new features do it.
My belief is that while designing properly for today, I don't think it has to be rewritten from scratch the next time around.
A Proposed Recommendation is still a "work in progress" and may still be updated, obsolete, and replaced. But even if it does not imply any official endorsement by the W3C, most often a Proposed Recommendation is close to the final Recommendation both in content and in time.
I agree with the point of departure of the article. Bad designers ignore standards, good designers adhere to them, and the best designers are intelligent enough to know when the rules stop being applicable. Common sense kicks in.
In fact, a designer who wouldn't even break a rule when abiding by it yields bigger problems than it solves, is not unlike an Immanuel Kant adherent who wouldn't lie, even to save lives. What duty-based ethics and web standards have in common, is that they both provide a very sturdy framework, aiding us in deciding WHAT IS RIGHT. They're great, but all too often, people trade in common sense for blind reverence.
"One must not go the other way around by altering the requirements of their projects just to satisfy incomplete specifications." Because that would be like Microsoft's approach to backwards compatibility - staying compatible with a precursor built like a card house is never worthwhile. XD
Now, I do think you made a few (possibly) false assumptions, or at least omissions.
1. You seem to assume that each and everyone of the people reading this is fully adept in web design, and can make a right judgment on the applicability of standards each and every time. However, some people, especially those who haven't yet fully grasped the abstract concepts behind separating structure and form, might even see this as an excuse to perpetuate bad design practices. Causing bad user experiences every day. (._.) 2. The attitude towards standards adherence shouldn't be dictated by economics and scale alone, but also by the very nature of the content that is being represented. While this pragmatist attitude will yield excellent results for an online store, it could turn out very badly when dealing with archival, historical and similar content, that will be stored for decades or even hundreds of years, and needs to remain legible whatever the case. It simply wouldn't be viable to make changes and fixes to those documents every few years or even decades. 3. I could be very wrong, but I don't think using tables for layout was ever a recommendation by any standards body. The number of standards being dropped, elements being deprecated; in other words the pace of evolution, has been catalysed a lot by bad design practices (and emerging new possibilities, of course), necessitating further development of standards. However, I feel that those efforts are directed for a large part towards decreasing the need for future game changers, and making the implementation of the remaining few easy for designers/authors. For instance, separating structure and form save us editing unbelievable amounts of spaghetti HTML code, even when most of HTML would be rendered a thing of the past.
(Also, hasn't the standards movement mostly been about either restoring or pushing forward concepts that where conceived at the very beginning of the web? I guess it's too early to tell whether standards will keep evolving at this pace, and whether they will need to.)
(I would like to hear more of your thoughts on this topic if at all possible)