UI design

Question 1

BA in UI design

Answer 1

• a basic set of user interfaces are created for us that allows end users to interact with those data elements. (simplifies user interface design process)
• design the data model and use it to drive our user interface design. (not UI mockup drives data)
• Main UI rules: harnesses, flow actions, and sections.
• BA is working with flow actions, sections, and skins
• advanced aspects of these rules that may require collaboration with more technical UI developers
• Harnesses and portals are system architect responsibilities, though we do participate in high-level discussions regarding their design and layout.

Question 2

Flow action

Answer 2

Flow action:

• within each harness, our application automatically loads a flow action to perform an assignment
• application displays the most-likely flow action by default
• remaining actions are available from a drop-down list order: first flow action (decreasing order of likelyhood) last: local/optional actions
• we can configure the Perform harness to display the available actions in other forms as well, such as buttons
• in real life we can review our harness configurations in DCO sessions
• describes a processing action that users can perform
• a bridge between the process and the user interface (the work the end user needs to perform, and when that should be performed)
• do not contain any UI details.
• displays the user interface configured in another rule, typically a section, when the user selects that flow action.

Question 3

Harness

Answer 3

Harness:

• describes the user’s workspace, and controls the type of work the end user can do at an assignment. (Perform, Review, New, Confirm)
• BA focuses primarily on the tasks end users perform and their interactions with the Perform harness.

Question 4

Intent driven UI

Answer 4

• focuses the user intends to do, and how that aligns with business needs and objectives
• UI elements accurately describe their function
• form titles should reflect the purpose or intent of the form
• field labels should describe the data we want to capture or present
• button labels should describe the action that occurs when end users click them
• controls clearly communicate their resulting actions

benefit:

• end user can understand, with little or no training, the actions they can take to complete an assignment, and choose the most appropriate course of action.
• end user spends more time focused on their tasks, and less time focused on how to provide information.
• application guides users through each assignmentts

Question 5

Portals and Skins

Answer 5

Portals:

• provide the operating environment that contains the harness, providing for menus and other navigational elements
• represent the work environment
• contains the harness
• provide access to applications

Skin:

• A skin contains formatting information, allowing us to quickly and easily control the appearance of our application from one rule
• contains information about appearance
• centralizes formatting across one or more applications

Question 6

Section

Answer 6

Section:

• contains the fields, lists, and other controls that users interact with to provide and respond to data
• represents the heart of UI design
• control how user perform a flow action
• contains layouts, controls, labels

Question 7

UI Design

Answer 7

1. process design (naming flow actions)
2. data modelling (generate UI drafts using property info)

Flow action specification is used to describe fields and controls presented to the user. Details have to be included like:

• Enter data in a field or select a value from a list
• When is a control available (always, circumstantially)
• Data is read only or editable?
• Does making a selection affect the UI?
• How do we layout controls?
• I some data required (list/free entry) Does it fit a certain expectation?
• functional aspects of our UI should be identified as part of our case type specifications. (affect the processing of a case)
• specifications are associated with flow actions, and implemented in section rules

Non-functional needs:

• How do users select an action? Do they select it from a list, or click a button?
• Do we want our text to be a specific font, or color? Do we need to incorporate organizational branding elements, such as colors, icons, or logos?
• non-functional aspects of the UI: affect how data is presented, not how the application uses those data elements to process the case
• should be described in the specifications that reference navigation requirements.

Navigation requirements:

• describe application-level navigation behavior, such as whether users click a button to perform actions, or select them from a list
• used to identify color schemes and other branding behavior, such as any logos to use.
• organized under the Navigation supporting type
• incorporated into the specification set for all case types within the application

Question 8

Layouts

Answer 8

BA: Dynamic Layout, Repeating Layout
SSA: Screen Layout, Column Layout

Smart Layout and Free-form layout: only backword compatibitlity, do not support responsive UI

• responsive behaviour is defined in a skin rule

Question 9

How you can open form configuration?

Answer 9

1. In the Step menu, you can select Configure form (new option).
2. When testing a case for which a form has not yet been added, you can respond to a new prompt with “Yes, I’ll add a form now.”
3. On the Process outline, you can use the Configure form link

Question 10

Data validation

Answer 10

add description to UI specs

1. controls
   - govern the display and presentation of data elements
   - present selectable options to end users
   - prided as part of PRPC
   - can be specified at the property or on the ui where the property is used
2. Validate
   - to check that a specific entry meets our criteria
   - entry falls into the proper range
   - applied to flow actions, and are processed when we submit a form to complete the action.
3. Constraints:
   - ensure a specific relationship between two properties
   - executed declaratively, rather than procedurally, so we don’t reference them anywhere in an application.
   - best left to Senior System Architects to implement.
4. Edit validate:
   - ensure that a property value matches a specific pattern, such as a postal code, telephone number, or email address.
   - applied to property rules, and they automatically evaluate when a user exits the corresponding field or control
   - utilize a library of standard edit validate rules as-is
   - creating or modifying one requires working knowledge of Java