[MGNLUI-5120] UX design for filterable/sortable grid Created: 01/Apr/19  Updated: 05/Jun/19  Resolved: 25/Apr/19

Status: Closed
Project: Magnolia UI
Component/s: framework
Affects Version/s: None
Fix Version/s: 6.1

Type: Task Priority: Neutral
Reporter: Roman Kovařík Assignee: Roman Kovařík
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 0d
Time Spent: 2d 3.35h
Original Estimate: Not Specified

Attachments: PNG File Screenshot 2019-04-01 at 13.23.07.png     PNG File Screenshot 2019-04-11 at 08.46.50.png     PNG File Screenshot 2019-04-11 at 14.50.44.png     PNG File Screenshot 2019-04-18 at 14.04.06.png     PNG File definitions column filtering dropdown.png     PNG File definitions column filtering hover.png     PNG File definitions column filtering variationA.png     PNG File definitions column filtering variationB.png     PNG File definitions column filtering.png     File sorting.mov    
Issue Links:
Relates
relates to MGNLUI-5196 Change the layout for default title r... Closed
dependency
is depended upon by CFGUI-85 Migrate Definitions app to new UI fra... Closed
supersession
supersedes MGNLUI-4914 Implement filterable columns in Grids Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Sprint: Foundation 9
Story Points: 5

 Description   

Migration of the definitions app to new framework uses vaadin grid:

  • search box is now included in the column header
  • filters are gone in favour of column header filters (origin, type, module)
  • group by is gone in favour of sorting/filtering by any column
  • problems subapp replaced by severity column in the browser (to be reevaluated)
    • problem icon shows on the problematic property and all the parent nodes, hover shows the actual problem (might be shown in a dialog via an action as well)

 

UX & Visual design

  • Title row height: 45px
  • Label font: Roboto light, 10px, letter spacing -0.25, #232323, opacity 60%
  • Input field font: Roboto regular, 14px, letter spacing -0.5, #232323
  • On click in input field, the field remains grey (don't change to white)
  • On hover over icons show grey background circle (same as for all M6 icons), circle:22x22px, #ebebeb, icon font size: 18 or 20px (see mockup)
  • Select box dropdown follows same design as other dropdowns in M6 (see mockup)
  • Click on arrow down/up re-sort the column
  • Find detailed specs on zeplin here https://zpl.io/aX3YlJM

 

 



 Comments   
Comment by Roman Kovařík [ 12/Apr/19 ]

avongunten, do you have any suggestions regarding the former problems subapp?

  • There is no such app in the new app
  • one can filter by "severity" in the browser subapp.
  • the error is shown on hover (in not so colourful version compared with the former problems subapp)
  • the error is marked with icon on the property and all the way up in the hierarchy to the definition

Do we still need to have a lists of all problems or should we replaced with e.g. action which exports all the problems as a file?

 

Comment by Anja von Gunten [ 15/Apr/19 ]

rkovarik I cannot really answer the above question. The user in this case in a Dev. So the question would be, as a developer, do i need/prefer an overview and detail view of all problems? Or is it enough to see by the icon (+ hover info), what the problem is?

Comment by Christopher Zimmermann [ 15/Apr/19 ]

avongunten, rkovarik I will provide some input on the Problems View question.

Comment by Anja von Gunten [ 15/Apr/19 ]

To me the download option seems a bit clunky compared to displaying it in a subapp. But maybe there is benefit of having the files local that i don't know of.

Comment by Roman Kovařík [ 15/Apr/19 ]

I will provide some input on the Problems View question.

To me the download option seems a bit clunky compared to displaying it in a subapp. But maybe there is benefit of having the files local that i don't know of.

The usual use case is that I want to share/report the problems to somebody.

  • It's not even possible to copy it from the former sub app and even if it would be possible, it would contain bunch of extra HTML code.
  • The receivers doesn't have to have a magnolia running at the moment.
  • The only way today is to make a screenshot and in usual case of more problems, make a serie of screenshots.

Another use case would be a developer

  • Makes a template
  • Opens the def app.
  • Checks if the template is loaded with correct properties in the def. app.
  • Template does't work.
  • Looks into the problem sub app and filters problems (again the same filter as in the browser)
  • Fixes the problem
  • Goes back to browser
  • Refreshes the browser (forced to expand the properties again as the state is lost after refresh)

The idea of the flow in the new app is:

  • Makes a template
  • Opens the def app.
  • Uses the severity filter. The problematic property is expanded automagically. All affected definitions are marked with problem icon.
  • Fixes the problem
  • E.g. uses the severity filter again, property is refreshed, state is preserved.
Comment by Roman Kovařík [ 18/Apr/19 ]

had

Comment by Jan Haderka [ 18/Apr/19 ]

rkovarik thx. just commented about the same on CFGUI-87 few minutes ago

  • we should make window bigger to cover say 3/4 of the width of white area or make it resizable or both
  • we should allow ppl to copy whole message from the window easily since you need that message most of the time to follow up on the issue

Otherwise filtering by the issue type looks great and eliminates need for the old subapp. Great work that we could finally get rid of it.

Generated at Mon Feb 12 09:23:24 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.