July 21, 2014 · Weekend Testing

WTEU-47: A facilitator's report

Did you join us for the relaunch of Weekend Testing Europe? Many did. At one point we had 28 people in the chat, of whom 19 were actively participating in conversation. It's a new record for the European chapter, and one which produced its own challenges. Here's how it went for me...

It goes without saying, but as a facilitator, preparation is paramount. Firstly, there's the work required to come up with the idea for the session (including the selection of a test application), with a pre-session announcement two weeks before the session. After that, there's the day-to-day admin of responding to @europetesters' emails, tweets and Skype requests. Then there's the important matter of making sure the session itself is adequately prepped.

Amy and I received some really useful pointers in the run-up to this session, as I mentioned in my earlier relaunch post. Alessandra told us that (in her experience with WTANZ) it's useful to write as many of your chat messages before the session as feasible, as many of them (particularly the instructional messages) will be predictable and it reduces the amount of frantic typing when trying to manage the session. Ale also added another suggestion which was also echoed to us by Michael Bolton: Let the session flow naturally, let the attendees guide where it goes. Don't shut-off interesting discussion points just because they're not rigidly sticking to your idealised plan. (Though, of course, make sure that you don't slip too far behind your overall schedule.)

So, how did it go? Well, the "official" WTEU-47 experience report gives an overview of the session, and contains a link to the session transcript, so you can read/see for yourself. I wanted to add a few more words about my own experience, to give you a bit of a behind-the-scenes view!

![My Weekend Testing environment](/content/images/2014/Jul/Bs--4c9CYAA6RQX-jpg-large.jpg)
My presenter's environment, pre-session. Currently with only five open Skype windows...!

Facilitating a Weekend Testing session is very much like being a director. More specifically, it's like directing an improv show, such as the below clip from Whose Line Is It Anyway; the presenter has some guidance over themes or the overarching discussion, but it's the participants who shape what happens.

With so many attendees for the session, I was initially overwhelmed by the amount of unexpected last-minute admin; for instance, assisting users who were unable to connect to the Skype chat, and mopping-up last minute invite requests. For that reason, it was extremely useful to have Amy as co-facilitator, as she was able to keep the session moving forward when I was otherwise distracted. It was also extremely useful that we were presenting together in the same room, as it signficantly reduced the feedback time when we needed to make quick adjustments. From my own standpoint, becoming more familiar with these admin tasks will free-up a lot more time in future sessions.

Another challenge of having so many voices was trying to ensure that they all had a chance to be heard. The chat can sometimes fly along at a breakneck pace, with some people dominating the discussion, so it's important that these other voices do not get lost. Personally, I tried to engage with as many new faces as possible (again, this will be easier with less time spent administrating in the future). The technique of splitting into smaller groups seemed to help, as it meant that participants were collaborating in groups of 5-6 people, giving them more opportunity to be heard. I think the "breaking into smaller groups" technique is one we'll definitely use again for a class of this size, although we perhaps spent too much time on getting each group to present their findings (when we were actually more interested in how their chosen heuristics helped them to reach those findings).

Speaking of which, I'm delighted that the testing community is so open and willing to give feedback (and that, as colleagues, we are equally willing to receive and absorb that feedback). I was expecting to have a period of introspection a few days after the session, but we were getting comments a few seconds after we finished! (Again, that feedback is visible within the chat transcript, if you wish to take a look.) It's all incredibly useful stuff that we can apply to make future sessions even better, and as we're shaping these sessions for the benefit of attendees, it's absolutely vital that we know what our attendees are thinking.

So now, while our participants head off (and hopefully return for our next session on August 17th), the behind-the-scenes work begins again. We're off to plan for WTEU-48, and we'll be aiming to make our sophomore session just as enjoyable as the first!

My testing notes

Given that we knew we wouldn't have any time to test the application during the session itself, Amy and I each conducted a brief exploratory session ourselves prior to Weekend Testing. This proved to be very valuable, as many of the issues that we found were also raised within the group discussion, so it enabled an element of "me too" validation.

For the record, here's an abridged summary of what I found:

City Selection

  • Various data integrity issues which may be outside the developer's control, if they're using an external lookup service (I didn't get time to investigate further):
  • The list of cities includes the names of timezones themselves, for instance "GMT" finds "GMT Standard Time". However, many other timezones don't appear because there are too many cities containing that string; e.g. BST, PST, CET don't return those timezones. (Though you can indeed type "Central Europe" to find CET.)
  • Whilst figuring-out the above, I discovered that typing PDT would find a single result called "PST8PDT". What does that even mean?
  • Going back to the GMT search, it returned some other weirdly-named entries e.g. "Etc/GMT+10"
  • I typed in "United States", to see if it would find me a list of popular United States cities. It did, but the first entry in the list was the peculiarly-named "United States, DC, Washington, D.C." which looks like a data error
  • Typing ^, $ or / (but not other symbols) seems to offer the whole list of cities. From my limited coding experience, this seems to suggest that a regular expression is being utilised.
  • ...Indeed, further exploration shows that \d will show all cities containing numbers, and [a-z]{20} shows me all cities with 20 characters in their name. These are probably interesting observations, or "hidden features" rather than issues to address.
  • One general problem that I found (using the Comparable Products heuristic): I think that the city-select dropdown algorithm should give more weighting to values which BEGIN with the entered search term. For instance, if I type "New", I don't see New York, but I do see a city in Papua New Guinea! I recalled this excellent usability blog post which I had seen previously, about beautifying free-text location searching.

URL manipulation

I noticed that the user's entered city information is displayed verbatim in the URL, and clearly formatted as an array:

http://clock.darkhorseanalytics.com/ ?a[0][name]=London &a[0][tz]=Europe%2FLondon &a[0][isHome]=true &a[1][name]=New+York+City &a[1][tz]=America%2FNew_York &a[1][isHome]=false

This gave me a number of ideas about ways that I could reformat this array, to see if I could produce interesting results.

  • For the most part, breaking the integrity of the URL resulted in an empty black page, which isn't a great user experience - I'd prefer if it kicked you back to the city selection screen, or somehow otherwise allowed you to continue.
  • Changing an array element to a non-positive / non-integer value, e.g. a[x], a[-1] or a[1.5]
  • Changing the tz parameter to a name that isn't valid for a timezone lookup, e.g. [tz]=blah
  • Changing the [name] parameter to any other value (e.g. XXX) was accepted, and rendered within the clock. This actually seems pretty neat, as you could create a "custom" clock this way, e.g. displaying Weekend Testing Europe as the name of the timezone! There may be a "quick win" in adding the ability to configure this through the UI.
  • On the other hand, leaving the [name] parameter blank, or stripping the element from the URL altogether, still renders the timezone on the clock but without a label.
  • I checked what would happen if the [name] parameter was extremely long, to see how it would render on the display. Interestingly, the label stopped rendering when it reached 180 degrees on the clock-face; here's a live example.
  • I tried to fathom the significance of the "isHome" parameter in the URL, but didn't succeed. Page loads fine if there are 2 or even 0 cities set to isHome=true. In fact, isHome=xx doesn't seem to affect anything either. I ran out of time to investigate, but I think it might control which city(ies) are persisted when you return to the "Change Cities" dialog.
  • I observed that manually extending the array (e.g. to add a sixth city) resulted in six cities being rendered on the page, when the UI only allowed for five. Naturally, I had to take things to the extreme, so I created a clock containing 46 European capitals. Unless you're projecting it onto Times Square, you're going to struggle to see the whole clock, but do we care? It's obviously outside intended system usage, and although 46 timezones is clearly extreme, maybe there are times when plotting 6 or 7 timezones would be useful. (Another suggested future enhancement for the site - allow user to dynamically configure >5 cities in the UI.)

Miscellaneous incidental observations

Although I tried to focus on the two areas above, I noticed other issues in passing which were worthy of note:

  • When you hover over a time on the wheel, a yellow-bordered box appears, listing the time in each selected city. If one of your cities has a longish name (about 20+ chars) then it breaks outside the bounds of this box
  • You can select the same city twice, and it will appear twice on the wheel. Is that useful? Will anyone care?
  • There's a seemingly-unnecessary console.log() command within the code, which means that if you have a developer console visible e.g. Firebug, then when you press "Change Cities" it spits the HTML for the city input fields into the console window...? Probably accidentally left enabled by the dev.
  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket
Comments powered by Disqus