by Kyle Weems 25.August 2008 08:12
When it comes to discussing web-related topics on the Internet, your average person that makes websites frequently comes across as something of a drunk rugby player in a china shop with a disagreement with the shopkeeper. Conversation gets very heated very quickly, and there's usually collateral damage.
I attribute this to a combination of passion on the subject and the relative safety provided by conversing with someone hundreds of miles away by text. Carolyn Woods goes over this tendancy to bad behavior (and solutions to stop it) in her A List Apart article Putting Our Hot Heads Together. But I'm not here to discuss bad behavior.
However, I am going to discuss of the many topics that seems to attract so much vitriol: dropdown menus (or mouseover menus, or whatever you'd like to call them).
There's a lot of problems with this navigation technique. The first major issue is that they're not terribly effective at what they're supposed to do (namely, helping someone navigate a site). Don't believe me? Then perhaps some experts on the subject can dissuade you (like Jeffrey Zeldman, Jakob Nielsen, and the very guru of UI's, Jared Spool). I'll let the experts speak for themselves, but the heart of the matter is that dropdowns work against the way people naturally try to interact with the data presented on a page, and prove to be an obstacle to navigation, not an aid.
However, as I've noted, dissent is practically a hobby for website creators, so these little gems of the web keep showing up. Worse yet, non-experts who want a website are frequently very adamant about what they want on their websites, research be damned, so at various points in their careers virtually every web developer is going to have to make a dropdown menu or two (or ten, or a thousand. They breed like rabbits.)
So when the time comes to make one, you might as well make one correctly. This would seem an easy proposition, especially for people with even a bit of CSS under their belts, but the reality (as always) is never the same when it comes to developing for the web.
In a perfect world, we could use simple, clean HTML and CSS to make a dropdown menu. We don't exist in such a place, but for argument's sake, take a look at Example #1 to see how something like this would work. We've got a series of unordered lists to hold our menu. The highest level list is the main menu, and always visible. The secondary lists are the sub-menus, which we hide with ul#ulMenu ul {display: none;}
To make the submenus appear on a mouseover is a surprisingly simple, taking advantage of the :hover pseudoclass. ul#ulMenu li:hover ul{ display: block;} causes the selected submenu to appear when you hover over it's parent list item (animal, vegetable, or mineral in my example). It's as easy as that.
Well, in a perfect world.
Unfortunately, we live on a blighted sphere that is frequently troubled by a writhing, unholy, juggernaut of flawed design; a black beast that lives well past its natural lifespan by burrowing through the Earth to collect the souls of the unenlightened.
I speak, of course, of Internet Explorer 6, which was not only horribly flawed in its standards implementation on the day it was first released, it has managed to persist into the modern era where its standards implementation is positively anachronistic and deeply problematic. Why is it still being used? Mostly we can blame corporations and schools afraid of the cost and risk of upgrading their software. But rather than continuing to pontificate on my soapbox, let me just get to the point: approximately 25% of Internet users are still making use of IE6.
This means that in most cases we as website creators need to ensure that our contstructs can operate in the twisted rendering engine that is the black soul crouching at the heart of IE6. Unfortunately for our little dropdown menu, IE6 does NOT support the :hover pseudoclass on any element other than anchors. Which means that 25% of your users can't see your submenus if you're using the example above.
This is unacceptable in professional development.
So what now? Well, we could form some sort of web creator suicide pact and just depart this cruel world while stepping off an appropriately tall tourist destination. But rather than follow down that grim path, I'm going to suggest that we get creative.
Or borrow from people that have. Dropdown menus have been around for more than a little while, and so several clever people have come up with various solutions to the IE6 problem while only making use of valid HTML and CSS.
And more specifically, Internet Explorer's conditional comments.
In particular, I want to thank Stu Nicholls, who by all accounts pioneered the technique, and the fellow(s) at GRC that smoothed out the conditional comments a bit more with their navigation menus. The following example borrows heavily from their ideas and examples.
With credit given, let's take a look at Example #2. It still uses all the same techniques for compliant (or in IE7's case, mostly compliant) browsers. However, we've added a good deal of extra html behind conditional comments.
What are conditional comments, you ask? I've actually discussed this delicious topic before in my cleverely titled post Say Goodbye to the Stars. Go take a gander if you're not familiar with the topic. Once you are, let's continue.
The main obstacle with IE6 and the first example was the :hover pseudoclass only working on anchors. The solution is using conditional comments to create a tiny table inside an anchor tag for each submenu (by using conditional comments we preserve the validity of our markup for the major browsers). We need the table for IE6 so we can have the submenus appear when we hover on the main lists anchor tags.
Say what?
That's correct, since anchor hover styles work in IE6, we're shoving our submenus inside the anchor tags for that browser only, then using IE6-specific CSS to make those menus appear on a a:hover ul{display: block;} rather than the li-oriented style we used for our first example. However, due to various browser quirks, we need to put those submenus inside tiny tables so they actually display (without which, the ul's won't show).
There's some major advantages to this technique, chiefly that it requires only valid HTML (technically) and CSS to work on all browsers. The problem is that to make it valid and still work on IE6, we're using a whole lot of conditional comments, which really should be used sparingly. This is a great technique for a site that we need to ensure the menu works even if the users don't have Javascript enabled.
Although the solution is effective, it's not very elegant. However, we've got a third option: Using CSS & Javascript.
Some designers are quite opposed to making use of Javascript for page elements like navigation, due to the fear that it will make the page unusuable by users with their Javascript turned off. To this I've got two responses: 1. your dropdown menu shouldn't be your only navigation technique (see beginning of post) and 2. Javascript market penetration is pretty much universal at this point in time.
As I've mentioned many times before, a good man by the name of Dean Edwards has used Javascript to create a 'patch' that can fix many of the standards compliance issue that IE6 has. This script (called IE7 confusingly enough), is relatively small-impact on a page's load time, and among other things fixes the :hover pseudoclass limitation. So, by including it on your site with your menu from the first example, you get a site that is (1) valid, (2) clean, and (3) runs on every browser including IE6.
Example #3 shows this in action.
So, which technique should you use? Until IE6 has shrunk to the point of obscurity, you should probably avoid #1 on any site expecting normal traffic. Whether to use #2 or #3 depends a lot on your preference and your client's needs. I think that #3 is the cleaner solution, and many modern sites rely on Javascript to make the site render properly in IE6 these days anyhow, so you're usually fixing more than one problem with this technique. However, #2 is guaranteed to work on pretty much any browser regardless of whether they've disabled Javascript or not, and is completely valid (if only technically so).
However, I say use none of them. Beg and plead your clients to use a more reliable navigation technique. That said, since we've proven we're not in a perfect world, use the solution that best meets your needs and your client's demands.
by Kyle Weems 11.August 2008 12:40
There's a number of axioms that we, as humans, take for granted. One of these is that if it is small, it must be cute.
It's a reasonable thing to believe. After all, kittens are cute, Leptotyphlops carlae are cute, and even the diminutive toy horses that Mindflier (aka, Mindfly employee) Janae is obsessed with are cute. However, there are several exceptions that prove that small is quite clearly not always cute, such as earwigs, Verne Troyer, and most websites on mobile browsers.
Devices other than computers are accessing the web-o-tron in greater and greater numbers these days, chief among them handheld devices such as mobile phones. While the growth of handheld-related web visits in North America has been pretty small so far due in part to the horrendous pricing plans and comprehension of reality by mobile phone service providers, the massive popularity of the iPhone is showing that not only are web-capable handheld devices here to stay, but they're now also becoming the hot 'must-have' items for a growing number of people.
Seriously, try to talk to Mindflier Karina for more than five minutes without her drooling over the idea of owning an iPhone. I suggest bringing a napkin or something.
Web development people have known of this growing trend for years. In fact, we've been preparing for such eventualities with nifty contraptions like the media attribute for link tags and the @media rule in CSS sheets. In CSS3 the ante has been raised by extending the @media rule with media queries, which brings a whole cornucopia of options for device and capability-specific presentation for websites.
Yet I'm willing to wager that well over 90% of websites today have little to no options for being viewed optimally on handheld devices. This might be alright for now, with so far only a small percentage of end users using their tiny screens to view pages on a regular basis, but it goes without saying that this won't be the trend forever, and the smart web designer/developer will be pushing ahead with preparing for those users right now, instead of playing catch-up tomorrow.
So what's the big deal with looking at a website with normal stylesheets with a handheld device?
Well, mostly, size. With only a few notable exceptions, handheld devices have screens only slightly larger than a stamp, and often website designs are fixed at widths of 900 pixels or more. With the media-rich saturation of the modern Internet, a lot of these sites have visually complex designs or large images that won't fit on the tiny browsers of phones (assuming they even get loaded at all). This can turn a gorgeous website into a horrendous patchwork monster, moaning in pain and begging for a swift merciful death.
Rather than finding a shotgun and a priest, we need to be reaching for the appropriate tools of the trade.
Let's look at an example (and fictional) website, Ninjapedia. In Example #1 we see both my limitations as a designer and a page that at least loads as intended in the major browsers on a computer. However, if you were to view it in a handheld device like an Opera Mini-equipped phone, you'd find it rendering quite a bit differently. Opera provides a really nifty simulator for those of you without a browser-equipped phone. Opera Mini (and the browser on the iPhone) will try to load the normal stylesheets to begin with, so the page will show up in a fashion similar to what was intended, although (in Opera Mini's case) it'll be quite zoomed out, and the end user is forced to do a lot of zooming and panning to get all the content. If you haven't experimented with that, you'll quickly find it quite tedious. My own LG mobile phone rendered it even more horribly, making the page pretty much unviewable.
The first tool in the arsenal, then, is to make use of the link tag's media attribute to send specific device types to specific stylesheets for viewing a website. As an example:
<link rel="stylesheet" href="screen.css" type="text/css" media="screen,projection" />
<link rel="stylesheet" href="handheld.css" type="text/css" media="handheld" />
The first link tag has the screen and projection types for the stylesheet, meaning it will render on regular browsers connected to monitors or projectors. The second link tag's value of handheld for the media attribute means it should (key word: should) be loaded by handheld devices. Using these media-rich link tags, then, you should see Example #2 the same on regular computers, but a much less visually ambitious (but still branded and styled) version of the page should show up on handheld devices.
Once again, note the word should. Several ambitious handheld browsers, like Opera Mini and iPhone, think they've got what it takes to be a contender, and like or a kid on Thanksgiving try to sit at the big table. They ignore handheld stylesheets entirely and proceed straight to the regular monitor sheets (such as 'screen'). They even do a very respectable job of rendering the pages. However, due to the small size of their screens, they don't usually look quite right, especially with designs fixed at large widths or utilizing large banners.
As an alternative to the media attributes on link tags, we can instead use the @media rule in CSS sheets. This largely is more of the same, but putting the media declarations in the stylesheet itself. For example:
@media screen {
rules go here
}
@media handheld {
rules go here
}
Example #3 shows this, but the results are effectively the same as Example #2. The problem is that many handheld devices are increasing in capability in rendering pages, but their screens aren't getting any larger, so to view pages effectively end-users with the devices, a ton of zooming and panning occurs. Which, for the record, gets really tedious.
Tedious is not a desirable user experience. I haven't done any usability studies to prove this, but I'm going to guess that Jared Spool and friends have some data somewhere that backs up this fact.
So how do we make the most of these tiny yet capable browsers, while still making websites pretty for big screens and usable for the tiny, incapable browsers?
Well, we start looking at the Media Queries module. Like any part of CSS3, it is not universally implemented, and probably won't be until roughly four years after a man finally lands on Mars, but several browsers (Notably, several tiny browsers) have started making use of it.
What are media queries? They're extensions to the @media rule in CSS. You can decide whether to load styles based not only on the rendering type (screen, handheld, etc) but also based on the screen size and other capabilitites. This is the perfect way to solve our problems with the capable yet tiny browsers of the world. For example, to load a group of styles for a browser attached to a device with a small screen, you could encapsulate the styles as follows:
@media all and (max-width: 400px) {
styles go here
}
This will load the stylesheet (on a capable browser) that has a screen smaller than 400px wide. So putting this all together we've got Example #4, which looks as intended in normal browsers, has a reformed appearance for small but capable browsers, and a more simplified look for normal handhelds. Hooray!
The topic of media queries gets complicated. IE8 is not currently scheduled to support any media queries, Firefox doesn't have support (yet, but should with 3.1) and Safari and Opera support them fully. So the best solution to satisfy all these browsers (And all teh strange pocket browsers of the world) is probably a more robust approach that combines link tags with media attributes, media rules and media queries. Extra work? Definitely. Worth it? If iPhone sales are any indication, it will be.
Plenty of resources are out there for taking a robust approach to making websites accessible to handheld devices. In particular Opera has plenty of reources, such as this article on how to serve the right content to mobile browsers. Go forth and get tiny!
by Kyle Weems 4.August 2008 08:09
I am at this point strongly annoyed by Flash. No, I'm not referencing Flash Gordon, hero of the eponymous 1930's sci-fi serials. I'm referring to Adobe Flash, the multimedia software. However, the two are closely related in one point: overkill.
In the case of Flash Gordon, episode names like "Captured by Shark Men" and "The Tunnel of Terror" probably bring home the point as to what I mean. Alliteration and aquatic predator men kidnapping ladies is the sort of over-the-top adventure that makes bad sci-fi into good bad sci-fi. Not only do I heartily approve of its existence, I'm overjoyed that it is playing on a continual loop at the nearby sci-fi themed bakery Rocket Donuts. Of course, they've got it muted without subtitles, so it the action can get a bit misleading when Flash and an overweight winged man are wrestling around barechested and smiling a tad too much.
However, with Adobe Flash, I've got a problem with the overkill occuring. Mainly, it's being used too often in websites for all the wrong reasons, and later presenting problems down the road when someone like yours truly has to change a website embedded to hell with goofy flash objects with no source code to work with. In my opinion, using Flash as a solution for a dropdown menu is the equivalent to using a nuclear weapon to stop a sixteen year-old from stealing a car. It's not only a massive case of overkill, it is also going to create way more problems than solutions.
Now, I might be a bit over the top when I compare rich media to weapons of mass destruction, but hyperbole has never stopped me from being right. (Usually, not thinking before I speak prevents me from being right, but in this case I'm pretty sure I've ran this topic through my head enough times prior to starting this discussion.)
What's wrong with using Flash to solve small design challenges? Well, first off, it's almost a given that the editable source file for the Flash movie won't be available when a website's owner gets around to hiring a new designer/developer to tune up their website, meaning you'll get to start from scratch.
For those not familiar with the laws of capitalism, time equals money, so this is a bad thing.
Secondly, embedding Flash objects is the web standards equivalent to comitting seppuku. There's just not a good, clean way to do it. One way or another there's going to be entrails all over the place. This is an acceptable evil for a website that's actually including a movie, game, or highly interactive media-rich project. But for a simple slideshow, it's just creating a mess that will only get worse over time.
Lastly, Flash is notoriously evil when it comes to disrespecting Z-index.
When I say 'disrespect', what I mean is that Flash is dragging Z-index into an alley, robbing it, beating it senseless with a cricket bat, then hiding it in a dumpster.
I for one do not wish to support any violence against CSS styles.
So for every person that makes websites out there, I suggest considering the following when a lightbulb goes off in your head with a specific design and you say "Ooh, I could use Flash."
1. What feature are you using Flash for? If it's something appropriate to the plugin, like a movie or such, then great. If not, then...
2. Is there something else that can do the same job just as well, with less of the headaches Flash introduces?
There's a few dozen occaisons where someone failing to walk through those two questions before making a project that later fell into my lap when Mindfly was tasked with tuning up various sites. I know this, because I've been plagued with malfunctioning (or non-editable) Flash image fade-in slideshows for the past eight months.
In the past, I've had to dig around in dusty servers with a flashlight, looking for the editable movie files, trying to decipher the contents within in the couple cases where I got lucky enough to find them, or recreating the slideshows altogether with new flash movies.
Then I stopped and thought about it for a moment.
In each of these projects, nothing complicated or interactive was going on. There was an image (a banner usually) that would slowly fade from one image to another in a continual loop. It was nothing more than a bit of pleasant presentation, like lights on a christmas tree or red heels on a cute blonde.
So why was I fixing the problem with more flash files, just to have someone in a few years curse my name when they got to work on the project next?
There is something else out there that all the major browsers can use that is perfect for changing images. Javascript. Maybe you've heard of it before.
In particular, Javascript is great with CSS manipulation. And thanks to the advances in CSS over the past decade (despite the glacial crawl of CSS3), there's a style or two that can be used to imitate the fading of one image to another. As Javascript is seperate from the markup, and doesn't require some sort of bizzare, ritualistic embedding, it presents a lot cleaner of a page. And as it isn't compiled, the source can be edited or easily swapped out by future developers.
So down to the meat of the solution.
First and foremost, let's look at what we're trying to accomplish: A fade-in slideshow where a series of images fade between one another in a continual loop. Obviously we'll want an image element to hold the current image in. But how do we transition it to the next image in a fade?
Well, for the standard javascript world (as opposed to the world of propietary MS filters), there's no immediate easy 'fadeToNextImage' function. However, thanks to many different JavaScript libraries out there, there's various animation functions that allow us to transition CSS properties. The world of Javascript libraries can be confusing and scary to non-programmers who start dipping their toe into the pool, but one that I enjoy (and is very clearly documented) is jQuery, which I've recently been converted to.
Why? Well, for one it's compact, and for two it keeps things as simple as possible.
Simple is good.
So what we want is to fade out the image into the next image. The first image can easily be faded by animating a transition of it's CSS opacity property from 1 (fully opaque) to 0 (fully transparent). The trick then is having the next image there to be faded into. In an ideal future we'll be able to affect the foreground and background opacity of an element seperately, at which point we could apply a background-image to the image of the next image in the sequence (CSS is fun, isn't it?). However, in this fallen, modern, CSS 2.1 wold we'll have to use an extra element. The idea solution then is a div, which ideally has been given the same dimensions as the image it's holding. Give the div the new background image, then fade the opacity of the original image. It will look then like you're fading one image directly into another. Then flip the new image to the front and repeat the process.
Easy, right?
Well, before you get all panicked, I've created a nifty example (complete with javascript and ninja!) for you right here.
Go ahead and test in all the major browsers. Thanks to jQuery's nifty animation functions the opacity works the same for all of them (despite Internet Explorer's alternate, proprietary method for setting opacity).
The image urls for the slideshow are stored at the top of the fadein.js file as an array. You can easily replace these with other urls (or add more images to the list) to extend or change the library. For those of you with more confidence with Javascript, there's a number of ways you could supply the array for the URLs, such as an AJAX call. Using CSS selectors, you can change the target of the slideshow function as well, and if you feel up to it, even call for multiple slideshows on the same page. Just remember, you need to target the wrapper, not the image, with the function.
This is just one example of using Javascript for slideshows, of dozens out there. But more importantly, it's an example of not relying on Flash for a solution when a less intensive, less invasive option exists.
Save Flash for the movies, games, and rich web apps. A site with just fancy presentation can be done just as gorgeously without it.