Together is a mobile application that gives users the ability to find home groups of various beliefs and religions that are located in their immediate surrounding area. It’s an app that is really for the non-conformist. I saw the larger need of bring a sense of community back into our techno-centered lives; the sense of communal connection that doesn’t necessarily have to be present only after a tragedies.
One of the most difficult tasks to do is to find an idea that is worth dedicating the next 100-200 hours of your professional or personal life to becoming a reality. There are so many applications in the Google Play store, that I can sometimes feel the voice in my mind that says “eh, its not worth the build”. Incidentally, any Creative can identify with this dilemma.
During this phase, I researched the competition. I tried to find a competition; any competition. In reality, most applications focus on getting members within a congregation to be more interconnected with the goings-on of a church or house of worship, but applications that try to get people of no official affiliation to get together…well, there wasn’t much competition there. So, the discovery phase transitioned to social applications that utilizes maps and multiple user accounts. The goal was to survey the feature set, see general design patterns for User Experience, UI Design, and Information Architecture to craft a plan for my application.
One application that I found particularly appealing was AirBnB. Though I wasn’t a huge fan of the implementation inside the application; that is, to find a map and search in a way much like Zillow.com, I was a huge fan of the account creation and on-boarding processes. It was time to begin sketching out some initial UI designs.
Research & The App Definition Statement
At this point, the basic feature set could be easily defined as each screen had been somewhat captured on paper. I began to ask myself, does this layout make sense? Do I really need this feature in the initial build, or is a a nice to have? Once I answered these important questions and had a sense of the direction I wanted this application to go, I crafted the App Definition Statement and began making software decisions about required 3rd party libraries.
One of the primary programs that I love using is Adobe Experience Design (XD). Rapid prototyping is the name of the game, and this program does it really well. My general workflow was to move from sketching the screens out to designing them in Sketch, an amazing UI Design application released by Bohemian at https://www.sketchapp.com. Often times, the design that I sketch out is based on a basic picture in my head. The high-fidelity mockup that I produce in Sketch is a composite of the sketch drawings and inspirational UI designs that I reference during the discovery process. I determine the target market, the desired feelings the app should evoke while the user is engaged in those micro-moments, the proper information architecture on each screen, and I begin to craft the overall picture of how to manage application data well-before I write the first line of code. Together was no different.
Hi-Fidelity Mockup in Sketch
Prototype in Adobe Experience Design (XD)
The Build Phase
This is where the rubber meets the road. I chose to work with Firebase as the backend for this application. I intend to build Together targeted for both iOS and Android platforms, so utilizing Firebase as a singular cross platform backend was a no-brainer. With Firebase, I can easily integrate Firebase Authentication (that pesky process where a user can login and protect their information), Firebase Storage (a nice place to store images and other media for use inside the app), and Firebase Live Database to handle the data required for the application to do what it was intended to do. I also already had experience with GoogleMaps and integrating Google Services into Android applications, so this time, I thought I would give MapBox a try. It is a 3rd party SDK that makes turn-by-turn navigation highly customizable and is a competitor to GoogleMaps.
For the initial build phase, I only had three weeks. The idea is that for the Android Project Class, an Alpha version would either be completely designed and built, or pretty darn close. So, in short, I tasked myself with recreating AirBnB with a religious twist all in under a month. Yeah… let’s see how far I got in those three weeks!
Total build time for this week was about 39 hours. My main focus for week one was to get the Account Creation portion down. This would allow for the creation of multiple test users within the application, create user authentication tests, and make sure that application data maintained integrity. I also had the goal of getting the basic implementation for the MapKit map up and running.
Total development time for week two was about 43 hours. Week two was the workhorse of the development cycle. I had the goal of getting the Settings / User Preferences screens completed, the LocationDetails screen completed, get users to be able to see all of the reviews of a given location and also leave a review, as well as to display home groups on the map with dynamic data. I also wanted to get image data to be cached on the device in Protected Storage so that the application would conserve on download data usage and have a faster image render on various screens. I already knew that to get all of this complete in one week was laughable, but in an Academic environment, sometimes you need to shoot for the stars due to unrealistic deadlines. In a real-world scenario, an application build like this with one developer to complete in one month is a tall order.
User Preferences and Image Caching
Total build time for the final week was 46 hours. Most of the time for the final week was spent in handling home group information within the database, creating the information from the user’s settings screen for their hosted home group, displaying that home group dynamically in the map, and finally displaying all of the dynamic information in the Home Group Details screen. Within that timeframe, I also had to refactor my code in several locations to simplify it to become more manageable and to follow the DRY principle – Do not Repeat Yourself. I also needed to get notifications to work in the application to alert the host of each home group when a new user indicates they wish to attend. This proved to be a small challenge since Android API 26 added some “improvements” that required some unexpected research, tests, and implementation. I also had to include some way for the home group host to be able to verify that a user had actually attended the group prior to leaving their review.
Map Feedback & Address Search
Home Group Details Screen
Lessons Learned From a 3-Week Build
There is a saying that has stuck with me ever since the first time I heard it:
“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” – Abraham Lincoln
In this project class, I really had one week to choose what application I would build, design the site map, develop the Information Architecture, make UX decisions, design a high-fidelity mock up, and prototype it. The compressed timeline resulted in several iterations of code refactoring midway through the development process. In reality, the Discovery and Prototyping phases should encompass the better part of two weeks at a minimum. This would allow for better code architecture and data model management to be developed on paper well before the first line of code is written. Incidentally, every member in the project class felt the same way. It was valuable to see how productive and how much I was able to complete in my project plan. In the end, I feel that this app deserves its time in the spot light. Therefore, development will continue and Version 1.0 will go forward. Stay tuned for updates.