Tag: design

Posted on
by

I just read an interesting post from Microsoft’s Internet Explorer team on The IE7 User-Agent String. This statement in particular illustrates a problem not unfamiliar to Opera users:

There are a few remaining sites which fail to recognize IE7 because they are performing exact string matches to look for specific IE version strings. Those checks will need to be removed or updated to accommodate IE7.

Yes, you read that correctly: there are websites out there using bad browser sniffing code which will send the wrong code to Internet Explorer 7. In fact, they go on to say that they’ve released a tool which will let IE7 pretend to be IE6!

To enable you to workaround any remaining sites that block access to Internet Explorer 7, we developed the User Agent String Utility. The utility comes in the form of a small executable that opens an IE7 instance that sends the IE6 user agent string. It also provides a mechanism for you to report problem web sites to Microsoft so that we can follow up with the affected site owners.

I’ll admit to a certain amount of schadenfreude, but it also points up just how bad a strategy browser sniffing can be when done thoughtlessly: It effectively builds an expiration date into your website after which even the browser you designed it for will run into problems.

*This post originally appeared on Confessions of a Web Developer, my blog at the My Opera community.

Posted on
by

Posting an Opera button on your website or blog is a great way to encourage people to try out the browser — but what if the visitor already uses Opera? It shows solidarity, but what if you could show them something else, something that is new to them?

You might want to replace your regular Opera banner with an ad for Opera Mini. Or show them another graphic of your own design. Or maybe not even a graphic, maybe post some sort of message, like “Opera spoken here!” or “Welcome, Opera visitors!”

It’s relatively simple to do this in PHP, or ASP, or some other server-side script…but sometimes you have to stick with static HTML. Well, client-side JavaScript can replace chunks of your page, and here’s how to do it.

1. Put the following script in a file called operalinks.js:

function replaceOperaLink(linkID) {

if(linkNode=document.getElementById(linkID)) {

if ( 0 <= navigator.userAgent.indexOf('Opera') ) {

var newButton=document.createElement('span');

newButton.innerHTML = '<a href="http://www.opera.com/">Glad to see you're using Opera!</a>';

var parentNode=linkNode.parentNode;

parentNode.replaceChild(newButton,linkNode);

}

}

}

For the innerHTML section, you can plug in a new link and banner, or a special message, or anything you want. (Just make sure that you put a backslash () in front of any apostrophes you use.)

2. Put a unique ID in the tag for your regular Opera button. Use the outermost tag that you want to replace. For example, let’s start it off with this:

<a id="OpLink" href="http://www.opera.com">Download Opera!</a>

3. Load the script in your document’s <head> section:

<script type="text/javascript" src="operalinks.js">

4. Call the function in the body onload event using the ID you chose in step 2:

<body onload="replaceOperaLink('OpLink')">

When the page loads, the script will check the visitor’s browser. If it’s Opera, it’ll replace the banner with whatever message you chose in step 1. It’s compatible with both HTML and XHTML, and you don’t need to worry about using <noscript> tags to make sure the banner still shows up for people with JavaScript disabled.

*This post originally appeared on Confessions of a Web Developer, my blog at the My Opera community.

Posted on
by

Microsoft’s automatic update system is now offering an update to the Windows Installer. That’s the program that handles all those .msi files you use to install new applications, keeps track of what’s currently installed, and lets you uninstall them.

And it needs to reboot after installing?

WHY? What low-level system file did they have to change? There is a Windows Installer service, but it’s not running, and even if it were, they should just be able to restart the service. Why do I have to reboot the entire #@!$ computer because I agreed to install an update to something that isn’t running? Is the design so broken it can’t update itself?

I’ve never had to reboot a Linux box after upgrading RPM, Yum, or Apt (the equivalent software on many Linux systems). Never, in the seven years I’ve been using Linux.

And you know, it would have been nice to know that this update would require a restart before I decided, “what the heck, it doesn’t look like anything that’ll require me to restart, I might as well grab it now.” Telling me that some updates may require a restart is like labeling a box of cookies “Processed in the same state as a peanut farm.” It’s useless. It gets ignored. Kind of like this rant probably will.

Update 1: I’d love to make this change to the dialog box:

No, it’s not F*ing OK but you’re going to make me restart anyway!
Mouldypunk (link dead)

Update 2 (years later): “OK I guess” would have at least been amusing. And thank you sooooo much, Gnome Software, for bringing this behavior to Linux. There’s a reason I still use the command line to install updates.

Posted on
by

I’ll always remember a line from a play I was in during college. It was an original musical, and the composer couldn’t come up with a good line by the time he had to hand out the scripts, so he filled it in with “Come around and schmoo” just to keep the rhyme in place. Oddly, I can’t remember the line he finally replaced it with.

And of course, Firefox’s cookie preferences were labeled “Cookies are delicious delicacies” for so long during the beta period that by the time they wrote a real description for 1.0, someone wrote an extension to put it back in!

Well, sometimes dummy text makes it through “rehearsals,” so to speak. Jim Heid found live sites with various kinds of filler text. Not just the ubiquitous “Untitled document” (millions of pages), but samples of “lorem ipsum” filler and even ~250 hits for “this is placeholder text” (whoops, I’m gonna skew those results a bit.)

(via Scobleizer, who recommends using “xxxxx” exclusively for placeholders.)

Posted on
by

Here’s a pair of excellent articles about how to avoid cluttering up your website so that people can actually see your content. The article is, however, hampered by appearing on a site that seems to violate every usability principle imaginable…. to the extent that the second one showed up on the Cruel Site of the Day. From the introduction:

We’ve all visited websites that made us wince. You know what I mean: full of distracting animation, flashing text, and enough other clutter that it reminds you of a Victorian home filled to bursting with knick knacks. Are you guilty of filling your website with useless junk? Christian Heilmann takes you down his checklist of website clutter. You just might find yourself considering a redesign.

Yeah, that sounds like a description of Dev Articles to me. I count no fewer than 8 ads on the first page, 6 of them animated. The text is buried in a morass of advertisements and navigation that make it extremely difficult to actually read the article.

It reminds me of a book called Fumblerules, which collected (or possibly originated) guidelines like “Always proofread carefully to make sure you don’t any words out,” or “Plan ahead” with the last few letters scrunched together to fit on the page. These were designed to make their points by deliberately breaking the rules to make them more memorable.

Well, there’s always the Daily Sucker.

Update: I checked out the author’s website, which demonstrates he has the sense of taste and aesthetics one would expect from his articles. It really is too bad DevArticles isn’t willing to take his advice.

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 →

ยปAll pages site-wide with this tag