In the first part, I have brought back to your mind some points to evaluate UI specifications ( with after the development beginning). avoid back and forth designers 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 with Scrum). definition of ready 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 , there is no application charter global coherence the specification does not respect the (style, structure, components, spaces, dimensions, etc.) Android guidelines the specification does not make the most of the platform (eg : multi-pane, multi-window, etc.) the specification is not suited for (resolution * density) small or large screens the specification does not indicate which set of dimension it targets the specification concerns only the , the are missing (subscreens, dialogs, messages (warning, error)) main flow secondary flows the specification does not give all : dimensions (margin, padding, font, font size, block size), animation specifications details the unit used is (not known, not the Android working one) misleading The multimedia material the material received does not correspond to the specification the material is not (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)) optimized the material delivered is too big or the is not sufficient quality the graphic material is not delivered in the different Android densities the material is not (Android invalid name, density directories not given, gap of padding / framing between graphic material of same class, etc.) directly usable Others the structuring work made on a specification is called into question a short time afterwards while the was known risk of evolution the specification is not achievable in a reasonable time for a screen evolution, the specification is not (passed evolutions / compromises not taken into account) up-to-date 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 model. Definition of Ready 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 the if existing, there is a global coherence respects app charter the specification respects the Android and take full advantage of the platform, if not : the choice are justified guidelines the specification covers the min and max dimensions -> the device has been : min and max in dp (see 1st part) covering defined ahead the specification defines the main flow and secondary flows (subscreens, dialogs, messages (warning, error), etc.) the specification gives all the : dimensions (margin, padding, font, font size, block size), animation specification details 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 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) reproduce by programming the material is (appropriated dimensions considering the usage, good quality / weight compromise considering the usage, optimal format with no different in quality (compromise weight / loading time))(1) optimized the images are delivered in the different Android density formats : (ldpi), mdpi, hdpi, xhdpi, xxhdpi et xxxhdpi the material delivered is directly (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.)) usable the volatility of the specification is (or indicated in the feature description) : stable, will change soon, etc. indicated Others the specification is realizable in a reasonable time (eg complex animation) a developer has been done (Android guidelines, feasibility, …) review 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 for the definition of ready printed file an application charter an application charter in the “ ” format Cheat Sheet 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 related to the UI specifications. recurring problems Point by point, I have proposed checks to set up to resolve them, finally and to , tools to automate them. ease the process Android Developer at jacquesgiraudel.com
