Developer — Ready UI specifications (part 2)

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