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

Redesign settings #452

Closed
klues opened this issue Nov 14, 2024 · 26 comments
Closed

Redesign settings #452

klues opened this issue Nov 14, 2024 · 26 comments
Labels

Comments

@klues
Copy link
Contributor

klues commented Nov 14, 2024

Currently the menu "Settings" is just a long list of various settings and I think as the list grows and grows, it should be better organized. There are in fact three types of settings:

  • general device settings: for all users, but only on the current device, e.g. Application language, Passcode for unlocking user interface, Synchronize navigation and locked/fullscreen state for online users
  • local user settings: editable for each user, but not synchronized, e.g. Preferred voice (shouldn't be synchronized, because available voices differ between devices)
  • synchronized user settings: most settings like input options, colors, convert mode of labels, ...

And there probably should be a separation of topics like:

My assumptions and questions:

  • I assume that System / General should hold all options which are independent from the user and all other options are user-dependent.
  • Probably it's not necessary to make it transparent to the user if it's a setting across devices or not, is it?!
  • should the input settings stay at their separated place above the grid in the main view or also move to the settings (or both)?
  • my first thought would be to introduce tabs to the settings page for the categories, similar to the tabs in the "edit element" modal:
    image

Additional question: how to handle situations, where the same thing could be set globally, for one grid or one element (e.g. cell format options)? Maybe I would add an accordion "Advanced appearance options" to the "General tab" in edit grid item and put the suitable cell format options there along with other not often used options like "Don't add element to collect element" or "Toggle in collection element..." and maybe also "custom background color"

If we need the possibility to set options on grid-level, probably the way to go would be to add a menu item Grid options in this menu:
image

Maybe the "Change grid dimensions" could be changed to a more generic modal, where the grid dimensions and other grid-level options should be available, e.g. also deactivating the global grid, see #399

@arasaac-dga and @ms-mialingvo please tell me your thoughts.

@arasaac-dga
Copy link
Collaborator

We are happy that you are planning the development of this issue. It will be an advance in the usabilty, sure. We agree, in general, with your proposal, but due it's an important change give us some days (until next week) to think in how organice the option in tabs as you comment and prepare a visual proposal. We will reply too to other questions too.

@ms-mialingvo
Copy link
Collaborator

ms-mialingvo commented Nov 14, 2024

Currently when right-clicking on a blank cell the option 'new' with various sub-options shows up. If you click on 'new element', a pop-up window appears with the different options for a new element. That's not the case for the other sub-options, there it just inserts the element end then you again have to click on edit to open the pop-up.
So, suggestions here:

  • for clicking on 'new collection element' and 'new prediction element' also to show the pop-up window with the options specific for that element.
  • In the action tab of collect element only the speak collect element actions would be available.
  • In the action tab of prediction element only the dictionary selection would be available.
  • Similar for 'youtube player'.
  • And then an additional option 'special element' which would then include all the other possible actions.
  • Instead of having to right-click and choose from drop-down, clicking on an empty cell would directly open a pop-up 'choose new element' or so, with all the different element options (normal element, collect element, prediction element etc.)

Currently for the 'more' button, if no element is selected, the drop-down has the option to insert new element and various options mostly on (single-)grid level. Once an element is selected, it has options specific for an element but also still options for (single-)grid level.
Suggestions:

  • instead of the 'more' button, have two separate buttons for grid, element (the pop-up window content would change depending on which type of element is selected as suggested above), possibly grid set
  • or automatically change the contents of the 'more' button depending on whether a button is chosen or not. In either case, there would be a strict separation of (single-)grid-level options and button-level options
    Not sure if this already would cover all the options, outside of the system settings. I started an excel to try to get an overview of the different options... https://docs.google.com/spreadsheets/d/1pSU3CYc87yRee8xRVURigHcbe59rptymEExF9fAPvuI/edit?usp=sharing

@ms-mialingvo
Copy link
Collaborator

Another suggestion, that would make accessibility better: fields instead of drop-downs except if not possible (like for example not for the language drop-down) or suboptimal due to amount of elements and less important feature (like for the color category). Something like this:
image
edit grid item

@ms-mialingvo
Copy link
Collaborator

ms-mialingvo commented Nov 16, 2024

I assume that System / General should hold all options which are independent from the user and all other options are user-dependent.

Yes.

Probably it's not necessary to make it transparent to the user if it's a setting across devices or not, is it?!

Is there any user setting besides Preferred voice that is not synchronised? If not, maybe just a short remark at Preferred voice?

should the input settings stay at their separated place above the grid in the main view or also move to the settings (or both)?

It would make sense for me for them to be at the user settings, together with the other 'general input settings'

my first thought would be to introduce tabs to the settings page for the categories, similar to the tabs in the "edit element" modal

see excel

how to handle situations, where the same thing could be set globally, for one grid or one element (e.g. cell format options)? Maybe I would add an accordion "Advanced appearance options" to the "General tab" in edit grid item and put the suitable cell format options there along with other not often used options like "Don't add element to collect element" or "Toggle in collection element..." and maybe also "custom background color"

I think an accordion with a very clear title like 'overwrite default settings' or so. I wouldn't mix it with other options for clarity.

I have edited the excel and I think it should now have all current and most possible future features.
Collect element settings (default, as I do think individual is still needed for some cases) makes more sense in the 'grid set' settings than in the 'user' settings to me

@ms-mialingvo
Copy link
Collaborator

instead of the 'more' button, have two separate buttons for grid, element (the pop-up window content would change depending on which type of element is selected as suggested above), possibly grid set
or automatically change the contents of the 'more' button depending on whether a button is chosen or not.

...or: If nothing is selected, the "more" shows the text 'edit grid'. If a cell is selected the text changes to 'edit grid element' (or 'edit collect element' etc.). If multiple cells are selected it changes to 'edit grid elements'.
editbutton

@arasaac-dga
Copy link
Collaborator

We present you our proposal with aprox to the options and distribution of them in tabs and for grid and cell edit.

SETTINGS

Diapositiva1
Diapositiva2
Diapositiva3
Diapositiva4
Diapositiva5

As you can see, and reply to one of your questions, we consider that "Input options" must be in both places (where is now and in a specific tab inside Settings).

On the other hand we consider that language/voice always must be together due their correlation. About to make transparent or not the voice sync perhaps an icon with a alt-text could be the less intrusive and clarify the voice depends of each device and that is not sync between different devices.

We have added a new tab called "Output options" where we add options related to the output (like accumulated phrase or text corrections with IA). Anyway, if you consider giving this tab another name we are open to discuss because we have no clear idea if this name is the best.

In General settings we consider it important to clarify with a header the lock/unlock (better than actual Miscellaneous) due many people ask about the passcode and don't know that is in general settings. So, a clearer header, perhaps, helps.

In appearance it would be interesting to make conditional the background or border configurations and only show the specific configuration when you select it in the previous menu. So, if you select a border in Color Mode, border settings are shown and reversed.

BOARD CONFIGURATION

Diapositiva6

We agree to transform the actual Grid Dimension window to configure the Grid appearance. We only considered the options included in our screenshot to give response to special boards like Keyboards. More options - More complex to users. So with Font-Size and Line-Height is enough.

We called it "Grid appearance" in the Menu but are open to other suggestions.

  • or automatically change the contents of the 'more' button depending on whether a button is chosen or not. In either case, there would be a strict separation of (single-)grid-level options and button-level options

...or: If nothing is selected, the "more" shows the text 'edit grid'. If a cell is selected the text changes to 'edit grid element' (or 'edit collect element' etc.). If multiple cells are selected it changes to 'edit grid elements'.

We agree with @ms-mialingvo with both things 1) More menu change options when you select or not a cell to edit to show only options needed in each case and 2) the button that proposes to be next to "Editing off".

CELL CONFIGURATION

Diapositiva7

Here we consider that an accordion in General Tab under the label is enough. We consider that, for text editing, only font-color is needed and background or border color (depends on the Color Mode configuration in Communicator Settings). More text configurations add complexity in our opinion.

Currently when right-clicking on a blank cell the option 'new' with various sub-options shows up. If you click on 'new element', a pop-up window appears with the different options for a new element. That's not the case for the other sub-options, there it just inserts the element end then you again have to click on edit to open the pop-up. So, suggestions here:

  • for clicking on 'new collection element' and 'new prediction element' also to show the pop-up window with the options specific for that element.
  • In the action tab of collect element only the speak collect element actions would be available.
  • In the action tab of prediction element only the dictionary selection would be available.
  • Similar for 'youtube player'.
  • And then an additional option 'special element' which would then include all the other possible actions.

We don't see the need to change it as @ms-mialingvo proposed because cells like youtube, text prediction,.... are special cells preconfigured and most of the people never edit them. So we don't consider that open edit when created is needed. Due to preconfigured actions (with the right action added) we don't consider that it is needed to limit the new action menu (showing only the action related to the special cell because, perhaps, it could be neccesary in the same case to add another action instead of the actual one.

  • Instead of having to right-click and choose from drop-down, clicking on an empty cell would directly open a pop-up 'choose new element' or so, with all the different element options (normal element, collect element, prediction element etc.)

​We consider it more important that @klues create the cell where you make a right click than make click in order to create a new cell and select the kind of cell from a modal window. We don't consider that to save time. It's more problematic that the cell is not created where you have made a right click actually.

Another suggestion, that would make accessibility better: fields instead of drop-downs except if not possible (like for example not for the language drop-down) or suboptimal due to amount of elements and less important feature (like for the color category).

We only see this suggestion suitable for 2-3 options dropdown menus (like ARASAAC-OpenSymbols). For the action menu we don't see it. So, if there is some other 2-3 option drop-down menu it is posible to change it with buttons as @ms-mialingvo proposed. 

We hope don't forget anything ;-)

@ms-mialingvo
Copy link
Collaborator

I don't have much time now and will be busy these next three days so will study your proposals later in the week in detail, but just some first thoughts:

  • Combining 'general settings' and 'user settings' into one setting interface with several tabs is fine with me, given that there aren't a lot of general settings anyway.
  • I find it important to strictly differentiate between user settings and grid set settings, because if an user has more than one grid set, the settings might need to be different between sets. By 'grid set' I mean a main grid and all grids that are linked to it. I'm aware that currently it's not properly possible to have more than one grid set in AG (like for example use "Global Communicator" and "Quick_Say20" at the same time) but I'm hoping this will be an option at some point as there are users who switch between sets.
  • While I'm aware that making the settings 100% accessible to all kind of input options so all AAC users could use it is not possible at the moment, it's indispensable to make as many of the setting options as accessible to AAC users as possible and for AAC users to be part of this discussion. The ones I know personally (who cognitively would be able to edit their AAC interface) can't speak English (well), though, so I can't just ask them to join here. I need time to reach out and prepare the information in a way that is understandable. So it will take several more days until I can properly give feedback on dga's suggestions and possibly change my suggestions.

@klues
Copy link
Contributor Author

klues commented Nov 21, 2024

Thanks @arasaac-dga and @ms-mialingvo for all of your comments and suggestions! 👍

I won't comment everything now, because it would take another hour, which probably is better spent coding ;) But it think I have enought ideas and it's probably best if I create something based on your suggestions, which then can be further discussed.

Just some general notes:

  • I like the screenshots from the settings with tabs from ARASAAC, thanks, I'll go in this direction 👍
  • I think it makes sense to have to separate menus for grid-based actions and options and element-based actions and options in the edit view, I'll simply try something while implementing (having your suggestions in mind)

Another suggestion, that would make accessibility better: fields instead of drop-downs except if not possible (like for example not for the language drop-down) or suboptimal due to amount of elements and less important feature (like for the color category). Something like this:

Dropdowns are good because they can be easily extended without messing up the layout. However I agree that especially the actions page should be reworked. Maybe something like this, categories which filter the available actions to select from the dropdown (I did this in another project):

grafik

However, I think this should be a different issue, let's focus on the general layout and organziation of settings within this issue.

I find it important to strictly differentiate between user settings and grid set settings

While I understand that for some users it makes sense to have different "grid sets", I don't think it's realistic to implement it soon to have that possibility within one user. And I also think that it would make things more complex und probably also confusing for many users to add a fourth layer of options (global, grid set, grid, element). What would be much easier to implement: an action that switches to another user, so in this case the "grid set" level would be the same as the user level. However, I see the problems coming - of course after switching the user would probably like to have the same global settings...

Anyway - that's also another issue, which I won't be able to solve within this issue here - so maybe also create another issue for that.

While I'm aware that making the settings 100% accessible to all kind of input options so all AAC users

I think it's a good goal but quite unrealistic to have all settings 100% accessible for every AAC user. Maybe an idea would be to create some accessible settings page (which is accessible via the current input method) with the most important basic settings, additionally to the "full" settings, accessible by standard keyboard / mouse. But again -> need for another issue.

@arasaac-dga
Copy link
Collaborator

  • I like the screenshots from the settings with tabs from ARASAAC, thanks, I'll go in this direction 👍

Great!!! Visually is always better to make an idea about it ;-)

  • I think it makes sense to have to separate menus for grid-based actions and options and element-based actions and options in the edit view, I'll simply try something while implementing (having your suggestions in mind)

👍

However, I think this should be a different issue, let's focus on the general layout and organziation of settings within this issue.

Yes it could be a possible solution (categorize the actions) but better for other issue and develop.

While I understand that for some users it makes sense to have different "grid sets", I don't think it's realistic to implement it soon to have that possibility within one user. And I also think that it would make things more complex und probably also confusing for many users to add a fourth layer of options (global, grid set, grid, element). What would be much easier to implement: an action that switches to another user, so in this case the "grid set" level would be the same as the user level. However, I see the problems coming - of course after switching the user would probably like to have the same global settings...

Anyway - that's also another issue, which I won't be able to solve within this issue here - so maybe also create another issue for that.

We agree. It would be more useful and less complex/confuse to add an action to switch users and remain the actual organization that is clear and transparent. Anyway, it would be another issue and another develop.

@ms-mialingvo
Copy link
Collaborator

And I also think that it would make things more complex und probably also confusing for many users to add a fourth layer of options (global, grid set, grid, element). What would be much easier to implement: an action that switches to another user, so in this case the "grid set" level would be the same as the user level. However, I see the problems coming - of course after switching the user would probably like to have the same global settings...

Most of the popular AAC apps actually do this differentiation of 'general settings / user settings / grid set settings / grid settings / element settings'. The ones that don't usually have 'user settings / mix-of-general-and-grid-set-settings / grid settings / element settings' and as someone who has used or tested pretty much all the existing AAC apps, I find those ones less transparent.
I haven't opened yet an issue about having different grid sets (which is an option in some other AAC apps) because it has less priority, but I'm trying to think ahead: Designing the settings with future additions already in mind allows to set up a design that won't have to be redesigned later when it doesn't work anymore once these additions are made. And as each redesign forces the users to learn again what is where, thinking ahead makes sense.

I think it's a good goal but quite unrealistic to have all settings 100% accessible for every AAC user. Maybe an idea would be to create some accessible settings page (which is accessible via the current input method) with the most important basic settings, additionally to the "full" settings, accessible by standard keyboard / mouse. But again -> need for another issue.

I think the trickiest one would be scanning which is why I wrote that I'm aware that it's not possible for the moment as that would need a lot of redesign, I imagine. However for the moment I'm primarily thinking about users who use touchscreen with some motor problems. With that in mind, all the important basic settings would need to be configurable by touch only (so, no need for left-click, right-click, swipe, command key etc) and with areas (buttons etc.) that aren't tiny so the user with some motor issues still can hit the needed spot.

@klues
Copy link
Contributor Author

klues commented Jan 8, 2025

I've started to work on this and have to make a design decision regarding the tabs.

Currently the tabs are used in the edit element and look like this (mobile view):
image

This is good, but the problem is that the design doesn't scale for more tabs, at some points the tabs are getting to small. For the new settings in mobile view it would look like this:
image

Where you already see that the tabs are getting too small, and maybe there will come more over time. So I think we need another solution. I've experimented with truncating the text with ... but it doesn't solve the problem since users should be able to read the labels and at some points also the buttons are getting too small.

Stacking the tabs solves the problem:
image

However it's not good that the active tab has an open border at the bottom, but is not connected to the current tab.
Some interfaces solve this problem by changing the order of the tabs when selecting them, but this is also quite confusing.

So I've redesigned the tabs in this way:
Desktop view:
image

Mobile view:
image

I think with this design it's not that much of a problem if the active tab label is not connected with the open tab. However the drawback is, that the design is not so nice as it was before for desktop view. For consistency reasons I then would also change the tabs in edit element and they would look like this:
image

Which I think is OK, but not so pretty as before.

In the end tabs are not optimal for mobile views, thats probably the reason why the settings page on almost all mobile apps look like this - full screen and with a "back button" on top left:

For tabs some interfaces use horizontal scrollable tabs like Google here:

However for our case in the settings I don't like it, because many people won't notice that there are more tabs where you can scroll horizontally.

Conclusion: tabs are good for desktop, not so good for mobile. But we cannot do two completely different interfaces, so we have to decide on some kind of compromise.
@arasaac-dga and @ms-mialingvo what do you think is the best solution? What do you like most?

@arasaac-dga
Copy link
Collaborator

​Good morning, Benjamin and happy new year. We have reviewed the solution you propose and we agree with you that it is the best solution to give a standard design solution for mobile / tablet / desktop. We agree to change the design of tabs in Cell Edition to follow the same design. The solution proposed remains a good usability in all platforms and avoids confusions with the underline and tab color change.

@ms-mialingvo
Copy link
Collaborator

I agree, the horizontal scrollable tabs are to easy to miss. And the "back button" is a quite different organisation approach and I guess time-consuming to implement. There is the option of using an accordeon (https://www.gsarigiannidis.gr/tabs-on-desktop-accordion-on-mobile/) as another option that could look neat. However, I think it's important here to look at the ratio expense/income. While it's good to have access to all settings on mobile, any major editing will happen on larger screens. So if accordion is easy to implement, you might try that to check out if that could be a sensible option, but if it in any way is trickier/time-consuming, your solution is fully fine too, no need for more expense. With the underline and the color it's clear what is active at the moment.

@klues
Copy link
Contributor Author

klues commented Jan 8, 2025

OK, thanks for your thoughts!
Then maybe I'll stay with my current approach. I also thought of keeping it like this with some better highlighting of the current tab (e.g. the blue underline):
image

Like Manuela I also thought that most people will use AG on large screens, so maybe it's better to keep this version which is prettier on large screens (with no bottom border at the tabs).

@klues
Copy link
Contributor Author

klues commented Jan 8, 2025

Changed it to this:
image

image

Mobile:
image

A littlebit worse on mobile, but better on desktop in my opinion. And as discussed, probably it's better to optimize for desktop.

@ms-mialingvo
Copy link
Collaborator

Looks good for me :) Maybe the inactive tabs with a liiitle bit darker background or the font a bit lighter for better contrast to the active tab in the mobile? On larger screens it looks good like that.

@klues
Copy link
Contributor Author

klues commented Jan 8, 2025

Please test the new settings here: http://grid.beta.asterics-foundation.org/
All existing things should still work, tomorrow I'll implement and add the text settings.

@arasaac-dga
Copy link
Collaborator

​Discussing with the team we prefer the first Benjamin proposal with the background in blue. We think it is more clear for the final user and give another visual tip to know/focus on the active tab. We agree with @ms-mialingvo in using bold font in the active tab and normal font in the others to better focus on the active one.

Of course, we agree and the big percentage of use of Asterics is in big screens (tablets or desktops). So we must focus on offering a good design for this kind of screens and a correct/usable design for mobile screens.

@ms-mialingvo
Copy link
Collaborator

On first check all things still work correctly indeed. :)

The underline is currently both black and blue, I'd suggest blue-only.

​Discussing with the team we prefer the first Benjamin proposal with the background in blue. We think it is more clear for the final user and give another visual tip to know/focus on the active tab.

For the mobile version only or also for the big-screen-version? Because for the big-screen-version, white would be the same as it is in the current public design and the white of the title fading into the white of of the actual content is what gives it the clear feeling of this-belongs-together to me. I'm not opposed to a blue background, white just also makes sense for me due to that direct connection with the content. For the mobile version no fading happens for the tabs that are not in the last row, so I'd be fine with a blue background there, just maybe a little bit lighter than in the picture, for better contrast between font and background colors.

As I otherwise never check the mobile, upright format version of the app I noticed some other things. I opened a new topic for these observations, #464.

klues added a commit that referenced this issue Jan 9, 2025
@klues
Copy link
Contributor Author

klues commented Jan 9, 2025

​Discussing with the team we prefer the first Benjamin proposal with the background in blue.

OK, really? For Desktop I really like the open bottom and white more, because, like Manuela says the tab is connected with the white content. I've just updated it again, so only the active tab is bold font and the others are slightly darker gray for better contrast to the active one.

The underline is currently both black and blue, I'd suggest blue-only.

Where it's black? I only see a blue underline ;)

However, these are all very small details, I'll continue with bigger things today ;)

@arasaac-dga
Copy link
Collaborator

​Discussing with the team we prefer the first Benjamin proposal with the background in blue.

OK, really? For Desktop I really like the open bottom and white more, because, like Manuela says the tab is connected with the white content. I've just updated it again, so only the active tab is bold font and the others are slightly darker gray for better contrast to the active one.

The underline is currently both black and blue, I'd suggest blue-only.

Where it's black? I only see a blue underline ;)

However, these are all very small details, I'll continue with bigger things today ;)

Ok, after viewing it again "in situ" we agree on the actual design with white background and the need to continue between the tab and the window. In the mobile version perhaps you could have sense the blue background but if you cannot separate the designs forget it (is an irrelevant question and there are more important things to develop). 

We have tested all the options in the new configuration page and only we have found some trouble with  "grammar correction via ARASAAC's API" that when you activate it the spinner is permanently round and round and doesn't activate the option. 

On the other hand, one doubt...(we don't remember the final decision about it) In INPUT METHODS... will be finally included all the actual options through tabs as we send you in the designs 

image

or only inlude the options that you actually have added?

Anyway, as always, great work!!!

@ms-mialingvo
Copy link
Collaborator

Where it's black? I only see a blue underline ;)

image

So, Mac Firefox & Chrome: only blue. Mac Safari, iPhone Safari and Firefox, iPad Firefox: Blue and black.

@klues
Copy link
Contributor Author

klues commented Jan 22, 2025

iPad Firefox: Blue and black.

fixed.

"grammar correction via ARASAAC's API" that when you activate it the spinner is permanently round and round and doesn't activate the option.

fixed.

INPUT METHODS... will be finally included all the actual options through tabs as we send you in the designs

we could add all other input method options there, but for now I would keep it as-is, because it's again some work to integrate them here. So if you consider it important, please create a new issue for it.

@arasaac-dga
Copy link
Collaborator

we could add all other input method options there, but for now I would keep it as-is, because it's again some work to integrate them here. So if you consider it important, please create a new issue for it.

Ok. For us is enough.

fixed.

Thanks

@ms-mialingvo
Copy link
Collaborator

fixed

Perfect :) Thanks.

@klues
Copy link
Contributor Author

klues commented Jan 27, 2025

@klues klues closed this as completed Jan 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants