tl;dr
problem
Organizers and members of small to mid sized groups need to find meeting times that work as many people as possible. While there exist solutions for helping groups schedule meetings, they may be cumbersome to use even for the basic task, and many features users highly value are unavailable among any existing offering.
solution
acmeet is a responsive web application that simplifies the meeting scheduling experience and provides various features that assist in the process. It affords features such as user filtering and multiple calendar integration to make filling out availabilities and finding ideal meeting times a seamless process, all done within a single page.
A MVP of acmeet was implemented with a React frontend communicating via GraphQL with an Express server, with data stored in a PostgreSQL database.
case study
problem
In student organizations, group projects, team meetings, anything involving groups of people meeting together, it is necessary to find times that work for most, if not all, members involved to conduct meetings. Finding overlaps in available times via individual "announcing" (e.g. "I'm free 4-6 on Mondays and Thursdays") is time consuming, cluttering, and difficult to do, particularly as group size increases.
competitive analysis
Meeting scheduling apps, or simply meeting schedulers, generally operate by enabling groups of people to indicate their availabilities within a range of dates and times; this allows the organizer to identify the times that work best for the largest amount of people. There are two classes of users in meeting schedulers:
- Organizers create the meetings
- Responders fill out their availabilities on meetings made by organizers
Organizers may fill out their own availabilities as well after creating a meeting, going through both workflows.
There are 2 main products competing in this domain already: When2meet and LettuceMeet, both of which follow the same high level workflow:
- An organizer creates a meeting by selecting a set of dates, as well as a start and end time
- Responders fill out their availabilities on the meet
- The organizer uses the availabilities to determine a time to schedule the meeting
When it comes to the user interface, user experience, and/or features, however, the two apps differ drastically.
When2meet
When2meet is minimal but focuses on enabling a fast and simple experience for users, with the entire workflow for either organizers or participants able to be done in a single page without scrolling or pagination.
organizer user flow
- 1
Organizers enter the name of their meeting
A default title of
New Event Nameis provided; however, users are not permitted to use that as the actual title, and the default value is not a placeholder, either; this results in users having to manually clear out the meeting title in order to input their own. - 2
Organizers select the dates to include for the meeting
Users can toggle between selecting specific dates and selecting days of the week. The calendar can additionally be scrolled by clicking and dragging on the month or year labels, but few users knew of this, indicating a lack of discoverability: the only indication that the feature exists is from the mouse changing when hovering over them.
- 3
Organizers select the earliest and latest hour for the meeting, as well as the timezone
The select dropdowns in this section have an extremely large amount of choices - 24 each for the start and end hours, and over 500 for the timezone - making it difficult for users to find the option they're looking for. Fortunately, at least the timezone defaults to the user's local timezone.
- 4
Organizers click the "Create Event" button, which creates the unique event link and redirects the organizer to that page
responder user flow
- 1
Responders enter their name at an existing meeting link
Responders can optionally add a password to their availability, which prevents others from modifying their availability afterward. The default view provides a view of the overall availability matrix to the right.
- 2
Responders fill in their availabilities in the availability matrix
When2meet automatically live updates the overall availability to account for the participant's availability.
- 3
Users view the availabilities at given timeslots
Hovering over a timeslot in the availability matrix displays the number of responders available at that time, and enumerates the available and unavailable responders in two separate lists.
summary
When2meet excels at enabling users to swiftly set up and fill out meeting availabilities. However, it completely falls flat in its responsive design, or rather, its lack thereof: on mobile devices, the already limited space dedicated to the actual app becomes even smaller due to the smaller width of mobile devices, while the footer ends up taking over half of the screen.
LettuceMeet
In contrast to When2meet, LettuceMeet puts an emphasis on a pleasant user interface: it uses larger font sizes, and maintains a good balance of whitespace between elements. LettuceMeet additionally provides numerous quality-of-life features that enhance the meeting scheduling experience, such as built-in scheduling, user accounts, and Google and Outlook calendar integration; however, despite these additional features, LettuceMeet falters in user experience, particularly along its critical path - that of creating meetings and adding availabilities.
organizer user flow
- 1
Organizers select the dates to include for the meeting
With LettuceMeet, meeting creation begins with a calendar to select dates from; after dates are selected, the user must click "Let's Meet" to continue to the next step of meeting creation.
LettuceMeet's calendar defaults with the current date selected, and supports dragging to select, but not deselect, multiple dates. Different months can be visited by clicking on faint left/right arrows on either side of the calendar, although past dates are unselectable.
- 2
Organizers enter the name and optionally description of the meeting, and select the earliest and latest hour for the meeting in their local timezone.
The second page for meeting creation contains the meeting name, description, and start and end hours. Unlike When2meet, LettuceMeet does not support selecting different timezones, instead always using the local timezone. Also unlike When2meet, LettuceMeet separates the hour and the
am/pmselect, simplifying hour selection.Only after the second page is filled out can organizers click the "Create" button to actually create the meeting. As with When2meet, doing so creates a unique event link and redirects the organizer to that page.
responder user flow
- 1
Responders click the "Add Availability** button at an existing meeting link
The LettuceMeet meeting page defaults to a large view of the availability matrix, and a list of responders. Discontinuous dates are visually separated in the availability matrix by a small margin.
To begin adding an availability, the user must click the "Add Availability" button in the top right.
- 2
Responders fill in their availabilities in the availability matrix
After filling in availabilities, the user must click the "Continue" button to continue to the next step of availability creation.
The LettuceMeet availability is paginated, with up to 7 dates on each page. If the user is not on the last page when clicking "Continue", LettuceMeet will instead go to the next page. This helps users remember to fill in their availabilities for those dates as well.
- 3
Responders enter their name and optionally email
After filling out the availability matrix and clicking "Continue", responders who are not signed in to LettuceMeet must fill out their name and optionally email. Only after filling this out can the responder click the "Continue" button to finish creating the availability.
additional features
With regards to checking availabilities, Lettucemeet, like When2meet, supports hovering over a timeslot in the availability matrix displays the number of responders available at that time. As LettuceMeet displays all responders in its default view already, it indicates which responders are available by dimming and crossing out unavailable responders at the given timeslot.
Clicking on a given responder in LettuceMeet makes the availability matrix display only that responder's availability; doing so also replaces the "Add Availability" button with an "Edit Availability" button, allowing responders to amend their availabilities in response to schedule changes, or any mistakes made in filling out the availability.
LettuceMeet also supports a "Schedule" button, which allows a user to select a single block on a single date in the availability matrix as the "scheduled time"; this updates the meeting title to describe the date and time of the scheduled time block, and adds a distinctively-colored corresponding block in the availability matrix. While many users noted it was a nice feature to have, however, very few used it in practice, with most organizers reported preferring to notify others of scheduled meeting dates through their primary communication platform, such as Discord or Slack, instead; furthermore, most users reported rarely, if ever, revisiting a LettuceMeet meeting link after filling out their availability if they were not organizing the meeting.
For users with accounts, LettuceMeet also supports Google or Outlook calendar integration, which displays calendar events in a separate color in the availability matrix. While the majority of users preferred not to use user accounts, all of those that did have user accounts had one primarily for Google Calendar integration. LettuceMeet only supports integration with a single calendar, however; several users expressed the desire to be able to integrate multiple calendars with LettuceMeet, noting that only being able to import one calendar did little to help, as they had to refer to their accumulated calendars regardless.
summary
LettuceMeet affords a pleasant user interface coupled with numerous quality-of-life features; however, it falters in regards to user experience, and many of its additional features, while nice to have, don't align with or otherwise only partially support users' use cases.
user interviews
User interviews were conducted to better understand how and why users used the particular meeting schedulers they did use, and what other needs they might have or could use in meeting schedulers.
Among users that had used both When2meet or LettuceMeet, those that preferred When2meet most often cited its "convenience", "ease of use", and automatic updates; however, others stated they used LettuceMeet over When2meet in spite of LettuceMeet being more indirect and cumbersome to use due to When2meet's archaic user interface, described as, among others, "disgusting" and "pathetic". A large majority of users that preferred LettuceMeet over When2meet perceived LettuceMeet as "simpler" and "easier to use" in spite of them taking more time to create meetings and/or add availabilities in LettuceMeet compared to When2meet, reflecting an instance of the aesthetic-usability effect. Most other users preferred using LettuceMeet for its calendar integration, as discussed above.
Over half of all interviewees mentioned calendar integration as a killer feature; interestingly, over half of these people were unaware of LettuceMeet supporting such a feature. Several users, all of which already use LettuceMeet's calendar integration, specifically mentioned multiple calendar integration. Some users expressed wanting different weeks to be visually separated in the availability matrix. While all users generally used meeting schedulers on a desktop, a small proportion of users still mentioned mobile support as a factor in choosing meeting schedulers.
scope
primary persona
- college students involved in student organizations (ages 18-24)
- small to mid sized meeting/event (3-40) managers/leads/organizers (ages 24-65)
principles
To guide the development of acmeet, design principles were formed based on data and feedback obtained from the user interviews.
- 1
Keep It Simple Stupid
Using acmeet should effortlessly simple, straightforward, and unambiguously easy to use.
- 2
Aesthetics matter
Don't compromise on aesthetics, albeit not at the expense of usability. Let usability guide the information displayed, then make the user interface look good given those constraints.
- 3
Finish the remaining 20%
The Pareto Principle states that 80% of results come from 20% of the causes1. Don't settle for putting a little effort to design for "most people" - strive to design for the remaining 20% use case(s) as well.
solution
The final design, guided by the aforementioned design principles and built upon feedback from wireframes and prototypes, has the following features:
- create a meeting in a single page
- add an availability in a single page
- edit an availability in a single page
- delete an availability, directly from the meeting link page
- filter arbitrary subsets of responders' availabilities
- schedule a time for a meeting within the application
- display imported calendar(s) in the Add and Edit availability views of the availability matrix
design
lo-fi wireframes
creating meetings
Users want to be able to set up all information for their meeting on a single page, but still would like their meeting scheduler to look good. acmeet consolidates all information to create a meeting on a single page while maintaining whitespace between elements.
adding availabilities
To add an availability to an existing meeting, users click the "Add Availability" button to the right of the section heading titled "Availabilities" in the meeting page (Figure 2-A).
Doing so changes the section heading to "Add Availability" (Figure 3-A); reveals an input for the user to enter their name (Figure 3-B); replaces the button with a "Save" button to submit their availability (Figure 3-C); and transforms the availability matrix view to default into an empty one, where users can proceed to fill in their own availability. Together these allow all necessary information to add an availability to be contained within one page on the screen, making it simple to add a new availability.
Clicking the "Save" button adds the availability to the matrix and returns the page back to the overall availability matrix view, including the newly added availability.
checking timeslots
When hovering over or selecting a timeslot in the availability matrix, the responders list heading is updated to display the amount of responders available at that timeslot, out of the total number of responders (Figure 5-A); additionally, the names of responders that are not available at that time are greyed out and struck through (Figure 5-B).
filtering availabilities
Organizers expressed wanting to be able to view the availabilities for any arbitrary subset of responders. Clicking on responders' names in the responder list filters the availability matrix to display only selected responders' availabilities (Figure 6-A), and updates the responders list heading to display the number of responders selected (Figure 6-B).
Checking timeslots in a filtered availability matrix accordinly causes the responders label to update the number of selected responders available then out of the total number of selected responders. Formatting is still applied to all responders' names, however, irrespective of whether they are selected or not.
editing availabilities
Users observed often making mistakes or typos with inputting their name and availability, or having their schedules change after filling out availabilites. When a single responder is selected, the "Add Availability" button transforms into an "Edit Availability" button.
Clicking the button provides similar functionality to "Add Availability", albeit with the heading title instead being "Editing [Responder's name]'s Availability"; the availability matrix pre-populated with the current availability of that responder; and clicking "Save" updating the existing availability, rather than creating a new one.
scheduling
To "schedule" a meeting, users can click on the "Schedule" button next to the "Add Availability" button. This updates the heading title to "Scheduling meeting", and allows the user to select a single continuous block in one column; on doing so, the heading title is updated accordingly to reflect the selected block.
On clicking "Save", the page returns back to the overall availability matrix view, with a distinctively colored block overlayed upon the scheduled time (Figure 12-A), and the heading directly above the availability matrix also updated to describe the scheduled time (Figure 12-B). Additionally, when a time is scheduled, the "Schedule" button is instead replaced with an "Unschedule" button.
calendar integration
Users commonly expressed wanting support for calendar integration. Calendar events from integrated calendars are displayed as blocks underlayed in the availability matrix in all views.
design system
brand
The acmeet brand is built upon beauty in simplicity and compactness, striving to ensure all information is viewable on a single screen while still maintaining sufficient whitespace to appear "comfortable". In addition to the conventional decisions in typography and spacing, careful use of shadows to separate elements contribute immensely to this, with significantly fewer users considering the layout to be "cramped" or "tightly packed" when using shadows compared to borders.
colors
Minimal colors were used so as to not detract users from their purpose of setting up meetings and filling out availabilities for them. A/B testing was performed on calendar weekday selection and weekend color, and separately on availability matrix color and link color. Users overwhelmingly responded best to red in the calendar to indicate weekends, and strongly preferred blue for calendar weekday selection over other colors. Every user preferred green for availability color by a significant margin. Users generally preferred blue for link colors, but less so when exposed to the calendar selection color earlier; among these cases, purple was generally the most preferred link color.
As several users expressed wanting a meeting scheduler with dark mode, a dark theme palette was built as well.
typography
The sans serif font Red Hat Text was selected as the font of choice for its high x-height and fairly tight spacing, making for a compact yet highly legible font. A/B testing also found that a majority of users perceived Red Hat Text to better reflect the branding and purpose of a meeting scheduler compared to other fonts Quicksand (the font used by LettuceMeet), Arial (the font used by When2meet), Helvetica, Roboto, and Montserrat (three popular sans serif fonts). Sans serif fonts, in general, were overwhelmingly preferred over serif fonts.
To avoid using excessive vertical space, greater variance in font weight was used as opposed to font size to distinguish text importance.
hi-fi prototypes
I ended up just building the actual web application from the lo-fi wireframes. Unfortunately, I didn't end up implementing all the planned features there (see #features for justification) so hi-fis are technically incomplete ¯\_(ツ)_/¯
creating meetings
To create a meeting, users fill in the meeting name, select one or more dates on the calendar, and choose the earliest and latest hours and timezone for the meeting. After clicking the "create meet" button, the user is redirected to the meeting's unique link, where they can fill out their availability and share the url for others as well.
Content is condensed to be completable without scrolling on a desktop monitor, or otherwise without pagination on mobile screens.
meeting page
The meeting page displays the meeting title prominently, followed by the meeting description, if specified, in regular body text. The rest of the page is dedicated to availabilities, containing the availability matrix and a list of all responders for the meeting.
The heading of the availabilities section varies to describe the current "state" of the page (i.e. adding, editing, or viewing availabilities). The availability matrix itself is headed by the range of months/years spanned by dates in the meeting, and with each date labelled by its day of week and day of month, and each hour labelled as well. Gutters in the availability matrix make it easier to delineate between dates in different weeks, and in the case of a large number of dates, the availability matrix becomes scrollable along the x-axis to avoid overflowing or downscaling. A list of all responders is viewable to the right of the availability matrix on desktop screens, or below on mobile screens.
The proportion of responders available at any given timeslot in the availability matrix is reflected in the intensity of green displayed at that timeslot, providing an intuitive visual to identify the best timeslots. The total number of responders is displayed in the responders list heading.
adding availabilities
From the meeting page, which displays the current availability matrix and a list of all responders so far, users can click the "Add Availability" button to begin adding their availability. Doing so reveals an input for them to enter their name, and replaces the availability matrix displayed with an empty one for them to fill in their availability.
Users can click on the "Save" button, which takes place of the "Add Availability" button when adding availability, to add their name and availability to the meeting's responses. Doing so returns the meeting page to the "view" state of the meeting page, with the user's newly added availability included.
The availability matrix containing all other responses is intentionally obscured when adding availabilities, based on feedback from several users noting how many users tend to only respond in timeslots that are already relatively filled, creating a positive feedback loop where only the most "populated" timeslots continue to be filled, resulting in an inaccurate map of people's true availabilities.
The layout of the page is designed such that all information needed to add an availability can be done without vertical scrolling on not only desktop but also mobile devices.
checking timeslots
Users can click on or hover over a timeslot to "select" it and see more information about the timeslot. Specifically, on doing so, the responders list heading is updated to include the number of responders available at that time, in addition to the total number of responders; the names of responders unavailable at that time are also greyed out and struck through, enabling users to see exactly who is available at any given timeslot.
filtering availabilities
Several users strongly expressed wanting to be able to view some subset of availabilities. Users can click on responders' names in the responders list to select or unselect them, filtering the availability matrix to only display the availabilities of the selected responders (or if none selected, everyone's); in doing so, the responders list heading is updated to display the number of responders selected instead. Based on feedback from users finding it annoying or difficult to unselect responders, a list of tags of the selected responders' names is displayed underneath the responders list heading as well, where clicking the tag unselects the corresponding responder.
Checking timeslots in the filtered availability matrix works similarly to as if the full matrix was that of the filtered. To minimize misinterpretations of unselected responders' availabilities, names are struck through if that responder is not available at the given timeslot, irrespective of whether they are selected.
tech
stack
acmeet is a fullstack meeting scheduler web application, built with user experience in mind. The primary language used for coding was TypeScript, a superset of JavaScript which provides compile-time type checking.
The frontend is a React application built atop Next.js. React was chosen for its rich ecosystem and component-driven design, which significantly improves developer experience via improved scalability and maintainability; while not the most performant, React applications still are generally "fast enough" for users.
Styling is done using SCSS and CSS Modules, which enables modular, reusable code that fits well into the component driven design of React. All UI elements are built from scratch (including the calendar, which is made by me and available as @_--/react-calendar): the last thing I wanted to do was make Yet Another Generic Material Design/Tailwind App. This also enabled me to establish my own design system, and gain further knowledge in CSS and accessibility, without having the crutch of a component library to rely on. Among others, techniques such as persistence of state to local storage and dark mode (a tricky topic in React, as covered in depth by Josh W. Comeau) were also exercised.
To avoid unnecessary bundle size bloat, React's built-in Context API was used for state management, rather than using external alternatives such as Redux; for a similar reason, all date operations in acmeet manipulate native JavaScript Date objects, instead of relying on bulky external libraries such as Moment.
The frontend and backend communicate via GraphQL, a highly expressive protocol while also enabling only relevant data being sent in requests. To abstract intricacies such as caching and proper server side rendering, the GraphQL client urql was used in the frontend to interface with GraphQL API requests. GraphQL Code Generator was used to generate types from the backend's GraphQL schema to get typed urql queries that integrated nicely with TypeScript.
The backend is a GraphQL server built atop Node.js, Express, and Apollo Server. While Node.js-based backends are not necessarily very efficient, they are often serviceable, while potentially significantly improving developer experience by enabling the entire stack of an application to be written in one language.
TypeScript classes and functions are used as a single source of truth for both the GraphQL schema and database through using TypeORM and TypeGraphQL decorators, with TypeORM enabling describing tables via the aforementioned classes while also providing an API to operate on them in a safe abstraction from SQL, and TypeGraphQL converting the classes and functions into GraphQL schema, queries, and mutations. TypeORM additionally simplifies the process of performing database migrations.
PostgreSQL is used for the database, picked more so for gaining familiarity with relational databases than anything else. In practice, a non-relational database such as MongoDB would be more suited for the task of acmeet due to the heirarchical nature of data.
I wish I could say I was using Docker and that the server and database were containerized there, but unfortunately my computer simply doesn't have the free memory to run Docker without killing all my other processes.
features
The acmeet web application was ultimately built upon learning new technologies as a core motivator, in turn leading to various compromises in aspects such as performance; as a result, not all functionalities described in the design writeup are implemented, as I determined building the fully-fledged, feature-rich app would be better in an app built with doing so in mind. The acmeet web application can thus be instead thought of as an MVP of the design.
Even so, the acmeet web application still supports the basic workflow as well as the most commonly expressed wishlist feature among interviewees. In particular, acmeet supports the following features:
- creating a meeting
- adding an availability to a meeting
- checking the availability of responders at a given timeslot
- filtering a meeting by any subset of responders
- dark mode!
- fully keyboard-navigatable UI
The following features are implemented on the backend, but not on the client side:
- scheduling a meeting
- editing an availability
- editing a meeting, including the start and end hours (a feature not present in any other meeting scheduler)
- deleting a meeting
The following are other features that would be highly prioritized:
- user accounts
- preferred start of the week day
- (multiple) Google Calendar integration
- creating date-agnostic meetings (i.e. days of the week, rather than specific dates)
problems
acmeet is not a trivial to-do list or otherwise tutorial app; as a result, heavy emphasis was placed on effective code and folder organization and structure to maintain developer productivity. Among this included creating a separate TypeScript project for shared constants, type definitions, and utility functions between the client and server.
On the frontend, due to the decision to forego component libraries, all components had to be built from scratch; this resulted in building a mini-component library for minimally styled reusable components, otherwise relying on props to adjust the styling based on the parent context. Working with JavaScript Dates, particularly for various timezones, also proved to be a massive pain, with me ending up basically creating a mini date util library to work with them.
For the backend, limitations were encountered with using TypeORM to interface with the database; while it does provide many escape hatches for more complex use cases, the "happy path" use case for TypeORM seemed quite limiting in scope, such as being unable to update and return in a single query. It didn't help that I was not very familiar with relational databases, or backend as a whole for that matter. This resulted in spending time getting familiar with SQL to execute SQL in TypeORM rather than using TypeORM's abstractions. At least that time spent was time spent well, though, as knowing SQL can only ever help.
spotlight
calendar
The calendar date select in the create meeting page took a considerable amount of time. Existing React calendar components generally require a fixed width passed in, require heavy date utility libraries, or otherwise are difficult to customize and style. As a result, I sought to build my own calendar component with zero external dependencies, and of which could be used not only for the use cases of acmeet, but could also be generalized to use in various other situations as well.
The calendar supports three levels of granularity in view: month, the conventional calendar view of dates; year, which displays all 12 months in the given year; and decade, which displays the ten years of the decade. The three views combined enable rapid traversal to any reasonable date, and individually can also be disabled as necessary to fit the intended use case of the calendar in one's application.
The calendar supports three different modes of date selection, and can switch between them without needing re-mounting or duplicate components. In single select mode, only a single date can be selected at a time; in multi select mode, the mode used in acmeet, multiple dates can be selected; and in range select mode, a start and end date are selected. Beyond manually selecting consecutive individual dates, both multi select and range select support click-and-drag to select a range of dates.
Date tiles have three separate states: unselected, staged, and selected. Unselected tiles have no background color, while staged tiles are dimmer than selected tiles. Staged tiles are used to indicate the dates between the start and end dates in a range select; to indicate the dates that would be selected when selecting a range of dates with click-and-drag; and to distinguish between selected dates in the current and adjacent months (of which, if not desired, can be hidden through a prop as well).
Each date also has three boolean properties which can be set and styled as seen fit: highlighted, disabled, and weekend dates. Disabled dates cannot be selected, and are by default greyed out and struck through; weekend dates are by default colored differently; and highlighted dates are by default bolded and underlined. The calendar supports props for defining which days classify as "weekend", as well as which day of the week the calendar "begins" on (i.e. is the leftmost day of the week). Meanwhile, highlighted and disabled dates can be customized by passing a boolean function that determines whether a date should be disabled/highlighted, or by passing common string presets such as "today", "past", and "future".
The calendar's text and formatting is also highly customizable, accepting functions defining how days of the week, months, years, etc should be displayed and/or formatted. The calendar also accepts callbacks on any changes to it, such as when the calendar view changes, when the date selection mode changes, when the selected dates change, and/or when the staged dates change. This allows the developer using the calendar to listen and react to events in the internals of the calendar accordingly; for instance, by default, the calendar uses this to select all intermediary dates between the start and end dates when switching from range to multi select, and otherwise clear all selected dates.
Styling for the calendar is also shipped into separate stylesheets, so as to make setting custom styles simple; as a result, the "core" css consists only of styles that directly affect the proper display of the calendar, while various other useful presets, such as many of the "default styles" or having calendar tiles become square or circles, are provided as separate opt-in css files.
Building such a calendar (although admittedly still not nearly something that could be called "fully comprehensive") was admittedly not necessarily the best use of time, if taken solely into the context of building acmeet - after all, it's only one small part of the whole thing, and many of the features in the calendar aren't even used in acmeet - but doing so was still a valuable learning experience in its own right, and forced me to carefully consider API decisions, performance, and bundle size such that it could be reused in other applications as well.
overall reflections
acmeet was a really interesting project to do! Building through the entirety of the project, from research to interviews, design to actual implementation, was quite enlightening and helped further exposure with a wide variety of fields. My greatest regret with this project is that I didn't get around to implementing all the features from the meeting scheduler case study.
next steps
Ultimately, this project, while addressing an issue I had noticed was present, was built for learning in mind, and not producing an actual full-scale production grade application. However, through this I've gained a much better idea of what users are looking for, and how to create such an application. I'm planning on building this for actual use when I have the time - after all, there is a niche and demand for this!