1Fall 2004 6.831 UI Design and Implementation 1 2Fall 2004 6.831 UI Design and Implementation 2 Source: Interface Hall of ShameSybase PowerBuilder is an application development environment, not unlike Microsoft Visual Basic. Users of PowerBuilder construct forms by drawing controls (buttons, listboxes, graphical objects) on the form.Controls are selected by pulling down a menu from a toolbar icon. The menu actually looks like a palette, but it behaves like a pulldown menu in that once you make a selection, it disappears. After a control is selected, its icon is shown in the toolbar, and clicking on the form drops the control where you clicked.This design solves some interesting problems. Most of the time, the palette is hidden, saving screen real estate that the user might prefer to use to view the form being created. It makes it easy to drop multiple instances of the same kind of control on the form – an array of textboxes, for example, or several command buttons. The current palette mode is displayed even when the palette isn’t visible.But that last feature leads to the unfortunate problem with this design: the toolbar icon is different every time the user tries to find it! Even frequent PowerBuilder users report the disconcerting feeling of hunting around for this button. The button is always in the same place, but that doesn’t make it easy to find, since it’s located in the midst of other toolbar buttons. Shape is the best discriminator here, but the icon keeps changing shape.A task that probably seemed trivial to PowerBuilder’s developers – the user must know where that button was, since they’ve already used it! – turns out not to be trivial at all.3Fall 2004 6.831 UI Design and Implementation 3 ! Iterative Design Task AnalysisDesign ImplementEvaluateToday’s lecture concerns two topics.First, we’ll look at UI design from a very high-level, considering the shape of the process that we should use to build user interfaces. Iterative design is the current best-practice process for developing user interfaces. It’s a specialization of the spiral model described by Boehm for general software engineering. Your term project is structured as an iterative design.Second, we’ll look at how to get started with UI design – how to start the crank and get the UI design cycle going. Task analysis is the process by which you discover the characteristics of your target users and the tasks that they need to solve.4Fall 2004 6.831 UI Design and Implementation 4" #$ % & RequirementsDesignCodeIntegrationAcceptanceReleaseThe waterfall model was one of the earliest carefully-articulated design processes for software development. It models the design process as a sequence of stages. Each stage results in a concrete product – a requirements document, a design, a set of coded modules –that feeds into the next stage. Each stage also includes its own validation: the design is validated against the requirements, the code is validated (unit-tested) against the design, etc.The biggest improvement of the waterfall model over previous (chaotic) approaches to software development is the discipline it puts on developers to think first, and code second. Requirements and designs generally precede the first line of code.If you’ve taken 6.170 (or a similar software engineering course), you’ve experienced this process yourself. The lecturers handed you a set of requirements for the software you had to build --- e.g. the specification of GizmoBall or Antichess. (In the real world, identifying these requirements would be part of your job as software developers.) You were then expected to meet certain milestones for each stage of your project, and each milestone had a concrete product: (1) a design document; (2) code modules that implemented certain functionality; (3) an integrated system.5Fall 2004 6.831 UI Design and Implementation 5' (% & RequirementsDesignCodeIntegrationAcceptanceReleaseValidation is not always sufficient; sometimes problems are missed until the next stage. Trying to code the design may reveal flaws in the design – e.g., that it can’t be implemented in a way that meets the performance requirements. Trying to integrate may reveal bugs in the code that weren’t exposed by unit tests. So the waterfall model implicitly needs feedback between stages.The danger arises when a mistake in an early stage – such as a missing requirement – isn’t discovered until a very late stage – like acceptance testing. Mistakes like this can force costly rework of the intervening stages. (That box labeled “Code” may look small, but you know from experience that it isn’t!)6Fall 2004 6.831 UI Design and Implementation 6% & ) User interface design is risky So we re likely to get it wrong Users are not involved in validation until acceptance testing So we won t find out until the end UI flaws often cause changes in requirements and design So we have to throw away carefully-written and tested codeAlthough the waterfall model is useful for some kinds of software development, it’s very poorly suited to user interface development.First, UI development is inherently risky. UI design is hard for all the reasons we discussed in the previous lecture. (You are not the user; the user is always right, except when the user isn’t; users aren’t designers either.) We don’t (yet) have an easy way to predict how whether a UI design will succeed.Second, in the usual way that the waterfall model is applied, users appear in the process in only two places: requirements analysis and acceptance testing. Hopefully we asked the users what they needed at the beginning (requirements analysis), but then we code happily away and don’t check back with the users until we’re ready to present them with a finished system. So if we screwed up the design, the waterfall process won’t tell us until the end.Third, when UI problems
View Full Document
Unlocking...