choose topic (my topic is a desktop publishing system) and design your user inte
ID: 667232 • Letter: C
Question
choose topic (my topic is a desktop publishing system) and design your user interface design. your final output will be your storyboard for your design and the use case.
1. you are required to perform a use case for desktop publishing system.
2. perform a detailed task analysis for any one of the systems listed in problem given. use either an elaborate or object oriented approach. ask: what does the user input? how is it processed and how is the processing evidenced via interface? what is produced as output?
Explanation / Answer
Ans:The user input is A storyboards are used to understand and reason about the requirements of the user interface, including usability requirements. They represent a high-level understanding of the user interface and are much faster to develop than the actual user interface. This boards can be used to create and reason about several versions of the user interface before it is prototyped, designed, and implemented.
A use-case storyboard is described of boundary classes and their static and dynamic relationships, such as aggregations, associations, and links. Each boundary class is in turn a high-level representation of a window or similar construct in the user interface.
The benefits of this approach is
It provides a high-level view of static window relationships such as window containment hierarchies and other associations between objects in the user interface.
It provides a high-level view of dynamic window relationships such as window navigation paths and other navigation paths between objects in the user interface.
It provides a way of capturing the requirements of each window or similar construct in the user interface, by describing a corresponding boundary class. This is because each boundary class defines responsibilities, attributes, relationships, etc. that have a straightforward mapping to the corresponding construct in the user interface.
A use-case storyboard in the analysis model is traced to a use case in the use-case model.
Events
The following are guidelines on how to describe a flow of events - storyboard:
Start by clarifying the use case itself - not its user interface. Start by keeping the description independent of the user interface sholud use case is unexplored. This will help you capture the essence of the use case, similar to the "essential use cases" described in Concepts are User-Centered Design. Then on the use case is understood, the flow of events storyboard can be augmented with user interface and usability aspects.
Keep action statements brief. The description does not necessarily have to be self-contained, because it does not have to be comprehensible to people other than user-interface designers. Action statements that consist of brief steps give a better overview, since it makes the use-case descriptions shorter.
For example, when you describe how the use case exchanges data with an actor, you should keep the description brief and comprehensive; you can list the exchanged data at the end of the line, within parentheses.
Human actors can often perform the actions of the use case in different sequences, especially in user-interface-intensive systems where the user is in control. Sequences often imply modes of the user interface, and you should avoid modes if possible. Thus, you should specify only the sequences that are mandatory in the use case. For example, that the user must identify himself before he can withdraw money from an ATM, or that the system must show the invoices to the user, before the user can accept or reject them.
The following is an example of an initial flow of events - storyboard of a storyboard for the use case Manage Incoming Mail Messages.
a) The use case starts when the mail user requests to manage mail messages, and the system displays the messages.
b) The mail user may then follow one or more of these steps:
c) Arrange mail messages according to sender or subject.
d) Read text of a mail message.
e) Save the mail message as a file.
f) Save the mail-message attachment as a file.
g) The use case terminates when the mail user requests to quit managing incoming mail messages.
The user-interface designer should walk through the flow of events, and consider the following issues at each step:
What guidance could the user possibly need? and system possibly provide?
What should be represented and what should not?
From the flow of events, the basic functionality of the system can be identified. From the desired guidance, you should be able to identify "optional" functionality that is not crucial for the user to be able to carry out his work, but that might help him carry out the work by (implicitly) providing him with information that he needs. Thus, anything that could help you find such optional functionality should be represented as desired guidance. You should not, however, represent desired guidance that only identifies functionality we would find anyway, just by using good user-interface shaping practice Desired guidance can also be used to tell you what not to show, thus enabling you to shape the user interface so that the user doesn't get swamped by irrelevant information.Desired guidance is not "requirements" in the same way as the flow of events-it is more like "wants," or "nice-to-have." When you identify and describe desired guidance, you should not think in terms of what the system shall eventually provide, but in terms of what the user might need in addition to that; otherwise, you restrict our thinking. So, remember that the desired guidance is not absolutely necessary, it is merely a means of increasing usability.
Example:
The following is an example of the flow of events - storyboard of a storyboard for the use case Manage Incoming Mail Messages augmented with desired guidance
a) The use case starts when the mail user requests to manage mail messages, and the system displays the messages.
b) The mail user may then follow one or more of these steps:
c) Arrange mail messages according to sender or subject.
d) Read the text of a mail message.
e) Save a mail message as a file.
f) Save a mail-message attachment as a file. [The user should be able to see the file types of the attachments.]
g) The use case terminates when the mail user requests to quit managing incoming mail messages.
Desired guidance is often required in actions where the user has to make a decision. The following points often apply to such decisions:
They are non-trivial to the user.
They impact peoples life or businesses surrounding the system
They matter once the use case has terminated.
A storyboards are used to understand and reason about the requirements of the user interface, including usability requirements. They represent a high-level understanding of the user interface and are much faster to develop than the actual user interface. This boards can be used to create and reason about several versions of the user interface before it is prototyped, designed, and implemented.
A use-case storyboard is described of boundary classes and their static and dynamic relationships, such as aggregations, associations, and links. Each boundary class is in turn a high-level representation of a window or similar construct in the user interface.
The benefits of this approach is
It provides a high-level view of static window relationships such as window containment hierarchies and other associations between objects in the user interface.
It provides a high-level view of dynamic window relationships such as window navigation paths and other navigation paths between objects in the user interface.
It provides a way of capturing the requirements of each window or similar construct in the user interface, by describing a corresponding boundary class. This is because each boundary class defines responsibilities, attributes, relationships, etc. that have a straightforward mapping to the corresponding construct in the user interface.
A use-case storyboard in the analysis model is traced to a use case in the use-case model.
Describing the Flow of Events - Storyboard
The following are guidelines on how to describe a flow of events - storyboard:
Start by clarifying the use case itself - not its user interface. Start by keeping the description independent of the user interface, especially if the use case is unexplored. This will help you capture the essence of the use case, similar to the "essential use cases" described in Concepts: User-Centered Design. Then, later on, as the use case is understood, the flow of events - storyboard can be augmented with user interface and usability aspects.
Keep action statements brief. The description does not necessarily have to be self-contained, because it does not have to be comprehensible to people other than user-interface designers. Action statements that consist of brief steps give a better overview, since it makes the use-case descriptions shorter. For example, when you describe how the use case exchanges data with an actor, you should keep the description brief and comprehensive; you can list the exchanged data at the end of the line, within parentheses: "create person (name, address, telephone)."
Avoid sequences and modes. Human actors can often perform the actions of the use case in different sequences, especially in user-interface-intensive systems where the user is in control. Sequences often imply modes of the user interface, and you should avoid modes if possible. Thus, you should specify only the sequences that are mandatory in the use case. For example, that the user must identify himself before he can withdraw money from an ATM, or that the system must show the invoices to the user, before the user can accept or refuse them.
Be consistent with the use case. Since the use-case storyboard can be described more or less in parallel with the corresponding use case, these two artifacts should be kept consistent with, and give feedback to, each other. In particular, the flow of events - storyboard of a use-case storyboard should be kept consistent with the flow of events of the corresponding use case. Note that this often requires an extensive communication and feedback loop between the use-case author responsible for the use case and the user-interface designer responsible for the use-case storyboard.
Example:
The following is an example of an initial flow of events - storyboard of a storyboard for the use case Manage Incoming Mail Messages.
a) The use case starts when the mail user requests to manage mail messages, and the system displays the messages.
b) The mail user may then follow one or more of these steps:
c) Arrange mail messages according to sender or subject.
d) Read text of a mail message.
e) Save the mail message as a file.
f) Save the mail-message attachment as a file.
g) The use case terminates when the mail user requests to quit managing incoming mail messages.
The user-interface designer should walk through the flow of events, and consider the following issues at each step:
What guidance could the user possibly need?
What guidance could the system possibly provide?
What should be represented as desired guidance and what should not?
From the flow of events, the basic functionality of the system can be identified. From the desired guidance, you should be able to identify "optional" functionality that is not crucial for the user to be able to carry out his work, but that might help him carry out the work by (implicitly) providing him with information that he needs. Thus, anything that could help you find such optional functionality should be represented as desired guidance. You should not, however, represent desired guidance that only identifies functionality we would find anyway, just by using good user-interface shaping practice (for example, don't represent that the system should give the user feedback on his operations, or show the user all the different options he has, etc.).
Desired guidance can also be used to tell you what not to show, thus enabling you to shape the user interface so that the user doesn't get swamped by irrelevant information.
Desired guidance is not "requirements" in the same way as the flow of events-it is more like "wants," or "nice-to-haves." When you identify and describe desired guidance, you should not think in terms of what the system shall eventually provide, but in terms of what the user might need in addition to that; otherwise, you restrict our thinking. So, remember that the desired guidance is not absolutely necessary, it is merely a means of increasing usability.
Example:
The following is an example of the flow of events - storyboard of a storyboard for the use case Manage Incoming Mail Messages augmented with desired guidance
a) The use case starts when the mail user requests to manage mail messages, and the system displays the messages. [The user should be able to differentiate between new, read, and unread messages; the user should also see the sender, subject, and priority of each message.]
b) The mail user may then follow one or more of these steps:
c) Arrange mail messages according to sender or subject.
d) Read the text of a mail message.
e) Save a mail message as a file.
f) Save a mail-message attachment as a file.
g) The use case terminates when the mail user requests to quit managing incoming mail messages.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.