Jimmy Breck-McKye

A lazy programmer

Disabling Firefox Safe Mode

A couple of weeks ago I faced a problem where Firefox’s “Enter Safe Mode” dialog was causing problems for a Selenium test suite I was trying to run.

Basically, Firefox would sometimes throw the dialog and my test framework (naturally) wouldn’t be able to dismiss it without my help. This meant the Firefox instance stayed open, so if I tried running the suite again, I’d get an exception:

1
org.openqa.selenium.WebDriverException: Unable to bind to locking port 7054 within 45000 ms

Annoying. To me, it seemed the simplest solution was to merely disable Safe Mode entirely, as I would never need it during a test. Rummaging around in Stack Overflow and the Mozilla bugtracker, I found this ticket that proposed I could either:

  • set an environment variable, MOZ_DISABLE_SAFE_MODE, or
  • pass a config setting, maxResumedCrashes = -1 to about:flags or a user profile

According to the webdriver documentation, you can set a custom user profile flag fairly easily with profile.setPreferences("key","value")

Disabling Safe Mode was simple:

1
profile.setPreferences("toolkit.startup.max_resumed_crashes", "-1");

If you’ve got the same problem, you might want to give it a try.

Introducing Web Accessibility

A couple of weeks ago I gave a presentation, “Introducing web accessibility”, and I thought it might be worth sharing with the wider world. It provides a broad overview for developers who’ve never encountered accessibility before.

Some key points covered:

  • Visually impaired users use ‘normal’ browsers with CSS and JavaScript usually enabled. Don’t rely on your non-JS/CSS fallbacks for accessibility.
  • Assistive technology sits on top of browsers; it doesn’t replace them. So you cannot track / UA sniff users who need concessions.
  • How semantics encoded in your document actually reach the screen reader, and the points of failure in this journey
  • How screen reader users typically traverse a document
  • Common problems and their solutions
  • How to actually validate accessibility, and the importance of testing

You can get a hold of it here.

Styling Form Elements

Form elements are notoriously difficult to style. Even apparently simple tasks like horizontally aligning different types of input can prove a headache for experienced developers. Only by understanding how form elements are laid out can we master them.

Hello, Octopress!

So I’ve ditched the old blog and started anew.

There were a few reasons for this: firstly, I wasn’t terribly happy with my ‘new’ WordPress theme. It wasn’t totally terrible, but it still had rough edges design-wise, still wasn’t great for posting code, and still needed a lot more work to make it play nicely on mobile. These were all things I could fix, but why should I? I want to spend my time writing about stuff, not fixing my blog engine. That is why I’m blogging, after all.

Secondly, I didn’t really like working with WordPress that much. I can see how super-convenient it would be for a traditional blog, but my needs were quite different, and I felt myself having to work against WP’s architecture rather than with it. Maybe I could have spent more time reading up on PHP and WordPress development in particular, but they just aren’t technologies that I’m really prioritizing learning about right now. Never say never, though.

Thirdly, and most importantly, I really like Octopress. The simplicity of a static site; the quality of the default templates; the breeziness of markdown, liquid and Yaml; and the natural integration of programmer-specific features (the Solarized code highlighting); it all sold it for me. Plus, if I ever do want to tinker with my blog engine, I’d probably rather learn Ruby than PHP.

Of course, now I’ve sorted out the blog, I don’t have any excuses for not posting. So I’d better get cracking, hadn’t I?

Time for a Change

The story of my time as a User Experience designer, and why I turned my back on design in favour of development.

I’m No Longer a UX Designer

After twelve months of radio silence I’m resuming the blog under a new design – and, more importantly, a new focus on development rather than UX.

As 2012 dragged on, I found it harder and harder to channel my passion for UX. The work and the world I once loved became a chore to interact with, and my content dried up as a result. The last year has been quite tumultuous, but the upshot is that after a lot of soul-searching I’m now doing exclusively what I always really loved – software development. It’s quite an unusual move, but I’ve never been so convinced that I’ve made the right one.

I’ll be writing some posts on my reasons for this and how I made the transition in the future, but in the meanwhile, anyone who’s come here for UX stuff should check out the UX archives.

Human Vision for UI Designers

This is a historic post rescued from my old UX blog

With rare exception, the interfaces we design rely on graphical output. They use text, colour, layout and motion to communicate messages and respond to user activity. Working with a primarily visual medium, then, it’s vital that we understand the capacities and limitations of human vision.

Character Count Design: Some Guidelines

This post was rescued from my old UX blog

Character limits are ubiquitous on the web, not least in applications that rely on user-generated content. Yet for something so common, character limits are often poorly implemented. Thankfully, by following six simple guidelines about designing length-limited fields and displaying character counters, you can make writing character-restricted text and smooth and painless as possible.

Designing In-context Editors

This is a post rescued from my old UX blog

In-context (or ‘in-place’) editors allow users to edit content in the same page or space that they view it, rather than using a separate form or administration area. They establish a strong relationship between content and the tools used to manage it, which makes those tools extremely discoverable, and gives users confidence about the consequences of their activity. However, in-place editors can also pose certain design challenges. I take a look at these issues and offer some ideas on how to ameliorate them.

The Problem With Video Help

This post was rescued from my old UX blog

Video guides have become enormously popular as a help strategy. They’re attractive to new users, they’re easy to create with today’s tools and they impart a real ‘wow’ factor. But like all tools, video help has its limitations, and needs to be employed carefully – because advanced and long-term users find them tremendously frustrating.