Checklist: Considerations Before Publishing an App
Creating an app is addicting. Brainstorming the idea with friends is invigorating. Crafting a mood board, the UI, the UX is fun. Architecting it to work cross-platform is a welcome challenge. Inventing solutions to tackle problems is satisfying. All of this is exciting until the project reaches the 80% completion mark. There’s an invisible wall once most projects reach 80% completion. All the fun, creative, exciting efforts are completed. What's left are the tedious, little details that will make or break the project. If the Pareto Principle is any indication, the most important things are the 20%. This article will focus on the 20% an app must get right prior to its release.
Once an app reaches the 80/20 critical mark, attention to app details start to diminish. The worst time to stop paying attention to details is when the app is ‘almost done’. If an app is 80% done, it means the main feature sets, architecture, and UI/UX requirements are set in stone. What’s left are all the minutiae such as, “What happens if the user decides to ‘Not Allow’ the GPS radio?” or “Why can the user hit this button multiple times while it’s loading the next page?”. Getting the 20%, the app bugs and UI/UX expectations, right is vital.
The concept of checklists is well known in mission critical industries like airlines, and medical, emergency situations. Even weddings and stage productions use checklists to insure all required tasks are completed before the curtain goes up or the bride walks down the aisle. However, with software these checklists have infrequently been utilized, and less often institutionalized within software organizations. Given the pace of mobile app development, the number of required updates and the complexity of multi-platform development, this is a perfect time to implement a checklist-based approach to the final 20% of mobile app design.
Sometimes the 80% mark means most of the ‘major’ bugs are fixed. A major bug doesn’t kill an app. Lots of little bugs that nag at the user, that cause frustration, kill apps. They are the kind of bugs that exist in conversations every day, the ones where people say, “Yeh, that app is ‘ok’”. Not great, just ‘ok’." The audience isn’t sophisticated enough to know why the little bugs are happening and they certainly are not willing to overlook them.
Bugs checklist prior to submission
- The app does not freeze during any main/secondary function or screen
- All remote service calls have proper error handling and gracefully fail
- No hard coded data where dynamic data should be used
- The app knows how to handle GPS operations when the GPS is turned off
- The app knows how to handle notification operations when notifications are turned off
- The knows how to handle network activity issues (offline / online and slow performance)
- Development console logging is off
- Closing (pause) and returning (resume) an app run their processes without interfering with app logic
UI / UX
Good UI / UX sells. IBM states, “Every dollar invested in ease of use returns $10 to $100”. That’s an ROI of 1,000 - 10,000%. Likewise, the potential for project failure is magnified when the UI / UX is not established well. UX issues are one of the top reasons projects fail. Even when the UI /UX is defined, implementation of that UI / UX, the 20% mark, many times is not implemented properly. Stated previously, the audience might not be sophisticated enough to point out an app’s UI / UX shortcomings but they can say something like, “Ah, it’s ok, I guess.” Music is a good analogy: A pianist might play every note of Rachmaninoff’s “Piano Concerto No. 3” with only minor timing issues. His audience might not be sophisticated enough to say, “It was good but in the 10th measure his timing was off by a 16th of a beat”. They will, however, say, “It was alright. I guess that was really hard”. Users expect an app to be flawless. Don’t let any minor UI / UX issue go undone.
UI / UX checklist prior to submission
- The app is matches the UI / UX requirements and the UI / UX engineer signs off on expected behavior.
- The app indicates a long operation is happening to the the user (via something like a loading indicator).
- The app properly handles multiple clicks on UI objects when only one at a time is expected (e.g. tapping a button 10 times should not open up 10 new screens).
- Animation is consistent across the entire app both in speed duration and type of animations.
Like UI / UX, successfully implementing a design will make even an average app stand out. Care should be taken to ensure light sources and shadows match, images are sliced and used in the way prescribed by a design document. Especially important for Android, graphics should be responsive so they are consistent across multiple screen resolutions and densities.
Design checklist prior to submission
- All images are resized and compressed correctly
- Images are available for all target platforms
- The implementation of the design matches the designer’s goals. The app designer signed off on the design implementation.
- Images are not distorted, blurred, or mis-aligned
- The design implementation is responsive to the target screen sizes and densities
- Text sizes and fonts are appropriately used. Text is not blurry.
From a technical level, the server-side of an app is one of the biggest reasons an app fails. Likewise, app projects can be delayed almost indefinitely while waiting on the server side of things to be set up. Server availability, scalability, and performance can cause users to wait too long for their data to render on device. This can be perceived as a slow app. Improper or malformed data feeds can cause an app to ingest excess data it should not be processing. This causes performance clogs on user devices while they have to process data that should be handled on the server. If the back end services are poorly made the app will feel poorly made, no matter how pretty or usable the app.
Backend service checklist prior to submission
- Web services have been stress tested with many concurrent user connections
- Server response times meet acceptable requirements for the app
- HTML tags are stripped out of the data feeds when not necessary
- The server is sending the correct response data for each remote call
- The server is not sending anything to the user that the user is not allowed to access (e.g. Access control)
- The server returns the correct error messages
End User License Agreement (EULA) and Terms of Service (ToS)
An oft overlooked detail, an app’s EULA / ToS can limit a business’s use of data mined from the app. Apple's standard EULA is a good base EULA but it limits the use of the data mined from the app. A poorly constructed EULA / ToS can cause unnecessary harm to the product. The recent changes to Path’s ToS are due to unnecessary damage received from a previous, unclear ToS. From the start, it’s important to have a well formed EULA / ToS that meets your business requirements and doesn't put you in a corner.
EULA / ToS Checklist
- The EULA / ToS clearly states what data and information the app collects
- The user’s rights and limitations to their data and other data in the app is clearly defined
- The EULA / ToS indicates how the data and information collected may be used
There are a few more things that could be added to this baseline list (e.g. The app description, icon, etc. in their respective marketplaces). Whatever checklist is used, the important thing is attention to the little things, the 20% that take an app from good to amazing.
Checklists don't have to be long and you can add to them as you continue to institute best practices. Additionally, once the framework of a checklist is in place, the usage of it becomes automatic and repeatable. There is a danger of stagnation of these checklists, especially because the functionality of these apps are so dynamic. In addition to committing to following the checklist, software orginizations must also commit to updating those checklists on a regular basis, say every 3-6 months.
Rick Blalock is an Architect in Appcelerator's Professional Services Group.