An interesting discussion on UI layout came up the other day regarding when / where / how it was appropriate for business rules to surface to the User Interface . The topic of the discussion was based around the value of consistently and explicitly directing user attention to an entities state on a User interface versus omitting information to infer its meaning, where the inference (by way of omission) was extracted from a break to the repetition of the layout. Phew, a mouthful I know but bear with me for just a moment longer!
It would be helpful to the discussion at this point to display the UI in question and then pick it 
apart. I am showing only the relevant portion of the screen that was subject to the discussion, in this case the twenty four hour digital clock. Each line item in this dashboard contains a due time and indication as to the amount of days or months passed or to follow. The screen shot shows three line items where:
-
Is due in 10 days at 5:38 PM
-
Is due today at 5:26 PM
-
Is due in 10 days at 4:16 PM
Things to note: the ‘number of days indicator’ (below) 
and digital clock are both right aligned, placed in close proximity to each other and each element is repeated regardless of their values, establishing a unified consistent layout.
The Debate
To understate the debate better there is one feature of the underlying business logic that 
should be understood first; a high percentage of jobs are turned around in the same day, meaning the ‘number of days indicator’ will exhibit the value of “TODAY” at a high frequency.
One suggestion in the discussion was that given that the large percentage of due dates would evaluated as “TODAY” then it would make sense to omit it. The logic behind this is that most jobs get done “TODAY” making it almost a default value. Here (to the left) is what it would look like if we enacted the business logic on the layout of he user interface and looking at the result the converse arguments become clear:
-
It creates trapped whitespace.
-
It is less organised through loss of repetition.
-
It is less unified with the loss of proximity.
The other effect of removing the ‘number of days indicator’ is that users will have to be trained in the rule that the omission has a specific meaning. If most line items would show “TODAY” then its likely that the repetition of the text or trapped whitespace would make it possible to spot the exceptions, however the loss of organisation in the layout through the introduction of trapped whitespace makes it more difficult to discern, even with a ‘squint test’ where the user deliberately searches the screen for the items with an empty value in the ‘number of days indicator’.
In writing this post it also became clear that the upper case rendering of characters in the ‘number of days indicator’ needs to change with a view to making it less cluttered and achieving better contrast with the 24 hour clock.
All in all a very useful discussion where the debate continues testing the principles in place and highlights the need to retain some simple, subtle yet effective design choices that continue to be refactored through the iterations of the application.
I will be speaking at the September meeting of the alt.Net User group about Task Based user interfaces, their benefits and how explicitly modelled code can make the job easier, more manageable and lead to systems that leave the business in control. I will also discuss how this approach can leverage alternative patterns to MVVM and work hand in hand with messaging.
