Unless we implement a duplicate create button in the Type/Filter web-part, we would have to first select an existing Enquiry (or any other business data) in order to create a new one. Each form will have its own individual buttons but they should all contain the basic functionality indicated above ideally with the buttons placed in the same positions on the form.
When we see information on a form, it is likely that the user will want to browse (or drill-down) into the detail of that particular business entity e.g. an Enquiry. There are several options available to us to handle browse.
1) Consolidated View button. We would require this button in order to see more detail surrounding a particular piece of business data in a form. For example, if a particular note were displayed in a list-box of all notes for a particular Enquiry, clicking “View” would open up the Wizard Pane to give more details regarding that particular note without losing context with the Enquiry proper.
2) Multiple View buttons. This is as per the above except that each control capable of being drilled-down into has its own View button. The user would only be able to examine in detail the particulars of one business datum at a time on a form, so it makes sense to have just one (consolidated) view button rather than cluttering-up the form with one View button per-datum. The disadvantage of both of these approaches are that they disrupt standard hyperlink flow, for example; if the user sees an Order Part in a list of linked Order Parts, he has to select it and then select “View” in order to see it in detail. The advantage is that the linking process is simplified as the user doesn’t need to differentiate between the links i.e. the row containing the Order Part and the control i.e. the list-box containing all Order Parts.
3) Separate the hyperlink from the control. This would be required in order to both allow regular hyperlink operation but differentiate between this and the user merely wanting to change the value. If the user wanted to change the value in a control he would click the area of the control not covered by the hyperlink. If he wanted to instead drill-down into the value in the control, he would click the hyperlink instead. The main disadvantage is that the user needs to be aware of the difference and this is not typical UX behaviour. It also means that the user can drill-down into several values without losing focus upon a particular control. The main advantage is that all hyperlinks work in the regular manner.
Option 3 (Separate the hyperlink from the control) option is selected for our model; principally because this way means that we do not have to compromise on standard hyperlink operation.
In the case of the Enquiry example described above, the Wizard Pane did not have to be used to provide the detail view; although in the case of viewing the details of notes, which do not have a lot of information around them; this is recommended. An alternative approach would be to (upon View click) re-purpose the entire Browse/Next web-part to display the detailed information and provide a “Back” button towards the bottom of the form. In this way, much more screen real-estate can be used to display the detailed information; although this is at the expense of context i.e. Enquiry details will be temporarily hidden to accommodate the new details. This type of behaviour would be recommended for viewing the details of the principal business objects e.g. Enquiry, Task, Order, Order Part only.
The model uses existing Find and Browse UX components in order to find entities in forms, for example; finding a particular Contact from the Asset Filter (a Type/Filter UI component) to add to the Task Details form. This allows us to: Reduce development time; as additional find and browse capability is not required; Reduce testing efforts because the principal controls need only be tested once; Reduce training efforts as the user knows to always go to the Asset Browser to find assets (Customers, Classifications, Products and whatever else is deemed an asset in future) and finally - obtain data entry speed benefits as the user’s flow of operation is consistent. It also lends itself more readily to macro-automation.
Several options around implementing find functionality are available:
1) Accept loss of Type/Filter status. When highlighting a control on the form i.e. Contact details. We just go to the Asset Filter and choose the correct Contact Id to add to the form, clicking “Link” to add it to the requisite area on the form highlighted. Benefit: Don’t need a new button. Benefit: Can use existing one-way line of web-part communication i.e. from Type/Filter to Display/Update web-part. Drawback: Lose focus upon whatever was previously highlighted in the Asset Filter (Type/Filter) e.g. Particular Products of interest may have been in the Asset Filter; these may have had lengthy filter criteria which, if the user wants the list back, will need to be re-entered.
2) Add “Find” button to form. This would temporarily re-purpose the Asset Filter in order to find the Contact that is needed to add to the form. Clicking “Link” would in addition to putting the selected Contact or Contacts in the form, place the Asset Browser back into the state it was previously. Benefit: Don’t lose focus upon whatever was previously highlighted in the Asset Filter. Benefit: The “Type” and “Context” fields in the Asset Filter could be temporarily propagated to show correct context e.g. Type of “Customer” and Context of “Contact”. Drawback: Means that we have to build an additional line of web-part communication i.e. From Display/Update web-part to Type/Filter. This could be challenging if the Display/Update web-part is rendered in an iFrame.
3) Add “Save” button to Type/Filter. This would save the state of the Asset Filter (Type/Filter) before operating as for 1 above. Once at state is saved (only one state allowed to be saved), the button would turn into a “Restore” button, allowing the original state to be returned i.e. after we have located and added the correct Customer(s). In this way, it would operate much like the memory function on a regular calculator. Benefit: Adheres to the existing channels of web-part communication i.e. from Type/Filter to Display/Update web-part. No new channels required/means no additional testing required. Benefit: Provides additional functionality as a consequence of finding things e.g. a user could find some interesting Products and save them before looking at some Customers and then toggling between the two without even involving the Display/Update web-part and form filling. Drawback: It is an additional control to place upon a Type/Filter and so may add to general application complexity.
Option 3 (Add “Save” button to Type/Filter) is selected for our model due to this solution giving the user more power without adding behind-the-scenes complexity and risk.
The Type/Filter should also be used to copy things from one UX component to another. In this way, it is an extension of the method used to find things. For example, if a requirement exists to copy one or more Order Parts from one Order to another, the user would select the Order that he/she wants to copy to (bringing it up in the Display/Update web-part) and then switch to the To-Do List, selecting type of “Order” with a context of “Order Part”, clicking “Filter” and then selecting the checkboxes of the existing Order Parts to copy to the Order under focus and in the Display/Update web-part. It may be seen that the user can only copy things that are selectable in a linked Type/Filter through the standard filter options. If business elements outside of this selection are required, filter options should be changed to encompass the required selection rather than implementing some new copy/paste option. Filter options are easily changed as they are defined through exposed web-part properties.
No comments:
Post a Comment