Imagine you’re a professor on the first day of the semester. You’ve printed your syllabuses, reviewed your discussion questions, and donned your classic tweed suit. You’re expecting a nice, small class of 8 students--perfect for class participation. But when you get to class there’s over 30 students! That’s a lot of tests, quizzes and papers to grade. This semester’s going to be a long one.
Until our degree planning app, this was a plausible situation at the Graduate Institute of Applied Linguistics.
The Graduate Institute of Applied Linguistics (GIAL) is a graduate school in Dallas offering specialized training in linguistics, language and culture learning, anthropology, TESOL, international service, and world arts. With increasing enrollment in recent years, GIAL’s World Arts program was struggling to keep track of all the students. It was time to move beyond clunky spreadsheets in order to make sure that each student was assigned the right number of classes.
Luckily, the director of advisors at GIAL’s World Arts program, Dr. Robin Harris, had a family connection to James, a freshly minted Viking developer. James recruited two other Viking graduates to build the app, and the GIAL Degree Planner was born.
What The Degree Planner Does
Our application allows advisors to build a student’s graduation plan, schedule classes and print the plan for their records. It also allows admins to build degrees, create courses, schedule classes, manage advisors, and view enrollment numbers. Robin estimates it’ll save advisors at GIAL hundreds of hours annually, and significantly reduce scheduling headaches.
In this post, we’d like to pull back the curtain and show you how these three recent Viking grads built a production-level app for a real-world client over two weeks. First, meet the team.
Product manager, lead designer, and front end developer. Chief of Client Relations.
Back-end / Rails developer, with a healthy dose of Angular on the front. Chief debugger.
Authentication, testing, and new features across the stack. Chief blogger.
How We Kept This Project On Track
With only two weeks to plan, design, build, and test our app, we needed a clear system of organization. We ended up relying heavily on the Agile and Scrum methodologies that Viking had trained us in.
We divided our project into two 1-week sprints, each ending with a demo and check-in with the client. This allowed us to see how she interacted with the app so we could take notes on parts of the UI that were confusing or unhelpful to her. James also frequently met with Robin throughout the sprint to get clarification on her requirements.
Each day we began with a quick scrum, which was a chance for us to ask each other the following questions:
1. What have you completed since yesterday?
2. What are you working on today?
3. What are you stuck on?
Each night (and the occasional afternoon or morning) we checked in, demoed our latest code and reviewed each other’s pull requests.
With the project stretched across two sprints, we aimed to have a minimum viable product completed and deployed by the end of the first sprint.
But first, we needed to make sure our project got off on the right foot by designing mockups and writing user stories.
Designing the Degree Planner
James put together the initial plan. After several discussions with Robin about GIAL’s needs, he drafted a summary document in Workflowy, a collaborative note-taking app. This got the scope of the project onto paper and made sure we were tracking with each other.
Next, we designed mockups for key interfaces using Figma, a collaborative design tool. Not only did this become the foundation of our app’s final display, it also made sure we were on the same page. This early in the development process, we were able to cheaply add or kill features as needed.
Crafting User Stories
With our mockups in place, we began writing user stories using Pivotal Tracker, a collaborative project management tool (sensing a theme here?). The mockups made story creation a largely painless process. We followed a typical user’s flow through the app, breaking down large features into the following “epics”:
- User Accounts
- The Advisor Dashboard
- Building an Intended Plan of Study
- Creating the Student Schedule
- Managing Degrees
- Managing Classes
- Printing Intended Plan of Study
- Bells and Whistles
Our minimum viable product would be reached if we completed the first four epics.
Having sketched out our epics, we moved on to filling them in one by one with stories. Since our app was interface-heavy, there were quite a few stories to write. Thankfully, the designs we had done ahead of time translated seamlessly into user stories.
Lastly, we approximated each story’s development time by assigning it a point total through a blind vote. In total, the design and user story phase took us about a day and a half. With much of our planning front-loaded, we hoped to avoid as much future deliberation as possible.
Our Tech Stack
The back end was built with PostgreSQL and Ruby on Rails configured to serve JSON as an API. We used Devise for authentication. We set up a VPN to pull course data from GIAL’s servers, and imported that course data into our database by scraping CSV files.
On the front end, we used AngularJS, UI Router for multiple states, and Restangular for simple GET, POST, PUT and DELETE requests. We used Bootstrap for styles, and Bootstrap Typeahead for search fields.
The app was deployed on Heroku.
A Tour of The App
If you’ve made it this far, you’re probably eager to see the app. Here are some of the key interfaces. (Feel free to demo the app yourself here)
The Login Screen
We used the gem Devise for authentication with a few customizations, such as requiring an admin to create new advisors rather than allowing users to sign up freely.
The Student Dashboard
Once logged in, the app takes you to the student dashboard. Students can be sorted by clicking on any column header. Clicking on a student name takes you to their graduation planner.
Building a Student’s Intended Plan of Study
Here the advisor selects a concentration for the student, and chooses from the list of required courses on the right. Boxes turn green as requirements are met. Chosen courses are populated on the left.
Advisors can drag and drop courses onto a term to schedule them. Available terms are shaded purple while dragging. We depended heavily on HTML5’s native Drag and Drop API in this section.
Printing the Student’s Intended Plan of Study
A summary document based on GIAL’s existing official documentation, with sections pre-filled based on their previous choices. Advisors select the “print” tab to save or print a PDF of the student’s intended plan of study.
The Class Dashboard
A comprehensive list of GIAL’s classes and the number of students enrolled in each class. Robin was particularly stoked about this feature, as it will allow her to make sure her professors aren’t over or underbooked.
Examining a Class
Clicking on a class brings up a modal with all the class’s information and list of enrolled students. Class details can also be edited here.
The Degree Dashboard
Here an admin can create a degree from scratch and build a degree’s concentrations, categories within a concentration, and courses within a category. Our goal with this section was to make the app useful to any institution. This page turned out to be an iceberg with several entities that needed to relate to one another (degrees, concentrations, categories, courses, classes, students, the thesis track, the non-thesis track, etc.)
Managing the Advisors
A simple dashboard for an admin to view and update advisor information.
What We Learned About Working with Agile and Working with a Client
Like any software project, this one had its fair share of challenges as well as successes. A few key takeaways:
Overcommunication is cheaper than undercommunication: At the beginning it felt like sketching out designs and writing user stories was taking too long. It turns out that that habit saved time in the long run. By taking the time up front to nail down the what, it allowed us to focus on the how during the sprint. And defining our stories in Pivotal Tracker allowed us to work independently yet cohesively. On the flip side, while we were creating user stories there were a few challenges related to elective courses that we failed to discuss. Those later came back to haunt us toward the end of the second week. Unaddressed issues don’t disappear!
Pair programming is a useful tool when dealing with a challenging problem: For several days Luke was struggling with a non-trivial CSS issue on the scheduling page. When he was at his wit’s end, James offered to help. Together we determined the best way forward was to modify the way we were displaying classes. Only one hour later we had finished refactoring the code and both of us were ready to take on new features.
Pay close attention to the client’s feedback: We found client demos to be highly valuable. First, they let us know when we needed to course correct. When Robin was unsure of where to click next, that was a clue our interface needed to be tweaked. Second, client demos allowed us to celebrate slam-dunk features, which gave us the motivation to get the rest of the features right too.
Though our official sprints are complete, we are continuing to update course data, tweak code, and write tests. As the app rolls out with the GIAL’s World Arts program, we’ll continue to iterate as necessary to make sure the app fits their needs.