Specifying user interfaces

Many blogs including this one rely on the WordPress software. In previous states of the present page you may have noticed a small WordPress bug, which I find interesting.

“Tags” are a nifty WordPress feature. When you post a message, you can specify one or more informative “tags”. The tags of all messages appear in the right sidebar, each with a smaller or bigger font size depending on the number of messages that specified it. You can click such a tag in the sidebar and get, on the left, a page containing all the associated messages.

Now assume that many posts use a particular tag; in our example it is “Design by Contract”, not unexpected for this blog. Assume further that the tag name is long. It is indeed in this case: 18 characters. As a side note, no problem would arise if I used normal spaces in the name, which would then appear on two or three lines; precisely to avoid this  I use HTML “non-breaking spaces”. This is probably not in the WordPress spirit, but any other long tag without spaces would create the same problem. That problem is a garbled display:


The long tag overflows the bluish browser area assigned to tags, producing an ugly effect. This behavior is hard to defend: either the tag should have been rejected as too long when the poster specified it or it should fit in its zone, whether by truncation or by applying a smaller font.

I quickly found a workaround, not nice but good enough: make sure that some short tag  (such as “Hoare”) appears much more often than the trouble-making tag. Since font size indicates the relative frequency of tags, the long one will be scaled down to a smaller font which fits.

Minor as it is, this WordPress glitch raises some general questions. First, is it really a bug? Assume, by a wild stretch of imagination, that a jury had to resolve this question; it could easily find an expert to answer positively, by stating that the behavior does not satisfy reasonable user expectations, and another who notes that it is not buggy behavior since it does not appear to violate any expressly stated property of the specification. (At least I did not find in the WordPress documentation any mention of either the display size of tags or a limit on tag length; if I missed it please indicate the reference.)

Is it a serious matter? Not in this particular example; uncomely Web display does not kill.   But the distinction between “small matter of esthetics” and software fault can be tenuous. We may note in particular that the possibility for large data to overflow its assigned area is a fundamental source of security risks; and even pure user interface issues can become life-threatening in the case of critical applications such as air-traffic control.

Our second putative expert is right, however: no behavior is buggy unless it contradicts a specification. Where will the spec be in such an example? There are three possibilities, each with its limitations.

The first solution is to expect that in a carefully developed system every such property will have to be specified. This is conceivable, but hard, and the question arises of how to make sure nothing has been forgotten. Past  some threshold of criticality and effort, the only specifications that count are formal; there is not that much literature on specifying user interfaces formally, since much of the work on formal specifications has understandably concentrated on issues thought to be more critical.

Because of the tediousness of specifying such general properties again and again for each case, it might be better  — this is the second solution — to specify them globally, for an entire system, or for the user interfaces of an entire class of systems. Like any serious effort at specification, if it is worth doing, it is worth doing formally.

In either of these approaches the question remains of how we know we have specified everything of interest. This question, specification completeness, is not as hopeless as most people think; I plan to write an entry about it sometime (hint:  bing for “guttag horning”). Still, it is hard to be sure you did not miss anything relevant. Remember this the next time formal methods advocates — who should know better — tell you that with their techniques there “no longer is a need to test”, or when you read about the latest OS kernel that is “guaranteed correct and secure”. However important formal methods and proofs are, they can only guarantee satisfaction of the properties that the specifier has considered and stated. To paraphrase someone [1], I would venture that

Proofs can only show the absence of envisaged bugs, never rule out the presence of unimagined ones.

This is one of the reasons why tests will always, regardless of the progress of proofs, remain an indispensable part of the software development landscape [2]. Whatever you have specified and proved, you will still want to run the system (or, for certain classes of embedded software, some simulation of it) and see the results for yourself.

What then if we do not explicitly specify the desired property (as we did in the two approaches considered so far) but testing or actual operation still reveals some behavior that is clearly unsatisfactory? On what basis do we complain to the software’s producer? A solution here, the third in our list, might be to rely on generally accepted standards of professional development. This is common in other kinds of engineering: if you commission someone to build you a house, the contract may not explicitly state that the roof should not fall on your head while you are asleep; when this happens, you will still sue and accuse the builder of malpractice. Such remedies can work for software too, but the rules are murkier because we have not accepted, or even just codified, a set of general professional practices that would cover such details as “no display of information should overflow its assigned area”.

Until then I will remember to use one short tag a lot.


[1] Edsger W. Dijksra, Notes on Structured Programming, in Dahl, Dijkstra, Hoare, Structured Programming, Academic Press, 1972.

[2]  See Tests And Proofs (TAP) conference series, since 2007. The next conference, program-chaired by Angelo Gargantini and Gordon Fraser, will take place in the week of the TOOLS Federated Conferences in Málaga, Spain, in the week of June 28, 2010.

VN:F [1.9.10_1130]
Rating: 5.8/10 (4 votes cast)
VN:F [1.9.10_1130]
Rating: +1 (from 3 votes)
Specifying user interfaces, 5.8 out of 10 based on 4 ratings
Be Sociable, Share!


  1. cipher1024 says:

    I think the same person you paraphrase would criticize your quote by saying that it is two very different concerns to build a program that meets a certain specification and to verify that, given such a program, that it is a pleasant one for somebody. I think the literature classifies the first as being the problem of correctness and the second as being the problem of validity.

    In other words, I would tend to believe that the unimagined bugs are simply a mismatch between the requirements and the specification and it gives an interesting new turn to role of test; when it comes to correctness, it seems alright to believe that the test won’t be the support for our confidence in our system but, in the case of validity, I dare to propose that, having no meaningful ground for proving, our confidence might be based on tests (including tests with an actual user).

    VN:F [1.9.10_1130]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.10_1130]
    Rating: 0 (from 0 votes)
  2. bmeyer says:

    Regarding terminology, I don’t think “validity” is the right term since it has other meanings in software engineering; let me seize on another of your terms and use “pleasantness” below.

    Regarding the substance of your comment: part of the point of the article is that the border between the two kinds (correctness and pleasantness) can be fuzzy. To use again the example of a text that fits in its zone, or not: imagine a 911-style emergency system for dispatching fire crews, which has a field for such messages as “Fire reported at [“. Assume that someone enters as something like “the intersection of A and B”. If A is a very long street name, B might not be displayed at all. This is a loss of essential information which could have dramatic consequences. So we have a property that seems to be one of pleasantness but actually turns out to have a critical effect on correctness.

    Clearly, most issues will classify themselves naturally into either correctness or pleasantness, but some are much less clear-cut.

    VN:F [1.9.10_1130]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.10_1130]
    Rating: 0 (from 0 votes)
  3. cipher1024 says:

    Coming back on terminology, I read mostly that the activities of “checking” that the software was OK was divided into validation and verification, the former being the activity of confronting the specification to the requirement, hence the name validity that I thought might be fitting as the property checked during that activity. On the other hand, I don’t think pleasantness captures it properly; it appears to me to have been much more useful for Dijkstra to dismiss the whole field as being too fluffy for him. I would rather use a much more neutral one like “fitness”: “does the software as specified fit the actual need?”

    So much for the terminology. I just wanted to make sure to remove the tone of “fitting the fancies of the user” that can come with pleasantness.

    As for your example, I’m not sure how we can decide between the classification into fitness or into correctness without having a glimpse at the specification. I would think that this would draw the bottom line. If the specification states “the complete information must be displayed or the commands must be present so that every piece of information can be displayed upon request”, this would we a programming error but specification less complete than that would have us drop in the realm of fitness errors. Would that make sense?

    VN:F [1.9.10_1130]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.10_1130]
    Rating: 0 (from 0 votes)

Leave a Reply

You must be logged in to post a comment.