Iterative User Interface Design

Overview

This paper is about general iterative user interface design and it shows the successes of using this process. The improvement in overall usability was shown to be 165% from the first to last iteration, and the median improvement was 38%. They found that there should be 3 iterations since more iterations could actually decrease the usability if the usability engineering process was focused on improving other parameters.

The Benefits of Iteration

Nielsen presents a graph that shows that usability increases directly after each iteration until it eventually hits a plateau. A con is that sometimes after an iteration, usability decreases since new usability problems maybe introduced. The pro is that they can usually be ironed out shortly after. He suggests that interface reconceptualizations have not been studied on projects that were completed by an individual.

An example from later in the paper (Table 5) saw a dramatic decrease Time on Task, Subjective Satisfaction and increase in Errors Made and Help Requests from version 2 to 3 and 3 to 4. However, by version 5 they were all improved by the final version. A big con could be if a project can’t be updated before the final version and it would be better to have version 1 versus having version 3.

From my perspective, iterative design is natural, and projects will follow this without even the designers trying to. Building several different designs and comparing them side by side and then choosing the best will also work, but the chosen version would be improved through an iterative process. Choosing between multiple designs then using iterative improvements on the chosen design, using features from the different versions is the best method for design.

Conclusions

The number of iterations cannot be chosen in advance since the version from iteration 3 might be worse than the first but with two more iteration could be much better than the first. It would be a big con to try to chose the exact number of iterations before hand and a large pro to allow this number of iterations to be dynamic.

Discussion

• Iterative usability design for individuals instead of teams
• Alternative to iterative design: iteration is natural
• Nielsen writes about iPad & touches upon multi-touch in the paper:
• http://www.useit.com/alertbox/ipad.html

Binding Designs Store - Search Results

Software Engineering

PHP

Software Design

Network Programming

Web Development

Designs

Programming

How to Get a Software Project Started

from wikiHow - The How to Manual That You Can Edit

Get a software project started. If you are a professional or a hobbyist, this article will give you an introduction on how to start a project.

Steps

1. Draw up a brief description of the problem.
   
2. Make a requirements diagram that is much less abstract than the description.
   
3. Choose the target audience.
   
4. Choose the target machines that the software will work on. (I. E., desktop computers, mobile computers, WWW)
   
5. Choose a budget.
   
6. Find investors if applicable.
   
7. Decide if you are going to find a company or a consultant to implement the project for you.
   
8. Monitor the progress of your project on a set basis.
   
9. Publish your project on the web and other places.
   

Tips

• Don't panic if you encounter small problems: they are normal.
  

Warnings

• Find a reputable source that has the expertise to finish your project. Many claim that they can and even believe that they can, but later on find out that they can't finish the project.
  

Related wikiHows

• How to Change "Add a Listing" in Sharepoint Portal 2003
  
• How to Authorize Music from iTunes to Play on Other Computers
  
• How to Create a Custom Computer Cursor
  
• How to Retrieve a String Array Using Ksoap 2
  

Article provided by wikiHow, a collaborative writing project to build the world's largest, highest quality how-to manual. Please edit this article and find author credits at the original wikiHow article on How to Get a Software Project Started. All content on wikiHow can be shared under a Creative Commons license.

J2ME Mobile Applications

J2ME (Java 2 Micro Edition) is a version of Java targeting mobile devices. It is much more efficient than J2SE (Java 2 Standard Edition) and can run in a constrained environment. It is not strictly limited to mobile devices and can run on some embedded devices. Java is known to be highly portable. Portability allows a build once, compile for many different devices scenario. J2ME can be easily ported across mobile devices. This does not hold true for all situations. The hardware on one device can be different than the next device. So, a J2ME application with GPS functionality that runs on a GPS capable phone, obviously, can not be ported to a non-GPS compatible phone. J2ME provides a complete object-oriented programming environment. There are many tools included in the J2ME software development kit that allows developers to easily build clean and usable user interfaces. There are a large number of tools included in the development environment. The BlackBerry Software Development Environment/RIM (Research In Motion) utilizes J2ME for the programming language. There is a complete JDK Java Development Kit to handle developing applications for the BlackBerry.

Learn more about J2ME Services.

Introduction to J2ME.

Qualcomm's BREW

Qualcomm's BREW (Binary Runtime Environment Wireless) is an environment for application development for Verizon Cellphones. The language used is primarily C/C++. It is not the typical C/C++ that people are accustomed to. There is a library with specific functions that cab be used. The standard C/C++ libraries are not available. It should be called C, but it is an object-oriented version of C. It is not, however, the standard C++ that is popular in the development community. It is not an easy to use development environment. Only skilled and talented developers should venture into those areas.

Read more about Getting Started with BREW.

Find out about Services for BREW.

Single-Tasking vs. Multi-Tasking

Single-Tasking vs. Multi-Tasking

This concept reminds me of a great book called "The Mythical Man-Month". That book was a book about software engineering and computer science. It is a must read for any software engineer. It is a very old book, but is still true. The Mythical Man-Month states that bringing more people on a project, will not always speed it up. If there is a 1000 hour project, 1000 engineers each working on it for 1 hour is not the same as 2 engineers working on it for 500 hours each. The math works, but it does not map to the world of software engineering. This brings me to the point of this post. Working on 10 - 10 hour projects simultaneously is not the same as working on 2 50 hour projects one after the other. Context switching has to be taken into consideration. Switching from one project to the next every couple of hours will take up a lot more time. Working on 10 - 10 hour project with 2 hour time-frames and then switching to the next could indeed turn into 150 hours of project work. If working on each one after the other, it may be equivalent to 120 hours of project work. Working on 2 - 50 hour projects, would probably be more like 100 hours because the time for switching between projects (context switch) takes up a lot of time. The reason I use the term "context switch" is because in computer science, operating systems make a context switch when switching from one process to the next. It takes more time for the processor to make a context switch. The reason to make a context switch is if two processes must be continuously processed or one process is waiting for an event. It is the same in the real world.