DB Scavenger Hunt — Post-Mortem
With less than 2 months into a mobile app development class and less than a week in Flutter and Dart, my class was tasked with making an application for people to use at an open house in a little over a week; although, the total time given was less than 24 hours in total. A simple task of making a game where people look around for codes and enter them for points as a way to get the people to explore was given to us. Immediately, we staged out our time into planning, programming/producing, and publishing. These stages were then followed by marketing the app to people adventuring to the building.
Framework
The framework we used to program our mobile app was Flutter. This framework, as mentioned before, is based on Dart and was built by Google. We were told that this language would allow an app to be programmed once and complied to ios and android’s respective platforms. Through the assignment, I learned that Flutter was in many ways similar to Java and Javascript with which I already have knowledge of. It also, because of its base language, worked with the english_words package of Dart and allowed us to generate random words. In addition to all of this, Flutter provided simplistic handling of Widgets which allowed me to quickly integrate a list into a basic app screen (this I will touch upon later). The language allowed me to realize that all the knowledge I have of Java and Javascript were non-exclusive; however, my main language is Python which is worlds different than Flutter or Dart in terms of syntax. The syntax was not hard, but the focus on {} is vastly different than the focus on whitespace and colons. Aside from the differences between Python and Flutter, the language of Dart and the framework of Flutter was easy to pick up especially when utilizing the documentation online.
Planning
This was the entire first day (around an hour and a half) and involved various aspects of what was needed for the minimum viable product. The first step in our planning was deciding on a feature list. This went by fairly quick, although debates were held over some of the features; one of these features were particularly important: The codes. The code debate was between QR codes, alphanumeric codes (codes with numbers and letters), and numeric codes. I was rooting in favor of the numeric specifying that we could utilize the number keyboard on phones and it will allow simplicity. The QR code debate was staged similarly but we knew limitations of our knowledge and decided to stick with the others. The instructor held the debate that the alphanumeric was better for randomization of codes and to reduce possible guessing. The numeric side eventually was chosen to be used after the audience was accounted for as a factor.
The audience was probably the biggest factor in the entire project and was planned after our initial planning barring the code and UI (user interface) complexity, using up more of our limited time. The audience was based on who would be touring our building, which would be a bit of everyone from each age group from 5–100 years old. The wide audience had us settle on a stupidly simple UI. When planning in the future, the audience should be discussed first and foremost and be used as a way to focus the rest of the planning. After the audience discussion, a lot of the debates we had on the direction of the project got settled quickly by just remembering who had to use the program.
The planning included doing a wireframe of the application. The process was fairly simplistic and just involved layout the 3 or so pages we wanted to create with placeholder widgets. The planning process allowed me to learn about effective layout and planning when it came to specific aspects of the program. The application wireframe also allowed us to see the errors that would have been formed beforehand. The layout allowed us to visualize a general idea of what the ideal minimum viable product would have been and allowed us to see where, if given extra time, improvements could be made.
Overall, the planning process taught me the complex ins and outs of what seemed to be a simplistic process of design. The team debates over functionality could have been improved, however, it was a good way for us to discuss and decide on what would truly be the best choice for a vast audience. I learned the importance of teamwork and prep of projects during this period and will strive to improve and streamline this later down the road to improve the team efficiency and inclusion of opinion by getting the most important aspects laid out first.
Programming
The meat and bones of the project process, the period of creation. We first started by getting a Github repository setup. Utilizing Github’s project planning, we digitalized our planning then assigned tasks to each member. Not knowing our strengths and weaknesses yet made this part particular risky. We all assigned various tasks for one another by just calling what we wanted to do then eliminating. I called making the list page as I had the most input on that layout during planning. I set out to do this by using various documentation on listview.builder in Flutter. This proved fruitful as I was able to design a quick list built from an array which provided a number of items and the text needed. I then had to wait for a JSON file for the information to be provided and my instructor to get the database working. After the database and data were set up and usable, I then preceded to finish the list by simply replicating the array structure with the object properties for location.
After the list was created, I used git to commit the changes into a separate repository branch. Unfortunately, I accidentally committed them to the master repository. In the future, I will be just committing my branch then merging the changes in the local.
Publishing/Marketing
This was probably the most indirectly handled portion of the process on our classes part as our instructor set it up pretty much alone. He then showcased how it worked with the App Store Connect site. The app was meant to go on both the Google Play Store and the App Store but only got approval on time on the App Store.
The marketing of the app came in the form of a poster at the open house event placed on our classroom door. The poster netted us about 10 users, 8 of which remained active after the first few finds. The amount of users could have increased with a bit more promotion on both the school site and by adding a QR code on the poster which would link to the App Store page when scanned. In conclusion, the marketing and publishing design was simplistic but effective for our expected results.
The Take-Away
I learned many things throughout this process. The management side of design could have improved and simple debates could have been settled in advance. The programming side of the process required patience while I waited for both the database, through firebase, and the JSON. Flutter and Dart proved to be similar to other languages and being able to have easily readable and understandable docs made integrating features easier. Flutter did teach me how to use online resources. The publishing and marketing process did provide an overview of both the App Store and Google Play Store in terms of getting an application deployed. This also came with the requirements for the publishing such as images of icons. The entire process provided insight on how teamwork can be used to build an effective app.
In conclusion, the time we had to develop an app was an overall success in the feature set. Our intended design of a clean UI, clickable back buttons, an easy login, and displaying text with hints as an optional text (through buttons) did not come to fruition. Although many improvements can be made, learning the design, marketing/publishing, and programming processes of how an application is made were the core goals that I set and achieved. If we approached this program again, changing the user interface, sizing text, expanding the list to feature a wider amount of collectibles would be the first improvements I would seek.
