System Check Radio is a music app built for teams to nominate songs to a playlist of the week. At the end of each week, the #1 voted song is submitted to a "Greatest Hits" playlist that can be shared and listened to across time. This app is powered by the Spotify API to search for track data and enable song playback.
One of the most challenging parts of this experience has been these intense coding exams that we have every Friday. So I wanted to build something that future students could use to relax and focus while they take those same exams.
This page shows all songs submitted this week. When a song is selected it displays as a Spotify widget player. Users can vote songs up or down, and the playlist will sort itself in descending order.
At the end of each week, the highest scoring song is submitted to the Greatest Hits playlist. Song in this playlist can no longer be voted on, but admins can still edit the description.
Active members can find a song on the Spotify api using the search bar at the top. All results are displayed below with an option to leave a description explaining why the user chose that song.
Users can view their own profile, displaying their permissions, past submissions, and how many votes they received. Additionally, admins can view the profile of any user.
Admins can view a list of all users, and manage which ones are authorized to make submissions. My intention for this is to allow only current students to make submission and vote, but allow past users to still view the site’s content.
Off The Rails is a React / Ruby on Rails web app for rating and reviewing theme parks. Users can log in, search for parks by a tagged category, and submit a comment about a park with a rating. Ratings are averaged and presented under the park's details. Park images and profile pictures are stored using Carrierwave and AWS.
My team and I worked on Off The Rails to improve on our git workflow and to implement our first iteration of a React on Rails webapp.
A tile display for each park is shown here. From here, users can view a specific park or a list of tag categories. Admins can view the new park form to create a park.
Each park has a details page containing its description, average rating, tag categories, and any reviews made for that park.
Each park is categorized into a number of tags. Users can click on a tag to filter the displayed parks to only those matching the selected tag.
Users can submit reviews of theme parks and leave a rating. The rating submitted is then included in the park’s average score. Other users can give upvotes or downvotes to specific comments.
Practical Fractals is an Ember app that demonstrates what is possible within the canvas element. The display area is built out of “pixels” line by line. The fractal shape comes from an equation that uses two values, the x and y coordinates. Based on how those coordinates perform, the pixel is colored in.
On top of drawing each pixel, fractal images have an additional layer of complexity. Each pixel is “tested” multiple times. If the pixel is colored black if it makes it all the way through, and it’s given a different color if it only makes it halfway, and a different color if it meets a different break point.
This animation shows what happens when we change the number of times we “test” each pixel. The live version cannot animate this quickly, but we can do something similar if we use a lower resolution.
The zoom level divides the starting values for the x/y coordinates. So when the zoom level gets bigger, the values we are working with get smaller and smaller. This way, each pixel covers less “ground” resulting in a zoomed in picture. The Move buttons work in a similar way, directly adding and subtracting from the x/y values.
The color selectors update the hex values provided at each break point. In the future, I’d like to give the option to include more break points, and also let users adjust where those break points are.
View Project (Requires camera access)
I wanted to learn more about WebRTC, so I built this tool in React/Redux to take userMediaStream data and turn it into silly gifs with a cool 80s vaporwave theme. The user's stream is acquired using simple media constraints and a call to getUserMedia, then shown on the html video element. Screenshots are taken from the video and drawn to a canvas, which are then used to assemble a gif ready to download.
When the page initially loads, it will automatically request a media stream from the user's camera. The video element then sets the media stream as its srcObject. If for some reason the auto-start fails, there is button to manually request the stream.
When the stream state is active, the video element displays the current stream. The video scales with the page independantly from the size of the stream.
Once the user kicks things off, they see a countdown from 3, followed by a series of camera flashes. At each flash, the RecordImage action takes a screenshot from the video and draws it to a hidden canvas. Those canvas images are used to assemble an animated gif. The countdown and flashes both use the react-modal package in two different ways, depending on what props are passed to them.
After the photobooth function takes 6 pictures, they are encoded together to make a dataURL for an animated gif, which is displayed in another modal window. From there, the user can download the gif, or click 'try again' to return to the photobooth.
A guide to the many places mankind has reached throughout history, Camp Space is a website designed using Node.js as part of a web development course through Udemy. The process of building it covered RESTful routing, database driven content, authentication, and user created content.
The title page features a crossfading series of space themed images. Behind the scenes, this page also uses a header partial unique from the rest of the site.
The index view contains a list of landing sites pulled from mongodb using mongoose. From here, users can click on one to view more details, or add a new one. If they are not logged in, they will be asked to either sign in or create a new account.
The show page contains additional details about the site, if the current user is also the auther of the page, they are given the option to edit the details or delete the site altogether. Users can add comments below, and can similarly be edited or deleted by the comment's author.
The edit route prepopulates a form with the existing information about the site. When the user submits, the information in the db is updated accordingly. It also performs a check server side to make sure the user is in fact the page's author, and doesn't rely on the UI simply hiding the edit link.
This is a quick game made in javaScript to teach people how to read colors shown in rgb. In each round, you are given an rgb code, and six boxes, one of which matches the code.
In the default game mode, the game randomly chooses a 'correct' color and displays its RGB code at the top. It then makes six boxes and generates generates colors for each of them. To make the game fair, the random colors are compared to the 'correct' color to make sure they aren't too similar. If the user clicks on the wrong answer, that box is removed and resets their 'winning streak'.
In easy mode, half as many boxes are created, and the colors generated need to be even less similar to the 'correct' color.
A vertical view for mobile screens.
Made to demonstrate the UX methodology, weRead is a prototype for a learning management system that allows online classes to be taught in a way that is similar to in-person classes. I began with a series of interviews with teachers and students who have used online classes in the past. From those interviews, I created user profiles, pain points, and workflows that informed the design of the clickable prototype.
This is the home screen to be used by teachers. Here we see a list of classes that the teacher is assigned to, one of which is starting in five minutes! The number of classes shown here is a typical number that teachers would be responsible for.
In most cases, it will be multiple instances of the same class, set at different times of day, or different days of the week.
This is the classroom screen, where the majority of activities will take place. Teachers and students will enter the class similarly to a chatroom, and the teacher will control when class begins and ends using the switch in the upper right, and present lessons to the class via webcam or other media prepared ahead of time.
When the class period ends, the room stays open for students to collaborate and ask questions.
The system is planned around classes starting and stopping at predetermined times, but control ultimately rests with the teacher. On this screen, we see that the teacher has chosen to not end class automatically, and the class is currently running five minutes over. While it is not a good practice to go over time on a regular basis, this gives the teacher more flexibility.
The chat area below controls a number of options for conducting class. The teacher may call upon one or more students to speak to the group, review their messages for comments or questions, create workgroups, and talk selectively to those groups as needed.
Ben is one of the personas I created based on the interviews I had with teachers who have taught online classes in the past. His students have access to online collaboration tools through their school's online learning platform, but they prefer to use a patchwork of tools they are used to using in their personal life, such as email and facebook.
A basic flowchart documenting the normal flow of class. It walks through selecting a lesson deck, typing an introduction, and deciding when to start class. The teacher can then gauge how the students are responding to the material, and adjust the presentation accordingly. This kind of real time adjustment is only possible because of the way classes are structured in weRead. The ability for teachers to evaluate the class's understanding is the piece that is missing from many online learning platforms.
I developed this site map to show the primary pages that teachers and students will use, as well as the supporting pages needed to make them possible. I also identified Lesson Planning, Grades, and Assignments as areas for further development, as they are topics that are equally complex to the one I'm solving here, and deserve attention outside the scope of this project.
Safelight Security had a collection of cybersecurity training courses and wanted a better way to let our customers assign them to their staff and track their progress.
For staff, it highlights the course assignments that are due next, and features leaderboards to encourage participation. Staff managers can view the members on their team and monitor their progress. Additionally, program managers can assign course curriculums, set due dates, and edit course content.
The course homepage was the starting point for the Spark interface. Our development goals for Spark were to start with the smallest piece possible, and expand upon it over time. Safelight Security already had a large library of courses that including assessments and chapter navigation, so the course homepage was a natural place to start. One of the most common pieces of feedback we received about the existing courses was that users were unsure of what to do after completing a course. So for this interface, I wanted to make sure it was clear to the user when they accomplished a task, and where they stood in the grand scheme of things.
The video player shows an example of how Safelight's existing courses would fit in the interface. Chapters can be selected from the dropdown ribbon on the upper right, and transcripts are available to users who prefer to read the course text.
One of the major pain points of Safelight's clients was the lack of participation among employees. To help combat this, we experimented with a number of ideas to spur competition. This included a leaderboard that awarded points to the staff that complete courses first, and had the highest assessment scores. Another concept is awarding 'achievements' based on customizable criteria.
From this menu, program managers would select which chapters of the course would be seen by the different staff groups. For example, customer service staff might see a broad overview of the concepts being taught, while IT staff would be required to view a more in-depth lesson. Other chapters could be hidden altogether if they are not relevant to your organization. Similarly, assessments can be given customized question pools.
This infographic demonstrates how the positions of the earth, sun, and moon interact to form the eight familiar shapes we see in the sky.
