UX Design Day, Dunedin 2014

Posted on by Blair McBride

Things I’ve been saying for a long time: I need to blog more. I haven’t been very good at achieving that.

So, recently I was at UX Design Day – a one-day conference focused on UX and design. It’s the only conference of it’s kind in NZ, and it started here in Dunedin. Working remotely and not really part of the design community, I don’t often get a chance to sit down and talk UX/design in-person with people. This year the conference was back in Dunedin, so I jumped at the chance to attend.

spacer I was impressed by the diverse turnout this year. Interaction design, visual design, content strategy, marketing, education, user research, and software development were all represented. I had tried to drum up support from the local developer community to attend, and that seemed to have worked well. Too often do I see developers ignoring UX/design issues – either being very dismissive, or claiming it’s another person’s job; so this felt like a good sign.

Alone those lines, one of the things that stuck with me was the talk around not having UX teams separate from everything else. The largest example talked about was UX and content strategy, but I think it applies equally to software development teams too. Having these two groups work closely together, not segregated, helps bring so much context to both teams.

The other important take-away for me was the importance of not accepting crap. That is, experiences or systems that are, intentionally or not, lacking in design forethought and therefore lead to an unnecessarily difficult experiences, or a design that by default leads to harm. The primary concrete example here was physical safety in various workplaces, where people were put at needless risk due to the lack of safety by default design. I think this is a very relevant point for those of us building software, given that we so often experience design in software that feels broken, but too often don’t do anything constructive to help fix it.

spacer

Obligatory wall of Post-It notes

On the whole, I enjoyed the conference. However, since the talks covered such a wide corpus, I feel it didn’t provide enough time for any one area. Diversity is an asset, but I would have liked time for more in-depth explorations of topics.

Posted in Design, Mozilla

Bugzilla links in SourceTree

Posted on by Blair McBride

For those of you that use SourceTree for Mozilla development, here’s how you can set it up so bug numbers in comment messages become links to Bugzilla.

  1. Open your clone of mozilla-central
  2. Open repository settings (main menu → RepositoryRepository Settings)
  3. Select the Advanced tab
  4. Under Commit text links, click Add
  5. Set Replacement type to Other
  6. Set Regex pattern to:
    1
    (Bug |bug |b=)([0-9]{5,7})
  7. The next field currently differs depending on whether you’re on Windows or OS X.
    1. If you’re on windows, set Link to URL to:
      1
      https://bugzilla.mozilla.org/show_bug.cgi?id=$2

      Your setting should end up looking like this:
      spacer
    2. If you’re on OS X, set Replace to:
      1
      <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=$2">Bug $2</a>

      Your setting should end up looking like this:
      spacer

Now bug numbers in commit messages will be linkified like this:
spacer

You’ll need to do this for each repository clone you want Bugzilla links for.

Posted in Mozilla | Tagged sourcetree, tools, vcs

I Ain’t Dead

Posted on by Blair McBride

You may have noticed that lately I’ve been somewhat absent from, uh, everything. Dead to the world for most of December, and just brief ghostly appearances so far in 2013. I’ve posted a couple of times on Twitter about why, but I wanted to write something a bit more substantial about it all, now that I’m able to do so. Thus begins my tale of woe and boredom…

Once upon a time (1st December 2012), in a land far far away (New Zealand), there lived a great bearded wizard (that’s me), tormented by an evil troll.

spacer

Ok, so that’s not a troll — it’s our old garden shed. Although I do consider it to be slightly evil now.

Notice the grape vine creeping up the trellis; I was attaching the trellis to the wall of the shed one bright Saturday afternoon. I bent down to pick something up, stood up and turned around, and in a fit of bloody revenge the shed viciously attacked me. Or I may have just hit my head on the corner of the shed — I don’t specifically remember that part. I vaguely remember feeling well enough afterwards to finish the job and clean up; though afterwards I did need to retire inside for a rest on the couch, then have an early night.

Sunday morning was quite the opposite of “feeling well enough”. “Awful” is a much more accurate description. I’m usually very resistant to see any doctor, but I got there as soon as I could on Monday. The medical field seems to involve a lot of inexact science (or as I like to call it, “guessing”), and my doctor’s best guess was a pinched nerve in my neck and a concussion. I knew very little about concussions, but my doctor warned me to stay away from computer screens and books.

Now, I’ll admit to a fair amount of ignorance here, as at this stage I expected to have an easy (if somewhat boring) time and be back at work after a week. Obviously, that didn’t exactly go to plan.

In fact, I was so wrong that on Tuesday Anne and I planned to take a trip out of town (Anne driving, of course) so I wouldn’t be completely bored out of my mind. We got as far as the emergency department of the hospital. Nothing serious, but I did learn that even sitting as a passenger in a moving car was enough to bring on some very worrying symptoms. Confusion, disorientation, difficulty focusing attention, blurry vision, double vision, atrocious headache, nausea, etc. All of which turned out to be normal, for a concussion — but nevertheless scary to experience.

I think most people don’t have much of an understanding as to how a concussion (or any brain injury) can affect a person. I certainly didn’t. This lack of understanding, and the types of symptoms and limitations, can be very isolating. As it turns out, being a programmer involves doing everything that you’re not allowed to do when you have a concussion:

  • In front of a screen
  • Reading
  • Concentrating
  • Thinking

Yea, really — I was pretty much banned from thinking. And for good reason — thinking made my head feel awful. Interestingly, I was also banned from doing much physical exercise. I found I was very easily physically exhausted, as well as mentally exhausted. Conversations with people overloaded my brain very easily, and I couldn’t cope at all with listening to groups of people. Both the mental and physical symptoms are caused by what’s called neurogenic fatigue — which apparently is remarkably similar to sleep deprivation. And so the trouble with a concussion is that you can’t push yourself to recover faster — it just ends up making things worse.

So I was stuck for most of December trying my best to do as little as possible. I plan on writing a separate blog post about this, but it’s actually quite difficult to do nothing — really do nothing. I spent a lot of time sleeping, or laying on the couch or outside trying to keep my mind blank. Some forms of meditation worked, but many involve too much concentration. Most days I had a short trip into a quiet café somewhere — I’ve never been in cafés so often before in my life. Needless to say, it was a remarkably boring time. But thankfully this was during a very pleasant New Zealand summer, which permitted plenty of time lounging in the sun and quiet walks along the waterfront of St Clair beach (yea, such a hard life).

Oh, and of course it helped having my attentive friend Harley keeping me company:

spacer

On 18th December I was given the all-clear to start slowly returning to normalcy. On 3rd January I was told I could start reading work email for an hour, spread out over a day, every second day. It took me until 1st February to build up to being able to work half a day, albeit still not coding. If this seems slow, it was — agonisingly slow.

It’s 14th February now (for me, at least – yay timezones) and I’m still doing roughly half days, but building up what I’m doing. So I’m finally getting through my review queue, some technical reading, and generally catching up on things I missed. Hopefully I’ll soon be able to get back into some serious coding, help finish that little project I started last year, and generally be back into my normal routine. In the meantime, I’m a delicate little flower, so please don’t bury me with too much work spacer

Posted in Firefox, Mozilla, Personal

Add-ons Manager API: Change in event order when restartless extensions are installed

Posted on by Blair McBride

Over in bug 727398 I’m planning on making a change to restartless extensions that could potentially affect addon authors who use the Add-ons Manager API. This only affects code that registers a AddonListener or InstallListener event listener to get notified of add-on and install events, while also interacting with the startup of restartless extensions. I couldn’t find any add-ons on AMO that would be affected by this, but I thought it would be worth blogging about anyway.

Currently, when a restartless extension is installed, it’s startup() function is called before the onInstalled and onInstallEnded events are fired. This meant that a restartless extension would run it’s initialization code before anything else thought it was installed.

However, that causes some issues. For example, if a restartless extension uninstalled itself on startup[1], then it could be uninstalled before it was installed. Unsurprisingly, the Add-ons Manager UI broke when this happened (since it uses the same APIs that add-ons use).

So bug 727398 will change the order of those operations. When a restartless extension installs, the following will happen in this order:

  1. The extension’s install() method will be called
  2. onInstalled event will fire (AddonListener)
  3. onInstallEnded event will fire (InstallListener)
  4. The extension’s startup() method will be called

 

Update: This change will ship in Firefox update 14, which is scheduled to be released on 2012-07-17.

 

[1] Why would an addon immediately uninstall itself, you ask? Imagine an add-on whose sole purpose was to flip a preference to disable a newly-shipped but buggy feature, that would get re-enabled on the next application update. This is one of the things that a hotfix add-on could do. Additionally, I’ve been playing with various ideas for restartless extensions as a user support tool – the extension installs, does some work or collects some diagnostic data, then immediately removes itself.

Posted in Firefox, Mozilla

The Add-ons Manager and I are rather good chums

Posted on by Blair McBride

Back in… er… a long time ago, I wrote an add-on called Filter Extensions. I was just scratching an itch – I had more add-ons than the Add-ons Manager was designed to cope with. Turns out people like add-ons.

Because of that little add-on, one of my first projects after I started working at Mozilla was teaching the Add-ons Manager about outdated plugins. The theory was that since I had worked on that add-on, I should already have some background in working with the Add-ons Manager code. Hah… Yea, no, that didn’t help at all. That feature eventually shipped in Firefox 3.6, which now feels like an eon ago.

With a whole two Add-ons Manager related things under my belt, I must have earned myself a reputation for really loving anything to do with the Add-ons Manager. So late in 2009 I was asked if I’d like to help Dave Townsend with the re-write of the Add-ons Manager that he had been planning for some time (with Jennifer Boriss Morrow for UX, and Henrik Skupin for QA). It would be just a short project, helping out with the new UI – nothing major, I’d be able to get back to finishing my other project soon enough. Turned out that at that stage there was no UI yet… and it would take about a year for me to write it. The first very basic iteration was written during my Christmas holiday in Motueka, a few days later I threw away half the code due to a change in the (still young) UI design. We eventually shipped the rewritten and redesigned Add-ons Manager in Firefox 4. By this stage, the Wiki page containing the notes from our weekly meetings was so long that it often took several minutes to load. And sometime during that adventure, Dave made me a peer for the Add-ons Manager module. I say “sometime” because I don’t actually recall him ever telling me.

Fast forward to a few months ago, where I got the chance to break a third of all the unit tests for the Add-ons Manager. Okay, maybe that part wasn’t so fun… but solving the add-on compatibility problem was.

Apparently that (and everything else) went well, because then this happened:

Dave: Hey, so, wanna be module owner?
Me: Yea, sure.
Dave: Oh… I expected to have to convince you.

(Note: A mostly accurate summary, not an exact transcription.)

So here I am, (sub-)module owner of the Add-ons Manager. It even says so on a wiki, so it must be true!

So what’s this mean? Mostly it means more work for me – and certainly new challenges, which is partly why I so readily said yes. I’ve been thinking more and more about direction, code quality, and solving problems in the “hard” to “impossible” range – but that’ll come in a later blog post. For now, it’s business as usual. And I’m in the business of kicking ass fixing bugs.

 

Posted in Firefox, Mozilla

Solving Firefox’s add-on compatibility problem

Posted on by Blair McBride

“I want to upgrade Firefox, but my add-ons won’t be compatible.”

This makes me sad. And it’s a problem that’s been magnified by the switch to rapid release. One of the strengths of Firefox is it’s rich selection of add-ons. In fact, 85% of Firefox users have chosen to install an add-on. On average, those users have 5 add-ons installed. Firefox users really love their add-ons. So it’s not surprising that they get frustrated when one of their favorite add-ons gets disabled because it’s not marked as being compatible with the new Firefox update they just installed.

So I started working on a project to fix it. The end result will be that most add-ons will automatically be compatible with Firefox, starting with (hopefully) Firefox 10.

At the time of writing this, I’ve not yet finished the project. There are parts described below that I haven’t completed yet. But it’s progressed far enough to safely enable the new behavior on Nightly builds, starting with today’s Nightly build (labelled 2011-11-18).

Many of the changes are also on Aurora, but disabled. If you want to test the new behavior, go into about:config and change the extensions.strictCompatibility preference to false (true to re-enable the old compatibility behavior). Once I have a couple more major bugs fixed, we’ll make the call on whether to enable the new behavior by default on Aurora (which will ultimately become Firefox 10).

How does this work? The gritty details.

The problem with incompatible add-ons is that most of them are actually compatible – they just don’t know it. Unfortunately, blindly enabling all add-ons will enable some that are really are just incompatible, which will end in something breaking. So we needed a way to detect which add-ons would most likely be affected by incompatible changes to new versions of Firefox.

Assuming the extensions.strictCompatibility preference is set to false, add-ons will use the new compatible-by-default behavior. However, there are several reasons the Add-ons Manager will revert to using the old method of strict compatibility checking for a given add-on:

  • The add-on author chose to opt-in to strict compatibility checking by adding <em:strictCompatibility>true</em:strictCompatibility> to the add-on’s install.rdf
  • The add-on has been tested and determined to not be compatible with that version of Firefox (the Add-ons Manager gets this information from AMO)
  • The add-on uses a binary component
  • The add-on hasn’t been updated in an extremely long time (the compatibility data needs to state that it is at least compatible with Firefox 4, or Toolkit 2.0)
  • The add-on declares that is it only compatible with future versions of Firefox (we assume that add-ons are not backwards-compatible)

In the future, we also hope to give Firefox the ability to do a series self-tests to determine whether an add-on has broken something, and automatically mark that add-on as incompatible. Additionally, if the above heuristics end up producing false-positives, we may add the ability for AMO to tell the Add-ons Manager that it’s heuristics are wrong for a given add-on.

This also required a change to the way add-on updates are handled. Previously, users that disabled add-on compatibility checking didn’t get updated to the most recent version of their incompatible add-ons, since those updates often weren’t compatible with their version of Firefox (even thought they explicitly disabled compatibility checking). This meant that those users (which included most users running Nightly builds) didn’t automatically get important security updates of all their add-ons. The changes needed for the compatible-by-default behavior made it easy to support updating incompatible add-ons even for users that disabled compatibility checking, which means they’ll be running a more up-to-date and secure browser.

Finally, I should note that making add-ons compatible by default does not mean that add-on authors should stop including compatibility data, or stop updating it. Older versions of Firefox still rely on the compatibility data, and users can choose to opt-in to strict compatibility checking. Furthermore, add-ons need to still declare compatibility with at least Firefox 4 (or Toolkit 2.0).

 

—-
Gmail Archive Ukraine translation here – www.stoodio.org/archive-solving-firefoxs-add-on-compatibility-problem.

Posted in Firefox, Mozilla

7 Things About Me 2

Posted on by Blair McBride

Meme time again. Dave tagged me. And I need to blog more often… this ended up being a couple of weeks later than intended. So here we go!

4 Rules:

  1. Link to your original tagger(s) and list these rules in your post.
  2. Share seven facts about yourself in the post.
  3. Tag seven people at the end of your post by leaving their names and the links to their blogs.
  4. Let them know they’ve been tagged.

7 Things:

  1. I have two pet sharks – a silver shark and a rainbow shark. They live in two freshwater tropical aquariums along with angel fish, tiger barbs, neon tetras, bleeding-heart tetras, upside-down catfish, bristle-nose catfish, black-line flying-foxes, algae eaters, apple snails, black ghost knife-fish, a skunk loach, and a plecostomus.
  2. I’m acrophobic. This isn’t vertigo or not liking heights. This is full-blown irrational extreme fear. Panic attacks, complete disorientation, uncontrollable shaking, visual and auditory hallucinations, physically ill, vomiting, and losing consciousness. Getting up to the 3rd step of a step ladder is a huge accomplishment for me.
  3. I’m co-founder of the Dunedin Makerspace, which was established in late 2010. We do both hardware and software, and I organise the software-related talks for every second Thursday night. My current project there on Saturday afternoons is building a 3D printer.
  4. My online nickname, Unfocused, has no deep meaning. Some people read too much into it, but “Unfocused” was just a synonym for “Blur”, a nickname I originally gained offline. When I was around 9 years old, my classmates thought it would be funny to mispronounce Blair as Blur. It stuck.
  5. I am the southern-most Mozillian (AFAIK