Former scientist who traded in her chemistry set for a solid state hard drive. Crafty by nature with an eye for meticulous design, my passion is coming up with creative solutions to tough problems, be it with a sewing machine or a keyboard.
Currently working as a React/Node.js Developer in Atlanta, GA.
TABLE TALK TUTOR is an iOS app built with React Native, Redux, and Node.js that's designed to make you sound cool at parties.
Built for people who don't like staying glued to social media but also want to stay current with what people are talking about, this application pulls Twitter's Trending Topics and allows you to search them with preset search terms (e.g. "Who is", "News", etc), or with whatever search term you enter. After selecting a search term and pressing submit, the application displays an aggregate list of search results for that search term from Twitter, Bing, and Google.
When designing this application, I found that interactivity was the most complicated part of the design. When first displaying search results, I had them all in one list. To add interactivty to the results section, I made the Google/Bing/Twitter results their own separate scrollable horizontal rows, with each result being a card. When you swipe each row, the cards snap to the center of the screen individually. This made the design more dynamic and interesting to play with.
I used three external APIs for this project, the Twitter Develper API, the Google Custom Search API, and the Microsoft Azure Search API. These each brought their own challenges, but the biggest design pattern I had to architect was whether I wanted to group all requests into one fetch request using a Promise.all(), or if I wanted to make them individually. I ended up choosing individually, so that the time it takes for the user to see some search results is minizmied. It generally does take a second or so for all three requests to reach the frontend of the application, and if I waited for all to be completed, that's a second the user would see a blank screen. I decided it would be better if they saw a partially filled page rather than an empty one.
FRAMED INTENTIONS is a vritual vision board app built with React, Redux, Node.js, and PostgreSQL.
A vision board is a tool used to help you visualize your goals. Usually consisting of a collag of images that are various shapes and placements, our app allows you to search Unsplash for images to populate your own personal vision board and then allows you to move the images around the board and to resize them as you see fit.
I was personally tasked with devloping all of the board functionality and architecting our data structures. I accomplished the board functionality using Interact.js
I decided to use Interact.js for board functionality because it allows for drag/drop and resizing. However, Interact.js is not designed for React. There are Interact.js React wrapper libraries, but each of these were broken and therefore unusable. In order to get around this, I had to debug the wrapper libraries to see how to adapt its code for our own use. Structuring this code in such a way that I could grab the data from the onMove and onResize functions was also a challenge, because those functions do not return values. Instead, I moved a Redux dispatch function into the onEnd of each method that grabbed the width/height/x/y values and placed them in the Redux store, allowing me to grab them for board storage and styling in the future.
I was tasked with determing what our Redux store was going to look like and what our data structure for each store component was. Instead of storing saved images and the composition of the board images, I decided to store the saved images in the board image component of the Redux store. This way, we didn't have to update to pieces of the store whenever an image was added or removed from the search. The actual board image component of the store I decided to structure as an array of objects. Each object has a description, a URL, a width and height (set to a default size to start), and an x and a y (set to 0, 0 to start). This structure allowed for easy access to this information when rendering the board data to the screen.
I was personally tasked with adding authorization functionality, building the level database, and populating the statistics page with data from the database.
Authorization was one of the trickiest parts of this project. We wanted to ensure that only people who had signed in could see the gameplay and stats information. To do that, I used two express routers, one for public use which gave access to the login functionality, and one for authorized users, which made requests to receive the gameplay data and the statistics data. We also included JSON Web Tokens to ensure that users did not need to sign in multiple times in the same day.
Formatting the database was another challenging aspect of this project. We wanted to make our database scalable so that we wouldn't need to make major changes to it when we expanded our game. To do that, I simplified the table layouts by making one table specifically for decoy colors, and one table for solution colors. The columns of the table consisted of the level number, color itself, and it's ID. Doing this in this simplified layout allows us to add more than two of each type of color for future levels without requiring us to remake our table.
TONELY is a web application designed to analyze tone percentages of draft tweets so that companies can establish a consistent tone amongst all customer service representatives. It also provides an approval service so that tweets may not be submitted to Twitter unless they have been approved by a second member of the team.
I was personally tasked with obtaining the Watson API data, modal functionality, and all of the CSS styling.
One of the biggest challenges facing the styling was creating harmonious tones while also maintaining contrast. To do that, the majority of the colors are varying opacities of the same tone. This creates cohesion while also adding dimension to each layer of the site.
The most difficult function of the modal was the copy function. In order to automatically copy something from a page via a button, you must copy from an input box. This did not fit the styling or spacing of our modal, and for security reasons Google Chrome does not let you copy a hidden item. To work around this, the copy function first creates the input box, populates it and copies that text, and then destroys the input box. This happens so quickly that it is essentially invisible to the end user.
CHATTRBOX is a web chat application that uses web sockets to update open browser windows in real time. One of the biggest challenges faced in this project was communicating with the backend and frontend simultaneously.
The main purpose of this project was to explore web sockets in a functional app. I structured my code so that the server side was as simple as possible, making scaling easier when the app gets larger. In the future I would like to incorporate routing into this project to make my code even more efficient.
Initially, the bananas were intended to be a part of the main portions border. However, though the border-image repeat did place the images in the corners of the body, the CSS animate feature does not work on borders. To get around this, the bananas are all images placed in divs, that were fit to the corners using flexbox. I used @keyframes animate to have them spin continuously.
To animate the chimps, I used Math.random to determine a new x and y for each button, careful to limit the range of the coordinates to the view width/height - the chimp's width/height. After determining the new positions, I used jQuery's animate function to animate the chimps from their current position to their calculated new position.
The styling on this site aptly shows my design pickiness. I was careful to choose the perfect hover gradient on the images, so that the image themselves were not masked on the hover by too dark of a color while also giving a halo-effect. When this halo-effect is coupled with the box shadow behind the images, it creates a three-dimensional floating effect.
The modal was by far the most challenging aspect of this site. I hardcoded a basic, unpopulated modal into the HTML which is initially set to hidden. When an image is clicked on, it populates the modal, and the modal's display attribute is set to "flex." I utilized closures to ensure that the modal is populated with the image that is clicked on without having to use an ID attribute on each image. To handle each event (be it keyboard or mouseclicks), I used multiple, specifialized functions to make the code clear and easy to follow.
BUBBLEMANIA is a game built with Python's Pygame library, in which you try to collect points by colliding with point sprites while avoiding attack sprites. Some of the biggest challenges I faced were dealing with classes and collisions.
The most challenging part of this game was the class aspect. Since there were so many different pieces that had similar functionality, I made a sprite class that handled things like collisions and ensuring pieces didn't move off of the screen. I developed classes that took a multiple parameters so that I could limit the amount of global variables in the entire program.
Collisions were another challenge in this game. Pygame has a built in collision method for sprites, but adapting that collision method to work for multiple types of events (negative scores and positive scores) required including conditional statements that pointed to smaller, separate functions. This limited the complexity of the collision function itself as much as possible while still making the collision function as reusable as possible.