Categories
Books

Zen of Burningbird

I received a copy of The Zen of CSS Design: Visual Enlightenment for the Web from the authors, Dave Shea and Molly Holzschlag, and have been getting an intimate peek into the world of web page design the last few weeks.

This is a beautiful book, with an elegant and clever layout, and featuring many examples of the famous CSS Zen Garden. With each design, Dave and Molly have focused on one specific element and used this as a basis for whatever is the topic of that chapter: Imagery, Layout, Typography, and so on.

“Zen of CSS Design” isn’t a book for beginners, as it doesn’t cover the basics of CSS or HTML. It’s a book for someone who has worked with both and wants to take their web design beyond the basics–to explore, but to do so in a way that is cross-browser compatible, accessible, and that validates.

For instance, chapter 4 provides techniques to replace the text of a header element with a graphic, but still have the text accessible to screen readers, and search engines–something that was new to me. In fact, I thought I knew CSS quite well, but I found out there’s a whole new level of tweaking I wasn’t aware of, primarily because I don’t keep up with the many design and CSS mailing lists. Luckily Dave and Molly do, and have gleaned the best of it in the pages.

As for my design, I’ve finally been inspired to clean up my stylesheet and use the ID and CLASS selectors correctly. I’ve also been fairly weak with fonts, falling back on Verdana or Arial most times. In the book there’s a whole chapter on typography, and I have now discovered georgia, which will be appearing in my pages in the days to come. This will make Joe Clark happy.

An interesting coincidence: this week Dave wrote a post about accessibility and the “aaa” Bobby rating that’s shown in the CSS Zen Garden HTML template. A group of Italian designers had challenged this rating because some of the designs do fail with accessibility, primarily through the use of color. However, as he pointed out, in the post, this is addressed in the book, which includes a decent discussion on all the nuances that can make a page less than accessible. There’s more to accessibility than labeling your images and using headers correctly; for instance, one suggestion is that text in hypertext links should be able to stand alone without the context of the surrounding text. Something that doesn’t work very well within a weblog.

After my first glance through of the book, I was inspired to try my hand with the CSS Zen Garden template, using my own Floating Clouds as model for the design. You can see the result in this page*.

As you’ll see, I’m using Georgia, and it is a pretty font. I’m also using the Floating Clouds open page body blocks and have left the sidebar items unconstrained. Rather than force all of the items into a tight, squishy box, the proximity of the elements serves as grouping — providing a balance while still allowing an openness in the design. Well, at least that’s my philosophy.

I’ve also managed to incorporate my background switching code, and do it while not touching Dave’s HTML — a requirement for CSS Zen Garden. I did this by using an import on the PHP file as the first line in the CSS file:

import “photographs.php”

The header file returned by the PHP program sets the result to CSS:

<?php
// declare the output of the file as CSS
header(’Content-type: text/css’);
?>

In addition, I also use the CSS3 “opacity” attribute for the quick summary element. This is supported in Safari and Firefox, and for those browsers where it’s not supported, the element is a solid white. Since the text is just as readable with both, and the solid white doesn’t disrupt the design, it seemed a good use of ‘edgy’ CSS. It also validates.

It’s a rather quiet design, but very readable–and at least it doesn’t hurt when you look at it, as can happen in this rather humorous look at the good old days of web design (note, lots of animated gifs in the page that opens from this link).

“The Zen of CSS Design” has been an eye opener for me and I’ll never approach web page design in the same way, again. I can strongly recommend this book — it’s definitely worth breaking into the piggy bank to buy.

*Note: I am not a designer**

**Further note: whole-hearted agreement with this statement will result in my hunting down and hacking your site. Consider the CSS Zen Garden entry I linked to. Now, think how your site would look with blooming peonies in the background.

Categories
Just Shelley

The trouble with neighbors

No, not the virtual kind…at least, not this time.

Our housing complex is a very quiet one, mainly families, older couples, and long time residents. We’ve always been lucky with the neighbors we’ve had, but our luck was bound to run out, and it did with the newest neighbor next door.

I’ve had to go over twice to tell them to turn down their music, and each time, they then spent several hours pounding up and down the stairs or knocking on the walls afterwards–once until 2:30 and the other time until 4am. There are two men living there and they’re gone most of the time, but when they’re home, it’s a constant party.

The management has informed them of the rules, and has asked me to call the police now when there’s a disturbance, so they can get official records of the events. With these, if the neighbors continue, the management will be able to kick them out. As vindictive as they’ve shown themselves to be, I’m not looking forward to seeing their reaction to my calling the police.

However, there’s a bright side to all of this: when I can’t sleep and it’s late at night, like now, I just put a DVD in the player, put on my headphones, and get lots of work done.

Categories
RDF

Update: Yahoo search

I had made an assumption that Yahoo Search was using the RDF/XML embedded with the CC license information to build its search results; Mike Linksvayer, though, was kind enough to clarify in comments that the company is using the CC license links, only, to capture this information.

This is disappointing, as I feel that there is more about the CC licensed objects that Yahoo could provide and doesn’t because it’s only after the links. That’s about the same as running a mine for rubies and tossing aside the diamonds you find.

Mike also mentioned about the use of RDF-A to bypass problems with embedded RDF/XML. Trying to define yet another new syntax when there’s an option already available doesn’t make sense. The RDF/XML Syntax document stresses the use of <LINK> for linking to a separate RDF/XML document with whatever metadata is defined for the resource. This is a good approach, and I’m not sure why folks are resistent to this. It’s not as if the extra documents will take up a lot of space; for dynamic systems, such as many of the ones we’re using today for weblogging, commerce, and so on, the document can be generated on demand.

A scenario for use with CC could be that when the CC license is generated, the person is told to create a file and copy in the generated RDF/XML. Then to take this LINK and add it to the header of the page. If they also want to add a icon and a link to the license in human readable format, then copy this link and put it into the page.

Is this that much more complicated for the people? Yes and No.

No in that people who host their own sites could probably do this without much problem; especially if tools start providing ways of editing pages on the site. However, for hosted sites, this is a problem – and will continue to be a limitiation of these types of sites. Now, a smart hosted site will be one that eventually gets that they need to provide some mechanism to allow for this type of activity. But until then, yes this is a limitation.

But CC could solve this for the hosted sites, by hosting the license files themselves and giving the person the link to the file to put into their document. Even with a weblogging tool, you could do this just by embedded a tag for the individual file name as the name of the metadata file into the header.

Eventually, we need ways of merging data for many uses into these pages. One way would be to provide the RDF/XML document URI to these tools, and the tools would then read in the existing RDF/XML and add the additional statements. Another would be for tools to provide a way of reading in a block of RDF/XML, pull out the individual statements, and then merge into those that already exist.

There’s code everywhere to do this type of data merging, and best of all: it’s RDF/XML, which means you don’t have to worry about namespaces and collision.

All we would need, then, is nice search bots that grab this and pull all this info into a nicely consumable spot. With API that returns individual data query results, or RDF/XML.

Yahoo! Yahoo! *knock knock knock* Opportunities knocking. Don’t blow it.

Categories
Technology Weblogging

Update

Just a quick FYI in how this is going:

I need to integrate fulltext in the application. This allows people to view a single page in a multi-page posting.

I’m still trying to get the RDF meta-data component finished, using RAP (RDF API for PHP). Some troubles with data updates.

Still hunting down SQL statements that have been embedded in the process files, and isolating them in the backend.

Few other odds and ends. I had thought about not worrying about multi-blog support, but I think I will add this in, after all. I think all in all it would be easier to add it in from the beginning then to try and incorprate after the tool’s been used.

Lot’s of work. Most of it fun. Really like the metadata thing, and consider the discussion about datablogging timely, too. It’s not going to be that polished, though, because the metadata functionality will be an add on, whereby people provide a vocabulary and the functionality enables it for each post. But I agree with Danny: this is the perfect use for RDF/XML.

Categories
Technology

The importance of degrading gracefully

When I first went to work at the dot-com, Skyfish, too many years ago, I was faced with an application that had a partial interface, little back end development, and that had cost the investors 1.5 million dollars I believe it was (might have been 2 million — hard to keep track in those days). Where did the money go was the question, and the answer was: it went on building lots of graphics and a really fancy Dynamic HTML (or DHTML or HTML and script) page navigation.

Well, the first thing we had to do, after firing the design company, was pull the DHTML out and revert to plain links for the menu. Why? Because DHTML menus don’t degrade gracefully.

I first heard about DHTML from Scott Isaacs at an invitation-only author introduction to the technology held at Microsoft’s campus. I remember when he–or actually, I think it was the program manager who did the demo–clicked on a name in a web page, and the space beneath opened up and more content was shown.

I was floored. I was astounded. I was in love. Up to that point, the only dynamic component of a web page was BLINK or an animated GIF, and neither of these was particularly helpful from a professional stand point.

In the months that followed, as the technology of CSS-P, as it was known then, was released, I spent an amazing amount of time working with it; I was sure it was going to revolutionize everything we knew about web page design. In fact, it was at that time that I became heavily involved with ASP, and between the two–DHTML for the front and ASP for the back–I felt that this was it: we could close the book on innovation, tell the other contenders they could go home now.

Well, it wasn’t long before cracks in this little nirvana started to develop. Whatever cooperation existed between Microsoft and Netscape at the rollout of CSS-P died a rather painful death, and we started having to deal with a thing called “cross-browser compatibility”–making stuff work in multiple browsers.

Microsoft really drove the browser market, too. Too fast and too far, and sucking people in right and left away from the Netscape browser, Navigator, to IE. The frenzied pace splintered the browser market and left us with a legacy of non-standard, proprietary extensions that haunted us for years. And then when Microsoft had us, they dumped us.

Compatibility across browsers wasn’t the only problem; we also had to worry about making pages work across browser versions. I remember about two years ago, when someone using Navigator 4.x asked me to change something in my weblog and I said, enough is enough, I’m no longer supporting a browser that was released six years ago. Now, I feel that way about IE.

Compatibility issues aside, other problems started to pop up in regards to DHTML. Screen readers for the blind disabled JavaScript, and still do as far as I know (I haven’t tried a screen reader lately). In addition, security problems, as well as pop-up ads, have forced many people to turn off JavaScript–and keep it off.

(Search engines also have problems with DHTML based linking systems.)

The end result of all these issues–compatibility, accessibility, and security–is a fundamental rule of web page design: whatever technology you use to build a web page has to degrade, gracefully.

What does degrade, gracefully, mean? It means that a technology such as Javascript or DHTML cannot be used for critical functionality; not unless there’s an easy to access alternative.

For instance, the main use I make of JavaScript and DHTML in my weblog is the live preview and spell check for comments. Now, neither of these is critical for people wanting to leave comments, and this means my site meets one requirement of the fundamental rule: the page can degrade. However, I made a design error when I added the live preview text area and Check Spelling button, in that I didn’t degrade gracefully: the Check Spelling button still shows, as does the live preview area. If JS is not enabled, these should not show. (It’s now an item on my to-do list.)

Whatever holds for DHTML also holds for Ajax. Some of the applications that have been identified as Ajax-enabled are flickr and Google’s suite of project apps. To test how well both degrade, I turned off my JavaScript to see how they do.

Flickr was a delight and an example of a web page that not only degraded gracefully, if it were a dancer, it would be the prima ballerina. As an example of this, there is an option on each photo page for the photo owner to add tags. Clicking the option instantly opens up a set of text boxes to add new tags. This is using DHTML, and very handy.

However, when you turn JavaScript, and hence DHTML, off, this option isn’t there, but you can easily edit tags and other information by clicking the edit link below. Flickr used DHTML to enhance the user experience, but never once built a dependence on the technology to drive the user experience. More, if you access the page without JavaScript, you’ll never know that you’re ‘missing out’ by doing so. Lovely use of technology.

Google’s gmail, on the other hand, did degrade, but did not do so gracefully. If you turn off JavaScript and access the gmail page, you’ll get a plain, rather ugly page that makes a statement that the primary gmail page requires JavaScript, either turn this on, get a JS enabled browser, or go to the plain HTML version.

Even when you’re in the plain HTML version, a prominent line at the top keeps stating how much better gmail is with a Javascript enabled browser. In short, Google’s gmail degrades, by providing a plain HTML alternative, but it didn’t do so gracefully; not unless you call rubbing the customer’s nose in their lack of JS capability “graceful”.

You don’t even get this message with Google Suggest; it just doesn’t work (but you can still use it like a regular search page). As for Google Maps? Not a chance–it is a pure DHTML page, completely dependent on JavaScript. However, Mapquest still works, and works just as well with JS as without.

(Bloglines also doesn’t degrade gracefully — the subscription is based on a JavaScript enabled tree. WordPress, and hence Wordform, does degrade gracefully.)

If we’re going to get excited about new uses of existing technology, such as those that make up the concept of Ajax, then we should keep in mind the rule of degrading gracefully: Flickr is an example of a company that understands the principle of degrading gracefully; Google is an example of a company, that doesn’t.

Update: As Doug mentions in comments, flickr is dependent on Flash. If Flash is not installed, it does not degrade gracefully.

Sigh, there goes my prima ballerina.