Best Practices for Prototyping in Software Development - 4

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article is the fourth in series of articles on Prototyping in Software Development.

Who should be involved, how far you should go and when do you have to do Prototyping in a Software Development Project?

Often Prototyping in Software Development Projects will be done without planning and without involving the relevant stakeholders. This will lead to wrong expectations, initial budget overruns and customer satisfaction issues.

1. Who is Involved?
Prototyping can be done informally by anyone, regardless of their background or role in the project. It’s easy to make a simple but effective prototype by taking a bitmap from Adobe Photoshop, putting it into the Microsoft FrontPage Web site creation and management tool, and adding active buttons or links. These lightweight prototypes only go so far, and can become unwieldy for complex interactions.

For more formal prototypes by larger teams, a developer or project manager will often collaborate with a designer and a usability engineer. Together they’ll generate ideas, build a prototype that represents the best ideas, and then go into the lab to see how effective it is in solving user problems. Developers might get involved if they can spare the time, or if their technical expertise is needed. Often the designer or project manager will do most of the scripting or coding to build the prototype.

Treat this phase with importance, just like any other phase in SDLC and try identifying and involving the relevant stakeholders at all stages in the prototyping stage.

2. When Do You Build a Prototype?
Depending on the scope of the prototype and the level of detail required, prototypes can be built at any time during the project. Most often they are created early in the project, during the planning and specification phase, before developers write any production code. That’s when the need for exploration is greatest, and when the time investment needed is most viable. If developers instead of program managers or designers are prototyping, scheduling time becomes even more important because you need to make sure the work invested in the prototype is accounted for in the development schedule. Planning for any UI release should include some level of prototyping.

Late in a project, smaller prototypes can help resolve tough design and technical issues. A quick HTML mock-up of how a dialog box or Web page should behave can help answer a developer’s question or give other teammates a feel for what the desired experience should be. In some cases, a strong program manager or designer can implement the behavior in Microsoft JScript development software and approximate much of the programming logic that developers will need to think through.

The time it takes to create a prototype can vary tremendously, depending on the scope and precision of what the end result needs to look like. An informal prototype could mean a few hours of work by one person; a more organized effort can involve weeks of effort by an entire team.

3. How Far Should You Go?
In your prototype, build only as much of the design as you need. It’s okay to have buttons that don’t work, or text that never updates. As long as you can experience the interactions you want to explore, it’s fine to use smoke and mirrors for the rest.

Here are a few reasons why you should focus your efforts carefully:

3.1 Cost of building the prototype.
You want to minimize the cost involved in building the prototype. The challenge with prototyping is recognizing the minimal investment needed to effectively answer your questions about the design. This is where usability studies are critical, because they clearly identify the parts of your UI that need the most work. Even without usability studies, you should clearly define what user problems you’re trying to solve, or what tasks you’re trying to improve, with the design in your prototype.

3.2 Limited lifetime.
Prototypes should have clearly defined lifetimes. Is the end goal a presentation at a team meeting? An executive review meeting? A spec review? A usability study? Convincing yourself, with your devil’s advocate hat on, that the design solves a user problem? Once the needs for these specific objectives are met, the prototype should be set aside. The basic mindset is that the code or bitmaps generated in a prototype will be left behind in most of the cases. There might be exceptions where code or visuals live on in the product, but the expectation should be that this won’t be the case.

3.3 Risk of overwhelming the team and setting wrong expectations.
Showing prototypes to developers and teammates can be tricky. An overly complex or elaborate prototype, with amazing visuals and animation, can overwhelm people. You should always have a sense for how far to go and how much of what you’re creating in the prototype you want to be taken seriously.  This is important because to build this amazing visuals with full functionality will be a challenge and will take more effort.

So the general practice that is preferable to follow is to involve people who can later be part of the design and development team, try writing code and scripts during prototype phase in a language that can be easily merged and scaled to the actual language and projects that you use as part of the subsequent phases in your projects.

Best Practices for Prototyping in Software Development - 3

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article is the third in series of articles on Prototyping in Software Development.

Tips and Techniques in User Interface Prototyping during Software Development

The following tips and techniques should prove valuable during the prototyping phase of your SDLC (Software Development Life cycle), these can also be used as guidelines, best processes and practices for User Interface Development:

Consistency: Most important thing you can possibly do is ensure your user interface works consistently. If you can double-click on items in one list and have something happen, then you should be able to double-click on items in any other list and have the same sort of thing happen. Put your buttons in consistent places on all your windows, use the same wording in labels and messages, and use a consistent color scheme throughout. Consistency in your user interface enables your users to build an accurate mental model of the way it works, and accurate mental models lead to lower training and support costs.

Set standards and stick to them: The only way you can ensure consistency within your application is to set user interface design standards, and then stick to them. Preferably since Prototyping is done in an Agile manner, you should follow Agile Modeling Standards in all aspects of software development, including user interface design.

Be prepared to hold the line: When you are developing the user interface for your system you will discover that your stakeholders often have some unusual ideas as to how the user interface should be developed. You should definitely listen to these ideas but you also need to make your stakeholders aware of your corporate UI standards and the need to conform to them.

Explain the rules: Your end users and business users need to know how to work with the application you built for them. When an application works consistently, it means you only have to explain the rules once. This is a lot easier than explaining in detail exactly how to use each feature in an application step-by-step.

Screen Navigation:

Navigation between major user interface items is important. If it is difficult to get from one screen to another, then your users will quickly become frustrated and give up. When the flow between screens matches the flow of the work the user is trying to accomplish, then your application will make sense to your users. Because different users work in different ways, your system needs to be flexible enough to support their various approaches. User interface-flow diagrams should optionally be developed to further your understanding of the flow of your user interface.

Navigation within a screen is important. In Western societies, people read left to right and top to bottom. Because people are used to this, should you design screens that are also organized left to right and top to bottom when designing a user interface for people from this culture? You want to organize navigation between widgets on your screen in a manner users will find familiar to them.

Word your messages and labels effectively: The text you display on your screens is a primary source of information for your users. If your text is worded poorly, then your interface will be perceived poorly by your users. Using full words and sentences, as opposed to abbreviations and codes, makes your text easier to understand. Your messages should be worded positively, imply that the user is in control, and provide insight into how to use the application properly. For example, which message do you find more appealing “You have input the wrong information” or “An account number should be eight digits in length.”

Furthermore, your messages should be worded consistently and displayed in a consistent place on the screen. Although the messages “The person’s first name must be input” and “An account number should be input” are separately worded well, together they are inconsistent. In light of the first message, a better wording of the second message would be “The account number must be input” to make the two messages consistent.

Understand the UI widgets: You should use the right widget for the right task, helping to increase the consistency in your application and probably making it easier to build the application in the first place. The only way you can learn how to use widgets properly is to read and understand the user-interface standards and guidelines your organization has adopted.

Look at other applications with a grain of salt. Unless you know another application has been verified to follow the user interface-standards and guidelines of your organization, don’t assume the application is doing things right. Although looking at the work of others to get ideas is always a good idea, until you know how to distinguish between good user interface design and bad user interface design, you must be careful. Too many developers make the mistake of imitating the user interface of poorly designed software.

Use color and styles appropriately: Color and styles should be used sparingly in your applications and, if you do use it, you must also use a secondary indicator. The problem is that some of your users may be color blind and if you are using color to highlight something on a screen, then you need to do something else to make it stand out if you want these people to notice it. You also want to use colors in your application consistently, so you have a common look and feel throughout your application.

Align fields effectively: When a screen has more than one editing field, you want to organize the fields in a way that is both visually appealing and efficient. I have always found the best way to do so is to left-justify edit fields: in other words, make the left-hand side of each edit field line up in a straight line, one over the other. The corresponding labels should be right-justified and placed immediately beside the field. This is a clean and efficient way to organize the fields on a screen.

Expect your users to make mistakes: How many times have you accidentally deleted some text in one of your files or in the file itself? Were you able to recover from these mistakes or were you forced to redo hours, or even days, of work? The reality is that to err is human, so you should design your user interface to recover from mistakes made by your users.

Justify data appropriately. For columns of data, common practice is to right-justify integers, decimal align floating-point numbers, and to left-justify strings.

Your design should be intuit able: In other words, if your users don’t know how to use your software, they should be able to determine how to use it by making educated guesses. Even when the guesses are wrong, your system should provide reasonable results from which your users can readily understand and ideally learn.

Don’t create busy user interfaces: Crowded screens are difficult to understand and, hence, are difficult to use. Group things effectively. Items that are logically connected should be grouped together on the screen to communicate they are connected, whereas items that have nothing to do with each other should be separated. You can use white space between collections of items to group them and/or you can put boxes around them to accomplish the same thing.

Take an evolutionary approach. Techniques such as user interface prototyping and Agile Model Driven Development (AMDD) are critical to your success as a UI developer.

Best Practices for Prototyping in Software Development - 2

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article is the second in series of articles on Prototyping in Software Development.

Tools and Technologies that can be used in Usability Engineering, prototyping during Software Development

There are several different tools and technologies you can use for creating prototypes, each of which has its advantages and disadvantages. Consider the type of design work you’re trying to prototype and the goals of your prototyping effort as you decide which tool or technology is right for you.

Paper - For usability studies or quick reviews, paper is often the fastest way to prototype a design idea. Using Photoshop, mspaint, or any tool you are comfortable with, produce screens that express the design, and print them out on paper. If you make enough screens, you can simulate walkthroughs, allowing test users to make choices and experience the design. However, for prototypes of moderate complexity, generating paper prototypes can be cumbersome. Highly interactive things like games or chat rooms can not be simulated well on paper. Also, the more elaborate the tasks, the more pages you might need to have handy.

Microsoft .NET: This is the fastest technology for creating Windows-style and Web based UI prototypes. The Web browser object makes it easy to integrate HTML UI with your standard Windows-style components. While it’s true that an experienced C/C++ developer might be able to generate UI faster in C/C++, this creates the temptation to reuse code from the UI prototype in your production code. It takes discipline to recognize that the goals of a quick and dirty UI prototype are highly divergent from high-quality engineering. Make sure you know what kind of code you’re writing, and that your team or manager understands what will be discarded.

Macromedia Director or Flash: This is one of the most popular UI prototyping tools among designers. It is most useful for multimedia or non-standard GUI designs, or for prototypes that require significant animation. It’s high flexibility makes it cumbersome for Windows-style UI compared to Visual Basic. However, a proficient Director user can generate Windows or Web UI without difficultly.

HTML: Dream weaver, FrontPage and other HTML editors allow for fast creation of simple prototypes. The latest technologies based on LAMP tools can also be used for faster turnaround times during the prototyping phase. To express an idea, you can often create bitmaps that illustrate a sequence of user interaction, and place them into FrontPage. Then you can create link areas to connect the pages, and simulate how you can interact with the design. Java Script and DHTML take things to another level, allowing for very sophisticated logic and interaction. If you are using HTML to prototype your Web site, the warning just described for C/C++ applies here as well don’t fall into the trap of confusing quick prototype code with production-quality engineering.

Ajax - This is the latest technology that uses Web 2.0 concepts to create user friendly presentation Layers, with this you can break up the page/screen into a variety of small UI elements, like a header, a navigation menu, a sidebar, etc and then we should be able to create reusable snippets of code

Also, most importantly by using Ajax in prototyping, you are prepping up the site for web Application Integration. The general structure of an Ajax prototype is remarkably similar to the structure to how a Engineer would incorporate the design into a web Application framework. They don’t have to dig through endless lines of presentation code, rather each function is nicely separated into it’s own HTML file.

Best Practices in Prototyping in Software Development - 1

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article addresses the needs of prototyping in Software Development , this will be the first part in the series of articles on Prototyping in Software Development.

1. Why Prototype?
Prototyping is a means of exploring ideas before you invest in them. The best reason to prototype is to save time and resources. So, for a minimal investment, you can find usability and design problems and adjust your UI before you invest heavily in the final design and technologies.

On examining the needs of your particular project, you might come up with reasons for creating a prototype other than saving money. Is the goal to explore a new interface model? Make modifications to one part of the existing design? Investigate a new technology? It’s important to be clear about why you’re building what you’re building before you start. If you begin with clear goals, you can be direct and effective in your efforts. The reasons for creating prototypes fall into three basic categories:

1.1 Proof of concept.
Among some teams there are disagreements about the future direction of a project. You can use a prototype to prove that an idea or new approach has merit or value. A prototype can help illustrate that an idea works, express its qualities in a visual and interactive way, and/or motivate team members to think about the problem from another perspective.

1.2 Design exploration.
If you design interactive things, the only way to explore how something will be used is to create a mock-up and interact with it. Sometimes the mock-up is tied to a usability study, where parts of the prototype can be evaluated in a structured way. Sometimes it’s just a way to clearly express to a developer how something should work or look. In many cases, a designer might simply be experimenting, in an effort to get a sense for what approach might work. Anyone on the team can use prototypes to explore design issues, although designers are generally the most skilled. Design explorations should be directed at trying to solve specific problems that you’ve recognized in your product.

1.3 Technical exploration.
Developers investigating implementation approaches to a problem often try out different coding techniques to see if they work well. Using HTML, Jscript, SQL, DHTML, FLASH, ACTION Script, PHP or specific coding approaches within each technology have different tradeoffs. Sometimes a prototype represents an exploration into what technology will work well to support a certain UI or web feature.

Sometimes prototypes are created for a combination of these reasons. If a team plans well enough, they can allot time for a developer and a designer or project manager to work together on a prototype. In such cases, it’s extremely important to clearly define the goals and the contributions each team member is expected to make. You want everyone to be clear on what the goals are, what’s at stake, and what the potential outcome will be.

2. Who is Involved?
Prototyping can be done informally by anyone, regardless of their background or role in the project. It’s easy to make a simple but effective prototype by taking a bitmap from Adobe Photoshop, putting it into the Microsoft FrontPage Web site creation and management tool, and adding active buttons or links. These lightweight prototypes only go so far, and can become unwieldy for complex interactions.

For more formal prototypes by larger teams, a developer or project manager will often collaborate with a designer and a usability engineer. Together they’ll generate ideas, build a prototype that represents the best ideas, and then go into the lab to see how effective it is in solving user problems. Developers might get involved if they can spare the time, or if their technical expertise is needed. Often the designer or project manager will do most of the scripting or coding to build the prototype.