Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GUI feature/accessibility request: different number of columns #1952

Open
leaumar opened this issue Jun 23, 2024 · 1 comment
Open

GUI feature/accessibility request: different number of columns #1952

leaumar opened this issue Jun 23, 2024 · 1 comment
Labels
common: uncommon Most users are unlikely to come across this or unexpected workflow severity: minor Impairs non-critical functionality or suitable workarounds exist type: enhancement New feature or request

Comments

@leaumar
Copy link
Contributor

leaumar commented Jun 23, 2024

Usecase: I have 15 cards so far and often only remember at the last moment that I need to get one out because only a minority of shops have cards worth using. Samsung S23 fyi.

Problem: they're displayed in (hardcoded) 2 columns, making them overly large and resulting in a scrolling view. Finding the right one is often a hassle that takes me longer than I feel it should, because I find them hard to recognize visually (lack of use and inconsistent designs) and they don't have a position you can memorize. The scrolling and closeup detail of each card effectively takes away the "overview" aspect of the main page.

Screenshot_20240623_194202_Catima

For comparison, my phone apps menu is a single page filled edge to edge with nameless icons and that's awesome for me. Their locations hardly change and most apps are easily recognized when scanning left or right from the expected position (except google's awful new icons, just blobs of random colors with edges that don't make any material sense), so it comes down to finding them once and then muscle memory takes over.

Screenshot_20240623_194206_Nova Launcher

Request: let the user pick the desired number of columns within a reasonable range, depending on implementation flexibility. I see that in landscape the view changes to 3 columns already, so perhaps it already is just a variable or we can generalize the layouts to a single dynamic layout, and then expose it as a setting. A 3 or 4 wide grid with smaller cards would suit me much better.

If you think off the top of your head that it can be done with the existing code and could point me in the right direction, I'm willing to try writing it myself.

On a sidenote for a possible second ticket, if the view's gravity is top-down, it might be worth considering changing it to bottom-up since adding columns will create vertical blank space. Phones are tall these days and most people hold them from the bottom I believe, so the bottom half of the screen (where the keyboard usually sits) is much easier to reach, while reaching to the top usually requires changing your grip, and doing that one-handed (while shopping) risks dropping the phone. I notice a lot of samsung apps leave the top 1/3rd of the screen in menus blank or non-interactive and actually kinda like it.

@TheLastProject
Copy link
Member

Sorry it took me so long to respond to this.

Request: let the user pick the desired number of columns within a reasonable range, depending on implementation flexibility. I see that in landscape the view changes to 3 columns already, so perhaps it already is just a variable or we can generalize the layouts to a single dynamic layout, and then expose it as a setting. A 3 or 4 wide grid with smaller cards would suit me much better.

Currently, the amount of columns is set by the main_view_card_columns. It defaults to 2 except for screens of a width over 600dp, where it uses 3 columns: https://github.com/search?q=repo%3ACatimaLoyalty%2FAndroid%20main_view_card_columns&type=code

It is probably reasonable to add a setting in Settings for this, something like "Display columns", which defaults to "Automatic" and can be set to a few reasonable values, with automatic using the currently hardcoded default.

I'm not sure if it's worth making it two settings, the "portrait"/"landscape" difference we have right now is more pure coincidence, I'm not sure if many people would be interested in that but it would make the Settings screen more complex.

If you think off the top of your head that it can be done with the existing code and could point me in the right direction, I'm willing to try writing it myself.

The way Android manages settings is always somewhat complex to me and I always have to look back how it works again, but it seems to me that you could set another setting in Settings for this (similar to theme), with the default "Automatic" storing it as null or something in the settings database and then use a setSpanCount if the setting is not null to override it in onCreate. Something similar to

GridLayoutManager layoutManager = (GridLayoutManager) cardList.getLayoutManager();
if (layoutManager != null) {
layoutManager.setSpanCount(getResources().getInteger(R.integer.main_view_card_columns));
}

Feel free to take a look if you want :)

On a sidenote for a possible second ticket, if the view's gravity is top-down, it might be worth considering changing it to bottom-up since adding columns will create vertical blank space. Phones are tall these days and most people hold them from the bottom I believe, so the bottom half of the screen (where the keyboard usually sits) is much easier to reach, while reaching to the top usually requires changing your grip, and doing that one-handed (while shopping) risks dropping the phone. I notice a lot of samsung apps leave the top 1/3rd of the screen in menus blank or non-interactive and actually kinda like it.

It's currently just regular top-down yeah. Android XML can be quite painful and it would seem to me a lot of the app would need refactoring for that so we'd surely need some design mockups first before we do something like this (and people seem to quite like the current design and tend to complain about change so this needs to be done very carefully) 😅

@TheLastProject TheLastProject added type: enhancement New feature or request severity: minor Impairs non-critical functionality or suitable workarounds exist common: uncommon Most users are unlikely to come across this or unexpected workflow labels Jun 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
common: uncommon Most users are unlikely to come across this or unexpected workflow severity: minor Impairs non-critical functionality or suitable workarounds exist type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants