I spent the summer after my freshman year (2017) developing a new event-sharing platform for the Olin College Library. As the lead frontend developer, I helped select a JavaScript framework, led the subsequent charges learning React and Redux, and directed most of the design decisions to ensure a cohesive and appealing user interface. In the end, the platform reached about 80 percent complete, with the remaining 20 percent left for future development.
Skills developed
- Learned React
- Learned Redux
- Practiced UI design
- Used GitHub with pull requests and issues
- Deployed React app to Heroku
A quick origin overview
The theme for the Olin College Library’s “Summer of Software” was “community software.” The goal was to prototype software that could serve small communities in order to improve their members’ lives. Looking at our Olin community and identifying elements shared by other communities of a similar size, we decided information sharing in the context of community events was a compelling problem space.
Despite having such a small campus, Olin community members are still amazed by how much goes on that we don’t know about. Email is the primary form of information dissemination at Olin, but it’s easy to miss things and the deluge is overwhelming. It also requires that one be on all of the campus mailing lists to have access to all event information, which is impractical. There had to be a better way.
So…you made a calendar?
Yes, and no. While what we made may look like a calendar, there is a key difference in the underlying data structure. Instead of an event being added to a specific calendar (e.g. “Gardening Club,” “Student Affairs”), all of the events are stored in the Amorphous Blob of Events (ABE) and assigned tags. That way an event can have multiple tags and effectively be on multiple “calendars.” A user can then simply choose which tags to see, and all of the relevant events are shown. The user can even create an ICS feed to add to their own calendaring software (e.g. Google Calendar) to automatically see events with the desired tags on their own calendar. (New events will show up automatically.)
My role
As the team member with the most web development experience, I was the de facto leader when it came to making informed design decisions. These included selecting a JavaScript framework, deciding to use Redux, and ditching the jQuery-based Full Calendar for our own home-grown React calendar component.
We selected React because it appeared to be the most popular JavaScript framework at the time and because our advisor, Oliver Steele, had significant experience with React. It was a decision that we did not regret.
Once the web app began to grow in complexity, it became clear that Redux would be helpful for maintaining state. I took the lead on learning that and migrated the first few components to use Redux.
While Full Calendar served us well in many regards (e.g. it gave us a calendar grid right out of the box), its underlying architecture (i.e. its use of jQuery) proved to be more of a curse than a blessing in the long run. We ran into issues with component resizing and tooltips not disappearing, so I began developing a React component to replace it. Dubbed the Ultra-Responsive Calendar, it was entirely React-based with as much styling done with overridable CSS as possible. By the end of the summer, it was good enough to replace Full Calendar, though it still lacked optimal handling of edge cases (e.g. lots of events on one day in month view, many overlapping events in day/hourly view).
Takeaways
This summer served as a great opportunity to take my web development skills to the next level. I was comfortable with HTML and CSS, but my experience with JavaScript (using jQuery) was limited to a single quick project I’d done in high school. I left this summer experience with a solid foundation in React and Redux and the confidence to build my own web app from start to finish (or at least most of the way there).
Recent Comments