For our project our group was thorough in considering usability as a process and an outcome. We were careful in evaluating our choice of tools based upon how likely those tools would let us build what we envisioned. Before selecting our final set of tools (Javascript, HTML, and CSS with GatsbyJS as the host and infrastructure) we took a look at more drag-and-drop style tools including Google sites and WordPress. Ultimately, we decided that even though our chosen infrastructure was more challenging, and could not be as easily divided between the team members, it best fit what we intended.

We played to our individual strengths and shared knowledge through regular group meetings – in these meetings we would share findings, what we learned, and did the occasional “tutorial” so that even if the technical aspects were largely done by myself, we all had a clear picture of the group’s progress. One of the reasons that we chose to include a thorough project summary was to highlight each member’s main contributions. My main contribution was to actually build the tool, but I was only able to do so in iteration and with feedback / testing from my group members.

You can see the code here: https://github.com/alisonmyers/resource-management-tool. Because we used GitHub for our repository, I was happy to see the insights of Code changes over time:

Personally, I wrote more dynamic functions that allowed the ingestion of data from multiple sources (Google Sheets being an attempted new addition), and allowed different kinds of information to appear in each resource card. This was only my second JavaScript project, and I was able to learn a lot by revisiting my old code! The trickiest bit of programming was making the search functionality work – and I am glad I persevered on this. If I were to do one thing differently, it would be to start earlier on the parts of code that were new to me – so that the presentation to the class would have been more complete.

See how the search functions (left) and the code written (right).

Our team was able to assess and demonstrate usability of our tool because we ensured that our decisions were grounded in literature, and were relevant to our original proposal and the initial reasons we decided that LOCR needed a facelift.