-
Notifications
You must be signed in to change notification settings - Fork 23
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
Comments
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. |
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.
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.
|
Yes.
Is there any user setting besides
It would make sense for me for them to be at the user settings, together with the other 'general input settings'
see excel
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. |
We present you our proposal with aprox to the options and distribution of them in tabs and for grid and cell edit. SETTINGS 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 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.
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 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.
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.
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.
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 ;-) |
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:
|
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:
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): However, I think this should be a different issue, let's focus on the general layout and organziation of settings within this issue.
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.
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. |
Great!!! Visually is always better to make an idea about it ;-)
👍
Yes it could be a possible solution (categorize the actions) but better for other issue and develop.
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. |
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 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. |
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): 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: 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 Stacking the tabs solves the problem: However it's not good that the active tab has an open border at the bottom, but is not connected to the current tab. So I've redesigned the tabs in this way: 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: 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. |
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. |
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. |
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. |
Please test the new settings here: http://grid.beta.asterics-foundation.org/ |
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. |
On first check all things still work correctly indeed. :) The underline is currently both black and blue, I'd suggest blue-only.
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. |
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.
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 or only inlude the options that you actually have added? Anyway, as always, great work!!! |
fixed.
fixed.
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.
Thanks |
Perfect :) Thanks. |
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:
Application language
,Passcode for unlocking user interface
,Synchronize navigation and locked/fullscreen state for online users
Preferred voice
(shouldn't be synchronized, because available voices differ between devices)And there probably should be a separation of topics like:
My assumptions and questions:
System / General
should hold all options which are independent from the user and all other options are user-dependent.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: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.
The text was updated successfully, but these errors were encountered: