Online schoolers developing an online school: for your consideration
Here at Lambda school we are an ambitious cohort who launched ourselves fully into an immersion coding bootcamp experience accidentally during a global pandemic. In the seven months since this group started, the world has actually changed drastically and online communications have moved front and center for home and business. As all of us in school are working remotely from home and relying on personal wifi connections more than usual, as well as spending increased time on social media accounts…it has become obvious that this is a trend that is here to stay.
For the labs portion of our curriculum, which endeavors to place developers on teams creating real-world products that could eventually go to market, our team was placed on a brand new product called “Reach LMS”: an online schooling platform that is agile and easily adapted to users from varying levels of technological capacity. That requires an efficient design taking into account various software and hardware limitations and challenges that could arise. Given that each of us is using an online schooling platform daily, we felt uniquely poised to recreate what a user may want in terms of functionality and design. As much as we tried to think of every possible scenario and pitfall in the first few days, by the fourth week (now) we were still faced with development decisions we did not foresee.
A few glitches in the road…
As we continued developing components, including a primary admin dashboard to view programs and create new ones, we went through a few days of rapid coding with the aim to create functionality but not necessarily streamline it. This is a common instinct as you primarily want to see something you create work before you care how it actually works. These days coincided with productive days on the backend team, who were managing all of our data through an increasingly complex series of Java Spring controllers. They went above and beyond to produce as many endpoints as we thought could be necessary to manage the users and their respective programs, courses, and modules.
When our initial API endpoints were working, we immediately placed them into the components we had built out and waited for the magic to happen. Instantly there were bugs of course, but eventually our program data rendered nicely and courses soon behind them. This was a functioning application, but a pretty ugly one at that. Release one made the grade in terms of our functionality goals, but we were behind in terms of having a cohesive style and a user-friendly method for presenting information. Also our application was lacking basic commodities like a navigation bar on every page and buttons in logical places for users. Still, seeing the app live and rendering changes was enough to encourage us after two weeks of a little overconfidence and shortsightedness. Nevertheless, like true students and martyrs to the cause, we buckled down and were determined to make release two the one to remember.
Release II and the journey to actual usability…
Release two felt more like the real deal in many small ways. For one thing, I had finally decided we were going to stick with Ant Design all the way through the app, despite my initial reservations about it. After a few trial and error moments, I grew fond of the Layout function for its ease in bringing the entire page together and setting up concrete boundaries. This meant that I would save time not stressing over individual pixel dimensions of divs on various pages and could ship one cohesive style that I believed in for all pages. The example code that started this trend in the Dashboard is below:
Having successfully rendered programs to our admins and courses to our teachers, we faced a “we’ll cross that bridge when we get there moment” with the final content: modules. Very soon into release two development, we reached that bridge. It seemed cumbersome to all of our users to approach modules in the same way that we approached both programs and courses, also taking into consideration that they would be the most voluminous category by number and size of content. So taking a cue from other common examples around the web, we made a unanimous decision to go for a series of dropdown menus. The first would showcase the module in that particular course and the bottom two would allow admins to add teachers and students to that course. Our half-baked inception moment was complete and beautiful.
See the real action here:
Final List of Shipped Features:
- Mobile First: the application is highly responsive to different screen sizes and also supports larger sceens.
- User Roles: Each user has one of three roles: admin, teachers, and students. Each role has a specific set of features available once inside the app.
- User Profiles: Each user can view and update their own user profile once inside the app.
- Program Management: Admins can create a program once inside the app and can update and delete that program as well.
- Curriculum Management: Admins can create, update, and delete courses per program, as well as modules per course.
- Dropdown menus in UI for students to more easily manage their modules.
This marked the last major phase of front-end development for this stage of the application; it will be up to another team to decide where to go from here and to judge if our instincts were right all along… or to scrap everything and start over. We are confident that the foundation we laid will be a good jumping off point and also a cautionary tale on making last minute decisions, although they can lead you into some pretty fun territory. Future features could include direct streaming (suggested by our partner team) and a progress bar throughout the whole app. We also suggested to take the route more traveled now and gamify a student’s progress as in points earned and rewards along the way. This is always good for morale.
As is the pace with software development, next week may be a whole new world. But for today, we online schoolers salute you!
