Archive for August, 2011

Motivation Hack: Make Annoying Tasks Fun!

Tuesday, August 30th, 2011

Motivation is a tricky thing. Sometimes it can cause us to complete wildly-improbable tasks, other times it can cause us to dread even the simplest of chores.

The software I’m creating at work has one such chore. Our application interacts with a complex, proprietary, and highly-secure server. One of the consequences of this pattern is that we have to deal with security tokens.

Tokens forsaken.

It works like this: Whenever someone logs into the app, the server issues them a security token. From that point on, all communication between the app and the server must use this token. Easy, right?

Tokens purged.

The chore is this: Due to some wonky bug that is beyond our control, the server can only issue a few dozen tokens, and they’re not renewed properly. We’ve never counted it out, but I’d estimate the server can grant tokens for a hundred or so logins before it runs out.

Tokens scrapped.

When this happens, and it happens every couple of hours, someone needs to manually access some web form and click around a few times to reset the tokens. This is a pain for two reasons.

Tokens obliterated.

First, it interrupts whoever is trying to run the app. Maybe it’s QA breaking my stuff, or our PM showing the app to somebody important, or a dev like myself just trying to validate his latest code change. Whoever is unlucky enough to see the login fail must run through all the token-resetting hoops, and then context-switch back into real-work mode.

Tokens repudiated.

Second, nullifying the tokens will kill any and all existing sessions on the server. So if QA got the last token and is in the middle of a test sequence, and I try to log in next, and fail, and reset the tokens, then QA’s session is suddenly invalid and they’ll start seeing errors left and right.

Tokens slain.

So to stop QA from logging a whole whack of bugs that would be impossible to reproduce, we came up with a system. Whoever resets the tokens lets the rest of the team know by sending a message to our project’s group-chat in Skype.

Just murdered the tokens.

See? Like that.

This was really annoying, especially since we had to do it many times per day. There was much complaining, and clamoring about getting a new version of the server that might solve our problem.

Then, something changed.

Tokens punched in the face and had their milk-money stolen.

We made a rule: Every time you clear the tokens, your message to the group must be unique. At first, we saw a lot of synonyms for “killed”. When we grew tired of running to a thesaurus every few hours, we started getting more creative with our phrasing:

Tokens are dead, and their heads have been mounted on pikes to warn future tokens to stay away.

Topical, even. We would hit movie quotes, the latest news, memes… Nothing was off-limits.

Tokens defeated by attacking their weak points for massive damage.

It became a game. Who could come up with the most creative token-killing message? Who could get the most laughs?

Tokens were eaten by a grue.

Our moods did a full 180 from a few weeks prior. Instead of feeling frustration when I see that login failed error, I now feel excitement. “I have just the thing!” I proclaim, and off I go to reset the tokens before anyone else notices and beats me to it.

Down came the rain and washed the tokens out. Then, I shot them.

We successfully turned a real headache into a fun experience. Morale went up. And a happy team is a productive team!

Tokens fed through a detokenizer.

I’m going to look for other places where joy can replace annoyance. Maybe you can do the same?

You maniacs! You blew them tokens up! Damn you! Damn you all to heeeeeell!

Is Firefox Past its Prime?

Wednesday, August 17th, 2011

A few weeks ago, in a post about why Google+ is going to succeed, I noted that Google Chrome has been on an upward trend of about .5–1% per month since it launched nearly two years ago.

While I didn’t mention it at the time, Firefox has an interesting usage graph as well. If you follow that link, you’ll see that Firefox’s curve hovered a little over 30% for the tail end of 2009 and the better part of 2010, but has started to drop over the past twelve months.

If these trends continue, Chrome will be more popular than Firefox by the end of next year.

What does this mean for everyone’s favourite open-source browser?

From Phoenix to Providence.

Back around 2003, the ‘net was desperate for something new. Sure there were other browsers around, but nobody could hold a candle to the market-dominating behemoth that was Internet Explorer (source). Innovation was non-existent, and the web as we knew it was suffocating.

Enter Mozilla. The release of Firefox 1.0 in 2004 was a breath of fresh air for the online community. Suddenly there was an open-source, standards-compliant competitor gaining momentum. We were thrust from the shackles of monopoly into an arms race that culminated in the second browser war.

Mozilla was a critical piece of the puzzle. It was a veritable flagship of new, exciting features. Better CSS support. A clean, tabbed interface. The prevalence and importance of add-ons could be its own post; countless extensions have become standard features across the board of popular browsers.

By the time Firefox 3 was released, in June 2008, Mozilla could do no wrong. Everything was on the up-and-up.

Then, the landscape changed.

Is Firefox still necessary?

With Microsoft innovating again (see IE9), Apple’s devices gaining popularity (and Safari with them), and Google bursting into the browser space with Chrome, competition was hot in 2009/2010.

Firefox still played a key role at this time: it was the yardstick against which all other browsers were held. Sure Safari and Chrome have built-in development tools, but are they as good as Firebug? How does WebKit’s HTML5 support compare to Gecko’s? And isn’t IE still laughably behind?

But this role has run its course. The major players are now well-established. Most users are aware of alternatives to their operating systems’ default browsers.

This can’t be a long-term position for Firefox. It won’t last.

The competition is no longer resting on its laurels. Chrome is closing in. Internet Explorer is finally in a position to reverse its eight-year downward trend, and WebKit is absolutely dominating this year’s explosive rise in mobile browsing.

Extensions are everywhere. Support for standards has never been better. Firefox is quietly becoming less and less relevant with each passing update.

So I ask again:

Does the golden age for Firefox lie in its past?

Your Three-Step Plan for Getting Out of a Slump

Wednesday, August 10th, 2011

My softball team won our first playoff game last night. It went to extra innings, and we just barely managed to eek out a win against a very strong team. Everyone was excited that we won, but I was a little more thankful than the rest of us…

You see, I’m in a slump.

My hitting has been sub-par the last few weeks. I’ve gone from hitting doubles every at-bat, to struggling just to make it to first base. Yesterday’s game was especially bad. When the team was rocking a two-out rally in the bottom of the seventh, I hit a soft ground ball back to the pitcher to end the inning — killing our momentum, and stranding runners on base.

I feel like I’m letting my team down. I know I’m not playing badly, but I can do better. I’m not my awesome, clutch-hitting self. And that hurts when it starts impacting our score.

Do you ever feel like you’re not as stellar as usual? Do you miss it too? It’s time we dig ourselves out of this. Here’s the plan:

Step 1: Stop psyching yourself out.

Your mental state in a slump is a toxic environment. You start counting your failures, and worrying about everything you might be doing wrong. You sweat the small stuff, and this throws you further off balance.

It’s one part vicious cycle, one part self-fulfilling prophecy.

We have to turn that thinking around. Let’s stop focusing on the negatives. Instead of beating ourselves up, let’s put on a happy face. Celebrate the little victories. Start building some momentum.

The first step towards getting out of a slump is to acknowledge that you’re under-performing, and to look for the positives anyway. Don’t let your nagging voice get in your way; fight back and show that voice who’s boss!

Step 2: Get back on track by tweaking your workflow.

When you’re in a slump, you’re there because something went wrong. Maybe your environment changed, maybe you got a little over-confident, maybe you were trying something wonky with your swing (guilty).

Whatever happened, it’s probably not possible to undo at this point. So it’s time to move on.

Remember that we’re not alone in this. Let’s ask for advice, and genuinely listen to what we get back. It can be a humbling experience, and it will give us a few new tricks to try out.

The second step towards getting out of a slump is to experiment. To gain some insight, and implement any necessary changes. Slowly, little-by-little, you’ll start moving in the right direction — back to your killer former self.

Step 3: Back and better than ever.

I know it probably seems like this is far away right now. It’s not. Despite what your mind might be telling you, you’re closer to your goal-crushing, homerun-hitting prior self than you think.

And you know what will get you that last bit of the way there? Hard work.

We’ve got to keep our heads down, and power through this slump. Sure, we’re not as productive as usual, but that’s the nature of the game; nobody’s a hero on every single play.

The third and final step towards getting out a of a slump is to just keep at it. Don’t let ordinary output slow you down. Instead, generate as much of it as you can! You won’t even notice when the switch happens. One moment you’re mediocre, then all of a sudden you’re kicking ass again — and we can forget this whole slump thing ever happened.

Falling into a slump is totally normal, and an expected part of any long-term endeavour. It’s not the end of the world. The way to beat a slump is to stop making it worse, start making it better, and keep at it until you’re back to your usual, entirely awesome self.

P.S. This applies as well to web development as it does to softball.

Good and Bad Examples of Localization

Monday, August 1st, 2011

I bought some opera tickets online the other day. For an opera in Vienna.

The website that took care of the booking was in German by default, but provided an English option. Being a web developer that specializes in building user interfaces, this intrigued me.

You see, I’ve spent a fair amount of time worrying about localization; the art (and science!) of ensuring an interface is accessible in multiple languages. It’s a tricky problem. There are a lot of pitfalls for the naive coder.

What I’ve spent much less time doing is actually using localized websites.

So as I worked my way through the booking process, I took note of what the Wiener Staatsoper did to make sure their user experience didn’t suffer when translated from German to English. Here are the results:

Good: The Layout didn’t Break.

English-German is an especially interesting translation because German words tend to be so much more… verbose than their English counterparts.

This can provide a lot of headaches for developers and designers. Yes, “speed limit” fits very nicely within the confines of that pretty tab in the stylish, narrow header. You know what won’t fit so well?

Geschwindigkeitsbegrenzung.

In web design, if you’re not careful with your overflow, or you’re sloppy with your floats, or you just plain didn’t think to test real, translated strings when working on an international product, you’re in a lot of trouble.

I’m glad to report that despite my paying very, very close attention, the Staatsoper website didn’t have any awkward gaps or fields/labels that were needlessly long. This may sound obvious, but it’s a very important first step in creating a well-localized product.

Bad: Non-translated strings.

I was surprised this was such a problem. Especially since English and German are the only languages the site supports, it seems like it would be perfectly reasonable to keep both string tables up-to-date.

Alas, I found many instances of German text on English pages. Yes, some were show names and proper nouns, but just as many were not.

This feels unprofessional. As a user, I’m not expecting to see a whole lot of German after I select English. Every instance is a fault, and may cause confusion.

Good: Matching tone.

A website for something like an opera should stray on the side of elegance and formality. While I can’t vouch for the quality of the German copy, I can say that this message came through on the English side.

One specific example:

I originally attempted to complete the entire checkout in German. As I was filling in personal information, I noticed the standard * definition at the bottom of the page, letting me know that marked fields are mandatory. The description was about 6 words long!

“In English, we just say required”, I mumbled to myself.

Lo and behold, when I arrived at the same page in my native tongue, it didn’t say “required” at all. It said “These fields need to be filled in.”

A little wordy, sure, but that’s the point. This is an opera house. They aren’t targeting their copy at superusers who instantly know that * == mandatory. A fuller definition was entirely more appropriate, and the presumably-matching tone was both appreciated, and likely intentional.

Bad: Typos.

I can’t believe I even need to mention this, but: Get your strings proofread!

I spotted a handful of typos and very basic spelling/grammatical errors towards the end of the checkout process. This is just plain painful. If you’re going to go to all the trouble of adding support for a new language, go all the way and get your strings double-checked!

Typos and poor spelling/grammar look lazy and unprofessional. This is a really easy problem to avoid, and your users will thank you for it.

Good: Automatically adjusted region labels.

This was by and large the most impressive part of the Staatsoper’s localization effort. If you take only one piece of advice from this article, let it be this one.

I noticed something interesting while filling out address information. Without me taking any action whatsoever, the labels were already Canada-friendly.

Province instead of State. Postal Code instead of ZIP. Proper long-distance region already filled in. Canada at the top of the country drop-down, preselected.

I was blown away.

Granted, your average user isn’t a web developer, and won’t consider how much extra effort you put in to craft that exact experience specifically for your users, but this is something to strive for! Helping your users breeze through a form is no small feat, and playing localization to your advantage is a stellar way to improve their experience.

Overall, the Wiener Staatsoper did a more than decent job translating their user interface from German to English. The use of localized labels, matching tone, and proper layout techniques were very considerate and helped me considerably. The minor annoyances of missed and improperly-translated strings could easily be fixed, and would help make the translation an even better case study.

Now, was any of this helpful? What can you take away for your own projects?