User Interface Outside
User Interface OutsideRather than copy in, link to Jim Coplien's site
for this extract from my paper Social Issues and Software Architecture (CACM, Nov 1996).The point is, the UserInterface is not really part of the application. It is the first client of the application. Put the UI outside the application and your application will live a happier, less stressful life (and so will you).
--- AlistairCockburn
This is good advice, but sometimes, unfortunately, the UI is put off until the system (or application) design is done. This leads to situations where unexpected usage requirements are not supported by the application.
Consider a Load File routine in an application. There are a number of user interface issues that will affect how it is implemented. If the routine takes too long (maybe more than a couple of seconds) to complete, then that is a potential usability problem. Perhaps the interface should show load progress or allow the user to cancel the operation. In a single-threaded program, the application (including the user) is stuck in the Load File routine. There is no feedback and no chance to cancel.
A Load File routine in this case could provide methods or functions for periodic feedback calls, or the routine could be implemented to load incrementally (load one line per invocation).
An application with a high level of interactivity (especially a direct manipulation application) needs to consider how user manipulation will affect the program's API design.
You have to consider the impact of the user interface on the application's design.
-- ToddCoram
I think that you're both right. I tend to take a middle approach. Let me talk for a moment about the way our SmalltalkApprenticeProgram development process works. I always consider the "most likely" user interface as part of the design process -- I like using LowFidelityPrototypes as part of requirements gathering. I then use the paper prototypes to feed UseCaseGathering? and from then on consider the use cases to be the major driver in the process.
Once we've gone from use cases to CRC to UML I then like to prototype the system with NO user interface but using the use cases found using the LowFidelityPrototypes. We then build a test framework that acts on something very much like Alistair's "program driven" domain model.
From there on we then build a prototype UI to verify that things really interact the way we intended them to. Finally, we prototype the database and external system connections. I've called this "Building a hamburger from the meat out", but it really sounds more like Alistair's HexagonalArchitecture.
We encourage our apprentices to consider the result they've obtained to be either only the first iteration of a spiral cycle, or if it's a really complex domain, to consider it a true protoype and throw the thing away. However, they have gained enough knowledge about HOW to build applications in this way that even if they do throw it away they've got a much better understanding of how to go about it.
I don't disagree with anything I saw in Todd's append, it is not in conflict. All I ask is to be able to access all functionality from the Transcript Window or equivalent line interface. Also, if your UI is the first (second, in Kyle's case) client of your application, you will learn very fast about things like performance and feedback indicators. - AlistairCockburn
EditText of this page
(last edited July 20, 2014)
or FindPage with title or text search