Category: Web Design

Posted on
by

Well, I signed up with Gravatar, mainly so I could test the plugin.

Basically the idea is that you can define an avatar that will follow you around the Internet, anywhere you post. All that’s necessary is for the site you’re commenting on to be Gravatar-enabled at the time someone visits.

The one thing I’m not entirely thrilled about is that it uses your email address as the basis for your ID. They really didn’t have many options to choose from, since most blog comment forms only have space for your name (not always unique), email address, and website (not everyone has one). To avoid publishing addresses accidentally, they one-way encrypt it using MD5. (MD5 is a hash function, so while you can have two systems generate an MD5 signature from the same data to see if it matches, you can’t restore the original from the signature.)

If you’re interested in Gravatars, head over to their site, see if you agree with their policies, and if you enter your email address when commenting (don’t worry, current and future WordPress versions never display it outside of the admin area), your avatar will show up next to your comments.

Anyway, once I had gravatars showing up, I had to find a layout that (a) looked good and (b) worked in IE. (Yes, that again.) Continue reading →

Posted on
by

All the Linux desktop action these days is in KDE and GNOME, but on older hardware, servers, or anything else where you need to squeeze every last ounce of performance from the box, something lighter is needed.

[Screenshot of a WindowMaker desktop] My Linux box at work — a 300 MHz Pentium II — runs WindowMaker. It’s familiar, it stays out of the way, and it doesn’t tie up the memory or CPU that a modern version of KDE or Gnome (or Windows, for that matter) would. But you need to add applets like a clock or a desktop pager. You can find them easily enough — I ended up using the aptly-named wmclock and wmpager – but there’s a significant problem with both. WindowMaker lets you change the size of the dock icons, but when I shrank the dock to get more space I discovered that both applets have a hard-coded size of 64×64 pixels.

[Pair of WM Applets, first at default 64x64 size (they look fine), then at 48x48 (they don't adjust and edges get cut off)] As you can see, a 64×64 applet just doesn’t work in a 48×48 space. It surprised me, though, since these dockapps are designed specifically for WindowMaker, and it’s WindowMaker itself that lets you change the size. You open up Preferences, change the size, and restart WM. Just menus and buttons. No config files, no registry, no third-party add-on. This isn’t an esoteric hack that takes serious effort to find, it’s a basic feature. You might as well design a Mac program that assumes the Dock is on the bottom of the screen. For most people it will be, but it’s not rocket science to move it.

In my ICS classes, they always discouraged us from using “magic numbers” — just throwing a number in the code without identifying or abstracting it. There are two very good reasons for this. The first is that you might forget what this 64 is doing. The second is that you might decide to change it later on, and it’s much easier to change one SIZE=64 definition than to track down every 64 and hope you’ve neither missed any you need to change nor changed any you need to leave alone.

Those dock applets are stuck at 64×64 pixels because the programmers were thinking in terms of the pixel grid, not in terms of actual display size. Continue reading →

Posted on
by

Some people browse collections. I collect browsers. Mostly I just want to see what they’ll do to my web site, but I have a positively ridiculous number of web browsers installed on my Linux and Windows computers at work and at home, and I’ve installed a half-dozen extra browsers on our PowerBook.

One project I’ve worked on since my days at UCI was a script to identify a web browser. In theory this should be simple, since every browser sends its name along when it requests a page. In practice, it’s not, because there’s no standard way to describe that identity.

Actually, that’s not quite true. There is a standard (described in the specs for HTTP 1.0 and 1.1: RFC 1945 and RFC 2068), but for reasons I’ll get into later, it’s not adequate for more than the basics, and even those have been subverted. That standard says a browser (or, in the broader sense, a “user agent,” since search robots, downloaders, news readers, proxies, and other programs might access a site) should identify itself in the following format:

  • Name/version more-details

Additional details often include the operating system or platform the browser is running on, and sometimes the language.

Now here are some examples of what browsers call themselves: Continue reading →

Posted on
by

A few weeks ago I was looking at the website error logs and noticed some attempts to access images with names like /flash/images/%20%20%20%20%20%20%20ans3.jpg. I got around to looking at it today, and all of them are the same name, all of them from browsers looking at my profile of the Teen Titans, which includes an image called teentitans3.jpg.

I finally realized what’s going on. Some moronic filter has broken up the name not as “teen titans” but as “teen tit ans,” decided it must be porn, and replaced the “offending” words with spaces (%20 is the code for a space in a URL).

It really makes me wonder how badly mangled the page looks to these people, especially if it turns out that every instance of the team’s name gets pointlessly erased.

Further reading: The Censorware Project, Peacefire, Electronic Frontier Foundation.

Posted on
by

I just caught a reference to Arve Bersvendsen’s EvilML file. What is it? It’s an HTML document designed to make use of the fact that HTML is, technically, SGML, which has all kinds of strange shortcuts you can use. Of course, no one has ever bothered to make a web browser that actually handles all these shortcuts.

It’s hard to describe it. The code is barely readable. The first line of text looks like this: <body<h1<em>Emphasized</> in &lt;h1&gt;</>. No browser in existence is likely to display it correctly, and yet — amazingly enough — it validates…

I already thought that moving to the more rigidly-defined XHTML was a good idea, but suddenly it makes a lot more sense!

Posted on
by

While looking for more ideas related to my earlier post on fighting link rot, I came across some interesting articles:

Web Sites that Heal [archive.org] considers some of the causes of linkrot, including: changing CMS systems (which I’ve dealt with here twice), poor structure (starting small and simple, but finding that as the site grows, the old design doesn’t work anymore), lack of testing, and plain apathy. More interesting are some of the reasons it becomes a problem, in particular the difficulty in setting up redirections and informing other sites that you’ve moved. That’s something else I can relate to: My site hasn’t been on the UCI Arts server in four years, yet despite a massive attempt to get people to update their links, Altavista still shows 82 pages linking to my site’s old location. Something I think the article leaves out is the number of sites – particularly people who set up a free Geocities account back in the dot-com era – that just aren’t maintained anymore. The pages are there, but they’re six years out of date – and so are the links.

The article then proceeds to suggest an automated server-to-server system that will detect incoming links to a moved page, then contact the referring site, report the new location, and instruct it to update the link with no human intervention whatsoever. A great idea, though it will require people like me to drop the edit-locally-and-upload model of development.

“Web Sites That Heal” referred to a Jakob Nielsen column on Linkrot. Nielsen’s advice is frequently useful, though not always applicable [archive.org]. Sadly, his recent columns have tended toward rehashing old ones or applying to ever more specialized niches, but sometimes his advice is spot-on. In this case, the article from six years ago still applies to today’s web: run a link validator on your site from time to time, and keep old URLs on your own site active (whether with actual content or with a redirect). The comments on this article are worth reading as well.

Lastly, I found a remark on Consequences of Linkrot [archive.org] as applied to weblogs. Most of the post is actually an excerpt from Idle Words, where the original author notes that the classic blog post – a single line linking to something of interest, or a series of the same – is particularly susceptible to linkrot. Without the original material, there’s nothing (or next to nothing) left. And it happens fast: The Web isn’t that old, and blogging is even younger, yet information is disappearing rapidly enough that you really have to wonder how much of what exists today will still be around – in any form – ten years from now. One of the key lessons DeLong takes from this article: it’s “critically important not just to link but to quote–and to quote extensively.”

The lesson is clear: The site you link to today may not be there tomorrow, and you may not have the time (or inclination) to go chasing it down. Quote it, summarize it, add context, write lots of commentary, whatever. Make sure what you post can stand on its own… just in case it has to.

Posted on
by

On an ideal Web, pages would stay put and links would never change. Of course, anyone who has been on the Internet long enough knows just how far away this ideal is. Commercial sites go out of business, personal sites move from school to school to ISP to ISP, news articles get moved into archives or deleted, and so on.

There are two sides to fighting link rot. The first is to design your own site with URLs that make sense, that you won’t find yourself changing a few months or years down the road. If you have to move something, use a redirect code so that people and spiders will automatically reach the new location.

The other side to the fight is periodically checking all the links on your site to make sure they still go where you expect.

So how do you handle online journals? Obviously they’re websites, so from that standpoint you should at least try to keep the links current. But on the blogging side, there are problems with this, in particular the school of thought that you should never revise a blog entry (also discussed in Weblog Ethics). Continue reading →