[MGNLUI-2776] Show scrollbars if there are many apps and app groups Created: 27/Mar/14  Updated: 05/Dec/14  Resolved: 25/Sep/14

Status: Closed
Project: Magnolia UI
Component/s: applauncher, design
Affects Version/s: 5.2.3
Fix Version/s: 5.3.4

Type: Improvement Priority: Neutral
Reporter: Andreas Weder Assignee: Aleksandr Pchelintcev
Resolution: Fixed Votes: 2
Labels: pain-point, support, usability, ux
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File 17_AppsScreen.png     PNG File 18_AppsScreen.png     PNG File 19_AppsScreen.png     PNG File 20_AppsScreen.png    
Issue Links:
Relates
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

Not all apps and app groups remain visible and accessible, if you have many items on the Apps screen, or if you're running Magnolia on a screen with lower resolution that the one it was originally designed for.

The Apps screen is supposed to scale to basically accommodate an arbitrary number of apps and lower resolutions by showing scrollbars for the upper section containing the open app groups. The attached visual designs show the solution in action.

We should rework the Apps screen with support for such scrollbars.



 Comments   
Comment by Cheng Hu [ 23/Sep/14 ]

@apchelintcev Thanks very much for making the patch, but currently the patch https://dl.dropboxusercontent.com/u/12603520/applauncher.patch only shows changes from the current commit and does not seem to use the LayoutManager?

Comment by Cheng Hu [ 23/Sep/14 ]

In the latest commit, we made the following changes:

  • Use LayoutManager rather than window listener to handle resizing of the top panel
  • Use SCSS variables for color rather than color codes
  • Specify that the horizontal scrollbar should never appear
  • Increase the column width slightly to accommodate the vertical scrollbar

Note:

  • We did not increase the width of the column substantially because currently it is the maximum width for iPad in vertical orientation
Comment by Cheng Hu [ 25/Sep/14 ]

@Sasha. Thanks for improving it still more. I took a look at the latest code and I'm okay with it. Only a small question:

  • Do we need to remove the listeners from LayoutManager when the AppLauncher unregisters?
Comment by Aleksandr Pchelintcev [ 25/Sep/14 ]

@ChenHu we certainly should do that, actually it was there (I even have a map there for those purposes) but must have been lost during the rebasing Chunhua's branch. Added and pushed.

Comment by Mikaël Geljić [ 26/Sep/14 ]

Code:
1. Please don't add new color variables The color scheme is fixed and defined here http://wiki.magnolia-cms.com/display/UX/Style+guides+for+visual+design. Use one of these instead.
2. Not fond of the ping-pong registration of resize handlers: Connector/presenter asks view to add groups/tiles, view creates corresponding widgets and asks presenter back to register resize handlers... That wouldn't be an issue if the views weren't dealing with the business pojos, but rather accepting widgets created by the presenter. On the other hand that's not to be changed now.
3. Since we ditch the VAppLauncher dumb presenter class already, can't we implement the presenter on the AppLauncherConnector itself rather than as an anonymous class?
4. newly introduced AppLauncherUtil is only used in one location, and would be more/less a one-liner... I suggest we roll that one back. Then how it's all done with the jQuery callbacks might change if we do something for point 7.

UI: interaction is not convincing imho.
5. Collapsible groups are typically of lesser importance than permanent groups. However, as the viewport shrinks down, some permanent groups get invisible below the fold, while temporary groups are the only ones left always visible.
6. Similarly, expanding these groups is altering the "permanent area"; I actually prefer expanding these groups "in front", rather than forcing the rest to make up some room. Yes, that's the way it is done now, I think it just needs a good visual tweek to emphasize the layering.
7. Impl-related: size/border update now only happens when expand/collapse transition is complete — doesn't feel natural as the scrollbar and borders suddenly jump in your face.

Keeping it in review till further discussion.

Comment by Cheng Hu [ 29/Sep/14 ]

@Mika.

A lot of the code points (2-4) were made because of the LayoutManager in @Sasha's commit, so I'll let @Sasha respond.

But regarding Code 1: This color is quite an odd one. It is the medium green of the admincentral background on older versions of IE which cannot display a transparent background. We checked that it is not any of current pre-defined color variables, however it is used all over the place (just do a text search for the hex value). I have to admit I was surprised that it was not already a pre-defined variable.

Regarding the UI, this is clearly something we should discuss during UX as it is a question of whether the UI specified in this issue is the right way at all to display many rows of icons in admincentral.

Comment by Aleksandr Pchelintcev [ 29/Sep/14 ]

@Mika @ChengHu
2) We discussed that w/ Mika in a verbal discussion and his point is clear. However, I don't see the direct benefit from moving all the UI-element-crafting logic to the connector and making the view totally dumb. I am personally fine with the current approach, where the presenter/connector orchestrates the applaunchers' data and the view takes care of the UI layout and uses the {{LayoutManager}}s' capabilities via presenter. So it is not the presenter who tells the view that the size of some view element has changed, but rather view asks presenter to notify it if some element size has changed.

3) No objections here, since we add a method to the presenter and it's not that tiny anymore - might make sense to remove inline class. (btw VAppLauncher was not used for years, that's why it was ditched).

4) Those one lines are not that clear as they are and refer to the view impl internally, so I dared to conceal them in a utility class.

5)...

6) With scrollbar approach it is at least possible to reach the permanent group tiles, whereas with layering it is not.

7) We could pbbly try to hook to some step function, though I am not sure it's possible with CSS3 transitions we use. But we could try.

Comment by Mikaël Geljić [ 29/Sep/14 ]

@Cheng re: color code, it's just used for the background gradient and curtain of the shell, which isn't a solid color. Still if we can't find any reasonable match within the color palette, let's go for the hex code.

As for rgba colors, I'm interested to see that since modern browsers support it well (only IE8 doesn't, shouldn't be a showstopper).
Only hurdle is that there's no Sass function in Vaadin's compiler to give an rgba color from a variable. Meanwhile I found the dark green $c30/30% opacity to work pretty well 2px solid rgba(62, 89, 0, 0.3) — yes it's supposed to be a 2px border btw.
It works even better if the borders are composited in front of the scrollable content, then it definitely feels like a fold (requires a couple extra divs though, so not a must have).

Comment by Andreas Weder [ 29/Sep/14 ]

Yes, I'd appreciate it if the color variables only contain colors from the official palette, colors from which you're supposed to choose from. If I'm not mistaken, we did change the palette once or twice to get additional shades of gray, but that was because we explicitely needed them.

But as for "hacks" to make colors look "good" or "right" in older or newer browsers, I'd use hex values for those to make the hack explicit, even if it means we have to repetitively use them. If you'd like to make things clearer by documenting the value in a single place, you could use a comment with the hack, the value and the conditions under which it applies next to the color definition it's supposed to offer.

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