ALTERIOR.NET

Having Met the Makers

Meet the Makers is a conference held in both New York and San Francisco where people are intended to be able to discuss the future of web design. Unfortunately, the session I attended turned into a series of advertisements and vague overviews of proprietary technology, only interspersed with intelligent discussion. The saving grace for me was time spent talking with Tantek Çelik (of Mac IE's Tasman rendering engine fame) and Arun Ranganathan (Netscape Senior Software Engineer) about web standards, and the future of their two great browsers.

This isn't too say that I regret having gone (for free nonetheless, much thanks to Brian Alvey). But it didn't do much to tame my disillusionment with the web's current state, or my skepticism towards the solutions that continue to sell despite the overall economic downturn. What particularly bothered me was the prevelance of clunky, over-complicated, and oftentimes platform-specific technologies, and the continued existence of the so-called "prevailing market forces" that drive their adoption. I'm no marketing whiz, and admittedly, my eutopian view of the internet is flawed and unrealistic, but I do know better than to build (for instance) a CMS that's too bloated with client-side interactivity to work with anything other than IE on Windows.

The morning interview session featured a talk with Google engineer Shiva Shivakumar, who divulged to us their production environment of choice: Linux, with a "hodge-podge" of C++, Python, Perl, and other languages. <tangent>At least for me, it's comforting to know that I'm not the only developer that doesn't think there's just one tool to get the job done. Like any self-respecting UNIX user, I've finally reached the point where it's easier to write a Perl script to do something than it is to do it by hand. I suppose that, to a larger extent, that's the equivalent of IIS developers writing VB Script applications to perform mundane tasks, but that doesn't sound nearly as sexy.</tangent> In the second interview of the morning session, MapBlast CTO Steve Weinstein exposed the true brains behind all those online mapping systems: people just drive around and take notes! Okay, it's a little more complex than that, but suffice to say that most of the methods for gathering street-level information are suprisingly low-tech. Now, as far as the transformation of that data into usable information goes, I'll leave that to people much smarter than myself to figure out.

Next came a series of labs. Surpisingly, Microsoft's session showcased the .NET platform's portability with other systems, thanks to their adoption of XML. It's just too bad they sell all their web services on a transaction basis. Props to the rep for use of the term marketecture during his PowerPoint presentation, though. Next, Atomz tried to sell us on their weighty CMS that appears to focus more on customized search results than well-structured navigation and content... sigh.

The third lab was held by Macromedia, who required we sign an NDA before bearing witness their awsome new application. All I can say is that I was very impressed, and I hope that it becomes a viable solution for people that want control over their content, instead of having to rely on shady CMS vendors or unreliable web geeks to update their sites. You'll see what I'm talking about in a couple weeks.

The last lab of the morning session dealt with Adobe's new Graphics Server 2 (formerly AlterCast). A very cool product to say the least: among other things, it allows systems to implement generated (think "localized" or "dynamic") navigational graphics based on PSD templates, to rip print collateral on the fly, or to apply transformations on hi-res graphics with an XML-RPC call. Sure, some of this is doable with open-source tools like the NetPBM suite and ImageMagick libraries, but the interoperability with popular design workflows (namely Photoshop and Illustrator) alone is priceless. Well, not priceless exactly... It's actually pretty fucking expensive. And it only runs on NT and Solaris. Poo.

Eating leftover pizza behind the safety of heavy plastic blinds just feet above sea level, it's even more painful to remember how nice it was to eat great food with a view of the entire Bay Area from the top of the Hyatt downtown... The best pasta salad I've ever had, hands down. If it weren't for the asinine conversations and awkward silences that followed, it would have been a perfect lunch. Mike and I skipped out early to snag an ethernet connection from one of the empty conference rooms, which presented us with the opportunity to test out Mac OS X's Airport internet connection sharing between my iBook and his new PowerBook. Worked like a charm.

The afternoon interview session featured my three favorite people at the conference: Tantek Çelik, Arun Ranganathan, and Douglas Bowman. While Tantek fiddled with the projector (which either had a busted connector, or just didn't like his PowerBook's aspect ratio), Arun spoke a bit about Netscape's transition from the old Communicator code to the Gecko rendering engine, and fielded some questions about web standards and all that jazz. Afterwards, I was able to ask him a couple questions that prompted him to divulge that Netscape is planning on building in support for the famed IE/Windows-ism, contentEditable. Check out the relevant Bugzilla entry for more info.

Tantek's presentation was brief, and not too informative for anyone that already knows the great lengths he's gone to make IE for the Mac the most standards compliant (and arguably, attractive) browser — on any platform — of its time (that is, back when Mozilla was too bug-ridden and unpolished to do much of anything). His CSS examples certainly wowed the crowd, but I can't help but be skeptical of their practicality until other UA's support them. Tantek was surprisingly down-to-earth when I spoke to him, and he assured me that there will be a version 6 release of IE for the Mac, despite widespread claims to the contrary. His response regarding CSS3 compliance was vague: The CSS3 module structure is apparently difficult to implement, and it appears as though none of the module specs (some of which Tantek himself is authoring) is even close to being finished. It wasn't all doom and gloom, though: We did have a nice little laugh over an offhand comment from a certain WaSP member that "XHTML 1.0 has been deprecated." Funny, the spec doesn't mention that...

The MTM folks brought things back to an interview format for Douglas Bowman, Network Design Manager of Wired News, and the man deemed responsible for the site's redesign using valid XHTML Transitional and CSS. What I found amazing was that he placed their site's Netscape 4 usage at "14 to 20 percent," which seems a bit high for them to have gotten away with it. If it's that easy to hide most of the presentation from nearly a fifth of your users, why can't we all do it? I talked with Douglas earlier about the rash of mailing list naysayers that ran the new Wired site through the W3C validation gauntlet, his response to which was along the lines of "well, the developers should have done that before we launched." A lot of people have a stick up their ass about validation, but I'm of the camp that says it really isn't that important until browsers treat XHTML as anything other than (somewhat more valid) tag soup (and yet I flaunt that referer validation link like it ain't no thang!).

The afternoon lab sessions were simply a series of commercials for three products, only one of which I found mildly interesting. netomat is a JVM class that pulls in content in the form of an SGML application called NML: the netostat Markup Language. Their reps assured us that DTD's would be published to facilitate more open development of products their platform. I don't think it'll be the killer app that dethrones Flash, but it certainly appears to be a simpler, quicker development environment. If their nml studio application ends up taking off, though, they could have a shot. Unfortunately, the other two labs aren't even worth mentioning.

The final interview session featured self-proclaimed usability expert Jeff Veen of Adaptive Path. Not much new on the "user-centered design" (really, is there any other kind?) front, but that man does have a great stage presence. If you get a chance to see (and hear) him speak, I would definitely recommend it. The audience got a laugh out of some of the comments made by the last interviewee, E*Trade "UI Visionary" Paul Whitmore, who started off by refuting a lot of Jeff's comments, then slowly building up an opposing argument that eventually ended up supporting them again.

A lot of what he said made sense, though. What stuck with me most was his evangelism of the process called iterative design. In a perfect world, we'd all be able to run every atom of our work through well-written test cases performed by careful QA staff. Sadly, it seems that with web budgets continually shrinking, little shops like ours won't have the manpower or the clout to demand things like elapsed usability tests, and other nicities that allow us to create web sites and applications that are (apparently) easier to use. For now, I guess we'll just have to depend on common sense.

A nearly universal theme throughout the day ended up being XML, which many vendors have been touting as the future of the web for years now. A lot of us have remained skeptics throughout, but I think it's time that we drop those misconceptions. Just about every popular programming and scripting language used today has XML processing built in, and we need to show vendors that we support their use of open standards to exchange information, lest they return to proprietary formats and protocols. Set up a 'blog if you must, or write a test document using RSS, and load it up in your favorite news aggregator. Compile mod_perl on your Apache webserver, or download any number of free XML parsing tools for your platform. Play with it, and learn it. Convert your HTML documents to XHTML, so that when the day comes that browsers can handle validation, you're ready for it. If you can't do it for yourself, do it for the web.

All in all, it was an eye-opening day. A couple applications made Mike and I think a bit about what we're doing, and how we could make things better for both ourselves and our users. At the same time, it was disheartening to think that we might not be able to compete with those gargantuan CMS vendors, and maybe that we need to change our focus. Everything's still up in the air with our group while we attempt to keep our heads above water, but I think that if we stay in touch with industry trends somehow, and more importantly, that we continue to listen and react to user feedback, we'll be able to make it in this new climate. Back in '99, a lot of large corporations probably accepted that they had spent too much money on their web services, but refused to spend anymore. The result is a lot of unhappy customers with outdated tools that don't align with our new world of standards and user-centric design. What I enjoyed about Meet the Makers were the portions that attempted to address these problems. The rest I could have done without.

posted by shawn @ 2002-10-22 10:10PM ∞
{ geekspeak | web }

Stylesheet Switching with PHP

All the hubub over the recent Wired News reformulation in XHTML and CSS has brought up a lot of questions. A recent one on css-discuss concerned the implementation of stylesheet switchers: bits of JavaScript or server-side logic that change the appearance of pages by loading different screen stylesheets. In the interest of advancing this technology, I've whipped up a PHP solution which I'd like to share with you.

It's kinda funny that, in between when I started this project (the date for this entry indicates the first time I saved it, not when it was published) and finished documenting it (approx. 2002-10-14 19:41), two completely separate implementations have been released. It's a strange coincidence, and by no means is the technique shared by all three revolutionary or ground-breaking. Regardless, check them all out and let me know which one you think is better. And remember: competition breeds innovation. ;)

The concept is simple: give the visitor a choice of styles from some predetermined list, and when they choose a new one, display those changes, and set a cookie so they don't have to make that choice on each subsequent request. This implementation consists of 4 separate chunks of code in 3 files that work together to save and display the users's preference for alternative stylesheets. Keeping with my slightly narcissistic tendency to name projects after myself, I've dubbed the collection of files "S3: Shawn's Style Switcher".

Configuration: s3.cfg.php

Our configuration file sets variables used by the other scripts. Centralizing this information allows you to add new stylesheet options to your entire site by changing a single file. Let's take a look at it:

<?php

$style_path = '/';

$available_styles = array(
    'default',
    'blue',
    'green'
);

$default_referrer = '/';

?>

Let's take a look at these variables:

string $style_path

the path (relative to the document root) of your stylesheets. If you keep all your stylesheets at the root, this should just be "/".

array $available_styles

An array of stylesheet names in your $style_path, sans file extension (e.g. "green" instead of "green.css"). The first value in this list should be the default (used if the supplied style doesn't exist in the array).

string $default_referrer

If somebody loads the switching script manually, the HTTP referrer won't be set. In this case, the redirect which sends them to the referring page would fail. Set this string to the location you'd like them sent to if this happens (I recommend either your site's root, or an error document). This can be either a full URL ("http://alterior.net"), or a URI relative to your domain ("/").

The configuration file will be read by all other scripts to determine which stylesheet to store as the cookie and to link to in your HTML. Now, let's take a look at the script that sets the cookie.

The Cookie: s3.php

The s3.php script take a request variable named "style", compares it with our configuration variable $available_styles, and attempts to set a cookie if the new value differs from the current cookie. If an HTTP referrer was supplied, the user is redirected back to that page, so they won't lose their place when they change styles. Otherwise, they'll be sent to the location indicated by $default_referrer.

<?php

if (!@include('s3.cfg.php')) 
    die("Unable to include config file!");

$set_cookie = true;

if (isset($_REQUEST['style'])) {

    $style = $_REQUEST['style'];

} elseif (isset($_COOKIE['style'])) {

    $style = $_COOKIE['style'];
    $set_cookie = false;

}

// if no style supplied, or invalid supplied...
if (!isset($style)
    || !in_array($style, $available_styles)) {
    // set style to default (first available)
    $style = $available_styles[0];
}

// our cookie will last 2 years, and will apply to
// all directories of all subdomains of example.com
if ($set_cookie)
    setcookie('style', $style,
              mktime() + 2 * 356 * 24 * 60 * 60,
              '/', '.example.com');

$referrer = (!empty($_SERVER['HTTP_REFERER']))
    ? $_SERVER['HTTP_REFERER']
    : $default_referrer;

header('Location: ' . $referrer); die();

?>

Obviously, you'll want to modify the arguments to setcookie() to suit your needs (at the very least, change "example.com" to your domain name, and remove the preceding "." if you don't have any subdomains). For a thorough explanation, take a look at PHP's function reference.

If all goes well, a cookie should have been set using the supplied request variable (either a GET with a query string variable, or a POST), and the user will be redirected back to the referring page. Now we can use that cookie on any subsequent request to write out a style declaration or link in any document on our site.

The Switch

The rest of our scripting will take place in the "guts" of your site. Try working off a copy of an existing HTML document, and remember to create easily distinguishable (for instance, using a different body background-color) copies of your default stylesheet (according to the names you supplied in $available_styles) so you can be sure things are working.

First, we need to include our configuration file again, so we can get our default style if the cookie hasn't been set. We'll also need the $style_path to form a path to the stylesheet. Replace the line that links your current stylesheet (in the <head> of your document) with the following:

<?php

$path = $_SERVER['DOCUMENT_ROOT'];

if (@include($path . '/s3.cfg.php')) {

    $style = (isset($_COOKIE['style']))
        ? $_COOKIE['style']
        : $available_styles[0];

    printf('<style type="text/css" media="screen">
           @import url(%s%s.css);
           </style>',
           $style_path, $style);
}

?>

The first line should set $path to the filesystem path of your site's root. If you've placed s3.cfg.php somwehere else, or this doesn't work, you may need to supply the full filesystem path to the file. If you have shell access to your webserver, cd to the directory and type pwd to find it. The line that sets $path should then look like:

$path = '/absolute/filesystem/path/to/s3.cfg.php';

If the configuration file is found (which means you can simply remove the configuration if you want to disable style switching altogether), a style element is written out that imports the stylesheet named either by the cookie, or the first string in our $available_styles array. If you normally use <link> to link your stylesheets, replace that printf() statement with the following:

    printf('<link rel="stylesheet" type="text/css"
           media="screen" href="%s%s.css" />',
           $style_path, $style);

You may choose to link multiple stylesheets, or to change the media from "screen" to "all" if you're interested in supporting Netscape 4. You may even wish to move the formatting string to the configuration file. This is left as an exercise to the reader. :)

We still need to give the user a way to change the stylesheets. I've chosen to do it with a form and a <select> input, but it would be perfectly reasonable to do it with a list of links. Try placing the following anywhere in your document (preferably with the rest of the navigation):

<form
    action="/s3.php"
    method="get">
    <p><label for="style">Style:</label>
        <select name="style">
        <?php
            foreach ($available_styles as $_style) {
                printf(
                    '<option value="%s"%s>%s</option>',
                    $_style,
                    ($_style == $style)
                        ? ' selected="selected"'
                        : '',
                    ucfirst($_style));
            }
        ?>
        </select>
        <input type="submit" value="switch" />
    </p>
</form>

If you've given the switching script another name, be sure to change the form's action attribute. I've chosen the GET method because it uses less bandwidth and it's easier to debug, but our receiving script will accept either GET or POST requests, as long as the supplied variable is named "style". If for some reason your webserver is running an ancient version of PHP (anything before 4.1), you may have to twiddle some variable names. Refer to the PHP manual for more info.

That's it! If you want to see it in action, I've implemented the whole thing on my site with stylesheets that change the color of the navigation and the permalinks. You can view their source (with PHP's ugly syntax highlighting) here: s3.cfg.php, s3.php, and index.php. The relevant stylesheets are red.css, blue.css, and green.css, which all import default.css. If you're short on time or bandwidth, download the demo tarball, which is just a snapshot example of this site. Take a look, play with the styles, and be sure to email me (shawn@alterior.net) if you've got any questions or recommendations for changes!

posted by shawn @ 2002-10-13 4:10PM ∞
{ geekspeak | web }

The Font Report

A long, long time ago, I posted a lengthy response to an email on webdesign-l summarizing the state of CSS type sizing on the web, and the obstacles facing authors that wish to make their text accessible to a wide variety of audiences. A couple people asked me afterwards if I could post it for posterity, and I said, "sure." Then I forgot. More than 2 months later, here it is:

As pointed out several times on this list, and articles on various blogs and resource sites, there is no "perfect" unit for the web. This is by no means a thorough description of the problems you'll run into, or a recommendation of which ones to use, but here are some of the things I've learned in my time spent with CSS font styling...

Pixels are great for absolute sizes on the "screen" medium, but are a poor choice with respect to accessibility because of IE/win's inability to scale them.

Ems are great in theory, but fail in implementation as IE/win tends to handle anything less than 1em with an "undefined behavior". This may not be an issue if you don't have much small text. However, if you've got to set a base size for all the fonts in your document (10px, for example), you'll run into the pixel problem above. The alterative is percentages, which have the added benefit of increased stylesheet readability ("1.4em" vs. "140%"). However, this doesn't solve the issue of using relative units for margins, padding, etc. (percentages for these properties refer not to the inherited values, but to parent dimensions).

The other alternative is the use of font-size keywords (small, medium, large, etc.), which are limited by design, but more generic and scalable (and they map directly to most browsers' menu items for controlling font-size on a per-window basis). Like em's and percentages, however, they receive different treatment in most UA's. Different versions of IE for Windows, for instance, either come with varying default font size preferences, or scale slightly differently based on these keywords (confirmed by comparing fresh installations of IE5.5 and IE6, at least). Another big problem is that most users never change their preferences, so the assumed value "medium" renders too large on their systems. So, pixels it is?

IE/win seems to be the stumbling block here, but some have argued that px are an absolute unit, making the browser's behavior correct in that absolute units should not be scalable. The sheer necessity to design pages that render well in the popular browser leaves us with a difficult choice:

• design a liquid layout that can handle a wide variety of font sizes, with a "base" font size of 1em/100% (the user's default, or preference)
• tailor your font sizes to the preferences of users by using the keywords, and accept the fact that most users will be served up huge text that they can scale down
• design a layout with a particular font size in mind, but limit the ability of IE/win users to scale the text
• provide users with some method of changing the text size/face via links or buttons

I haven't figured out which one is best yet. So far, using a combination of px and em's has worked for most sites I've done: It seems that most Windows users don't even know how to change the font size anyway, and most of them are used the poorly-styled text on large news sites, etc. But with all this hubbub about accessibility, I'm finding it harder and harder to purposefully lock people into an absolute font size. I've given the keywords (combined with percentages) a shot on this site purely as an experiment, which has so far proven pretty successful.

The stylesheet-switching stuff is definitely a hack, and most designs that I've worked with lately don't provide much room for an interface element that would provide that kind of functionality without detracting from the overall look of the site. For single-page newsletters and such, it's most certainly overkill.

Ultimately, the problem seems to be an implementation issue (as is usually the case with anything standards compliance-related). It doesn't seem as though the IE team would want to purposefully cripple the ability to scale text, considering their tendency to violate standards in the name of usability. Yet most people claim this behavior correctly follows the standard, while other UA's like IE/mac, Mozilla, and Opera (with a unique scaling solution of its own) allow users to scale text sized with any unit. Regardless, we're obligated as web designers to cater to the majority, so we'll likely be faced with this issue for a while (IE6 is still a relatively new browser, so we've got a long time until the next revision gains enough share to justify dumping support for its predecessors).

Until then, be smart about your font size choices, and remember that an increasing number of elderly and vision-impaired users are coming to the web in search of information. Recently, I've even found myself squinting at the default text sizes in many popular sites, having to position my iBook so far in on my desk at work. And while browsers such as Mozilla and Chimera allow me to easily scale all the text up (although I wish I could be more precise about it), if I were on a PC, I'd be screwed. That's not a situation anyone should with upon their audience. I needn't remind most of you of the client that continuously states, "the text is too small!", or insists that the majority of body text be bold for the sake of readability...

posted by shawn @ 2002-09-20 4:09PM ∞
{ geekspeak | web }

W3C Drafts: XHTML 2.0, CSS2.1

The W3C released several new drafts this week, most notably the XHTML 2.0 Working Draft. The new proposed spec drops <img> in favor of the more robust <object> element, allowing for a nested hierarchy of different media objects that can be displayed by the UA in the event that certain content types are unsupported.

I've been crossing their fingers on this one for a while. Finally, web authors will no longer have to depend on unreliable javascript plugin sniffers and cookies to supply alternative content for UA's without plugins, or without the ability to display certain image formats. Granted, the new method of creating an image is a bit more, well, verbose:

<object data="foo.gif" type="image/gif">
    <param name="width" value="128" />
    <param name="height" value="64" />
    here's your alt text
</object>

I still think it's a move in the right direction. The W3C hasn't created a DTD yet, apparently because there is an "open issue about how to integrate the XForms instance data" (XHTML2 drops HTML form elements in favor of XForms), so I can't tell whether or not other elements will be allowed within <object>. This would be an even greater improvement that would allow authors, if they wished, to substitue rich media with styled markup (as opposed to the CDATA-only limitation on alt attributes).

Another update from the W3C was the CSS 2.1 Specification (or, more formally, "CSS Level 2 Revision 1"). Most of the updates consisted of error corrections and clarifications, but I was most pleased to find out that:

The underscore character ("_") is allowed in identifiers.

Hooray! Another one I noticed was that border-color and its ilk now allow the value "transparent" (although I'm not sure how any of the UA's interpret this at the moment). Margins are now computed in determining a positioned element's offset from the edge of the containing block. Also, the white-space property applies now to all elements, not just block-level elements (some UA's got this right with their CSS2 implementations, regardless of the spec).

Go yee forth, and implement standards!

posted by shawn @ 2002-08-09 1:08PM ∞
{ geekspeak | web }