Aaron Whitman

How to confuse and annoy website users

Aaron Whitman — Sat, 28 Jan 2012 16:16:54 +0000

From Saturday, January 28th, 2012 on http://cbc.ca

The web developers at CBC want to save me from an “older version of Internet Explorer”. That’s nice and all, but I’m on a Mac, using Firefox 10. Part of me blames Daniel Alfredsson, this is the kind of stunt he would pull.

From Thursday, January 26th, 2012 on http://williams-sonoma.com via http://evite.com

I clicked on a full page ad at the end of the signup and profile setup process on Evite.com. What can I say, I liked the ad and wanted to learn more about a blender… but I digress.

Evite knows I’m in Canada, since I just filled out and saved a profile. Of course there are also other ways to know this, especially for ad targeting.

First thing I notice on the Williams Sonoma site is the “shipping to” link with a USA flag – so I decide to re-scope my session with Canada as the shipping destination by clicking on the flag. Turns out Canada is not in the 75 countries that Williams Sonoma wants to sell online and ship to.

I would have thought having the world’s 35^th largest population would get us into the 75 ship-to locations — certainly ahead of Paraguay — which I’m told is a lovely country – ranked 105th in terms of population.

hCard parser H2VX not ready for HTML5 yet

Aaron Whitman — Sat, 14 Jan 2012 20:59:13 +0000

Updated January 16, 2012

New frontiers come with unexpected challenges. I like using the hCard microformat in websites to make it easy for people to add contact information to their address books. I also like building websites in HTML5 for the semantics and am confident it is the way forward. Tools like Modernizr make browser support less of an issue with the new tags.

What’s an hCard without a parser?

The hCard format is great for publishing contact info in HTML, but to turn it into a vCard that can be downloaded and added to your address book, something has to do the conversion for you. A “production deployment of the X2V hCard” is located here allowing one-click downloads of hCards in any web page.

This is a real gift — saving us from keeping vCard files up to date on our own servers, and/or writing our own hCard to vCard conversion tools. It was created by the hCard microformat authors Tantek Çelik and Brian Suda which perhaps has added to it’s popular usage.

What’s not ready with this parser?

Regarding ~~hCard microformats~~ H2VX and HTML5, here’s the rub: it does not support the new HTML5 tags, and will not find them in your webpage if your hCard root element is an HTML5 tag.

I noticed an issue when updating some websites to use

tags instead of

tags for the root element of an hCard. (NOTE: the root element of an hCard has class=”vcard”).

HTML5 for your .vcard root element will not work


    Aaron Whitman

HTML for the .vcard root element works as expected


    Aaron Whitman

So, when updating websites with hCards to use HTML5 tags, make sure to consider this issue. Thankfully, there is a dev version of H2VX that does support HTML5 tags. The fact that this is a “dev” version implies it is not to be relied upon, but it is encouraging to see that HTML5 support is in the works.

Now to check every website I’ve built in recent memory for the hCard broken by HTML5 situation.

QR Codes should delight you

Aaron Whitman — Wed, 26 Oct 2011 19:38:45 +0000

I love using QR Codes for what I believe their intended purpose is — to transfer a short string of data to somebody’s smart phone. Specifically, a URL for a responsively designed web site. Single-purpose mobile optimized web pages are ok in some circumstances too, but that’s a topic for another post.

There is no more efficient way to get a person to open a specific web page on their smart phone from the physical world. In fact, nothing else comes close. Not augmented reality. Not Google Goggles Search. Nothing can touch QR Codes for sending a person to a specific web page on their smart phone from outside their smart phone.

Considerations for arguments against QR Codes

There is a noticeable anti QR Code sentiment among designers, developers, marketers, and famous technology critics. Here are some positions I disagree with.

QR Codes are are ugly on products/packaging

Bar codes are ugly too. So are disclaimers, surgeon general warnings, and many brand identities for that matter. If a QR Code is taking over a design then it’s a design failure. It does not take away from the purpose of the QR code.

I don’t know where the QR Code is going to take me

You don’t know where a URL is going to take you either. You have clicked on hyperlinks that say “click here” a million times since 1996. If anything, you should expect that the marketer or product manager who slapped that QR Code on the package has put together something special for you on a web page that will work well on your smart phone. If a QR Code burns you, feel free to call out whoever produced it on your social media platform of choice.

I just use URL-shorteners

Great for Twitter, but you would still have to type the URL into a smart phone browser address bar. Also, they require a pass-through the URL-shortening server, and you can’t tell the final address until you arrive (same as a QR Code).

By the time I get my QR Code scanning app open, the bus drives off

I could not agree more with this. QR Codes on anything that you can’t hold in your hand, require conditions to be perfect for you to scan them. When was the last time conditions were perfect for anything? Exactly. However, product packaging, print, even signage; they all let you control conditions until the scanner app is ready to scan. I admit to cringing every time I see a QR Code on the side of a bus.

More on QR Codes you can hold

This is the use case where QR Codes shine. You have a person with a smart phone, holding an object they want to know more about. The producer of that object has prepared a web page (or entire website) that works properly on a smart phone. By “properly”, I mean a responsively designed website that provides the best experience on any device — after all the person who scans the QR Code might want to Tweet, email, bookmark, or share the page in some other way. The person with the smart phone scans the QR Code and gets the exact web page they need within the context of the object they are holding in their hand. There was no hassle due to typing, moving QR Codes, a crowd of people to navigate, etc. Just the shortest path from wanting to know more about an object to getting that information.

QR Codes don’t suck, bad implementations do

I’m going to wrap with the idea that, there’s probably a few dozen ways to use QR Codes to make people really glad you did, and about a million ways to make them wish you hadn’t bothered. People in charge of delighting customers run the risk of messing up the implementation of any technology. Don’t blame the technology itself. Nobody said slapping QR Codes on everything was a good idea. I say slapping them on the right objects for the right reasons is a brilliant idea.

Google+ is elegant, but too much hassle

Aaron Whitman — Tue, 09 Aug 2011 12:42:27 +0000

I think Google+ has nailed a lot of useful features, and has a great web interface. No question in my mind that if it launched before Twitter, I would think it is the best way for me to share with others online.

But it did not launch before Twitter, and now I have a list of Twitter-ers that I rather enjoy following and sharing with. I don’t want to pick and choose what I post to Twitter and what I post to Google+. I need to post to both automatically.

Waiting for a desktop/mobile client

I understand and appreciate the spirit of hacking functionality into new services, and applaud the work of folks like Rob McGee. This pushes feature sets forward, and hopefully there is some future reward for their hard work if they’ve really hit the mark. I just happen to have a few hang-ups about giving access to my data to people and/or companies that I don’t think need it.

I use the Twitter client for Mac/iPhone to share on Twitter. This is what I am going to keep doing until there is a similar option for Google+. I suppose this means an API for Google+ first, since the Chrome browser is Google’s obvious choice for desktop users of “Plus”.

It would feel better to me if the Twitter for Mac client added a post to Google+ feature. Or if there was a some other Google+ client that posted to Twitter. In any case, I would want to be sure that my credentials for both Twitter and Google+ stayed on my computer and not in somebody else’s database with dubious security standards.

Cool? Yes. Hassle? Yes.

To recap: I dig Google+ but can’t do without Twitter. Now I’ve spent way too much time trying to find somebody else’s solution for making the two into a peanut butter cup. I’m out — or at least on hold — for now. Call me when there is less hassle, and I’ll start using Google+ again.

Please prove me wrong

I would like nothing more than for you to comment with the perfect solution that I have given up looking for.

When CSS is !important

Aaron Whitman — Fri, 29 Jul 2011 15:04:34 +0000

If you are reading this, you know the gist of “!important” is to counter-act the normal application of CSS rules based on selector specificity. One way to look at this is that it’s a shortcut to make up for another rule’s selector that is too broad. Another way would be to describe it as getting things done and moving on. We can argue both ways depending on how much time/budget you have — but more importantly — how many places a given CSS file will be used.

Important situation #1 – it’s just me

Let’s say you have a nicely crafted blog interface, with modern HTML, CSS, and non-obtrusive JavaScript — maybe even a responsive design. For a special post you might want to override a CSS rule to achieve some worthwhile effect once in a while. In this case “!important” might be the fastest way to override the default rule, and it is a one-time use with limited or no tentacles.

Here are a couple examples that I’m not proud of, but are honestly in style sheets I’ve written:

#subnav li { list-style-image: none!important; }
#search_form button { margin-top: 0em!important; }

Why are these instances of “!important” there? I control the entire project after all. Looks like I chose the “get it done and move on” option, I really can’t remember. There are probably a few elegant ways to remove “!important” and get the same effect from the CSS rules in my interface. Fortunately, it’s just me. For now. What if others start to work on these projects with me someday? This could grow tentacles fast.

Important situation #2 – I’m delivering to (or sharing with) others

Imagine you are authoring a plugin for an open source project and included a CSS rule like this:

#content .button { background: #e5e5e5; color: #444!important; }

That snippet of CSS makes me think the author was thinking one or more of the following:

Somewhere in my plugin the .button class is different than inside #content
Under normal use only my plugin will have markup with an element id=”content”
Nobody should change my gray buttons, gray buttons are important

Here’s my reaction each:

So what, if you are writing the HTML and CSS there is always another way to get a more specific selector without using “!important”
This hardly seems reasonable, now if somebody wants to override your rule they have to include “#content” in their selector
Really? Some designs may not work with gray buttons

The cascade of “!important”

I’m not directly talking about the cascade — rather — the ripples of “!important” that run through a project when you have to undo another CSS rule that is “!important”. This can happen with plugins when the author opts for the “get it done and move on” path in their CSS.

In order to undo the gray button rule, we need something like this:

Gray buttons from plugin-styles.css

#content .button { background: #e5e5e5; color: #444!important; }

Now make blue buttons with my-styles.css

/* Won't cut it
.button { background: #21759B; color: #fff } */

/* Still won't cut it
#content .button { background: #21759B; color: #fff } */

/* Here we go! */
#content .button { background: #21759B; color: #fff!important; }

Imagine an update for one special form with red buttons

#content .redForm .button { background: red; color: #fff!important; }

The user experience of your interface is one thing, but we should probably also consider the user-experience of other developers that install the plugin in their projects.

But this CSS rule is important

Fair enough, it’s just a matter of where and when. Let’s not create work for others when we don’t have too. That is how the world ended up with “Paste from Word” buttons that remove bloated markup and inline styles. There is almost always another way to apply your CSS rule rather than resorting to “!important”. This is especially true if you are authoring the HTML and CSS.

Find, review, and justify your “!important”s

$ grep '!important' style.css | wc -l
   4

Looks like I have four things to make sure of before I commit styles.css no? Maybe a nice commit message would include the rationale for leaving them in.

Ironically, it’s not that important

The implementation of “!important” in CSS always looks a bit odd to me, since “!” is the not operator in many programming languages. The irony that CSS gives more weight to things that are “not important” always gives me a grin.

A CSS rule that comes with “!important” on the tail is almost never important for all uses.

Having said all that, what do you say?

Please leave a comment with any good/bad/ugly uses of “!important” that you’ve been involved with.

Green in Regulation – plugged

Aaron Whitman — Fri, 22 Jul 2011 17:29:28 +0000

Via Flickr: On an approach from the rough, stuck the green and plugged. The photo does not do it justice, the ball was plugged pretty deep.

WordPress 3.2.1 — body class changes

Aaron Whitman — Fri, 15 Jul 2011 14:32:03 +0000

WordPress developers take note — somewhere between version 3.1.3 and version 3.2.1 there is a change related to custom themes and body classes that might break your CSS in some certain scenarios.

If you have custom templates with underscores in their names, updating to WordPress 3.2.1 can break your CSS. For example a template file called “template-my_custom_template.php” used to produce body class names *without* underscores prior to verison 3.2.1

As of version 3.2.1 that body class is now generated with the underscores in place:

This is actually the way it should have always been, but can cause havoc if you’ve got any CSS rules that use the old model.

Subversion Tree Conflict: local delete, incoming edit upon update

Aaron Whitman — Fri, 13 May 2011 11:08:32 +0000

Forgotten lesson: always run a SVN status check before commits/renames/deletes, or you risk wasting time and wishing you had.

Had a stunned look on my face for a while after trying to rename a folder in a subversion repository:

$ svn mv [old_folder] [new_folder]
[output marking old_folder as deleted and new_folder as added]

$ svn ci [old_folder] [new_folder]
Deleting        [old_folder]
svn: Commit failed (details follow):
svn: Directory ' [old_folder]' is out of date
svn: Your commit message was left in a temporary file:
svn:    'svn-commit.tmp'

$ svn up [old_folder]
   C [old_folder]
At revision ###.
Summary of conflicts:
  Tree conflicts: 1

$ svn status
?       [new_folder]
!       C [old_folder]
        >   local delete, incoming edit upon update

PBKAC

My brain cramp was induced by the terse error message: “local delete, incoming edit upon update”. The problem was, of course, between the keyboard and chair. I had not committed/updated [old_folder] before trying to rename it. The moral of the story is always run a status check first, so you don’t assume readiness for commits/renames/deletes/etc:

$svn status

Googling the answer (a.k.a the internet makes us soft)

The Googling that helped me to understand “local delete, incoming edit upon update” lead to this nice summary.

Cleaning up the mess I made

$ svn revert [old_folder]
Reverted '[old_folder]'

$ svn status
?       [new_folder]

$ svn add [new_folder]
[output marking new_folder as added]

$svn ci [new_folder]
[output for successful commit]

$ svn status
[no output - this is good]

Lesson re-learned

Phew, there’s a detour I hope to never take again, turned a 10-second task into about 30-minutes of head-scratching.

Coffee at Mos Eisley Cantina

Aaron Whitman — Thu, 12 May 2011 17:17:22 +0000

In this version of events, Obi-wan dispatches Shaq after a fair trade espresso.

Pitfalls of styling the HTML element

Aaron Whitman — Wed, 13 Apr 2011 18:15:16 +0000

This was ~~fun~~ painful.

On the new ablesense.com website design, I had foolishly applied some styles to the element — specifically my font stack for the website. The particular selection of fonts was very important in making this mistake obscure:

html { font-family: helvetica, arial, sans-serif; }

Browsers have default fonts

The fonts all looked fine in Firefox, Safari, Chrome, and Internet Explorer (Helvetica on Mac, and Arial on PC). This lines up with the CSS rule above, so it seemed like everything was fine — but it was not.

Opera has a purpose after all

To satisfy some sense of thoroughness, I took a look at the website on Opera. Kaboom! All the text was displayed with “Lucida Grande” — which appeared nowhere in the website CSS! However, the developer tools revealed that “Lucida Grande” was in fact being applied quite on purpose. As it turns out, “Lucida Grande” is the default font for Opera, at least on Macs.

Faulty rationale

If putting CSS rules on the tag is convenient for the cascade, then putting them on the element must be — well — even more convenient! Right? Wrong.

Getting smart, after out-smarting myself

body { font-family: helvetica, arial, sans-serif; }

Let’s move on, and quickly

So to wrap up, don’t style the element in CSS. You probably already knew this, but now you have another example of why it’s a bad idea.