Cascading Style Sheets are what makes the Web not boring. CSS is descended from SGML (Standard Generalized Markup Language), which was created in the 1970s. The first version of the CSS standard was published in 1996, with version 2 being finalized in 1998. Version 3 is still under development.
The first browser to fully support CSS1 was a browser that only one person remembers: Internet Explorer 5 for the Mac. You read that right: The first CSS standards-compliant browser was created by Microsoft. That was in 2000, four years after the standard was first published and two years after CSS2 was released. Other browsers played catch-up in the months following.
The problem with the Internet in the time leading up to the adoption of the CSS standards was that no one had been willing to wait for the standards body to, well, standardize, and so they implemented horrible proprietary things like <blink> and <marquee>. Each new version fought to not only include the newfangled tags that its competitors had introduced, but also to create new features of its own. "Best viewed on <browser x, version y> at <designer's screen resolution>" became all too common.
So who was our knight in shining armor who delivered us from this? Internet Explorer 6.
Indirectly, of course. IE 6 in and of itself was not particularly revolutionary, except for the fact that its Standards Mode hewed more closely to the standards than any other major browser at the time (sorry, Opera, even back then you weren't a major browser). The revolution was its competitors.
See, IE 6 had something called Quirks Mode. Basically, if your HTML document had a certain doctype (or no doctype declared at all), the browser would fall back and render the page like IE 5 would have. This was to keep old pages from breaking. One consequence of this was that the infamous "whitespace bug" was perpetuated. CSS2 support was also not as good as it could have been. Mozilla and others jumped into the fray at this point, reigniting the browser wars. The result? Today, because IE 6 was so bad, we have Firefox, Opera, Chrome, and IE 9 (which will supposedly implement the standards way better than any previous version of IE).
Thank you, IE 6.
November 09, 2010
November 01, 2010
Instant Results and Spin
After reading the transcript of the SpoolCast episode Luke Wroblewski and Innovations in Web Input, I decided to write about two subjects they brought up. It's a double post! What does it mean?!*
*Yes. This joke is stale.
Isn't Google Instant Awesome?
I mean, really! You start typing and (as long as you're not using Opera) results just pop up (unless your connection's too slow)! It's like magic! It makes Amazon's search suggestions look quaint and your public library's catalog search look positively archaic! Why can't they do magic like that, too?
Well, Google has approximately one quadrillion times the resources of your public library, for one thing. Something like Google Instant takes a lot of resources. If a company tries to implement something like that without the required resources, the resulting performance hit (and probably downtime) is as bad as or worse than not having search at all. Yahoo! actually tried to implement something similar to this in 2005, but they ended up ditching it because they were concerned about server load.
This does put smaller organizations at a bit of a disadvantage, because if people get used to seeing results instantaneously, they start expecting it everywhere. Why should I have to type my entire search query, hit enter, and wait for another page to load? (I guess you could argue that Google is aiding Twitter's nefarious plot to shorten the attention span of the world's population.) Unfortunately, though, businesses have to allocate resources to the activities that will provide them with the most benefit, so Google Instant-esque capabilities are probably going to be fairly low on the list.
Their Numbers Don't Mean As Much As You Think They Do.
On the other hand, one could argue, for the time period mentioned in this anecdote, maybe 160 million users isn't the metric we should use to judge Ping's success. Surely, not all 160 million people are trying to buy music at the same time. Maybe only half of them are typically online at any given time. That makes Ping's user base…just over 1%. The point is, a company can spin numbers in a multitude of ways to make themselves sound better.
(Wroblewski goes on to suggest that the reason for Ping's disappointing adoption rate is an uncharacteristic lack of attention to detail on Apple's part. Version 2 might be better.)
*Yes. This joke is stale.
Isn't Google Instant Awesome?
I mean, really! You start typing and (as long as you're not using Opera) results just pop up (unless your connection's too slow)! It's like magic! It makes Amazon's search suggestions look quaint and your public library's catalog search look positively archaic! Why can't they do magic like that, too?
Well, Google has approximately one quadrillion times the resources of your public library, for one thing. Something like Google Instant takes a lot of resources. If a company tries to implement something like that without the required resources, the resulting performance hit (and probably downtime) is as bad as or worse than not having search at all. Yahoo! actually tried to implement something similar to this in 2005, but they ended up ditching it because they were concerned about server load.
This does put smaller organizations at a bit of a disadvantage, because if people get used to seeing results instantaneously, they start expecting it everywhere. Why should I have to type my entire search query, hit enter, and wait for another page to load? (I guess you could argue that Google is aiding Twitter's nefarious plot to shorten the attention span of the world's population.) Unfortunately, though, businesses have to allocate resources to the activities that will provide them with the most benefit, so Google Instant-esque capabilities are probably going to be fairly low on the list.
Their Numbers Don't Mean As Much As You Think They Do.
I used this analogy recently…there's 160 million iTunes users, and within 48 hours they announce that one million of them were on Ping. So the metaphor I used there was, well if 160 million people are driving down a road, and I put a pile of dog poo on that road, chances are one million will drive through it. — Luke WroblewskiIn a world where Apple can do no wrong, their music social network Ping is a fledgling feature that hasn't yet reached its full potential. In the real world, well, it's been compared to a pile of dog poo. "One million" is a useless measure without context. I'd love if one million people read my blog. Facebook would probably kill a new feature that only attracted one million users. For the iTunes Store, one million is less than 0.7% of their users.
On the other hand, one could argue, for the time period mentioned in this anecdote, maybe 160 million users isn't the metric we should use to judge Ping's success. Surely, not all 160 million people are trying to buy music at the same time. Maybe only half of them are typically online at any given time. That makes Ping's user base…just over 1%. The point is, a company can spin numbers in a multitude of ways to make themselves sound better.
(Wroblewski goes on to suggest that the reason for Ping's disappointing adoption rate is an uncharacteristic lack of attention to detail on Apple's part. Version 2 might be better.)
October 31, 2010
Usability In The Rainforest
On the web, usability refers to the ability of users to find and use stuff on a website. (How's that for a circular definition?) According to Mel Pedley on Accessites.com, there are five core components of usability:
- Learnability: On a first visit, can users find what they're looking for?
- Effectivity: Can users do stuff quickly?
- Memorability: If it's been a while since a user was on the site, can s/he still use the site?
- Reliability: How error-prone are users while using the site?
- Enjoyability: Do users like using the site (or, at least, do they not hate it with the burning passion of a thousand suns)?
She sees that Amazon is the first result, and decides to click on it. (Hey, bonus points for findability!) She is then dumped onto Amazon's main page.
Okay, not a problem. Amazon's apparently a big site, which makes sense since her search query was very general. She looks around for "DVD Burners", or "Computer Components", or anything that looks like it could be what she's after. There's "Computers & Office" in the sidebar, and voila! There's "Computer Components" right there.
Lots of computer components to choose from. She remembers now why she asked her nephew for help the last time she needed to buy computer parts. Where are the DVD burners?
She scrolls down and – oh, there they are! Her nephew told her once that optical drives are the same as CD/DVD drives, so she clicks there.
She's still looking in the upper-left corner when the next page loads, so she immediately sees the link for "DVD Burners" in the navigation and clicks on it, too. No use in seeing all that other stuff she's not after.
Now that Sarah has found the DVD burners, let's evaluate how Amazon has been doing so far.
- Sarah could find what she was after with relative ease, so they get a point for learnability. (On the other hand, if she had been looking for something more obscure, she probably would have had a harder time of it.)
- She didn't have to waste a lot of time to get to where she was going, but she had the benefit of already knowing that "optical drives" and "DVD burners" were synonymous. Therefore, Amazon's effectivity was mediocre.
- This is a first-time visit, so we're not analyzing memorability.
- Sarah could easily have missed the link she needed to click on a few different times, because it was not necessarily put in a place that made the most sense. Reliability may or may not be an issue.
- So far, Sarah doesn't have a problem with using the site, so its initial enjoyability is not an issue.
October 17, 2010
Accessibility Is The Path To Awesomeness
That's one definition of accessibility in an online context. A simpler definition might be: A web site that everyone can use. That's a touch simplistic and idealistic, but it gets closer to what accessibility truly is.Accessibility in the context of a Web site is the degree to which that Web site is usable by people with disabilities. Web pages often have access issues for the following groups of people:
- Visually impaired people using screen readers
- Hearing impaired people using browsers with no sound
- Physically impaired people
- Color blind people (About.com, "Definition: accessibility")
There are a lot of resources out there devoted to helping web designers make their sites more accessible. The University of Minnesota, for example, has a long list of resources and tools related to accessibility. It's pretty overwhelming. About.com also has several articles about accessibility.
There's a simpler method, though, and while it's not 100% foolproof, it will get you fairly close to an accessible website. It is this: Use common sense and well-formed HTML code.
"But," you protest, "what about access keys, and alt text, and all those other things they talk about?" Remember what I said about well-formed HTML code. Images are required to have alt attributes in order for a page to validate. (Pages will still validate with blank alt attributes, though. That's where using common sense comes in: does the page still make sense without the image and without any alt text?)
Access keys (alt+[key]) are slightly different, as they are not required in valid HTML code. It also doesn't always make sense to use them. Using too many on a page can be overwhelming for a user. You also have to be careful not to use keystroke combinations that are already used for browser menus or other similar functions.
The WAVE report for the main page of Wikipedia reveals the access keys that are in use there. By my count, there are 14 different access keys, which make varying degrees of sense. Alt-F might make sense if the search field were labeled "Find articles", but it is not. Alt-U for "Upload file" does make sense, but Alt-K for "Related changes"? Another problem with using Alt-F to get to the search field is that that combination is used in nearly every Windows program to access the File menu. Firefox gets around this by adding Shift to the access key combination (Alt-Shift-F), but Safari overrides the default (Alt-F always brings up the search field).
Wikipedia does do something right, though. If you disable styles on the page, the navigation drops down to the bottom of the page. This makes it easier for people with text-only browsers or screen readers to get to the content.
Another important aspect is the color scheme. If you're planning on designing a Christmas website with red text on a green background, remember that about 5-7% of people suffer from red-green color blindness, or protanopia/deuteranopia, which would make it extremely difficult or even impossible for them to even see that there's text there. Tritanopia is another type of color blindness that affects a person's ability to see blue. One of my friends in college suffered from monochromacy and could only see shades of gray. When choosing colors, you might try using a graphics editor to convert them to grayscale and see if there is enough contrast there even without any "real" coloration.
Finally, organizing content in a way that makes sense is probably the most important step towards accessibility. Remember, you're not designing just for someone with a disability. You're designing for everyone.
September 26, 2010
Beauty In Type
@font-face {Do you know what this is?
font-family: "FontinSansRegular";
src: url('fonts/fontinsans.eot');
src: local('?'), url('fonts/fontinsans.woff') format('woff'), url('fonts/fontinsans.ttf') format('truetype'), url('fonts/fontinsans.svg#webfontn8vXGJ0x') format('svg');
font-weight: normal;
font-style: normal;
}
It's the future.
Okay, maybe it's not quite that dramatic. However, it does represent a huge step forward in web design. It's a web font declaration in CSS.
Let's go back to the dark ages, when Internet Explorer and Netscape Navigator ruled the Internet. In those days, text online was rendered in whatever fonts you had on your system. Running Windows 95? You got Arial and Times New Roman. Running a Macintosh? Default fonts were Chicago and New York.
Then came CSS, Internet Explorer 3, and the core fonts for the Web project.
The core fonts project aimed to provide a set of fonts that would be widely downloaded and used, which was supposed to ensure that websites looked the same across platforms. The downside to this was that the fonts had to be present on the user's system, not just on the web server. Granted, due to Windows' near-complete domination of the computer market, the vast majority of people probably did have the fonts installed. With the new (partial) CSS implementation in IE 3, you could specify typefaces. Yes, that's a choir of angels you hear singing "Hallelujah".
It still wasn't perfect, not by a long shot. You were still limited to whatever fonts your users had on their systems. You could be reasonably sure, however, that the fonts included in the core package were going to be present for the vast majority of your users. I mean, I could design a page using Footlight MT Light, but it might fall back to Times New Roman on your system.
With the introduction of the @font-face declaration in CSS 2, you could finally reference fonts that weren't stored on the user's computer! In the example above, I'm telling the browser to grab the Fontin Sans file, which is stored in the subfolder fonts. On my server. Not your computer. As long as you're using a browser that's at least as new as Internet Explorer 4, you'll see Fontin Sans on this webpage.
"Wait!" you say. "It displayed your fancy-schmancy new font after a minute, but when it first loaded, [it was in Times New Roman/I couldn't see any of the text]! What gives?"
Yeah, that's the problem with using @font-face. Pingdom says that fontinsans.ttf is one of the last things to load, and it takes a comparatively long time to load on top of that. Until it loads, the page is in limbo. Different browsers handle this limbo time in different ways. Firefox and Opera temporarily fall back to the next font in the font stack. Safari completely hides the text (though not the underline on hyperlinks, interestingly enough; if you load that page in Safari, you can see random lines going across the screen). Internet Explorer, for me at least, takes so long to load the entire page that it renders in Fontin Sans when it finally displays.
When the page is finished loading, though, the typeface is so beautiful that it makes Michelangelo weep.
(Again, maybe not quite that dramatic.)
Want to learn more?
September 13, 2010
I Have A Canvas And A JavaScript Paintbrush
One of the biggest problems of the Internet today is an over-reliance on proprietary plugins. Mac users will be especially familiar with the feelings of abject rage as a Flash game bogs down their system, takes over a chunk of memory, and causes the fans in their laptop to whir consistently, due to the lack of hardware acceleration in the Mac version of Flash Player (which was only recently remedied). There's Flash, Silverlight, Java, and whatever proprietary single-use plugin TV networks' websites make you install to watch their shows.
"So what?" you say. "I just install the plugins when I need them. No big deal." Yeah...except each one requires a download, an installation, and a browser restart. It's a hassle. (And we won't get into cross-platform issues.)
Better than that, each plugin introduces its own set of security holes. Flash is notorious for this, but it is not alone in that regard.
Plugins used to be the only way to provide interactivity to a website. Something better is looming on the horizon, though: HTML5, and with it, <canvas>, <video>, and <audio>.
The video and audio tags are fairly self-explanatory. As long as the browser properly implements them, they provide plugin-free playback for videos and sound, respectively. Canvas is an HTML tag that essentially gives you a blank area that you draw on using JavaScript. The code required is fairly similar to creating graphics in a Java applet, for those of you who are familiar with that.
Java Applet Code:
g.setColor(new Color(0x5E, 0x2F, 0x00));
g.fillRect(0, 180, 200, 50);
JavaScript Canvas Code:
ctx.fillStyle = "#5E2F00";
ctx.fillRect(0, 180, 200, 50);
Canvas/JavaScript provides no easy way, however, to draw ovals or rounded shapes. Compare the two methods for drawing a rectangle with rounded corners:
Java Applet Code:
g.setColor(Color.white);
g.fillRoundRect(45, 35, 50, 35, 10, 10);
g.setColor(Color.black);
g.drawRoundRect(45, 35, 50, 35, 10, 10);
JavaScript Canvas Code:
ctx.fillStyle = "#FFFFFF";
ctx.strokeStyle = "#000000";
ctx.beginPath();
ctx.moveTo(45, 45);
ctx.quadraticCurveTo(45, 35, 55, 35);
ctx.lineTo(85, 35);
ctx.quadraticCurveTo(95, 35, 95, 45);
ctx.lineTo(95, 60);
ctx.quadraticCurveTo(95, 70, 85, 70);
ctx.lineTo(55, 70);
ctx.quadraticCurveTo(45, 70, 45, 60);
ctx.lineTo(45, 45);
ctx.fill();
ctx.stroke();
ctx.closePath();
Even with that convoluted code, I still saved approximately 60 lines of code generating this image in JavaScript with canvas than it took to do the same thing in a Java applet. Most of this savings probably came from the fact that JavaScript has both a fillStyle and a strokeStyle, while Java uses setColor() for everything, necessitating more color changes. Plus, the user doesn't have to install a plugin to make it work, it renders pretty much instantaneously in the browser window, and you could copy the generated image and save it if you wanted to, which would be useful if you wanted to code a drawing web app of some sort.
Want to learn more about drawing with <canvas>?
"So what?" you say. "I just install the plugins when I need them. No big deal." Yeah...except each one requires a download, an installation, and a browser restart. It's a hassle. (And we won't get into cross-platform issues.)
Better than that, each plugin introduces its own set of security holes. Flash is notorious for this, but it is not alone in that regard.
Plugins used to be the only way to provide interactivity to a website. Something better is looming on the horizon, though: HTML5, and with it, <canvas>, <video>, and <audio>.
The video and audio tags are fairly self-explanatory. As long as the browser properly implements them, they provide plugin-free playback for videos and sound, respectively. Canvas is an HTML tag that essentially gives you a blank area that you draw on using JavaScript. The code required is fairly similar to creating graphics in a Java applet, for those of you who are familiar with that.
Java Applet Code:
g.setColor(new Color(0x5E, 0x2F, 0x00));
g.fillRect(0, 180, 200, 50);
JavaScript Canvas Code:
ctx.fillStyle = "#5E2F00";
ctx.fillRect(0, 180, 200, 50);
Canvas/JavaScript provides no easy way, however, to draw ovals or rounded shapes. Compare the two methods for drawing a rectangle with rounded corners:
Java Applet Code:
g.setColor(Color.white);
g.fillRoundRect(45, 35, 50, 35, 10, 10);
g.setColor(Color.black);
g.drawRoundRect(45, 35, 50, 35, 10, 10);
JavaScript Canvas Code:
ctx.fillStyle = "#FFFFFF";
ctx.strokeStyle = "#000000";
ctx.beginPath();
ctx.moveTo(45, 45);
ctx.quadraticCurveTo(45, 35, 55, 35);
ctx.lineTo(85, 35);
ctx.quadraticCurveTo(95, 35, 95, 45);
ctx.lineTo(95, 60);
ctx.quadraticCurveTo(95, 70, 85, 70);
ctx.lineTo(55, 70);
ctx.quadraticCurveTo(45, 70, 45, 60);
ctx.lineTo(45, 45);
ctx.fill();
ctx.stroke();
ctx.closePath();
Even with that convoluted code, I still saved approximately 60 lines of code generating this image in JavaScript with canvas than it took to do the same thing in a Java applet. Most of this savings probably came from the fact that JavaScript has both a fillStyle and a strokeStyle, while Java uses setColor() for everything, necessitating more color changes. Plus, the user doesn't have to install a plugin to make it work, it renders pretty much instantaneously in the browser window, and you could copy the generated image and save it if you wanted to, which would be useful if you wanted to code a drawing web app of some sort.
Want to learn more about drawing with <canvas>?
- HTML 5 canvas - the basics
- Canvas tutorial - MDC
- W3Schools HTML5 tutorial (for HTML5 in general, not canvas specifically)
September 05, 2010
The Standards Are There, So Use Them
Imagine a scenario.
Kate has just been hired by Widgets Ltd., a start-up company that is being run in a garage outside Madison, Wisconsin, to create a website for their products. She has no web design experience outside of Comp Sci 101, back in the bad old days of freshman year. "No problem," she thinks to herself. "I've got an old copy of Microsoft FrontPage here. I'll just draw some tables and drop the content in. Easiest money I ever made."
Of course, we, as web developers ourselves, can imagine the hideous code that will result from this misguided approach:
What are web standards, you may be asking? They are a set of guidelines codified by the World Wide Web Consortium (and Ecma International, which standardizes ECMAScript/JavaScript). They define the elements, the syntax, the attributes, the doctypes, everything. Browser developers then take these standards and program their browsers to properly render web pages based on these standards. Opera generally leads the pack as far as standards compliance, with Firefox and Safari following and Internet Explorer trailing in a distant fourth.
Now, designing with web standards does not mean making your website look exactly the same across all browsers. Someone looking at it in Firefox on Windows XP is going to get a slightly different look than someone looking at it in Safari on Snow Leopard. Is that wrong? Is that bad? Not at all. Very few people will even notice without you pointing it out to them. They're different, not wrong — if you coded the site correctly, that is.
So, in summary, my argument for designing to web standards is this. Internet Explorer 6 (and prior versions) didn't care about abiding by web standards, and complications stemming from that caused much wailing and gnashing of teeth. Why would you want your website to even have a possibility of inspiring a response like that? Design to the standards. It will cause many fewer problems.
*The problems described herein are not unique to Microsoft products by any means. However, every time I bash Microsoft, Canonical and Red Hat send me a tenth of a penny. I look forward to being able to afford a gumball.
Kate has just been hired by Widgets Ltd., a start-up company that is being run in a garage outside Madison, Wisconsin, to create a website for their products. She has no web design experience outside of Comp Sci 101, back in the bad old days of freshman year. "No problem," she thinks to herself. "I've got an old copy of Microsoft FrontPage here. I'll just draw some tables and drop the content in. Easiest money I ever made."
Of course, we, as web developers ourselves, can imagine the hideous code that will result from this misguided approach:
<html><head>So much for separating organizational and display functions. Kate's work failed to adhere to (or even consider, for that matter) web standards. Without boring you with the details, the above code snippet contains four errors when run through the W3C HTML Validator — and we haven't even made it to any of the actual content yet.
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Welcome to Widgets, Ltd.!</title>
</head>
<body bgcolor="#00FFFF" link="#00FFFF" vlink="#00FFFF">
<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber1" height="59">
What are web standards, you may be asking? They are a set of guidelines codified by the World Wide Web Consortium (and Ecma International, which standardizes ECMAScript/JavaScript). They define the elements, the syntax, the attributes, the doctypes, everything. Browser developers then take these standards and program their browsers to properly render web pages based on these standards. Opera generally leads the pack as far as standards compliance, with Firefox and Safari following and Internet Explorer trailing in a distant fourth.
Now, designing with web standards does not mean making your website look exactly the same across all browsers. Someone looking at it in Firefox on Windows XP is going to get a slightly different look than someone looking at it in Safari on Snow Leopard. Is that wrong? Is that bad? Not at all. Very few people will even notice without you pointing it out to them. They're different, not wrong — if you coded the site correctly, that is.
So, in summary, my argument for designing to web standards is this. Internet Explorer 6 (and prior versions) didn't care about abiding by web standards, and complications stemming from that caused much wailing and gnashing of teeth. Why would you want your website to even have a possibility of inspiring a response like that? Design to the standards. It will cause many fewer problems.
*The problems described herein are not unique to Microsoft products by any means. However, every time I bash Microsoft, Canonical and Red Hat send me a tenth of a penny. I look forward to being able to afford a gumball.
Subscribe to:
Posts (Atom)
