Pixel Surfers

Andy Rutledge wrote this post about web standards that I thought was a pretty good description of the “why” behind standards. He says that web standards are not being marketed properly; that it’s not about compliance, but about quality. He says:

The general public does not care about Web standards any more than it cares about the minutiae of standards for aircraft hydraulics. The airplane just better damn work right. So the general public does care about product quality, and companies or craftspeople that are known to produce low quality products are not well regarded, and for good reason. Standards are for organizations to sort out amongst themselves for their own edification. Quality is what matters in the end. Quality is what matters to those who have to interact with products.

He makes the point that W3C and the Web Standards Project have done a poor job selling web standards to the design community at large to whom “standards” come across as “arbitrary rules”. Well, Andy actually works in a web design firm with other designers, so he may have contact with a lot of designers that are bucking the standards trend “just because”. However, as someone that has only gotten a grasp of how to do web design over the last several years, I know that from the moment I read about web standards, I wanted to adopt them. Why? Because I wanted to design web sites right. It was never a mystery to me that it is about quality that had multiple benefits to the user, the site owner, and the world at large. Perhaps a large part of the credit goes to the Academy of Web Design, where I was taking classes, which introduced good reasoning for standards early on. I must admit that as I went online in search of more information, though, I found the same overarching “quality” arguments that Andy makes in his post made again and again by others, if not in those exact words.

In fact, the challenge for me has been to some up with a way to express the difference that abiding to web standards makes to customers. How do I explain that what I do is different than what a web designer that doesn’t care about web standards does? The following is part of my attempt to explain this difference in a very generalized way from my business site:

Beauty is more than skin deep

What if you brought home a beautiful new Ferrari, only to pop the hood and find the engine put together with rubber bands and duct tape? Unfortunately, this is the way many web sites are built: slick and shiny on the outside and a tangled mess of code “under the hood”.

And messy code is, in the long run, expensive.

* It is expensive to maintain.
* It is expensive to change.
* It is expensive in terms of server resources.
* It is expensive when it costs you customers as the web site or web application “breaks” and loses functionality.

and

Beautiful code

…has the following qualities:

* It validates.
* It is accessible.
* It renders the similarly across browsers.
* Content and style are kept seperate.
* It is written in semantic markup.
* It is easy for another developer to read and edit.

Using web standards makes the above possible, even if I don’t mention them specifically.

I’m not sure if the marketing message for web standards really does need improvement vis-a-vis designers in general. I was sold from the very beginning. But when communicating to clients about what I have worked so hard to learn, talking about web quality as opposed to web standards is a very smart move to make. As Andy says, “professionalism and quality products are hard to argue against”.

A recent post by one of the designers that worked on the fabulous Garland theme has sparked a very interesting conversation about the problems surrounding developing themes for Drupal, of which there are many. The comments there are well worth the read. I will have more to say on this once I have get a little farther along in “developing” my own Drupal site and playing around with the foundation theme, right now I’m still too new to Drupal to get into specifics.

However, I offer these two points:

1) Drupal, being so powerful and extensible, creates a huge problem for designers in the sheer number of types of modules and content a theme has to handle. Calling for themes that are created for a specific kind of Drupal site (e-commerce, blog, brochure, etc.) is an excellent idea.

2) Although designers can be belladonnas, oops!…I mean primadonnas and/or lone wolves, there is a way for them to participate with the development community concerning themes. It would just have to work a little differently what people have been used to. I think the method used by TWiT tv to design their Drupal site is one that can be used to the advantage and purpose of bringing themes to Drupal, which is described in this podcast by Lullabot. Essentially, a designer would come up with the graphics, the CSS (most of it, anyway) and the overall site layout and conventions. Then, a team of folks like myself and more experienced programmer types would work on extending the theme so that it works with Drupal.

It would take a major change in approach but it is do-able with the community we have.

After playing with several Drupal installations, I have my first real project to work on. I am finding a real-world example makes all the difference when it comes to really learning how Drupal works, although that should come as no surprise. I have been reluctant to track my progress on this site here, simply because it is an extra step and I have only so much time to work on things. I rethought this as I found myself returning to previous posts, like this one, when it was time to do another dotProject installation.  I decided it might be valuable to do especially because modules in Drupal seem to multiply like cottontails after a wet spring.

This project is good because it is limited in scope and the site owner is fairly relaxed as to schedule, which is excellent. The site will look like a regular website until the user, either a Teacher (content creator) or Parent (content reader, commenter), logs in. Then, users will land on home page with the latest updated content, and from there a Parent will be able to click on a page with a list of all content that references their child; search for other content based on other children’s names; and have access to their child’s progress reports. That child’s Parent and the Teacher should be the only ones that have access to this information. There will also be an area for downloading forms or other documents, and a school calendar/syllabus combined.

That is the english version. In modified Drupal-speak, the site needs to:

• Present like a regular site to the unregistered user; with no access to updated material like blogs.
• Present different homepages for anonymous and logged in users.
• Present different blocks for different roles.
• Present different menu items for different roles.
• Allow for uploading, embedding, and possibly captioning images in posts.
• Allow for creating nodes based on taxonomies.
• Allow for access to nodes by a single user.
• Have a calendar.

After playing around a bit, I think I have figured out what I can and cannot do from the above list with the standard core installation. It is now time to think about modules. I’m sure that I might end up with some duplication as I wade out and try to figure out what is and is not going to work; in any case modules will be the subject of Part II.

Here is the location of my test site.

BTW, I’m happy to announce that the very first module I installed was the brand-spankin’ new Update Status for Drupal 5 by Merlinofchaos. Thanks, Earl!