Java™ Application Development on Linux - Dator

11.7 Documenting, Prototyping, and Stakeholder Buy-In27511.7.3 PrototypingPrototyping can be an effective way to carry on the discussion of both requirementsand user interface design. Given only a hypothetical or abstract descriptionof some software, it can be very difficult for people to imagine what theimplications of its use will be. A simple prototype can immediately bring thediscussion down to the concrete; people can point at things and say “I like this”and “I don’t like that” and “How would I do so-and-so” and then see whetheror not it would work. Sometimes, ideas that sound great on paper turn out tobe pretty poor ideas when realized. Prototypes can help you discover thatquickly and easily.One very useful but inexpensive prototyping mechanism can beHTML—that is, creating Web pages. Simple static HTML can be fast andcheap to build, but can begin to approximate what the user interaction willlook like—especially for, but not only for, Web-based solutions. It may not bean exact replica of the final product, but for a first step it can really get thediscussion moving.If the UI is too complex for a Web page mock-up, you can still use HTMLfor prototyping by getting images (screenshots) of what you want your finalsolution to look like and then making these images clickable on Web pages, tosimulate some simple user interaction with hyperlinked image sequences.The idea is to get something “tangible” in front of people as soon as possible,to further the discussion in a way that written descriptions never can.(“A picture is worth a thousand words.”)Once you’ve built a prototype, shop it around. Hold informal meetingswhere you demonstrate the basic functions to stakeholders. We recommend,as much as possible, meeting with one group of stakeholders at a time. Thatway you can keep your conversations focused. If you have two different stakeholdergroups represented and their expertise and interests are wildly different,you’ll be boring ½ the participants all the time. Even if their expertise is similar,you may have groups with competing or conflicting requirements. While youneed to understand such conflicting requirements and eventually come to somedetente, this meeting is not the best venue for settling those issues; it wouldmore likely simply scuttle your meeting and void any value from it.that Dale Carnegie is as important to the software designer as Yourden or Booch. Your usersneed to be your friends if you want to succeed.