Skip to: Navigation | Content | Sidebar | Footer


Full Archives

IA with OmniGraffle

June 25

A recent find has been making parts of my life easier: OmniGraffle, a diagramming tool which comes bundled with the latest Macs.

Though I'm probably the last OS X user on the planet to try them out, I figured I owed it to myself to take a spin through some of the free software that came with the new Powerbook I picked up last month. There are some real gems bundled, including the Art Director's Toolkit, the iLife suite, and a few applications from the Omni Group.

OmniGraffle is a diagramming and charting tool that's simple, elegant, and easy to use. I was building my first for-production-use chart within a minute of starting up and clicking around for the first time. The various stylistic graphics for technical and business purposes mean dragging and dropping your way to a useful flowchart is a snap.

Boolean gates, flow charts, UML, and more are available; a somewhat Mac-centric network diagramming palette facilitates great-looking LAN diagrams (scroll down to 'Network Layout'), for instance.

As soon as I got to the Garrett IA chart items, the natural reaction was to start plotting this site's current setup. And some interesting things are coming of that. IA is obviously important, but has always been somewhat peripheral to me; the processes and information flows around here were developed unconsciously and intuitively. While this isn't a terrible method for someone who uses the web daily and understands a lot of what not to do, a more formal plan of attack can't hurt, can it?

Sample flowchart: mezzoblue.com

It's not a perfect tool, since the connecting lines can be sticky at times. There are countless things I'd change about the styling palette, and I find it odd that I can't easily change a graphic after it has been set; perhaps answers will come after more use. Still, it's an interesting little program, and a great addition to the toolbox.

Permalink › | 28 comments

Web Apps are Hot

June 23

An ongoing conversation about web applications is highlighting key points about the future of computing, the web, and the industry.

While Joel Spolsky's seminal article on Microsoft losing the API war appears to have been the first drop in this torrent, it echoes conversations that go back least as far as the W3C's Workshop on Web Applications. (which is the same workshop that people like Opera employee Ian Hickson came away from, disillusioned, just prior to the announcement of the WHAT WG [which was covered on this site earlier this month]).

A Technorati search reveals the interest in web applications in general (and Joel's article in particular), but what has been particularly interesting to me is how the conversation has morphed as it continues.

The beginning, or at least where I came in, saw discussion of which technologies future web applications would be built on. HTML and CSS are great for documents, but not so good for applications. Microsoft has XAML on the horizon, the W3C offers XForms and SVG, and the WHAT WG aims to offer an extension of basic HTML that's backwards compatible with IE6. Two of these technologies require radical change in end-user technology; one does not.

Whether Joel's article was written in response to, or prior to these discussions is largely irrelevant—whatever the case, the publication shifted the entire tone of the conversation. Instead of discussing the technologies themselves, it moved web applications into the spotlight as being an important way forward and a threat to traditional software business models.

John Gruber picked up at this point and wrote yet another tone-setting piece, The Location Field Is the New Command Line. Arguing that web applications provide different, less comprehensive, but easier methods of interaction, Gruber rightly points out that Google's mega-popular GMail is light years ahead of the competition in the webmail space but almost non-competition when compared against desktop mail clients. Gruber concludes that "... web apps don't need to beat desktop apps on the same terms. What's happened is that they're beating them on an entirely different set of terms."

Steven Garrity goes on to compare Gruber's reasoning with yet another article buzzing around the web, Cory Doctorow's presentation on Digital Rights Management given to Microsoft last week. Ian Bicking throws two cents in the ring with his list of features web applications offer that traditional desktop apps do not.

Of course, nobody seems to be talking about Macromedia's Flex and the continuing application development capabilities within Flash itself. Hindered by stigma that Flash is evil and purely about animation amongst developers that should be buying into Flex, it's hard to see this combination taking off; however, as a dark horse, it's a hard one to ignore on sheer numbers alone. Ninety-odd percent of web users have Flash installed, and Flash renders consistently cross-platform. Remember what Joel reminds us though: it's all about developers.

An incredibly thought-provoking article in April speculated Google is building a massive, global platform for distributed computing. Microsoft has renewed an interest in developing Internet Explorer. And don't forget that mobile and wireless devices are reaching incredible saturation levels—the global mobile phone subscription base is expected to hit 2 billion in 3 years. All these things are related.

It's a lot to digest and that's only scratching the surface. The obvious trend is the key to understanding the future of computing: the web is it. Servers are becoming more important than clients. While raw processor power will remain useful for applications that need it, simple and general purpose data management—including email, scheduling and time management, office applications, and all other text and information manipulation tools—will increasingly move to a globally shared environment that makes it easier to collaborate and easier to access. The recession is over, the slump is ended. Web development is in demand, and the demand is only going to increase.

Permalink › | 33 comments

Validation, Moderation, Constipation

June 17

Validation matters. No it doesn't. Validation is hard. No it isn't. Standards are flexible. No they're not. Does this conversation sound familiar? Updated 18 Jun 2004

While variations of the debate over the ease and importance of following the standards to the letter have been flying around for years, the coming summer months appear to be heating up the arguments once more.

There's a cross-site conversation about validation happening at the moment, and you may have seen it in places I haven't. On this site anyway, a seemingly innocuous opinion piece from last week calling for moderation and sensibility saw the discussion fly completely off the rails and devolve into a sordid display of finger pointing and blame. A misunderstanding is occuring between two loosely-defined groups that is resulting in unnecessary hard feelings.

(I'm going to generalize here and label everyone as a 'designer' or a 'coder' to illustrate my point; recognize these statements are general trends; exceptions exist, and there are people who are both or neither.)

When standards-conscious designers validate their XHTML and CSS templates, everything is nicely compliant up until the point where they start tying in the necessary automated systems like ad software, CMSes, or e-commerce apps. The tools then get in the way and code is needed to fix validation, but a lot of designers don't code. Because the issue is technically out of their hands, they look for ways to justify the validation failure and avoid responsibility.

Coders that care about standards have fixes for the problems they experience with software. It's relatively easy for a coder to automatically escape ampersands in generated code; at the very least, they know how to Google the fixes. At best, they can scrub all automated output, fix errors, and tune their HTML to a degree most designers would only dream of. And many of these coders look at the designer's failure to duplicate their success as laziness or worse, without realizing that a designer's skill set simply does not extend to the world of fixing code output.

This divide is illustrated nicely in Mike Davidson's article which I linked yesterday. Mike is looking for reasons not to validate because he deals with these types of systems, and fixing them is a Herculean task he doesn't have the resources for. The fun begins when Steve Champeon pokes his head in (comment 15) and attacks Mike's arguments on firm logical grounds. But Steve throws in a telltale sign that he has unrealistic expectations of Mike, by referencing "the slacker ethic" and stopping just this side of calling Mike lazy.

There are two truths here. One, people of all different backgrounds and talent levels are creating content for the web. Two, there's still a remarkable assumption that one who does a certain job for the web does all jobs for the web, which even comes from colleagues who should know better. That the assumption exists is true; the assumption itself is suspect. Everyone who survived the past 5 years of economic downturn did so by diversifying, but specialties still exist simply due to the massive variety of possible skills that no human could master in one lifetime. I don't expect a coder to know the first thing about monitor colour profiles or typography; it's great if they do, but I don't expect it. Likewise, a coder should not assume a designer knows how to deal with data, or fix validation errors using code.


Okay, whew, we're through the build up. That wasn't even the part I wanted to write. This is:

Can we all just shut up and start listening to each other please?

Designers: the coders are trying to tell you that there are ways to encode those ampersands and validate things like comments, do it with minimal time investment, and make it happen automatically.

Coders: the designers are trying to tell you they don't have the skills to implement these methods and they need guidance here.

During the raging debate on this site last week, two contenders — Jacques Distler and D. Keith Robinson — both contributed their share of the blows, but after the dust settled they ended up working together to solve Keith's problems. A coder willing to share his or her experience is worth 20 coders who will point out a problem without suggesting a fix. A designer willing to accept help instead of sweep the problem under the rug and justify it with spurious logic is golden.

What we need is to start working together like this on a larger scale. You've gone to lengths to programmatically fix improperly nested tags? Great, write it up. You have a killer PHP function for parsing out raw ampersands that can be copied and pasted into a site-wide header? Perfect, share it. You can make a bad tool better? Do it! We don't have to keep re-inventing the wheel for every new site, we can build common code bases that make validation painless and share them.

A knowledge base of tricks and tips for dealing with bad HTML would go a long way if it's easily understandable by the non-technical, or even better, copy and pastable. Arguing is a good way to waste time, but if you really want to change the way someone works, show someone how it can be done. Don't leave it up to them.


Now this is more like it. David Osolkowski shares his PHP. Anyone else? Let me know, I'll start building a list:

Permalink › | 69 comments

Mike Industries

June 16

Mike Davidson is writing here. Mike who? Only the driving force behind a little site called ESPN, and their conversion to standards-based design last year.

Offering up tips and views on getting hired, storytelling, inspiring art projects and more, he's off to a great start.

You may find plenty to disagree with about his take on validation. But then again, you may find he's right on target. Mike is not a purist; he's a realist. And that's okay too.

Permalink › | 11 comments

Wicked and Worn

June 16

That Wicked Worn Look — Cameron Moll concludes his four-part look at Photoshop-induced wear and tear with a guest artist gala.

Nice work fellas, you've just replaced the centered, fixed-width drop shadowed layout as the hot new design meme.

Permalink › | no comments

IE Notes

June 16

On dumping Internet Explorer, how you can provide feedback to the IE team, and why IE is bad for Microsoft's business model.

Why you should dump Internet Explorer — Nothing new here, but it's interesting to see that web designers aren't the only ones calling for change.

Internet Explorer Feedback — Robert Scoble says that what's left of the IE development team is following this Wiki closely. A quick look shows that a lot of common complaints have shown up; if you have a pet issue, go add it.

How Microsoft Lost the API War — Former Microsoft employee Joel Spolsky on an issue that has way more to do with IE than first appears. A long read, but essential for anyone who has ever complained about IE's dormancy, and it begs the question: will feedback to the IE team go anywhere?

Permalink › | 7 comments

Link Tuesday

June 15

Grab a cup of coffee and get comfortable, it's time to clear out the backlog of links that usually make it into the Dailies.

VisitorVille is a whole new level of server-side stats; think SimCity for web traffic. Your site is represented as an isometric city, and your visitors are the pedestrians and automobiles that roam its streets. Philipp Lenssen shares his impressions of the service, which are favourable. §

In Exercise in Customer Experience, Mark Hurst compares the customer experience of a theme restaurant, a dentist's office with a Star Trek motif, and a flashy e-commerce site that spent all of its money on image. Strange bedfellows these designers make, but Hurst effectively illustrates that understanding what the customer expects is the key to success. §

User testing? Free beer! Erik Burns advocates café testing as a quick, easy, and cheap way of gaining valuable user feedback. Great idea. §

AIGA symbol signs, free of charge — designed for airports and large international events where there may be more than one common language spoken, AIGA released the original set 30 years ago and have expanded it over time. Now the entire set is downloadable and ready for use in your work. §

The Dangers of Judging Web Designs Superficially — Joshua Porter thinks we're all a little too quick to offer a throwaway opinion. It's difficult, if not impossible to know ahead of time all factors involved in someone else's work when you're not on the team; while constructive criticism can be helpful, perhaps there is a line to be drawn. Joshua believes superficial commentary "lowers expectations and creates a market where looking good is the same as being good." Interesting perspective. §

WCAG and the Myth of Accessibility — in perhaps an inaccurately named (and overly contentious) article on what he sees as an overall dismissal of cognitive disabilities on the web, Kevin Leitch sets out to raise awareness of the issue which he has certainly accomplished. The article is long, and the comments are longer, but it's worth your time to read them all. The more you know… §

:hover emulation for IE5+ — Janos Horvath offers a variation on the popular CSS :hover menus meme, this one compatible back to IE5 and presumably quicker than other solutions that end up parsing an entire CSS file for :hover instances. Downside: an extra class is needed in the markup. Not a bad tradeoff though, and worth investigation. §

How to survive creative burnout — former Microsoft program manager Scott Berkun offers advice on pulling yourself out of a creative rut. My advice? Change your scenery. A new route in to the office does wonders for your outlook when you get there. §

Cutaway Technical Illustrations — What 720 hours of illustration gets you. (Besides creative burnout. See above.) Amazing. §

The real reason you should care about web standards. — Design By Fire on the benefits of a competitive market. §

Fireworks and XML — Andy Clarke demonstrates using an XML control file to automatically generate the various headers and graphical text items for your site through Fireworks. Now this is a reason to use Fireworks if I've ever seen one, thanks Andy. (somewhat related — today's A List Apart article, Dynamic Text Replacement) §

Firefox 0.9 is hot off the grill. 1.0 is just around the corner. §

Permalink › | 14 comments

CSS Source Examples

June 14

A quick tip that anyone who would put together a CSS example page for an article or a demo should follow: embed your CSS in the HTML, don't link it.

Linking or importing a CSS file is a good practice when finalizing a production site of course, but when you expect people to view the source of your demos and learn from your CSS, don't make it a four step process.

Do this:

<style media="all">
 body {color: #000; background: #fff;}
</style>

And not this:

<link rel="stylesheet" type="text/css" href="example.css" />

Instead of making I and everyone else wishing to understand your code 1) view source, 2) hunt down the path, 3) select and copy the filename, then 4) paste it into the address field, we will appreciate your simplifying the process to a single step. And we thank you for it.

Permalink › | 24 comments

CIRA .ca Domain Suspensions

June 12

CIRA's on a witch hunt, and the first casualties are the wave of multiple suspended .ca domains dropping off the internet this weekend.

From the inception of the .ca TLD in 1993 to the transfer of control to CIRA in 2000, the .ca registry was run by the University of British Columbia in Vancouver. Owning a .ca has always meant adhering to strict Canadian presence requirements, but the rules have relaxed over time. During UBC administration an individual or company was required to maintain a physical presence in the country. Subdomain use was liberal and an individual had little chance of registering a higher-level domain than http://name.city.province.ca/.

When the Canadian Internet Registration Authority took over the regional segregation was dropped, although physical presence requirements remained. But it has become apparent non-Canadian residents were able to skirt around this stipulation, and CIRA started pulling the plug on their sites this weekend.

Californian Greg Storey was contacted on May 25th about his domain, Airbag.ca. CIRA wished to verify his registrant information, and threatened suspension if he didn't comply within 5 business days. Further, they informed him they would be blocking any access to his domain during the verification process:

Please note that during the RIV process, CIRA is restricting your Registrant profile and all domains associated with it, this includes Registrar transfers, Registrant transfers and administrative contact changes etc. Unless the Registrant is unable to respond satisfactorily to CIRA's RIV request, the restrictions will be removed upon completion of the RIV process.

Because Storey wasn't able to meet the Canadian presence requirement, CIRA followed up with notice of suspension on June 11th, and by June 12th airbag.ca had disappeared from the web. And he's not alone; notable typography site Typographi.ca has gone dark, and the list of suspended domains is growing daily.

While it was obvious all along that non-Canadians shouldn't own .ca domains, CIRA's handling leaves a lot to be desired. A domain switch is not an easy process; bookmarks break, traffic falls, and server configuration takes time. Instead of wantonly closing down sites that slipped through the cracks, they could have instead extended a grace period to the registrants and allowed time for a proper domain transfer. CIRA allowed these registrations to happen; silencing resources that others have come to enjoy and rely on isn't the proper way to handle the situation.

Note — Airbag has since moved to airbagindustries.com, so update your bookmarks. Feel free to use comments on this article as a lost and found to hook up missing .ca domains with their new address.

Permalink › | 22 comments

“Everything looks like a blog”

June 11

A hallmark of good design is that it provides context and meaning for the work it's applied to. It enhances and emphasizes, and if necessary it distracts and obfuscates. Design is about visual communication and it's about enhancing written communication equally; not all text is designed, not all design is text.

The web is predominantly about written communication though; usable web standards don't extend to multimedia as well as they could. The basic constructs of HTML/XML and CSS are text, and the content they manipulate is most often text. Even the surge of weblog popularity hinges on the importance of the written word.

Consider the shape of text. Long passages share a common characteristic; they are narrow and long, never wide and short. You scroll down a page, and everyone resents scrolling vertically. The basic building block of the sites we all build is shaped like a big narrow rectangle, and there's no way around that.

Do a lot of the sites in the CSS Vault look like weblogs? Yes. Do many of the designs in the Zen Garden use two columns and scroll vertically? Yes. Because they were designed to best suit their content, which is simply good design.

Permalink › | 33 comments

WHAT's Next

June 9

WHAT's Going On? — Simon Willison analyzes the new WHAT Working Group, composed of representatives of three of the major four browser vendors.

On a broader level, what's brewing in browser space is a war over what's next. The web as a document viewing platform appears to be as good as it will get for a long time. The future is in web applications, and everyone has a different solution. Microsoft is betting heavily on its proprietary XAML and the forthcoming Longhorn technologies it will integrate with. W3C concerns are more interested in integrated solutions of XML, SVG, XForms, etc.

The reality is that right now, the web still revolves around HTML. The W3C has been trying to put it to bed for ages as it moves on to new, non-backwards compatible XML-based languages. But millions of sites and applications depend on it today. They're not all going to find the money to upgrade to the Next Big Thing, when it seems the only thing coming next is fragmentation.

So the minds behind Opera, Mozilla, and Safari have formed a new working group called the Web Hypertext Application Technology Working Group, or WHAT for short. The focus is to develop solutions that are extensions of vanilla HTML, in order to co-operate with today's browsers instead of relying on non-existent future implementations.

What of XHTML? What of CSS? It's increasingly obvious that while it's possible to use them for applications, they're not the best tools for the job. It's unclear whether they'll play a key part in any of the new strategies, or will exist only to complement in document-based settings. Most indications at present lean toward the latter.

The next chapter of the ongoing saga of the web is shaping up to be a brand new epic. What makes this battle different is that the major player is a well-established company with deep pockets, and the standards body that should be releasing definitive and practical technologies appears to be wrapped up in theoretical future technologies and ignoring the current problems web authors face.

If a group of alternative browser vendors can make a difference, when their combined total market share is still in the single digits, then the forming of WHAT might be a very important milestone one day. For now it's still anyone's guess where this battle will take us, although given the players, it's not hard to draw unpleasant conclusions.

Permalink › | 11 comments

Lorem Ipsum

June 9

Ye Olde Lorem Ipsum Generator — fortified and extra strong, this is the new lipsum.com.

What in the world is Lorem Ipsum? The practice of 'greeking' (as in 'it's all Greek to me') is a time-honoured tradition of substituting made-up, pseudo-Latin text in a mockup for what will eventually become real content. 'Lorem ipsum dolor sit amet…' is the beginning of the most famous of 'Greeked' passages.

Why do it? Two very practical reasons. One, you haven't received content yet. In lieu of beginning your next best-selling novel within a client's mockup, having a set of stock verbage to copy and paste into a text field saves time. Two, clients get hung up on the text itself. If you've ever passed off a mockup and couldn't wrestle feedback out of them more specific than "change word 15 to 'grandpa'", you know what I'm talking about. Design previews should almost never contain real data or text, if your goal is to elicit impressions about the design itself.

And this new generator is among the best I've seen. Ugly, but form over function in spades. Paragraph and word count! Foreign languages! Smart ass commentary! Morse code, L33tspeak, Esperanto, and I've never even heard of Volapük before, but they're all in there. Ye Olde Lorem Ipsum Generator: it's like rhubarb for your mind.

Permalink › | 14 comments

The Standards Police

June 9

The Standards Police will get you! — Brian Garside offers advice for those who would validate others work and follow up with an email pointing out the errors: don't.

Further from Brian:

"It doesn't help anyone, we're all aware of our defficiencies [sic], and could probably point 100 more out on top of the 10 you point out. Not only that, but you have no idea what kind of conditions we're working in, or what else we're trying to do (or the fact that we're building a whole new standards compliant, CSS based site behind the scenes, but Rome wasn't built in a day...at least it wasn't built properly in a day)."

Instead of spending the time it takes to hunt down a site owner's email address, compose your message, and post about it on your weblog, why not spend that time doing something useful? Write a how-to article on validation. Contribute bug reports to the major browsers. Volunteer to build a site for a non-profit group. Find something that will add value to the overall message of web standards, instead of detracting from the work of others.

The time spent sending bad vibes and turning site owners off of your message can be harnessed for better uses. Why not try?

Permalink › | 63 comments

WaSP asks: you!

June 8

Web Standards Survey — the Web Standards Project wants to know what you think about web standards.

WaSP is a popular resource for people of many backgrounds, but until now we've had no clear way of knowing who it is we serve, and who we need to be devoting more attention toward. Take a moment to go complete the survey and tell us what standards mean to you, how you're using them, and what you'd like to see WaSP focus on.

Permalink › | 6 comments

Other Redesigns

June 8

Stopdesign, Reloaded and Just Watch the Sky: I Heart You — speaking of redesigns, Doug and Ryan launch a couple of killer remixes.

On StopDesign

Incredible work, and in such a short time after pitching the old one for Phase I. If comments are any indication, Stopdesign v3 is a smash hit. Hats off to the master.

On Just Watch the Sky

A red banner topping a blue content area—who would have ever thought that would work?! Beautiful gradient work, good use of Inman's Flash Replacement, and a consistently strong type treatment equal a smash hit. Nicely done.

Permalink › | 4 comments

Redesign: Design Notes

June 8

I had planned to wrap up the redesign analysis series with a look at the design elements of Proton, but plans change.

Partly because I was tackling low-hanging fruit first, and partly because I needed the space to think after the many, many comments last month's redesign prompted, I left a deeper look at the design elements until the end.

But extra time brings extra perspective, and looking back 'Proton' as it was released solved some problems and introduced others. Overall result—not the success one would hope a redesign should be. Sifting through the comments, a few trends emerge. The header is universally seen as a problem area due to low visibility of navigation and clutter, the content area is almost universally seen as an improvement over Radar.

It's interesting to note that the new header spurred the redesign in November, but it has remained unchanged since as the content area got all the focus recently. Note to self: don't let ideas sit for too long. It's also interesting to note that while Proton began its life on a Windows CRT, most later development was on a Mac LCD. The gamma differences are startling when it comes to the yellow areas, which is something I realized only after launch.

At the moment incremental adjustments are being made to a separate copy of the stylesheet, which you can trigger as your new default stylesheet for this site to watch the progress. Some things may stay, some may change radically, and I have no great plan in mind other than to see where I can take this. At some point Proton will be finished; for now it's a work in progress, and you're all invited to watch.

Permalink › | 12 comments

Positioning your Services

June 7

After a particularly frustrating afternoon spent trying to find a subcontractor, a list of suggestions formulated for having work noticed.

A project that required extra help saw me searching available resources to find a good fit for the job last week. I doubt I'm a typical contractor, but my methods ended up covering wide ground and asking questions that I'd assume a savvy potential client would ask, and I came up with empty hands.

First of all, where did I look? Where I knew a bunch of standards-friendly web designers had their work on display, of course. I cruised through the blogroll on Web Graphics, I went through the CSS Vault's archives, and browsed the Zen Garden submissions list.

It shouldn't have been so tough, but two factors kept me from making a quick choice: I couldn't easily tell if the person or company provided the services I was looking for, and I couldn't determine whether their level of experience and skill matched what I needed.

While it's tempting to project a grandiose image of being a large multi-faceted company which is internationally sought-after, the problem with doing so is that you miss out on a lot of smaller work since it's assumed you're too expensive. If you are in fact a large company, the smaller work might be of little concern. If you're not and you enjoy working on projects that require less of your time, then you may wish to reconsider the message you're putting forward. The market is large, and getting larger; there is a need for all levels of skill and experience.

What I often couldn't tell from visiting a site was if the designer was an employee of some other company, or available for hire. This was important to me in particular as I was looking for an individual. Some don't list any affiliation at all which further compounds the problem.

When I could distinguish who was an independent, the problem then became evaluating the work. You wouldn't believe how many don't link to their portfolios on their weblogs. If I know you, chances are I know you through your weblog; if I want to hire you, guess where I'm going to turn?

And when I found a portfolio, often it didn't have a wide enough variety of work to form an impression. Naturally a portfolio should only contain your best work (although sometimes that rule should be broken to also include your most recent work; a stale portfolio instills doubt) but when there isn't enough work to pick and choose, brevity doesn't solve the problem. You need a good stable of examples to show me what you know.

In the end I found what I was looking for, but it strikes me that as we're carefully crafting semantically rich markup and visually gorgeous surroundings to deliver our messages within, sometimes that message gets lost in the shuffle.

Permalink › | 15 comments

Redesign CSS Notes

June 3

Alluded to in the earlier Technical Summary, the next analysis takes a look at the important CSS highlights of Proton.

Menus

As with the menus in Radar, these were inspired by Eric Meyer's Pure CSS Menus demo. Using nothing but strategic placement of :hover they work without a line of Javascript, and degrade to a simple unordered list in older browsers.

Well, no script was the goal, but Windows IE doesn't do much when you apply :hover to elements that aren't links. As noted in the technical notes of this redesign, I launched with Peter Nederlof's whatever:hover but had to back out due to slowness. I'm hoping to find a way around this when I have a free moment, something that will be a familiar refrain around here for a while as I knock down the various bugs in whatever free time I can find.

The markup behind these menus is relatively simple, although I may back out of an earlier decision to provide the text summaries for third-level menu items in the HTML, simply due to the fact that I'm not yet convinced it's worth the overhead to provide what amounts to gratuitous text. The unstyled markup is quite a bit bulkier as well, which means more bytes to download and a lot further to scroll before getting to the content. (see it yourself, although you'll have to shake off the cookie if you click that link by following it up with this one. You've been warned.)

The contact form embedded within the contact menu item was a proof-of-concept, mainly to see what the response would be. It's flaky, and I got the first spam from it within hours of launch, so it won't stay.

Content Scaling

Some of the 'looseness' comments that have been directed at Proton are no doubt a result of the liquid layout. Resizing the window leaves the center text column at a fixed width, while allowing the white margins on either side to fill the extra space. Except in IE, where the margins stay fixed and it's the content that scales; a reasonable way to work around the lack of max-width support.

If you scale the text in your browser, the width of the centered text column changes accordingly, filling up the white space. Assuming those with larger windows also run larger resolutions (a logical assumption), and guessing that their fonts are generally smaller anyway, this kills two birds with one stone... for those who resize.

The CSS behind it is a simple matter of using an em unit on the max-width value, like so:

.contentarea {
  max-width: 45em;
  padding: 0 25px;
}

Again, no IE support, so padding was also applied to the edges of .contentarea for the sake of margins in browsers that don't support max-width.

Accessibility Menu

One of the first pieces of markup to occur after the <body> tag is an accessibility menu, which doesn't display on-screen in either Proton or Radar:

<div id="skipNav">
 <ul title="Accessibility options">
  <li><a href="#mainContent">Skip to Content</a></li>
  <li><a href="#siteInfo">Skip to Navigation</a></li>
  <li><a href="#styleswitch">Skip to Style Switcher</a></li>
  <li><a href="#linkList">Skip to Sidebar</a></li>
 </ul>
</div>

What is it for? With this markup, those without style enabled, and those using alternate access devices have a way to skip to various important parts of the site. (Skipping "to" content makes more sense to me as a user than skipping "over" content, since I care about that which I want, not that which I don't want.) We all know by now that display: none doesn't function as expected in screenreaders, so using it to hide this menu adversely affects some of those who need it most. What to do?

A suite of test cases was run against many common screenreaders last year to solve this dilemma, and one CSS technique was a clear winner. This is what I use:

#skipNav {
 position: absolute;
 left: -9999px;
 font-size: small;
}

By moving the menu off-screen to the left by almost 10,000 pixels (why not save the byte? I did, hence 9999) we can almost guarantee that it won't display on any browser but those that need it. Note that if the links are underlined, Firefox runs the underline all the way back to the content area. Also, if for some reason you're not confident that 10,000 pixels will be enough, you can clip the viewing area of the off-screen menu. The following code virtually guarantees nothing will show up, although the above snippet will usually be sufficient:

#skipNav {
 position: absolute;
 left: -9999px;
 width: 9000px;
 font-size: 1px;
 letter-spacing: -1px;
}

The fun doesn't stop there. If your browser allows it, try hitting tab to cycle through the page's links and form elements. By hooking into the :focus link state and absolutely positioning the individual links back into the content area, they show up on-screen as styled blocks.

Example of Skip To links

While this method doesn't quite solve the dilemma of visible skip links, the only reason I can see why that is true is browser support. Those with mobility problems who use keyboard navigation can access them, those who are unsighted and using a screenreader can access them, and those browsing with a PDA or cell phone without style enabled can access them. If only :focus were more widely supported...

And with that, we're through today's analysis. Those were the more interesting CSS tidits from this redesign. I'll leave discussing the more mundane layout and styling issues for another day. Next up in this series: design notes.

Permalink › | 27 comments