[Gllug] OT: Police Web Site

Walter Stanish walter.stanish at saffrondigital.com
Thu Feb 3 18:02:39 UTC 2011


>> >I would not regard entering a postcode in lower case as incorrect,
>> It still _is_ incorrect. Postcodes are always used in upper case; you
>> would never consider writing one in lower case on an envelope.

>From the point of view of pragmatism, this is ridiculous.

One could also exclaim:
 "Postcodes are never displayed in cursive script!"
 "Every UK customer has a postcode!"
 "Not knowing your postcode is an edge case that is not worth
  considering in our interface design!"
... etc.

Each would be wrong.

These are a point where programmer / reality disconnect happens.

The idea of software is to FACILITATE data entry, not to reject it.

If the user wants lowercase, let them lowercase.
If the designer wants cursive, give them cursive!
If the customer is between houses, living in a hotel, only the UK
for a day, or otherwise without an address... then so be it!

The summary is that, at least when dealing with users, rigid
rule-following (especially when accompanied with chest-beating
and assertions about correctness) rarely helps anyone.

Getting the job done is more important.

BONUS SECTION - FUN INTERFACE DESIGN FACTS 2011:
 - More and more people travel internationally, so do not
   expect only local customers!  Further, these people
   may be a higher-spending demographic.
 - People do not always wish to pay by credit card,
   and some relatively famous international UI consultants
   have started pointing at mobile payment as a good
   alternative, having seen it take off with iTunes and in
   parts of Africa. (Personally I am dubious on this
   going anywhere this year, despite the proliferation
   of industry mobile payments buzz.)
 - Some people may wish to pay by bitcoin! ;)
 - Some people do not have a credit card
 - Some people do not have an address
 - Some people's address may differ from that of their
   credit card
 - International telephone numbers should be input
   after country of origin assumptions / corrections
   in order to save the user having to pre-select an
   international prefix
 - Whinging when spaces, dashes and brackets
   appear in telephone numbers is a BAD IDEA.
   Interfaces should 'just fix it', perhaps adding a
   temporary visible explanation using javascript.
   Interfaces should not issue popups. Eww.
 - Does your interface support IPv6 email addresses?
    (user at 1:2:3:4:5:6:7:8)
 - Does your mailer support IPv6 email addreses?
 - Does your DNS server support IPv6 resolution?
 - Have you tested your dodgy javascript on mobile
   browsers?  Prominent sites (eg: Eurostar booking)
   fail with subtle bugs on some mobile platforms.
   (That bug cost me 100EUR a month ago!)

Pragmatism ... ahh ... all of the above are reasons
why input interfaces should rarely be done manually.
Anyone who is still pumping out web interfaces
manually needs to look long and hard at the amount
of preventable bugs they are creating, the tedium of
pushing out bug fixes or new features to the larger
number of sites they are building, and thence look at
flexible code generation as an ally in working smarter.
This does not have to mean 'changing frameworks'
and throwing out an entire existing codebase,
but simply recognising properly what is duplicated
between pages, codebases, problem spaces and
analysing how to prevent that wasted effort without
sacrificing maintainability.  (Hint: write a code
generator, it won't take you long!)

Enough pontification.... +1 IPv6 post then back to
research.

- Walter
--
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list