The first assignment is completed and graded. This was the opportunity for everyone to get off to a good start ... (Note: Yes, you can get more than 100% on an individual assignment, since I did give a couple of bonus points). The next assignments will be a bit more challenging!
User-interface Design
I would like to take this opportunity to discuss some of the features and issues that I saw grading the assignment.
Here are some of the good practices that I saw implemented
- guiding the user by only enabling relevant controls (or disabling irrelevant or distracting controls)
- providing a clear squence of steps the user can to take to complete the task
- clearing controls (i.e., textboxes) when the content is no longer used or could be inconsistent with other information on the screen
- disabling input for controls that are only used for output (i.e., textbox displaying translation result)
- making the screen design robust to obvious changes or extensions. Can your user-interface handle the addition of another language (or another phrase) without much modification?
- providing feedback on user choices (i.e., highlighting selected language)
Some designs could have benefitted from reducing the number of active elements on the screen. Less is more (in my opinion) when it comes to user-interface design. Another issue was the lack of labeling input boxes. It should be clear to the user what kind of information goes into an input control.
Some of the user-interface design is a result of the logic of the process of arriving at the translation. Do you pick the language first and then the phrase, or vice versa?
Also some
Requirements Document and Use cases
Since this is a fairly simple application, the requirements documents were quite straightforward and done well. A couple of requirements documents could be improved by a crisper purpose statement. Keep in mind that this is what drives all the other parts and is also the thing that needs to get your reader (who might be the one who decided whether the project gets funded or not) hooked! It needs to be short and sweet, emphasizing the value of the application to the user and the organization. So this application is not about allowing "the user to choose between Spanish and German [...]". My favorite purpose statement was "The Language Translator will allow the user to translate useful vacation-oriented phrases from English into German and Spanish." Anything that is more than two sentences usually becomes convoluted and may be an indication the folks asking for this application don't really know what they want ... Big red flag for the project manager and his/her developers.
A use case should be a squence of detailed steps that a user would take to complete a specific task. A use case should reflect one possible path, even if multiple alternatives exist. There is always the option to create multiple use cases (or variations of a use case) to reflect different possible paths. This will make it very straight forward to leverage use cases for testing down the road!
Submissions
I do want to also mention that it is important to make "professional" submissions (which most were). What does that mean?
- If possible put everything in ONE clearly formatted document.
- Put your name, assignment number, and class on the cover page of each document
We will take a look at UI design during our next class session.
... and this is what the moon during the lunar eclipse looked like in Whitefish Bay. (
Lisa also took a nice shot!)
See the little white spek on the lower left?! ... That's Saturn.
MH