Prototyping with GitHub

Weeknotes Post #37: Jan 30–Feb 14, 2021

Andrea F Hill
4 min readMar 2, 2021

Yes, I know that Jan 30 — Feb 14 is more than a week.. But this is my 37th post since starting with the public service :-)
And I’m not posting this til March. Yikes! I got behind. I don’t think I even quite finished this post, but I’m going to hit “publish” as better late (and incomplete) than never.

This past week I really felt in my element! I started my UX career building HTML prototypes for usability testing, but it’s been quite awhile since my job officially involved any coding. Last week I had the chance to flex those muscles again.

We were building a prototype to be hosted on GitHub pages, so we can share the URL with external people. The tasks to be performed during the usability test was a combination of new pages and existing content. In order to constrain where the testers may wander off while performing the tasks, we didn’t want there to be links out to the current site, so instead we brought in copies of the content to make the prototype self-contained (or at least, that was the goal).

One of the challenges of running tests on a site as large as is that there are are lot of ways for participants to get off-track. We wanted to get a glimpse into possible pitfalls, but didn’t want participants to go too far down an unexpected path and be unable to recover. In a moderated usability test where you are interacting with the participant as they perform the test, you have the chance to redirect and get people back on-track. In an unmoderated test like those we run with TryMyUI, there’s no such opportunity.

So, a colleague of mine developed an approach for use in his prototypes that I adopted: it’s a simple page that directs people to go back to the previous page. This let’s us see what the participant tried to navigate to (because they did actually click), but redirects them to look for the information somewhere else. Simple enough!

A page directing the user to ‘go back’ and attempt to complete the task another way

Although there were only about a dozen proposed new pages to the prototype, we needed to include copies of a lot of existing pages as well, which meant a lot of links to check to ensure they worked relative to the prototype.

For this, I did some googling on Regular Expressions, and then opened up a fancy text editor.

Regular expressions let you search for patterns so you don’t have to do things one-by-one. For this project, I created a subfolder that held all the “copies of existing pages” — I called it “current”. I populated that folder by going to the webpage on the live site, right-clicking to “view source” and then copying the source code and creating a new file with that content.

I wanted to retain the file name, but not recreate the path (whether or not this was a good approach is another matter). But the code on existing pages shows relative links — things like this:

HTML from a page showing relative links — links that point to “/en/revenue-agency….”

If I kept those links the way they were, they would be looking for a file structure of /en/revenue-aency/services/tax… etc etc etc. That entire structure didn’t exist in my prototype. Instead, I wanted the path to be more straight-forward and just be in a subfolder called “current”.

I was able to use regular expressions to look for links with a certain pattern — and then if they matched my criteria, I could replace it:

See that $2 there? That takes what is in the second set of parentheses and puts in into what is being replaced. Pretty slick!

This stuff can be daunting, so what I really like about the text editor Atom is that it’ll give you a preview of what your find-and-replace will do.



Andrea F Hill

Sr Digital Analyst with the BC Public Service Digital Investment Office, former web dev & product person. 🔎 Lifelong learner. Unapologetic introvert. Cat mom.