UX Policies — Part 1
The Problem
This is an article part of a series. For objectives, fundamentals, project structure, and articles summary, see Android::Simplified
Make sure to read article Single-Activity first!
Repository: https://gitlab.com/migueltt/simpleandroid
Modern Android apps follow the Single-Activity principle, which states that your single Activity contains all major components like Toolbar (top or bottom), Drawer, BottomSheetDialog, or even a BottomNavigationView, all of them surrounding a container (NavHostFragment) that hosts all Fragments within a navigation-graph.
This sounds quite simple, but things get complicated when defining different modules requiring specific UX patterns:
- Sequence of screens where Back-Gesture is required
- Screens requiring special Toolbar design
- Some screens should prevent Drawer (if supported) to be displayed
- Menu should change based on the screen context
- Toolbar navigation icon handling functionality between Back-Gesture and Expand-Drawer
- Floating-Action-Button available for certain screens only
- Toolbar title should be in sync with the screens
… plus more UX requirements that will force you to keep adding more code to handle such use-cases — and worst of all: sometimes bugs will appear when changes are applied to handle additional use-cases.
Depending on how fast you want to release your app to the market, you may need to make some sacrificies:
- Focus on Material UX patterns: most of Android UX toolbox provides ready-to-use components base on Material Components — with a few tweaks you can achieve most of the app-theming.
- Coordinate closely with UX Designers making sure they do understand that UI improvements will come later, and some behaviors (transitions, animations) will be included once you have the core functionality in place. Overall UX (that is, UI+behaviors) can be improved incrementally.
- Concentrate on those “must-have’s” — otherwise, you will never release your app.
- App theming is quite important, but be careful: defining new UX patterns is not as easy as it may seem. You’ll need to define how each UI-control will look like, plus all the different states when enabled, disabled, clicked, long-clicked, hover, ripple-like effects; transitions/animations when showing/hidding; etc…etc…
Most Android apps just apply different colors and rely on out-of-the-box Material Components — because time is money, and the sooner you release your app, the better for everyone — you can spend time later to incrementally make your app more “attractive” and closer to your final vision.
Ok, so now you convince everyone to use the core Material Components. So, What’s next? Well, you have to deliver what you promised:
- Efficient resource management (memory, cpu, local-storage)
- Core functionality for all modules (lists, pagination, API calls, caching mechanisms, offline support, all screen-sizes, different orientations, etc…)
- Handle some edge-cases where screens have different decorations (e.g. different toolbar, on different location)
- Seamless and consistent navigation across all screens
- Different notifications types where the user is redirected to a particular screen
- Deep-link support and web integration
- Analytics/metrics for each interaction (visited screens, UI events, …)
These are the challenges and problems that all Android projects have, and depending on the approach you take, you will be either…
- … successful, in the sense that your architecture provides structure, making the whole project simple and fun to work with in the years to come…
- Or,… struggling on every single step you take, adding more and more code just to make things work, which will add more complexity and few months later, you will end up having a “refactor sub-project” just to throw away all the spaghetti-code you wrote.
So, let’s dive in — check UX Policies Part 2: The UX Patterns
