UI for License term configuration (UXPROD-1521)

[UXPROD-1960] Decide which UI approach to use for License Term Management Created: 08/Aug/19  Updated: 12/Aug/19  Resolved: 12/Aug/19

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: UI for License term configuration

Type: Sub-task Priority: TBD
Reporter: Gill Osguthorpe Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File image-2019-08-08-12-38-04-545.png     PNG File image-2019-08-08-13-12-57-153.png     PNG File image-2019-08-08-13-17-49-661.png     PNG File image-2019-08-08-13-17-57-987.png    

 Description   

There are two UI options which we could adopt. Owen is keen to take the path of least resistance. md331 and Aditya matukumalli, could you please take a look at both options and guesstimate the time to implement, or just say which you think will be the most straightforward.

Option 1 - three panes

In this approach, records are created in the same pane as the list of terms. It is used frequently by other apps but does not respond well in narrower browser widths and has not been used yet to display records with more than 4 fields. This example shows how the Cancel button is lost, and how little space is available for entering a description:

For license terms, we will need to display the following fields for each term:

  • Name
  • Description
  • Order weight
  • Primary term?
  • Default visibility
  • Type
  • Category
  • Last updated
    • Date
    • User who made the update

The question is can the current UI handle this number of fields in one row, and if not what needs to happen to make it possible? For example, collapsing the row group so that it spans more than one row in the UI, or displaying it as a card.

Option 2 - 4 panes

Data Import uses a four pane approach, with the Edit pane displayed full-width. This approach will solve the layout issues, but is it more time consuming to deliver? Mockups are below (have not done the Edit pane yet).



 Comments   
Comment by md331 (Inactive) [ 08/Aug/19 ]

Option 1

  • I'm not really sure that Option 1 is viable as-shown, for the reasons you give. It'll take too much horizontal space or squash everything down uncomfortably.
  • The component used in those UIs is ControlledVocab (and EditableList lower down). EditableList doesn't really have the ability to split an entry across multiple lines so if we wanted to go this route we'd have to add that functionality to it. It doesn't seem like a crazy amount of effort to do that, though. There are certain unknowns that I think we may run into that could turn this into a risky move that blows up the time to implement it.
  • One thing that concerns me about going with a ControlledVocab approach is how our backend endpoints work. We'd have to ensure that our backends behave in the way that ControlledVocab expects them to be structured and behave. Will be a thing for steve.osguthorpe to look into imo.

Option 2

  • Definitely possible but is significantly more work because it's more of a solution that's built-up from "first principles" rather than fully cooked components.
  • I'm not sure how much we're gaining with separate View and Edit pages here. I suppose that the Licenses using this term could be different across the two views, but I'm not actually certain that the fetch required to accomplish that listing is possible. Again, steve.osguthorpe?
  • I think we can still comfortably accomplish it in a sprint but it'd be one person fully-tasked for that sprint on it.

Option X

  • What about a card-based, three-pane UI? So instead of having one row per term like the Option 1 mockups, have a card per term instead? The card would be styled like the editable cards we use when editing the documents or terms of a license.
  • Save/Delete buttons could be on the right side of each card's header.
  • I think this way would give us the wins of Option 2 (not cramped, more visual space) without the downsides of it (time to implement).
Comment by Gill Osguthorpe [ 09/Aug/19 ]

Thanks md331. Introducing the card layout gets my vote.

Comment by Owen Stephens [ 12/Aug/19 ]

Thanks all. Will update ERM-391 Closed on the basis of this discussion

Note that "Licenses using this term" is not a requirement in the configuration

Generated at Fri Feb 09 00:19:57 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.