You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is what I haveby default on chromebook. I think when the screen is large, we should have more icons by default
Admittedly, there is an issue with the fact that the display size can change, especially on chromebook.
I don't think that increarsing the number of icon which are displayed if there is enough room would be a good solution, because they would get to be displayed on phone too, which would reduce the size available for the name of the deck.
I don't know exactly what extra actions should be added in the menu. I'd be in favour of bury, suspend, mark note, but that's only because of my personal use. Ideally we'd need stats on what actions people regularly use, but that'd take far more time to gather.
Let's consider an item such as "suspend" that should be displayed by default on tablet and not on phone.
My suggested solution would be that, when we check a preference value for an item, if the value is set, we honor what is set (as it means the user did an action), however, if the value in unset, the value we obtain instead depend on the size of the screen.
Admittedly, it means the default value displayed in our settings would be "menu only" on phone and "in the bar" on xlarge screen. that is, the value could appear to change when the user resize their application. This is not ideal, I doubt it would confuse a lot of people.
alternative
A more complex solution, would be to detect when the screen size change. If the same user on the same device is sometime xlarge and sometime not, it means they can redimension their app (and they actually do it). In this case, we could offer an option "display on big screen only".
I don't think this extra complexity is really worth it, but at least that would ensure the behavior I sugest could be reproduced by a choice the user make
The text was updated successfully, but these errors were encountered:
If someone wants to show more options, they can configure them. We won't ever know what it the "average best scenario" of what items should be shown to most people. There will be people who will dislike the change because they have more stuff to hide or because the options overload them or because their tablets had different default options and now they think that's a bug.
I also would like to avoid as much "big screen" stuff as possible. How less stuff to maintain, the better.
This is what I haveby default on chromebook. I think when the screen is large, we should have more icons by default
Admittedly, there is an issue with the fact that the display size can change, especially on chromebook.
I don't think that increarsing the number of icon which are displayed if there is enough room would be a good solution, because they would get to be displayed on phone too, which would reduce the size available for the name of the deck.
I don't know exactly what extra actions should be added in the menu. I'd be in favour of bury, suspend, mark note, but that's only because of my personal use. Ideally we'd need stats on what actions people regularly use, but that'd take far more time to gather.
Let's consider an item such as "suspend" that should be displayed by default on tablet and not on phone.
My suggested solution would be that, when we check a preference value for an item, if the value is set, we honor what is set (as it means the user did an action), however, if the value in unset, the value we obtain instead depend on the size of the screen.
Admittedly, it means the default value displayed in our settings would be "menu only" on phone and "in the bar" on xlarge screen. that is, the value could appear to change when the user resize their application. This is not ideal, I doubt it would confuse a lot of people.
alternative
A more complex solution, would be to detect when the screen size change. If the same user on the same device is sometime xlarge and sometime not, it means they can redimension their app (and they actually do it). In this case, we could offer an option "display on big screen only".
I don't think this extra complexity is really worth it, but at least that would ensure the behavior I sugest could be reproduced by a choice the user make
The text was updated successfully, but these errors were encountered: