In the first part, I have brought back to your mind some points to evaluate UI specifications (avoid back and forth with designers after the development beginning).
In this part, I go further by listing the recurring problems and propose a check list to evaluate the exhaustiveness of a specification (correspond to the definition of ready with Scrum).
The recurring problems
I distinguish 4 groups of problem : knowledge of the Android platform, lack of global coherence, incomplete specification and bad communication.
By pragmatism, I list these problems by inspection order.
The UI specifications
- the specification does not respect the application charter, there is no global coherence
- the specification does not respect the Android guidelines (style, structure, components, spaces, dimensions, etc.)
- the specification does not make the most of the platform (eg : multi-pane, multi-window, etc.)
- the specification is not suited for small or large screens (resolution * density)
- the specification does not indicate which set of dimension it targets
- the specification concerns only the main flow, the secondary flows are missing (subscreens, dialogs, messages (warning, error))
- the specification does not give all details : dimensions (margin, padding, font, font size, block size), animation specifications
- the unit used is misleading (not known, not the Android working one)
The multimedia material
- the material received does not correspond to the specification
- the material is not optimized (useless file, weight, performance) considering what is possible to do by programming (eg : gradient, splash screen including its background vs only the logo centered (useless redraw of the background))
- the material delivered is too big or the quality is not sufficient
- the graphic material is not delivered in the different Android densities
- the material is not directly usable (Android invalid name, density directories not given, gap of padding / framing between graphic material of same class, etc.)
Others
- the structuring work made on a specification is called into question a short time afterwards while the risk of evolution was known
- the specification is not achievable in a reasonable time
- for a screen evolution, the specification is not up-to-date (passed evolutions / compromises not taken into account)
Ready or not
These problems listed, we have to address them one by one to determine appropriated checks. For that, I propose a check list based on the Scrum Definition of Ready model.
Short definition : Definition of Ready means that stories must be immediately actionable.
Warning : this list is a proposition and may be too / not enough detailed depending on your work context, I recommend you to prioritize and begin short then improve progressively.
Check-list for a Ready specification :
The UI specifications
- the specification respects the app charter if existing, there is a global coherence
- the specification respects the Android guidelines and take full advantage of the platform, if not : the choice are justified
- the specification covers the min and max dimensions -> the device covering has been defined ahead : min and max in dp (see 1st part)
- the specification defines the main flow and secondary flows (subscreens, dialogs, messages (warning, error), etc.)
- the specification gives all the details : dimensions (margin, padding, font, font size, block size), animation specification
- the unit used is the Android working unit (dp for spaces and dimensions, em for inter-lettering, sp or dp for a font, etc.)
The multimedia material
- the material corresponds to the specification
-
there is no material easy to reproduce by programming in the delivery : * simple shapes * monochrome images displayed in the app under different colors (eg icon) * images easily obtained by simple transformations of another one (1 only loading arrow image rotated repeatedly) * images with useless spaces (reproducible for part with a 9-patch file)
- the material is optimized (appropriated dimensions considering the usage, good quality / weight compromise considering the usage, optimal format with no different in quality (compromise weight / loading time))(1)
- the images are delivered in the different Android density formats : (ldpi), mdpi, hdpi, xhdpi, xxhdpi et xxxhdpi
- the material delivered is directly usable (Android-valid name (no space or upper case), density directories supplied, no external margin / framing gaps between images of a same class (eg : drawer icons, etc.))
- the volatility of the specification is indicated (or indicated in the feature description) : stable, will change soon, etc.
Others
- the specification is realizable in a reasonable time (eg complex animation)
- a developer review has been done (Android guidelines, feasibility, …)
- for a screen update, the gaps between the past specified and the really developed have been reviewed
(1) : for small images : webp > png if minSdk > 18, svg (limited support), font icons
Automate
To ease the acquisition of these work habits, some tool ideas :
- materialization of the step in the functional and the technical flow (make it a must-do)
- a printed file for the definition of ready
- an application charter
- an application charter in the “Cheat Sheet” format
- an Android guidelines “Cheat Sheet”
- a renaming script
- a validation script for the multimedia material : weight, dimension, format (eg depending on the file type identified by its prefix : eg an icon ic_x must measure 20x20 and be to the webp format)
- the watch by the designer of the Android platform updates
In this article, I have reminded you the recurring problems related to the UI specifications.
Point by point, I have proposed checks to set up to resolve them, finally and to ease the process, tools to automate them.
Android Developer at jacquesgiraudel.com