Details
-
Epic
-
Status: Closed
-
Major
-
Resolution: Completed
-
None
-
None
-
1
-
Orchestrate - Execute Business Process
-
To Do
-
S04E28 - Bridge over troubl..., S04E29 - Unimagine, S04E30 - Sea Change
Description
Goal
The goal of this epic is to add custom view management features to the frontend dataset component. By custom view we mean views created by end users when consuming data via UI using the FDS.
Currently, FDS can remember per-user current view settings such as the visible columns. In this epic, we'll add the notion of custom view as a named snapshot of view settings representing (a subset of) the internal state of a specific dataset display instance, which can be saved by users. This way, users will be able to create many custom views and select an existing custom view to utilize.
The notion of view settings includes visual aspects but also characteristics of the data being displayed. To illustrate, some items to consider include active filters, item ordering and visualization mode (table, cards, list). When dataset display utilizes a table to display data, then additional items, such as visible columns, can be inclided in the view. As new features are added to the FDS, more items can become part of the custom view.
Acceptance criteria:
- FDS provides the custom view management operations: select a custom view to use, including the default one (
LPS-130190), and save state into a new or current custom view (LPS-130189) - System persists the custom views associated with a FDS instance (
LPS-130155) - Visualization settings use an open data model so that new items can be added without the need of an upgrade process
- Component API allows to enable/disable custom views (
LPS-130273)
Related links:
Test Information section
Test scenarios can be found in their respective story tickets in the epic.
Design
Introduction
What are custom views?
From the user experience perspective, custom views allow managing (only save and delete currently) customized views created in the Frontend Data Set component. That means that any modification over the filters, columns, order, or visualization mode, is considered part of a 'custom view' that can be saved by the user.
Custom views are an important part of the user experience as they allow users to create their own view configurations and manage them.
There are a lot of possibilities around Custom Views (some of them suggested in the description of this epic) but in this first iteration, we will focus on the basics of managing custom views:
- Save a new Custom View
- Save a modified Custom View
- Clone a Custom View
- Select different Custom Views
- Delete a saved Custom View
- Restore a Default View
Explanation of the component
In order to achieve the task of managing views we need to think in two terms:
- Actions
- Elements
'Actions' are the possible operations that the user can do over an element (a preset or customized view). So, in this case, the basic actions would be things like 'save' or 'delete', but in the near future, we could have things like 'favorite', 'rename', 'share', and so on...
'Elements' are the proper custom views saved (including also the default ones).
So, the component is designed to share these two concepts, on the left side houses the elements, and on the left side the applicable actions.
* It is important to have into account that the actions are applied to the selected view.
Use cases
Let's keep in mind that the 'Default View' is the first visualization that the user will see when the screen is loaded for the first time. Also, it is important to know that this view can't be deleted or renamed. It is a view from the system, and it serves to recover the default one of the systems or (defined by the admin in an Objects View).
As said before, it is important to differentiate clearly which elements are part of the view customization:
- Filters
- Columns
- Order
- Visualization Mode
So, let's say that if the user changes any of these elements, the default view will show that the View is unsaved showing an asterisk close to the name and applying a bit of weight to its name.
The user would be able to save the view from the 'actions' menu. In this case, we will only show the 'save as option because the default view cannot be overwritten.
The user can also overwrite any view that has been previously saved. This is simple and works in the same way, once a change is made to a saved view, the asterisk in the name will be redisplayed to indicate that it differs from the saved version.
It is the user's choice to overwrite it 'save' or create a new version 'save as. In the latter case, a modal window would be displayed to set a new name for the view.
It is also possible to save an unchanged view with a new name. This is similar to cloning in order not to lose changes or to buy two different versions. For that, the 'save as' option will always be active allowing to save even without changes.
Once the new view is created, it will become selected showing its new name.
Select a different custom view
It is easy to change the view displayed by simply using the view menu (left drop-down) once the user activates the desired view it will become selected.
The views created by the user can be deleted using the 'actions' menu only if the view to be deleted is selected.
In that case, the selected view will become the default view.
Exit without saving the changes
To avoid confusion or inconvenience in small modifications that the user may carry out, we will not ask to save the changes to the view once the user leaves the screen. It is a good point that we will have to evaluate and listen to the first experiences of the users to make a different decision or keep this one.
The visualization mode can contain three ways of displaying information:
- Cards
- Lists
- Table
These are part of the view configuration, (that means that any change is significant to show unsaved changes on the Custom Views component) and the user can switch between them using the display menu (outside of this component).
Notes on behavior
To improve the user experience, the selected view will be retained even if the user exits that screen. That is, the selected view will not change in any way until the user decides to do so.
Attachments
Issue Links
- depends on
-
LPS-130407 Migrate dataset display
-
- Closed
-
- fixes
-
LPS-156743 Configuration and Definition for Dataset Views of Headless Resources
-
- Now
-
- is a dependency of
-
LPS-146010 Enable the end user features from dataset display improvements
-
- Closed
-
- Is blocking
-
LPS-130262 Make CKEditor toolbars configurable via settings
-
- Open
-
-
LPS-130195 Enable column resizing in the Dataset Display
-
- Closed
-
-
LPS-130194 Inline editing/adding in Frontend Data Set
-
- Ready for Development
-
- is duplicated by
-
LPS-151246 Objects support preferences for persisting filters and visible/hidden columns
-
- Closed
-
- relates
-
LPS-165706 Using page builder to create object views
-
- In Planning
-
- split from
-
COMMERCE-5558 Let users able to customise views
-
- Closed
-
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...