Gator App

UX Architect | UI Designer | Graphics Artist | Programmer

Project Overview: I started a new job in mid-2019 at Eastern Gateway Community College and my supervisor identified the need for a mobile app for students and asked me to work on something. The initial design idea was focused on creating an “app wrapper” around the mobile-optimized web-based student portal. However, after some additional thought and consideration it was determined that a native mobile application would be a better user experience.

The Opportunity: This was my first app that would be created for a professional organization and not just as a hobby project or learning exercise. This required me to work through the entire development cycle from research to prototyping and finally to a finished product. This was also the first project that I have been involved in that required both an iOS and an Android release so I got the opportunity to learn an entirely new language and development environment as well.

Research Findings: When I inquired with the College about what kinds of features they wanted to see in a mobile app, the feedback was pretty limited. I was able to determine that their main requirements were based on communication (push notifications) and campus information (directory info). The small team that was involved in requirements gathering typically pointed to other colleges and universities in the area as examples of having an app while EGCC did not have an app. I decided to look to the App Store to see what other schools were providing with-in their apps for inspiration.

Based on the research and the amenities of the school (for example, many universities offer on campus school sponsored housing but EGCC does not) I was able to put together a framework and feature set for the 1.0 version.

Project Challenges

a) Cross Platform UI/UX Design: It was important to me at the outset of the project to design a unique experience for both the iOS and Android versions, respectively. I did not want to use a middle-ware development environment and I wanted the iOS version of the app to feel like an iOS app and I wanted the Android version to feel like an Android app. This was especially difficult as I had not had a lot of experience with the Android platform up to this point, but luckily my in-laws are Android die-hards and they had an older Galaxy Note device that I was able to root and install Android Q (10) on. After some time with the device, I was able to effectively design an Android experience that felt more like an Android app.

b) Android Development: Along with the UI/UX component of building the Android version of the app, I also needed to learn the entire Google development environment from first installing the IDE to publishing the app on Google Play and everything in between. If I’m being completely honest here, I found the entire experience to be frustrating and the learning curve was steep despite having been an iOS dev for several years. For a senior programmer, having so many options and ways of doing things is definitely a plus, but I consider myself a junior programmer and a complete newbie with Android. I spent countless hours researching the ‘recommended’ ways to do everything from navigation to interface design and ultimately pieced together my own personal ‘best practices’ with no way of actually knowing if these are really a best practice at all. All things considered, I think the Android version turned out pretty well for a first try.

c) Microsoft Authentication: One of the early challenges when developing the app was authentication. EGCC uses Microsoft Azure as their single-sign-on authentication provider for every IT service that students use. The “Gator App” would need to authenticate to Microsoft Azure as well. Fortunately, Microsoft provides an MSAL (Microsoft Authentication Library) library for both iOS and Android. I worked with the school’s network administrator to configure an Azure application and then implemented the necessary code to integrate Microsoft’s authentication and Graph API so that a user can authenticate to the school’s Azure instance and the Graph API returns the student ID as a value that can be used for other purposes inside the app.

d) Push Notifications: This challenge was less technical in nature and more of a UX problem to solve. The College identified that a major goal of the “Gator App” was to improve the communication with students and provide more just-in-time information to them. Naturally, the first inclination is to send a lot of push notifications to students but as many of us know, spamming users with push notifications will cause them to disable notifications on your app at best or delete your app completely at worse. We kept push notification capabilities for urgent messages but built a separate ‘News Feed’ section in the app that will feature a running list of non-urgent messages for students to read and stay informed. The news feed uses a JSON file on a website and is sorted and filtered by campus location so students only receive information that is relevant to their campus.

e) CampusCloud SIS API: The College’s SIS (Student Information System) is CampusCloud and it provides for an API for accessing student account data by student ID. Using the Microsoft Graph API, I was able to retrieve the student ID number from Azure and then use it in the API queries. This worked extremely well and I learned how to use SwiftyJSON (iOS) and GSON (Android) to consume the API data and then use it in the app to display student information, grades, transcripts, and the class schedule.

Design Documents

USER JOURNEY

WIREFRAME EXAMPLES

PROTOTYPING

UI MOCKUP USING SKETCH

FINAL DESIGN - iOS 14

FINAL DESIGN - Android 10

2022 Update: iOS SwiftUI Transition

After receiving a large amount of feedback from students who used iPads regularly and were requesting a native experience on that device, it was determined that we needed to support larger screen devices in addition to iPhones. After doing some research on what would be involved in updating the UI to support all of the iPad devices using UIKit, it was clear that the better approach would be to completely re-write large portions of the app in SwiftUI instead.

In Spring 2022, we released version 1.4 which was completely re-written as a SwiftUI project. In addition to migrating to SwiftUI, we took the opportunity to transition away from SwiftyJSON to using Apple’s native JSON decoder and to move away from CocoaPods for injecting the Microsoft MSAL and OneSignal notification libraries to Swift Package Manager. Not only did this make for a cleaner project build, but also cut down on the build-time and code maintenance complexity. These three changes combined to put our app on a foundation that is future-ready as Apple continues to evolve the iOS platform.

The move to SwiftUI took approximately five weeks, but ultimately it is a far superior language that allows for near automatic support for Accessibility technologies as well as universal Apple device support on iPad and iPhone. The move to SwiftUI also enabled the addition of Home Screen Widgets and even an Apple Watch companion app.

Technologies Used:

• Apple Xcode 12.4

• Android Studio 4.1

• Swift 5.5

• Kotlin 1.4

• Foundation, UIKit, SwiftUI, OneSignal, MSAL, SwiftyJSON, GSON

• CampusCloud SIS API

• Marvel POP

• Sketch App, Adobe Photoshop, Adobe Illustrator

• Apple Keynote