Tweak SimpleMenu layout and replace Kickoff
Open, Needs TriagePublic

Tokens
"Love" token, awarded by baberts."Love" token, awarded by alexde."Love" token, awarded by The-Feren-OS-Dev."Love" token, awarded by romangg.
Assigned To
Authored By
manueljlin, Nov 23 2019

Description

After talking and making many mockups in T9041 about changing the UI of Kickoff, it started to look more and more like SimpleMenu with the following changes:

New features:

  • Make username and user picture visible, with PC name on hover like what Kickoff does right now
  • Show categories for recently used apps and documents
  • Show category for Places
  • Be able to pin folders and files in Favorites category
  • Customizable set of power/session buttons visible on the main UI

UI Tweaks:

  • Move the category list to the left, and implement a triangle filter to prevent accidental category changing when moving the cursor from the widget's panel launcher item to the main view
  • Show favorite apps on a separate page rather than on the first page of the "All Applications" category
  • Make Power/session icons always show text labels, and expose the non-visible ones in an overflow menu
  • Enable more KRunner runners so that you can do math and unit conversion, and switch the search categories using the left and right keys
  • Use the Sliding Popups effect to show it and hide it
  • Scroll long grids rather than having discrete pages
  • Make the menu touch the panel like the rest of the popups

Bugfixes:

  • Make long names in grid views become multi-line strings rather than eliding at the end of the first line

1x


hiDPI 2x

svg

There are a very large number of changes, so older changes are hidden. Show Older Changes
ndavis added a comment.Dec 4 2019, 7:46 PM

I could agree with using a grid view for Favorites and a list view for browsing through app categories. We could also put the app comment/generic name near the app name in the list view like Kickoff.

manueljlin added a comment.EditedDec 6 2019, 1:19 PM

Maybe A - Z with a vertical list could look like this, the only problem is where to put the favorites apps and files. Maybe at the top of the apps list could work?
1x


4x

ndavis added a comment.Dec 6 2019, 8:16 PM

What if we just drop the A-Z tab or put it in the sidebar with the rest of the categories?

ndavis added a comment.EditedDec 6 2019, 8:22 PM

Or rather than being Categories/A-Z, do Applications/Files.
In the file view, put the places in the sidebar and folder contents in the main area, like a built in folder view. That could actually be super convenient, but I don't know if it's really needed.

joricke added a subscriber: joricke.Dec 7 2019, 8:28 AM

What if we just drop the A-Z tab or put it in the sidebar with the rest of the categories?

Or how about making it a switchable setting? I'm sure some users prefer just having categories and couldn't care less about a A-Z order appearing while others are the opposite of that and then there are some who don't care at all.
Benefit of making that a setting is a decluttering of the interface (which is shaping up really nice, btw, great job @manueljlin ).

What if we just drop the A-Z tab or put it in the sidebar with the rest of the categories?

Or how about making it a switchable setting? I'm sure some users prefer just having categories and couldn't care less about a A-Z order appearing while others are the opposite of that and then there are some who don't care at all.
Benefit of making that a setting is a decluttering of the interface (which is shaping up really nice, btw, great job @manueljlin ).

That's a good point too. While I can see a use for being able to sort alphabetically without switching a setting, it may be better not to add even more items to the category sidebar.

manueljlin added a comment.EditedDec 7 2019, 11:50 AM

So something like this, right?

Edit1:

ndavis added a comment.Dec 7 2019, 2:17 PM

So something like this, right?

Yes, that looks really slick. A lot of functionality, but presented in a simple way.

I really like the idea of making Files a tab that shows all the files from various places. Could you also add a "Recent" category for the file list?

Or actually, maybe the Favorite categories for both apps and files should be merged and be "Recent & Favorite", showing both, separated into different sections, like this:

Favorites
=========
- Discover
- Dolphin
- Firefox
- System Settings

Recently used
=============
- Kate
- Konsole
- Elisa
- etc

Thoughts?

ndavis added a comment.Dec 7 2019, 5:48 PM

I really like the idea of making Files a tab that shows all the files from various places. Could you also add a "Recent" category for the file list?

Or actually, maybe the Favorite categories for both apps and files should be merged and be "Recent & Favorite", showing both, separated into different sections, like this:

Favorites
=========
- Discover
- Dolphin
- Firefox
- System Settings

Recently used
=============
- Kate
- Konsole
- Elisa
- etc

Thoughts?

I think combining multiple categories in one view leads to a cluttered look and makes the categories involved less useful because they don't have enough dedicated space. I know I'm not everyone, but I have a lot of favorites. The only menu that can fit all of them in the view at once is actually Simple Menu.

Another thought, but maybe off-topic: Recently used files relies on Baloo right? We should probably disable that category when users aren't using Baloo.

ndavis added a comment.EditedDec 7 2019, 5:54 PM

Something else to think about:
The search bar is put on the same side of the screen as the content area on the right. Should it only search for content related to the selected tab or search for all content at once? I feel like the layout in the most recent mockup works best for finding content related to the selected tab. Other menus and KRunner search for both, although KRunner is more organized with separators, so doing the first type of search would not be consistent with typical behavior. However, with the Files tab being basically an integrated folder view (with Places sidebar), users may actually prefer only searching for files in the file tab and only for apps in the apps tab. We won't know for sure unless we can test it. If we do use separated search types, we should say "Search for applications..." or "Search for files..." in the placeholder text.

hein added a comment.Dec 8 2019, 12:48 AM

No, Recently Used works via KActivitiesStats.

manueljlin added a comment.EditedDec 8 2019, 10:33 AM

What if we just drop the A-Z tab or put it in the sidebar with the rest of the categories?

The "All applications" category probably should list apps A-Z, instead of changing the entire menu to one way or another, that way you can use both options quickly.


I really like the idea of making Files a tab that shows all the files from various places. Could you also add a "Recent" category for the file list?

Or actually, maybe the Favorite categories for both apps and files should be merged and be "Recent & Favorite", showing both, separated into different sections, like this:

Favorites
=========
- Discover
- Dolphin
- Firefox
- System Settings

Recently used
=============
- Kate
- Konsole
- Elisa
- etc

Thoughts?

Hmm, so like this old mockup but with categories instead of applications on the left


I don't know, kind of feels cluttered


Something else to think about:
The search bar is put on the same side of the screen as the content area on the right. Should it only search for content related to the selected tab or search for all content at once? I feel like the layout in the most recent mockup works best for finding content related to the selected tab. Other menus and KRunner search for both, although KRunner is more organized with separators, so doing the first type of search would not be consistent with typical behavior. However, with the Files tab being basically an integrated folder view (with Places sidebar), users may actually prefer only searching for files in the file tab and only for apps in the apps tab. We won't know for sure unless we can test it. If we do use separated search types, we should say "Search for applications..." or "Search for files..." in the placeholder text.

The safest way to do this probably is to list apps first when you are on the apps tab and files first when you are on the files tab.


I think we need colourful icons here instead of monochrome icons since we are using colourful icons in other sidebars.

I think it might be better to use 16px or 22px monochrome icons because that way the contrast would be way better with dark themes, but if anyone doesn't like it I can change it to the current ones.

If nobody likes the idea of combines favorites/recents, we can drop that.

Something else to think about:
The search bar is put on the same side of the screen as the content area on the right. Should it only search for content related to the selected tab or search for all content at once? I feel like the layout in the most recent mockup works best for finding content related to the selected tab. Other menus and KRunner search for both, although KRunner is more organized with separators, so doing the first type of search would not be consistent with typical behavior. However, with the Files tab being basically an integrated folder view (with Places sidebar), users may actually prefer only searching for files in the file tab and only for apps in the apps tab. We won't know for sure unless we can test it. If we do use separated search types, we should say "Search for applications..." or "Search for files..." in the placeholder text.

I really appreciate how the search in all of these menus is a global one rather than being restricted to the current category. Personally I'd like to see the search here having 100% feature parity with KRunner, because KRunner is not very discoverable right now as it's only activated with a keyboard shortcut that you have to already know.

Should I change the task image to this one then?

So here's my recommendation: we keep the app grid, since apps are primarily visual and the expanded click targets are good for touch:

But when viewing files, we switch to a list style, because the items here are primarily distinguished by their text:

I'd also like to make sure there's a "Recents" category for files. The "Recent documents/files" feature is one of the ways that less-experienced users tend to interact with their files, because they're less knowledgeable about the actual locations where their files live.

ndavis added a comment.Dec 9 2019, 5:29 PM

@ngraham +1, sounds reasonable

Seems like the best way to do it, yeah. I will add a Recents category for files and change the image from the task. I only have one question, should the size change when the tabs are switched?


or not

which would be easier to implement but, look at that unused space, oof.

ndavis added a comment.EditedDec 9 2019, 7:05 PM

Seems like the best way to do it, yeah. I will add a Recents category for files and change the image from the task. I only have one question, should the size change when the tabs are switched?


or not

which would be easier to implement but, look at that unused space, oof.

Why not make the grid 4 spaces wide? Then make the list view match that and you'll have a fairly reasonable amount of space for both views.

ndavis added a comment.Dec 9 2019, 7:12 PM

One more thing, should the file view be a list view or a tree view? I personally find tree views for file browsing almost universally superior, but I'm not certain that it's appropriate. Simple Menu isn't meant to replace dolphin, but it could be a fast launching point.

manueljlin added a comment.EditedDec 9 2019, 7:16 PM

Why not make the grid 4 spaces wide? Then make the list view match that and you'll have a fairly reasonable amount of space for both views.

Hmm, while it does the job, I don't know about sacrificing 4 icons

ndavis added a comment.Dec 9 2019, 7:28 PM

Why not make the grid 4 spaces wide? Then make the list view match that and you'll have a fairly reasonable amount of space for both views.

Hmm, while it does the job, I don't know abut sacrificing 4 icons

You could make the icons 48px (their native size), but that would make the buttons smaller.

probably not the best way to do this

ndavis added a comment.Dec 9 2019, 7:44 PM

yeah, gotta have room for the labels

ndavis added a comment.Dec 9 2019, 7:46 PM

Buttons should probably be this large:

One more thing, should the file view be a list view or a tree view? I personally find tree views for file browsing almost universally superior, but I'm not certain that it's appropriate. Simple Menu isn't meant to replace dolphin, but it could be a fast launching point.

The lists of recent and favorite documents have to be list views because they're not more than one level deep. As for the proposed categories that show the contents of various folders, it's tempting, but in general users do not understand tree views. For that reason I'm a tiny bit wary of including these categories in the first place. People probably shouldn't be browsing the file system in SimpleMenu.

@manueljlin We should also make sure that long app names become multi-line strings instead of being elided.

Is it necesseray for the "Search here" input field to have this not so pretty border and padding around it? Why not fuse it with the entire cell it's located in?

This would look more in line with how the avatar is represented, as well as how much space all buttons on the frame are taking up.

I don't agree that it's ugly. We normally use LineEdits for search boxes, so people will recognize it faster like that. The username/avatar can't be interacted with, so making them look similar sends the wrong message.

Well compared to the remaining UI elements that _can_ be interacted with it does look out of place or odd at least. Yes I agree that overall line edits are used for such things and it'd break up consistency, but it doesn't look "right" as it is right now. I'll try to work some thoughts into image later. 

  1. Dez. 2019, 13:05 von noreply@phabricator.kde.org:

ndavis added a comment.

I don't agree that it's ugly. We normally use LineEdits for search boxes, so people will recognize it faster like that. The username/avatar can't be interacted with, so making them look similar sends the wrong message.

TASK DETAIL
https://phabricator.kde.org/T12192

To: > hein, ndavis
Cc: > KonqiDragon, joricke, ndavis, mart, rikmills, ngraham, hein, pedrogomes1698, ognarb, manueljlin, LeGast00n, The-Feren-OS-Dev, cblack, konkinartem, ian, jguidon, hannahk, Ghost6, jraleigh, MrPepe, fbampaloukas, squeakypancakes, alexde, IohannesPetros, GB_2, trickyricky26, ragreen, mglb, crozbo, ZrenBot, firef, alexeymin, skadinna, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, aaronhoneycutt, abetts, sebas, apol, ahiemstra, mbohlender

We need to use a visible text field. As Noah said, it's important for things that are the same to look the same. Visual Consistency is important for learnability and speed.

@manueljlin Now that I'm looking at the mockups some more, I wonder if we should swap the position of the power/session buttons and the search field. That would be a bit closer to the current layout and also more conventional in general (typically search fields are more towards the top of a UI than the bottom).

It used to be like that in the other task and was swapped around to avoid accidental clicks but if no one complains I'll change it

We don't have the concern about accidental clicks anymore because we no longer have tabs directly above those buttons.

I think the layout is entirely fine now if not perfect, TBH, based on the latest comment to have a design in it. The search bar is placed near the menu so users see it first, and the search bar is usually always near the panel.

As for power buttons: I'm fine with them on the top to be honest, though I'd appreciate the option to disable the power button labels to instead have tooltips there if the user desires that.

Just in case we do go with the Simple Menu idea, here's the Feren OS mod of Simple Menu to save you flipping the categories and apps list:

Though, you'd also need to fix the fact the menu button isn't highlighted once the menu is summoned.

What's important is minimizing mouse travel time for common actions and maximizing it for rare ones. Where is the cursor normally? Will it be over the launcher button or somewhere in the middle of the screen? From that I would decide if the search field belongs to the top or not. The system buttons should be on the other side of where the mouse cursor normally is to maximize travel time for these rare interactions.

Another question is if KRunner functionality should be integrated and if yes how to depict it. If the search field is on the top we could show program icons below and additional results like 2+2 above. Or all of it in list form in the main area.

What's important is minimizing mouse travel time for common actions and maximizing it for rare ones. Where is the cursor normally? Will it be over the launcher button or somewhere in the middle of the screen? From that I would decide if the search field belongs to the top or not. The system buttons should be on the other side of where the mouse cursor normally is to maximize travel time for these rare interactions.

Another question is if KRunner functionality should be integrated and if yes how to depict it. If the search field is on the top we could show program icons below and additional results like 2+2 above. Or all of it in list form in the main area.

I'd expect the search field to be automatically focused for text input just like the other menus, so location doesn't matter as long as it's visible.

The common case is the user clicking on the panel item to launch it, which means that the cursor will be in the bottom-left corner. This makes me realize that we've reversed the position of the category list and might want to consider moving it back to the right side where it currently is, or else there's the risk of accidentally changing the category when moving the cursor up and to the right to click on one of the entries in the view.

The common case is the user clicking on the panel item to launch it, which means that the cursor will be in the bottom-left corner. This makes me realize that we've reversed the position of the category list and might want to consider moving it back to the right side where it currently is, or else there's the risk of accidentally changing the category when moving the cursor up and to the right to click on one of the entries in the view.

If we're using hover to change categories, that's a good point.

Yes, the categories change on hover.

So something like this?

This is against the flow of the logic: from high-level categories at the root of the menu to the left to the more specific to the right.

I remember there was a patch to context menus some time ago that allowed to move a cursor in an angle over the context menu such that it wouldn't activate the items below. I don't remember the details though. Somebody else knows more?

So something like this?

It might look better with the Avatar on the left of the username.

I think visually, I prefer the sidebar on the left.

Could to swap shutdown/session place and the search?

I like more this, when shutdown/session place on the top and categories on the left.

manueljlin added a comment.EditedDec 11 2019, 7:45 PM

Honestly, I'm against using categories on the right too, it just feels wrong tbh.

edit: meant to say right not left oops

This is against the flow of the logic: from high-level categories at the root of the menu to the left to the more specific to the right.

I remember there was a patch to context menus some time ago that allowed to move a cursor in an angle over the context menu such that it wouldn't activate the items below. I don't remember the details though. Somebody else knows more?

Yes, the concept of the "triangle menu filter" Kickoff has this now. If we keep the categories on the left, Simple Menu should definitely get one too. If we decide to keep the category list there, it's a must-have.

Seeing the mockups with the category list on the right, I kind of agree that visually it's nicer to keep it on the left. So maybe let's stay with that and then request the implementation of a triangle menu filter for the category list to prevent accidental category switching when moving the mouse over them quickly to get to the main view.


Ok, now both tabs have the same size (because the files tab displays now extra info) and there's even a couple of mockups for the krunner style search plugins.

Also, when the search bar is focused and the user has searched for something that has many options, pressing the left/right keys should change the category.
For example, in the lower right corner of every mockup there are multiple categories displayed (Applications/Pictures/Documents) so pressing right would directly select accesories-character-map.svg because it's the first option in the Pictures category.

Perfect.

Shipit!

ngraham updated the task description. (Show Details)Dec 14 2019, 11:17 PM
ngraham updated the task description. (Show Details)Dec 14 2019, 11:25 PM
manueljlin updated the task description. (Show Details)Dec 15 2019, 11:56 AM
zachus added a subscriber: zachus.Dec 16 2019, 3:57 PM

I stick with the old trusty kmenu, come hell or highwater.

ndavis added a comment.EditedDec 16 2019, 4:58 PM

I stick with the old trusty kmenu, come hell or highwater.

You mean Kicker (https://userbase.kde.org/images.userbase/c/c8/Kicker.png)? This isn't replacing Kicker.

Looks great!

hein added a comment.Dec 23 2019, 4:20 PM

Some notes while I start working on implementation:

  • Currently I'm planning to have a "Recent" section on both the Apps and Files tabs, though it's not included in the mockups.
  • I'm not sure what the status of the discussion is on what should be shown as icons and what as lists. My current plan is to default everything in "Apps" to icons except "All Applications" as list, default everything in "Files" to list, and have a context menu action to switch in every view that just remembers the choice. Search results are a list, too.
  • I kind of still like the pagination that the original Simple Menu does. I'm considering having lists be vertically scrollable, but use the pages for the icon views.
  • It's quite tricky to sort out what should be hover-activated and what should be click-activated in this UI design. I'm thinking the Apps and Files tabs need to be click-activated, hover there would be incredibly annoying.
  • I'll see if I can bring some sort of alphabetical categorization a la Dashboard into the All Applications view (maybe as a later round tweak though).
In T12192#214863, @hein wrote:

Some notes while I start working on implementation:

  • Currently I'm planning to have a "Recent" section on both the Apps and Files tabs, though it's not included in the mockups.

That's fine.

  • I'm not sure what the status of the discussion is on what should be shown as icons and what as lists. My current plan is to default everything in "Apps" to icons except "All Applications" as list, default everything in "Files" to list, and have a context menu action to switch in every view that just remembers the choice. Search results are a list, too.

This sounds fine, but I'm not sure if a context menu option to switch between list and grid is necessary.

  • I kind of still like the pagination that the original Simple Menu does. I'm considering having lists be vertically scrollable, but use the pages for the icon views.

I do too because it makes the contents of the view move less, but it's not as obvious as a scrollbar, so I'm torn.

  • It's quite tricky to sort out what should be hover-activated and what should be click-activated in this UI design. I'm thinking the Apps and Files tabs need to be click-activated, hover there would be incredibly annoying.

I agree with this. The sidebar categories can be hover activated while the Applications/Files tabs can be click to activate.

  • I'll see if I can bring some sort of alphabetical categorization a la Dashboard into the All Applications view (maybe as a later round tweak though).

You mean this?

A__________
contents
B__________
contents
C__________
contents

Sounds reasonable as long as the section headers don't take up too much space.

In T12192#214863, @hein wrote:

Some notes while I start working on implementation:

  • Currently I'm planning to have a "Recent" section on both the Apps and Files tabs, though it's not included in the mockups.

Sounds good.

  • I'm not sure what the status of the discussion is on what should be shown as icons and what as lists. My current plan is to default everything in "Apps" to icons except "All Applications" as list, default everything in "Files" to list, and have a context menu action to switch in every view that just remembers the choice. Search results are a list, too.

I know Marco will appreciate being able to choose the display style. :) I wonder if this choice should be in the settings window though and be less granular, rather than having a per-view context menu action.

  • I kind of still like the pagination that the original Simple Menu does. I'm considering having lists be vertically scrollable, but use the pages for the icon views.

Maybe I'm fighting the tide here bug I really hate pagination vs scrolling. Are there any concrete advantages to pagination or is it just a stylistic judgment call?

  • It's quite tricky to sort out what should be hover-activated and what should be click-activated in this UI design. I'm thinking the Apps and Files tabs need to be click-activated, hover there would be incredibly annoying.

Agreed.

  • I'll see if I can bring some sort of alphabetical categorization a la Dashboard into the All Applications view (maybe as a later round tweak though).

Sounds good to me!

In T12192#214863, @hein wrote:

Some notes while I start working on implementation:

  • Currently I'm planning to have a "Recent" section on both the Apps and Files tabs, though it's not included in the mockups.

That makes sense

  • I'm not sure what the status of the discussion is on what should be shown as icons and what as lists. My current plan is to default everything in "Apps" to icons except "All Applications" as list, default everything in "Files" to list, and have a context menu action to switch in every view that just remembers the choice. Search results are a list, too.

Nice, you can add the apps' descriptions and align them like this so it doesn't have unused space:

  • I kind of still like the pagination that the original Simple Menu does. I'm considering having lists be vertically scrollable, but use the pages for the icon views.

Hmm, I don't know if it should be different for both the vertical list and the icon grid

  • It's quite tricky to sort out what should be hover-activated and what should be click-activated in this UI design. I'm thinking the Apps and Files tabs need to be click-activated, hover there would be incredibly annoying.

Yup

ndavis added a comment.EditedDec 23 2019, 7:24 PM
In T12192#214863, @hein wrote:
  • I kind of still like the pagination that the original Simple Menu does. I'm considering having lists be vertically scrollable, but use the pages for the icon views.

Maybe I'm fighting the tide here bug I really hate pagination vs scrolling. Are there any concrete advantages to pagination or is it just a stylistic judgment call?

I think the main advantages (ignoring style) are that the contents of the view don't move as much, making it easier to scan each page with the eyes and you can scroll a lot more at a time with the mouse wheel. The disadvantage is that it's not as familiar and is probably more annoying for people who use touch gestures since you have to swipe a page at a time. The safer option is probably to just use vertical scrolling. Vertical scrolling is also more consistent with other Plasma widgets and KDE applications.

There's a missing input device: the humble laptop touchpad. :) I find that paging is really awkward with a laptop touchpad.

There's a missing input device: the humble laptop touchpad. :) I find that paging is really awkward with a laptop touchpad.

Ouch, I remember how bad it is on those websites that lock the view until you scroll enough to change it with the two fingers scrolling but you accidentally scroll like 3 times

One last thing it might be nice to have is the ability to make the set of power/session buttons shown in the main UI customizable. So by default it would show Shut Down, Restart, and Log Out, but you could replace those with alternatives if you prefer, and then the overflow menu would show different items.

ngraham updated the task description. (Show Details)Thu, Dec 26, 9:07 PM
hein added a comment.Thu, Dec 26, 9:08 PM

This is also possible in all of the other menus based on the backend, so that's sensible, yeah.

Should it be possible to configure the icon size for grid view?

IMO probably not, or at least not to make them smaller, because small cells in a grid view mean almost no space for the label underneath them. The grid cells need to have a certain minimum width if they have labels or else there just isn't enough room for them.

manueljlin updated the task description. (Show Details)Fri, Dec 27, 3:45 PM

Readded files tab as grid and apps tab as list, and tweaked the search padding

hein added a comment.EditedSat, Dec 28, 1:05 AM

Should it be possible to configure the icon size for grid view?

Let's not go crazy and try to do the 3.0 before the 1.0 :). These mockups were a lot simpler a few weeks ago, and I'm already a bit unsure if the increase in complexity was warranted. Let's start with something lean and make very careful adjustments thereafter, or we'll end up with a kitchen sink menu again.

In T12192#215384, @hein wrote:

Should it be possible to configure the icon size for grid view?

Let's not go crazy and try to do the 3.0 before the 1.0 :). These mockups were a lot simpler a few weeks ago, and I'm already a bit unsure if the increase in complexity was warranted. Let's start with something lean and make very careful adjustments thereafter, or we'll end up with a kitchen sink menu again.

I don't think anyone would complain too hard if you only implemented the Applications tab and left the Files tab for another release.

Agreed. As long as recent docs get into the 1.0 version (maybe in the standard category list, with no applications/files tabs), I think that's all we really need outta SimpleMenu with respect to files. Being able to access your Places Panel locations and/or the XDG locations are nice-to-haves, not need-to-haves.

ngraham moved this task from Backlog/Planned to Sent to dev on the VDG board.Sat, Dec 28, 8:37 PM
ngraham moved this task from To Do to Work in Progress on the Plasma board.
baberts added a subscriber: baberts.
chempfling added a subscriber: chempfling.EditedFri, Jan 3, 9:58 AM

Sounds awsome, i have to play with its accessibility later.
Would be cool to keep accessibility in mind just from beginning to have a proper focus and keyboard handling :). I can take a look at the accesdibility roles and labels then if wanted.

hein added a comment.Sat, Jan 4, 8:25 AM

@chwmpfling Definitely the plan! Will appreciate your review

In T12192#216454, @hein wrote:

@chwmpfling Definitely the plan! Will appreciate your review

Wow, the menu is very accessible :). Maybe here and there some tweaks if the design is complete but overall a huge benefit to kickoff what is currently not accessible at all.

I m very impressed :). its almost as accessible as the dash menu is. very cool!

i tested the version attached at this comment:

Just in case we do go with the Simple Menu idea, here's the Feren OS mod of Simple Menu to save you flipping the categories and apps list:

Though, you'd also need to fix the fact the menu button isn't highlighted once the menu is summoned.

Its also keyboard only navigate-able :).
there is only a detail i would like to change (with accessibility in mind)
the grid view (where the icons are currently placed) should not change the page by pressing left or right arrow if your current focus is the first or last element at the line / row.

Background:
Blind people don't know how many elements do exist in an line/ row. so they have to try out by "brute force" when the end of line is reached and they can move to next line. In case of accessibility "lists" are better to navigate (as they are just "one dimensional". People can then reach all elements just by pressing arrow up / down. if we use an grid we should provide some continuous navigation as well (like lists do). for this i can come up with 2 ideas:

  1. if the right end of line is reached and the user is pressing arrow right the focus should move to second line first element. if the first element has the focus and i press arrow left it should move to the most upper line and focus the last element. if the page could change by pressing arrow up/ down (if the focus is on first/ last line) instead

or

  1. pressing tab should focus the next element in the grid or even the lists. so pressing tab will bring you to next line if you reached the last element. Shift + Tab will bring you to the previouse element. Ctrl + Tab should change the panel (like move the focus from the category list to the grid).

both navigation solutions are very common and just fine.

just an idea :)

rin added a subscriber: rin.Thu, Jan 9, 7:41 PM