Archive for October 28th, 2008

• Designing for User Performance

  Date: 2008.10.28 | Category: Conferences, Design Excellence | Response: 0

  Stopped by to listen to Larry Constantine today to hear what he is thinking about how to best design applications.  These are a number of the key points I picked up from his talk:

  • Prioritize design efforts around tasks which have the most frequency and greatest importance.
  • Organize designs around the fewest number of transitions for key tasks
  • Keep the screen context consistent when you do transition.
  • Use proximal and visual context to group related and associated elements.
  • Provide context when offering corrections and support editing-in-place when the user makes an error.
  • Edit-in-place is the best way to train the user on the correct data entry.
  • Redundancy or alternate paths are in general a good thing; allowing actions to be reversible is better.
  • For user tasks that are not reversible we need to carefully consider their design. (ed. duh!)
  • Filter non-numeric characters from number only fields.
  • Don’t make the user a subroutine of the program, automatically update known information if the user gave it to you.
  • If there is a natural\alternative way of entering data in the real world, the machine should be flexible enough to accept it.
  • If the error is obvious and detectable by the program, why tell the user about it?
  • Propagate errors, and their cause, to the highest level that can handle them.
  • If there is an error in the program, tell people where the error is and how to fix it.
  • Don’t ever give an nodal\dialogue\confirmation box to a user unless the message is relevant, recognizable AND the user can intelligently respond to the message; otherwise just “eat” the message.

• SOA Measures for Success

  Date: 2008.10.28 | Category: Conferences, Measures | Response: 0

  One of the sessions I visited today was about what are the correct measurements to determine if your SOA initiative was successful.  One of the most interesting statistic from the speaker was this continuum of cyclometric complexity (CC):

      CC < 10: "simple" code
      10 > CC < 20: "moderately" complex code
      20 > CC < 50: "severely" complex code
      CC > 50: "untestable"

  He based that experience on a simple equation of:

      # of test cases = 2CC-1

  Which suggests code with a CC as low as 15 will have 16,384 test cases!  Ouch!  That has got to hurt considering functional testing only gets you about 20% of test coverage.

  I think another valuable observation provided was software reliability is inversely related to CC, the higher the CC, the less reliable the software.  The most eye-popping statistic from the talk was the speaker’s observation that if you can refactor your code to have a CC in the 10-15 range, an organization would reduce their maintenance costs by 2 to 5 times!

  Finally, these are the ten measures from the talk that I thought I would share with all of you and how one should optimize the measures.  The words in the parenthesis are what level the measures speak to.

  1. Dollars per service -> higher is better (corporate)
  2. Service vitality index (new service revenue/total revenue) -> ~10%-20% is good (corporate)
  3. Number of new services/total services -> higher % is better(management)
  4. Mean time to service deployment -> lower t is better (management)
  5. Mean time to service charge -> lower t is better (management)
  6. Service availability -> higher % is better (management)
  7. Service reuse -> higher % is better (project)
  8. Cost of not using/stopping the service -> lower $ is better (project)
  9. Service complexity -> lower CC is better (service)
  10. Service QA confidence -> higher % is better (service)