Another couple of days have passed, so another round of updates is in order. Some of the changes I’ll mention here affect the previous articles: Making a search command – the easy way! and Making a search command – part 2, so if you’ve read them: read this one too!

This is the part that broke your commands

And in more than one way. If you’ve tried some of the commands before the recent updates, you might have noticed that for some reason, certain queries wouldn’t return any previews, while other would work just fine. This is because some search engines return “strange” results in the middle of the normal results – and only do it sometimes – but the only way the parser knew which titles, previews and thumbnails fit together, was by their index in each of their own lists. This was a very fragile system, and while it it still available as fallback, using it isn’t recommended.

The main difference is that the parameter options.parser.container should no longer select the element that contains all the results, but rather it should select a list containing each result. Each results title, preview and thumbnail will then be found (if available) inside the result, and grouping is no longer dependant on indexes. This means that any given result can have a missing preview or thumbnail, and it won’t affect any of the others.

Obviously, changing the meaning of the parameter means you will have to rewrite any search command you have that uses it. I hope the benefit of stability will outweigh this initial annoyance.

JSON as promised

In my last post, I said I was going to be working on JSON support, and as of about 4 hours ago, initial support has landed in hg. I have successfully rewritten our default google and yahoo commands to use this new system, and still use the JSON API provided by the services, but as I don’t have much experience with this sort of interface, it is entirely possible that I have in some way limited the functionality and thus the compatibility with some services. If this is the case, the JSON support will of course be expanded.

A slight note on the usage is perhaps needed here. Let us take google as an example:

CmdUtils.makeSearchCommand({
  name: "Google",
  url: "http://www.google.com/search?q={QUERY}",
  parser: {type: "JSON",
           url: "http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q={QUERY}",
           container: "responseData.results",
           title: "titleNoFormatting",
           preview: "content",
           href: "url"}
});

First you might notice that there are two fields called url, one outside the parser and one inside. In that order, the first one does exactly what it usually did, except it’s only used if the user presses return to go directly to the search page. The second is the one used for the actual searching if you pass type: "JSON" to the parser. If the API requires you to use POST, this works the same way as you’re used to.

Secondly, if you happen to be uncannily familiar with the structure of the JSON google returns, you might notice that the container parameter I talked about earlier in this very post doesn’t seem to be pointing to each result. Instead, it’s pointing to the container of all the results. If you think about it however, in the HTML-case, jQuery makes sure we are returned a list of results, but in JSON, the parent element holding the results is already a list of results – so it sort of makes sense.

The only other new thing is the addition of the options.parser.href parameter, which was automatically calculated in the HTML version. In JSON, the url is usually held in a separate field, so this is needed to make sure we actually link to the results.

What you can do to speed things up

These changes that break backward compatibility will happen less often – or hopefully not at all – if I get fast feedback and suggestions. The more you complain, the more likely I am to do something about it fast

To try these changes out, run Ubiquity from source, or wait for 0.1.7 or 0.2pre15 where they will most likely be included.

While testing finished nearly 5 months ago the final report is to a stage that I can let it go and move onto the next study.
There was a LOT to learn in addition to a moving goal post. I spent a month fighting with my G4 computer for nearly a month before giving up and getting a new MacBook Pro on credit, annotating and uploading the videos to different video providers, rewriting the final report and moving it to the Mozilla wiki, finally reformatting those annotations in a spreadsheet format, triangulating the data, all the while trying to blog the results, create current and future state maps of the workflow and other things going on with Ubiquity, and learn how to work with a development team.
So it was obviously a learning experience. What’s CRAZY is that (while I haven’t been doing anything 100% original) no one else has really tried to do FOSS usability testing in such an open, remote, and distributed way. Thus the logistics were not worked out. Doing testing when your team is in the same city is one thing, trying to do it across continents is another.
The next step for me is to publish my workflow and expand the usability testing wiki section to encourage low cost usability testing in the FOSS community. If you are handy with Python there are some small scripts for an internal project that needs work. I have also proposed some screen capture software which I hope some smart, entrepreneuring hacker picks up soon.
~
I want to thank Jono and everyone hacking on Ubiquity for being so graceful in their handling of someone not used to working with a development, especially since I am doing this remotely.
I want to apologize to Aza, the study never really got to what he was after- alternate UI’s for Ubiquity. Between his international touring of Asia and the pressure to get something going we never really got in sync- which is a good thing. I think the testing is something we lack.
The biggest thanks go to my mentors who responded to my pleas for someone to give me direction and advice in what I was doing.
Dana Chisnell (author of the Handbook of Usability Testing and plenty of podcasts) gave me the most thoughtful feedback I have ever gotten, it was really incredible of her to spend her time and resources helping me. I really miss having Buddhist monks around and it’s refreshing to be around someone as compassionate as you.
Allen Gunner of Aspiration gave me invaluable advice in getting traction and broadcasting results. He is the rare and dedicated grassroots organizer in the FOSS world who compares with the best NGO people I know in the environmental movement. He knows how to kick ass and look good doing it ; ) I really hope my work will forward his mission to bring Usability to the FOSS world and I can’t wait to work with him in the future.
Andy Edmonds and I found each other almost by accident on IRC. He has been the most responsive person involved, indulging me with emails and chats about the smallest concerns and teaching me how to triangulate data. He is also the most experienced of the three in terms of dealing with large data sets (he used to work on search engines), how theoretical Test Pilot studies might work- assuring me that random statistical analysis can work in place of 100% collection and how best to anonymize data. He also taught me how Mozilla works, and nixed some of my crazier ideas.
You each gave me a different piece of the puzzle, it just took me a while to figure out which order they go in.