Arc and Angle

Oh my goodness, what is Facebook thinking!? It’s so disappointing to see the company so blatantly focus on revenue instead of the users. I’m not going to repost every good article I’ve read about its disregard for privacy issues, its terrible user interface, or the highly questionable behaviors of its current CEO because there are plenty of well-documented articles out there. Facebook and Zuckerberg are the talk of the town, at least in the computer world, and its mostly negative.

A few months ago I watched a video online of Matt Mullenweg, the founder of WordPress, being interviewed and he mentioned that he strongly believed that in due time, Facebook would eventually succumb to an open-source social networking application.

It seems that we may be seeing the beginning of this. Fueled by a high state of disenchantment with Facebook, a small group of young motivated guys (still in college) are getting a lot of attention and a lot of verbal and financial backing for a decentralized, open-source social network. They’re starting this at the right time. They’ve named it Diaspora and it hasn’t even been programmed yet, but they’re off to a good start having raked in several thousands of dollars in less than two weeks. They have vowed to spend all summer staring at their computer screens hacking this project out. I’m excited for them and hope it spawns some awesome alternative to Facebook.

There come a few times in a budding web designer’s life when they discover something very useful and incredibly helpful and they wonder, “Why on earth did nobody tell me about this before!?” And, being the collaborative souls that they are, they think, “I will share the news with all of the others so that they too will reap the benefits of this new knowledge!”

It is then that the cold truth rises to the surface. The fact is, this news is completely geeky and the topic is completely, assuredly boring to just about everyone except our inspired little geek.

Well, lucky for me I have a blog for this sort of thing. It may not interest my loved ones and does not merit an “I made a new post!” announcement on my various social networking sites, but I know that I have an audience out there. Somewhere out in the vast hinterland of the Internet, a lone shivering geek must also be asking, “Is there another way to make my web site faster!?!?!?”

And like me, they shun the easy non-standards solutions of image maps. Like me, they have read and re-read countless articles on how to optimize photos for the web. And like me, they felt there just must be something else out there. Something warm and fuzzy, like a tiny piece of code.

Today on my journeys, I learned a few new things on topics whose keywords involve GZip, htaccess, Live HTTP Headers, and YSlow. Don’t go away! Now’s where it gets exciting!

Just about every web developer uses Firefox add-ons, especially the Web Developer Toolbar. There are two others that are particularly useful when trying to increase the loading speed of a site and for some silly reason, I never used them until today: Yslow analyzes a site’s performance based on Yahoo’s rules for web performance and Live HTTP Headers displays the live communications between your browser and a site’s server.

I used YSlow to analyze one of my sites. I got an “A” in everything except GZip compression. Huh? I did some reading and discovered that I might need to configure my server to output GZip compression. To check this, I scanned the dialog between my browser and the server using Live HTTP Headers. I saw that my browser sent this request: “Accept-Encoding: gzip, deflate.”

This is the browser telling the server, “FYI, I accept compressed files if you have any.”

The server ignored that request, meaning that it was not set-up to Gzip my content. Bah!

I have a shared-hosting plan and never realized that I have access to certain server set-up options. Web hosts who put dozens of clients’ sites on one server would be insane to allow everyone access to the server’s config file. I thought I’d just have to send them a message if I needed something on the server changed. It turns out that individual accounts may have access to certain set-up options by using an .htaccess file (hypertext access).

First, locate the file. I signed into CPanel, went to the file manager, clicked on a little check box to allow me to view hidden files, and then went into my home directory. There it was, “.htaccess”. I clicked on it to edit it and added code from BetterExplained to configure the server to allow compression output.

# compress all text & html:
AddOutputFilterByType DEFLATE text/html text/plain text/xml

# Or, compress certain file types by extension:
<Files *.html>
SetOutputFilter DEFLATE
</Files>

I saved the file.

I then reloaded my site and behold! The load time was four times faster! My work here is done.

For great reading, check out these articles:

• BetterExplained: “How To Optimize Your Site With GZIP Compression”
• Yahoo! Developer Network: “Best Practices for Speeding Up Your Web Site”

This blog entry covers:

• Why it is important to use relative text sizing units (ems and percentages)
• Why NOT to use pixel units
• Why NOT to use point units
• Why NOT to use keywords
• Helpful resources

When designing web pages, you might think that choosing a font size should be amongst the easiest and quickest decisions a web designer makes: simply choose a readable pixel size and move on right? Well, that is one way to do it…but it certainly isn’t the most thoughtful, adaptable and accessible. It is, for several reasons, bad practice and anyone designing a website should seriously consider getting acquainted with the relative way of sizing text. It takes more work, but it’s a more efficient method that produces better results across multiple browsers and devices and allows your content to be accessible by a wider audience.

Pixels are not the only way to size text. The units available to web designers for sizing text are pixels, points, percentages, ems, and even keywords.

So which should you use?

Ems and percentages are considered the desirable units for sizing fonts using CSS because they avoid the pitfalls of pixel and point sizing (explained below), are re-sizable in all browsers that support resizing, AND are relative to a user’s font size preferences.

Yeah, well, computer screens display in pixels. I love pixels. Why shouldn’t I design in pixels?:

That would be lovely if everyone used the same browser, the same monitor and if we all had the same vision. We, however, don’t live in that world and good design keeps functionality at the forefront. A well-designed website will allow text resizing and will do its best to look the same across different browsers, platforms, devices, etc. The proper text sizing tool in the web designer’s arsenal is not the pixel, it is the em (with a little help from the %).

When it comes to text (and line-heights), our usual friend The Pixel, ignores user preferences and doesn’t re-size in Internet Explorer. This makes pixel-defined text sizes a bad idea when considering accessibility issues and we must consider accessibility issues. Accessibility to equal information and services is not only a human rights issue (which is reason enough), but also about making sure your code can be adaptable to a variety of devices and applications.

The resizing issue can’t be underestimated. Internet Explorer stills claims the largest audience and small text is a very real problem for countless users.

Another drawback, albeit one that I am guessing is not an issue for the majority of websites, is an inconsistency amongst browsers on how to handle non-integer pixel values (i.e. some can handle 12.5 px, while others can not). This matters if pixel-perfect sizing is desired on every major browser. I doubt designers regularly (if ever) code non-integer pixel units for text sizes, but it can accidentally happen when a pixel value is applied to a parent and a percentage or em to its child.

Ok, what about points?:

No! Don’t do it! Points were not designed for screen-based design. They are a great desktop publishing unit, but not a great web design unit. When being converted to pixels, the math is extremely inconsistent amongst different browsers. It’s a confusing explanation best left at: don’t use points for text sizing unless you are writing a print-media style sheet.

Hm, well, that leaves keywords?:

No again and I find them too confusing to explain very well, but they offer up the same issues as points regarding consistency and control problems. For a detailed explanation by someone much better at explaining these than me, feel free to read this concise explanation.

Helpful Resources:

The Em Calculator: Converts pixel sizes into em sizes

A List Apart article: Explains how to use ems and percentages to size text using CSS