Design
Danny Rankin (TAM Instructor)
“The conventionality is right where you need it to be. it looks and functions exactly how you seem to want it to, so I think you all are at the right place you need to be and are prepared to move forward.”
During our first meeting with Danny, he suggested a ton of things that we could use to produce an InVision prototype that could propel us into the actual production of our application. Although we had heard it before, he told us to try to get an entire, fully functional prototype working (meaning every single page we think we’d need) before we get cosmetic with the app. As we have already started working on the design, this was good to hear so that we can consider our timeline and assure that we get that fully functional prototype done before we begin to design anything further.
Some further suggestions in terms of UI/UX design:
- Is messaging the main function of the app? If so keep it in the middle, but then does that put less importance on the planner aspect? Maybe put the profile in the middle so that the attention between messaging and planner can be split evenly; debate between yourselves.
- In relation to the bottom navigation bar, think about popular apps that use a similar navigation bar. Think about how people tend to use their phones and try to rank the importance of each of your pages and place them where you all think is appropriate.
- User testing, user testing, user testing! Get a different set of eyes on your project instead of your own or your mentors.
Isaac Sheets (TAM Mobile App Instructor)
Overall, Isaac said they we are well on our way to creating a functional app and was impressed that we are doing it all programatically. He agreed that Firebase was a great way to go about authentication and has some great feedback on the UX design of the app. The following were his suggestions on what to change and what to consider moving forward:
Tab Bar Controller
- Consider profile on bottom right?
- Do some user testing on tab bar controller layout
- Think more about which page you want to be the opening page
Messaging Page
- Do you want the messages to look like iMessage?
- Maybe consider more customization here
Mentor/Student Connections
- Consider doing this on the profile page
- Only mentor should be able to add students
- Planner page for mentor: List of students that then drills down to each individual planner
- Consider authentication of students/mentors on register
Functionality
Michael Condon (Associate App Developer)
Michael was very pleased with what he saw so far and gave great feedback on what he liked and what he thought might help us as we move forward. The main point he emphasized was the organization of our code, saying the way lines were broken into logical blocks made the code “much easier to read.”
He also commended us for the structure of the code. We have different folders housing different types of files such as ViewControllers, Models, and Helpers, which he said prevented him from struggling to figure out where something was or where it belonged. He noticed how modular our code is (how we can reuse code in different places) and said this is an “important trait of well-designed code bases” as it minimizes bugs, speeds up development, and keeps it simple.
He was also very impressed we chose programmatic UI instead of storyboarding. Though programmatic vs. storyboard UI is controversial, this is the way he prefers to make his UI.
Some critical feedback he gave us was to focus on scalability. Specifically the tasks ViewControllers have to perform. As the app grows the ViewControllers could become “bloated and overly complicated.” He noticed fetches are performed in our ViewControllers and as the app grows more complicated, this could be hard to manage because of network requests and complex response handling. His suggestion was to look into Coordinators to help manage ViewControllers and to keep the ViewControllers “as stupid as possible” by keeping them simple and only doing thing things that ViewControllers can/should do. Coordinators can navigate, handle network requests, and keeping track of overall state of different flows in the app.
The other critical feedback he gave us was to avoid commented code. Not commented code that gives an idea of what’s happening, but code that could do something but is commented out. This will help other developers hop into the code base as quickly as possible because they won’t be wondering why code is commented out and not implemented. He suggested making a new branch with this code implemented or stashed so you have both versions.
Overall he said to keep up the great work and that this was an “industry level iOS project so far!”
TL;DR
Continue to…
- Organize code, lines of code broken into blocks
- Put files in appropriate folders
- Modularize code for easy reuse, and simplification
- Programmatically create UI
Suggestions
- Think about scalability going forward
- Use Coordinators
- Keep ViewControllers simple
- Look into SwiftUI
- Keep out commented code
Brandon Slade (Stride CEO) & The Stride Executive Leadership Team
The Stride team was very impressed with our progress and said that overall, it looks amazing! They especially liked the ability for someone with access to the Firebase SDK to read conversations from mentors and students. This was a key goal that we had in mind in the development of the app and moving forward are going to work on making the Firebase data more user-friendly and readable. Right now the data is shown by individual messages, but we hope to get it broken up into chat logs from person to person.
Questions They Had For Us:
- Would you be able to involve parents on the list but not in the texts?
- Is there a way to have a separate parent portal? Not one where the parents are reading the kids messages but one where we can communicate with parents. Like where they have a separate account so all communication is through the app
Suggestions They Had For Us:
- The lists could use breaking down by days and a place for missing assignments, goals, and what to work on in the homework center
- A cool possibility would be like a way to download or export the weekly plan so that parents could see the original without having to be a part of the app (giving the students more privacy but still having that access without having to create a separate list to email parents)
Takeaways
- Implement user testing to find the best flow for the tab bar
- Make sure to break down to-do list into separate days
- Decide on the best way to include parents –> most likely the ability to export the weekly to-do list so that mentors can share the lists via email
- Keep code organized and modular
- Reuse as much code as possible to keep clean, efficient, and simple
- Look into Coordinators
- Start thinking about scalability
Stride Learning Mobile Application 