IT:AD:Design:UX:Screen Flows:PrimaryData

• MUST: Items can be searched for via a DataSearchCriteriaEditView.
  • SHOULD: The search criteria should be a single entry, optionally parsed in realtime, the parsed criteria displayed in the SearchCriteriaDisplayView.
• MUST: The DataSearchCriteriaDisplayView offers the following Actions:
  • MUST: Search, leading to the redisplay of the (editable) DataSearchCriteriaEditView in its place.
    • MUST: The Search initiates a Repository request for a list of Projection View Models of the specified Item Summaries (ie not 1 to 1 projections of a single record).
  • SHOULD: When displayed on platforms with keyboards (eg: desktop), the Enter will be sufficient to begin the search process.
  • SHOULD: When more than criteria is involved (eg, not a single Text entry) a Clear action should also be provided, in order to reset the Search Criteria form.

• MUST: Items in the list must be viewable in a grid layout (DataListView).
  • SHOULD: As multiple column Grids are difficult to render correctly in Mobile displays, consider using an adaptive template-based rendering solution per row.
• MUST: Items must be sortable.
  • MUST: Items must be sortable by more than one criteria at a time.
    • SHOULD: If rendering items by template, consider using a mechanism similar to Kendo UI's Grid sorting mechanism.
• MUST: Data is retrieved in 'pages. * MUST: Retrieval of additional pages of data is performed using *“Infinity-Scrolling”.
  • MUST: In a touch enabled apps, the event is triggered by an upward swipe action,

    • MUST: In a keyboard driven app, the event is triggered by a page-down arrow key press.

    * MUST: DataListView rows/items can be selected.

  • MUST: more than one DataListView rows/item can be selected at one time.
  • MUST: a subsequent Action can be applied to the selected items.
• MUST: The DataListView offers the following Actions:
  • MUST: View, displaying a single record within DataItemDisplayView.
    • MUST: Container level flags must be persisted for later refetching of data:
      • MUST: PageNumber
      • MUST: RowNumber
    • SHOULD: Full row selection is advisable in Mobile displays.
  • MUST: Select, (indicating the item is selected, awaiting a subsequent Action).
    • Note: When rendering in touch enabled screens, consider using the solution that Gmail Mobile uses:
      full row Selection, except the area of the colour Tag/Category – which flips to a checkbox.
• MUST: The DataListView displays a list of buttons (at the top) representing the Action to be performed on the Selected items.
• MUST: The Actions to offer are:
  • MUST: Soft-Delete (an undo-able operation),

    • SHOULD: Merge/similar operation (see DataSelectedItemsView below).

• MUST: Upon display, a DataItemDisplayView retrieves a projected View Model of the specified data Item.
  • MUST: unless a 'DoNotRetrieveDisplay' Flag is set (set by DataItemDisplayView's Cancel Action).
  • MUST: The DoNotRetrieveDisplay Flag is always reset.
• MUST: A DataItemDisplayView offers the following Actions:

  • MUST: Edit, displaying the record in the DataItemEditView

  * MUST: The Edit Action initiates a Repository record for a single record (non-projected) View Model (with additional reference data sets as required).

  • MUST: Delete, showing an DataItemDeleteInlinePrompt
  • MUST: Cancel, returning to the DataListView
    • MUST: If the 'BeenEdited' flag is set (see below), the DataListView must perform a repeat of the original Search, keeping its page position, and highlighted row, in order to show the result of the Confirmed Action.

• MUST: The DataItemDeleteConfirmationView is a modal dialog requesting confirmation prior to soft-deletion.
• MUST: The DataItemDeleteConfirmationView offers the following Actions:
  • MUST: Confirm, returning to the DataGridView
  • MUST: Cancel, returning to the DataItemDisplayView

• MUST: An DataItemEditView offers the following Actions:
  • MUST: The Apply button persists the currently edited data item to a repository.
  • MUST: The Save does the same as Apply, and returns to the DataItemDisplayView.
  • MUST: Cancel, returning to the DataItemDisplayView
  • MUST: The DoNotRetrieveDisplay Flag is set prior to returning to the DataItemDisplayView.

• MUST: The DataSelectedItemsView displays the previously Selected records, in order to perform an Action on them (eg: Merge).
• MUST: The DataSelectedItemsView offers the following Actions:
  • MUST: Confirm, performing the agreed Action, and returns to the DataListView.
    • MUST: The DataListView must perform a repeat of the original Search, keeping its page position, and highlighted row, in order to show the result of the Confirmed Action.
  • MUST: Cancel, returning to the DataListView, without re-performing a query.

Repository Operations are performed during the following Actions:

• [R1] when DataSearchCriteriaEditView is activated in order to populate DataItemDisplayView
• [R2] when DataItemDisplayView renders a Output View Model of single data item. The Output View Model is a display ready projection of a Data Item (eg: where reference data (eg: 1) is rendered as serialized text (eg: Female).
• [R3] when DataItemEditView renders a nullable Output/Input View Model of a single data item.
  • the Input/Output View Model is 1-to-1 map of the original Data Item, except that its properties are nullable. This is so that the View's Controller can better determine the intent of the posted back Input Model data, determining the difference between returned string.Empty (for erasing data) and null (no-data posted back, do not change db record attribute).
• [R2] when DataItemDisplayView renders an updated (after a Save Action) Output View Model of single data item. The Output View Model is a display ready projection of a Data Item (eg: where reference data (eg: 1) is rendered as serialized text (eg: Female).
• [U1] when DataItemEditView:Save is actioned.
  • a container level Flag is set.
• [U2] Update merge
• [R2] when DataItemDisplayView is rendered, when returning from DataItemEditView and a container level Saved flag is set.
  • the container level Flag is cleared.
• [R1] when DataItemListView is redisplayed after an Edit Action has been performed.

Some of the Input/Output models used are:

• DataGridViewModel: Output Model
  • list of DataGridItemModels.
• DataItemDisplayModel: Output Model
• DataItemEditModel: Output Model
  • rendered as a form, but not all fields are rendered as form control values.
• DataItemEditModel: Input Model
  • used to post back data to the Controller.
  • the fields must be nullable for the Controller to distinguish between null data (ie: non-posted back) and empty strings (ie: erasure of data).

It is important to understand the following:

• The list loaded into the DataGridView is a list of view model projecions, and not the data source itself.

  • An example of this is apparent when considering the displaying of Patient records: one could be displaying a list of Output View Models containing

  simple data (Patient Name, DOB, Active) – enough info to distinguish one client from another at a glance. But each list item in the clientside datastore is not enough to populate a whole DataItemView (a patient record is much larger than just its name/dob/active status).

• To offer offline capabilities, the mechanism probably requires two client-side cached repositories (a light one developed rapidly for listing purposes only, one complete patients list, containing copies of the records clicked/viewed).