Joticle
Fall 21 Industry Project
Introduction
Joticle is a social learning platform for experts, educators, hobbyists, creators, and students. The platform provides a paywall-free research and learning experience with accessibility to everyone. Joticle allows users to create blog styled “jots” about any topic related to their choice of interest such as education, gaming, fashion, and sport!
Scott Wilson is the CEO of Joticle making him our main source of communication about the project. Mark Nelson is Joticle’s main tech lead, making him our developing mentor. With two highly knowledgeable clients, our team was able to navigate through any concerns with the project.
This fall term, our team of designers and developers are working on building a KPI (Key Performance Indicator) dashboard directed in the administrator function showcasing users’ retention and interaction data.
The Team
Zhu Cheng Li — Developer
John Carraher — Developer
Raymond Iacobacci — Developer
Maheshwari Tanwar — Developer
Michelle Huang — Designer
Laura Brigitte — Designer
Peter Shin — Project Manager
Timeframe
Oct–Nov 2021 | 6 weeks
Tools
The main technologies that were used consisted of:
Figma for most of the UI design
PHP for most of the backend API routing
Laravel Framework for library utilization
Vue.js for the frontend UI components
Javascript for the frontend code
HTML/CSS for the frontend UI components
Gitlab for codebase pushing
The Project
Design
Problem statement:
Joticle’s current administrative Key Performance Indicator (KPI) dashboard is too cluttered and lacks organization, making it difficult for users to quickly visualize and understand the data.
How might we make it easier for users to find and understand the company’s KPIs?
Low Fidelity Wireframes
Scott, the CEO of Joticle, provided a rough layout of what he had in mind for the KPI dashboard. From there we drew inspiration from what he provided, keeping the navigation bar the same but working on how data can be more efficiently displayed.
Mid Fidelity Wireframes
After presenting our low-fidelity wireframes to Scott, we received feedback that Dark UI is preferred as it displays the data more clearly and allows users to clearly see growth or a decrease in each container. Data visualization is something that is also being considered (graphs on the right) as it would give users better visualization of how each container is performing.
High Fidelity Wireframes
Creating more iterations based on previous feedback we received, color system and the navigation bar was the focus of what we needed to work on.
With color systems it wasn’t clear how the colors within the KPI boxes displayed no growth or a decrease. With that, we decided upon green for increase/growth, grey for no change, and red for decrease.
The navigation bar had new changes implemented to it, as we added a profile section and a solid-fill vs gradient bar to highlight which page the user is on.
Low Fidelity Prototypes
Implemented a two-tone color system for the navigation bar and interactive toggles on the drop down menu to indicate which days the user is seeing being displayed.
Usability testing
Conducting four rounds of usability testing we had our testers run through a set of tasks xyz. From testing we received positive feedback on the design system and they were able to run through and complete tasks with no issues. Some key takeaways from this were intuitive icons, dark UI was well received, and enjoyed the drop down shadows.
We presented these findings to Scott for a final round of feedback before handing off to developers. They suggested to save space on the left side of the page and leave more room for the navigation bar to toggle, so we shrunk the profile photo. We also implemented a new logo that would put emphasis on POD for centralized learning, as Scott heavily emphasized that.
High Fidelity Prototypes
With all the feedback and changes in mind, we created this as our default view of the KPI dashboard. Users can easily toggle between drop-down menus, view the KPI data at a glance, and alter the date range for what range of data they want to see.
With all of that we handed it off to the developers for the remainder of the project.
Development
API Routing
After getting the list of API pathing routes required from Mark, we wrote the API calls to interface with the AWS MySQL database. To minimize data transfer, all parsing commands were run by the serving EC2 instance on the Aurora-based database, and then sent to the client. These were tested with the app Postman, an API app that allows for request customization similar to that provided by Laravel frameworks. These calls were written in PHP, and used the Eloquent (Laravel) Database model to interact with the database. These calls requested data and returned it to the client in a packaged JSON format.
API Endpoints
Using the routes, makes the API calls to retrieve the actual data.
Figma
Platform we used for UI Design. Used wireframes and wrote HTML/CSS code for frontend elements using this platform.
Vue.js Components
Vue Class Components used for containing HTML/CSS code of elements. The methodology used was to abstract a singular container at a higher level without Jot specific information so that components could be reused for different metric containers via argument passing.
Blade Dashboard
The Vue.js components will be essentially inserted into this Blade Dashboard controller file, which will directly control the Dashboard on the Joticle website.
Takeaways & Challenges
Challenge: Project Scope
The original project had a larger scope than what we could fit into a 6 week term. The design team needed at least 3 weeks to finalize the design, and development didn’t start until it was greenlit. Ultimately, we completed as much as the project as we could within the timeframe.
Challenge: Communication
The scope of the project was broad, and we were given significant freedom in our design and development choices. However, it became challenging to move forward with the project when we did not have clearly defined next steps. It became necessary for us to take an active role in communicating with Joticle to determine their needs.
Takeaways: Design
For us, this was our first client project that simulated a real-life workspace, in which designers and developers collaborate closely to create a final product. By involving our developers, project mentor, and stakeholders in each step of our design process, we were introduced to new perspectives and learned the value of clear communication in a cross-functional workspace.
Conclusion
Thank you so much to Joticle for providing us with such a valuable opportunity and learning experience! We’re also so grateful to the CodeLab board for finding these opportunities for us and making this happen.
