Code | Demo

Background

For this final iteration of my makerspace project, I wanted to lean into the remote assistance experience. It sort of dawned on me that you don’t really want folks operating heavy machinery to be looking at their phones assisting others. On the other hand, allow members to remotely assist from their homes/office seemed like an idea worth pursuing.

User studies

The user studies were an invaluable tool in crafting a user experience that was unintrusive without leaving users in the dark as to what was happening.

I knew that a one-to-one assistance model was the best. Allowing multiple chat threads or group threads would mean the user constantly explaining their issue or the steps the’ve taken with other helpers. However, once a assistance had been offered, I wasn’t sure what to do with all the request notifications still lingering on other users screens.

The first two options I experimented with were removing the request notifications when it had been answered by someone else, or updating the text to say it had been answered. Both of these fell short from a user experience perspective (users felt they missed the original message) and an accessibility perspective (WCAG 2.0 requires a minimum amount of time before removing notifications).

The final solution, proposed by a classmate, is one utilized by a tool called Be My Eyes. Be My Eyes allows users with sight impairment to connect with volunteers on their phones who can assist in describing what the phones camera is seeing. Their solution to this problem is to display a message indicating the request has been filled only if the volunteer engages with the request. In this way, the volunteer was already engaged and wouldn’t miss or be distracted by the new information.

Next steps

Initially I thought video chat would be a luxury feature, but after user testing I’m convinced it would be really valuable. It’s difficult to describe complex machinery and parts through text and a picture/video would really help in many remote assistance circumstances.

Code | Demo

Background

We‘ve been covering real-time user experiences in Connections Lab. This iteration of the Asmbly dash utilizes adds a web socket server to allow users to "raise their hand" and ask for help at individual stations. I found the discovered the model for this “assist” interactivity from Glitch and thought it would be interesting to adapt to an actual space.

Technology

Having some familiarity with socket.io, I wanted to learn a bit more about ws with this iteration. This library is super light weight, and unlike socket.io, clients in the browser can just use native WebSockets to interact with the server. I had some difficulty updating my Linode box to permit WebSocket connections, but after rolling out a standard Nginx server with LetsEncrypt, those problems were mostly resolved.

On the frontend, I used a library called react-hot-toast to manage the new toast notifications. These notifications broadcast when a user requests assistance and also serve as a status indicator for the requestor.

After user testing with some friends, I found that communicating a “pending” state was particularly important so that users new their request was received without issue. It also serves to alert them when help is on the way.

Next steps

In project three, I’d like to make the assist interactions actually one-on-one, so that there isn’t several individuals responding to a request. In addition, I‘d like to add chat functionality so individuals tuned in from their home office can offer assistance. For a reach goal, I‘d like that communication to afford optional video chat.

Background

Our Connections Lab midterm project was an opportunity to combine and integrate ideas we’ve been covering over the past few weeks. I recently joined Austin’s local makerspace, Asmbly. During my onboarding and training the instructor mentioned the need for a way to quickly report issues with the stations. For my MVP I wanted to create a site that could contain information about each station (tips, safety, required training) and also allow users to submit those reports to the releveant staff.

Technology

I used Next.js for this project, this choice was motivated by two key features. The dynamic routes would allow me to programatically create pages based on a simple JSON file storing the tool data. In addition, when deployed on Vercel, the Next.js API routes makes deploying serverless functions a snap. I used this feature to create a function to create emails and route them to the appropriate staff using the nodemailer library.

For the frontend code, I used TypeScript, React and CSS modules to create reusable, scoped components. While this project certainly could have been tackled without these tools, I find that React greatly reduced the amount of code authored. In addition, TypeScript and CSS modules makes it difficult for future developers to break things. This is particularly important for this project considering Asmbly staff are all volunteers so anyone could chip in.

One piece that turned out really well was the QR code generation. I used a JavaScript library to map over the tools data and generate a QR Code for each one. I even got a chance to use the print media query to format the list when printed.

Next steps

I did a playback with Charlie, the instructor who first pitched this idea and he had some great ideas. The makerspace has a wiki that has some basic information about each tool. This could be used either as the actual link target or to source data into my app. Rather than throwing the information all on one page, another version might allow the user to select from three options: Info, Maintenance, Problem. The app could then simply route the user to the correct service depending on what they’re trying to do.