UX changes #29
Comments
|
I changed my mind about the below section, which I left here, quoted, for clarity. See the new comment.
|
|
(3) in the original post is related to #5 |
|
Thanks a lot for these insights! I don't have much design experience myself, so this really helps a lot. I will go over this in detail after I've relicensed Red Moon to the GPLv3+. |
See #29 Use a switch instead of a checkbox for the theme selection as per point 2. I also removed the unneeded summary from the preference.
|
I've started with the easiest part, I've changed the CheckBoxPreference for a dark theme to a SwitchPreference and removed the summary. I hope this satisfies point 2. |
See #29 Group the settings into 4 categories as per the material design guidelines. https://www.google.com/design/spec/patterns/settings.html
See #29 Update the text on the time and automatic filter preferences to be more descriptive and display the current state in the summary.
See #29 Remove the "Always open on startup" preference, since it doesn't have a clear usage scenario and may confuse the users. I've also reordened the preferences, since a separated category for one preference is unneeded. Instead I've made a separate PreferenceCategory for the contact information.
|
I tried the most recent changes. I think they're a great improvement! Actually, enough of an improvement (and time to think) that I've changed my mind about some features. I also think this thread is getting a bit hard to follow (and want to keep the scope reasonable), so I'm going to give a list of features to close this issue and omit the context.* List moved to the first post for easier tracking. * If you disagree with any of these or have questions, ask and I'll give my reasoning, I just don't want to clutter the comment if everyone agrees with the suggestions. |
|
Thanks a lot, this is very helpful!
I'm wondering what your reasoning is for not including a stop button in the notification. Does a stop button in the notification make it too easy for the user to accidentally stop the service? I'm also thinking of adding a "pause for 30 min" button to the notification and was wondering how you would feel about that? Would it be helpful to the user, or overly complicated?
Without this setting, I think the filter state should persist after a reboot. Would you agree?
Should the FAB just be the primary colour of Red Moon (red), or should I choose a tint colour? Thanks again! |
See #29 Red Moon now acts like this setting is always checked.
Exactly 😄 I think the top-level switch should be the only place a user can enable/disable the service. If there's some way to stop the service from running when the filter is off and then automatically start it again at a specified time, that might be useful, too -- but that's an implementation detail to save battery, not something visible to the user, who's thinking in terms of "Red Moon is enabled/disabled".
I think this is a good idea, but I'm also trying to limit the scope of this issue so it's easier to follow. However, if it's easier to do that than switch to a 1-button notification, by all means go for it :)
Yes!
This is a visual design question, which I don't have any particular expertise in. I skimmed the Material design guidelines on color and FABs; I'd try it with the primary color and see how it looks, then go from there. It might also make sense to use the small FAB variant, but that'd be an easier decision to make if I could see it in action (ie, just pick one and go with it and we can assess if it's better to use small or normal-sized later). |
|
Do you get notifications when I edit my comments, or should I also make comment saying what I edited?
|
|
Thanks for the answers!
I don't get any notifications when you edit your comments, so a comment would be helpful.
Sadly, the timezone doesn't provide any information for the sunset and sunrise times in the users local times. However, I think it is a good idea to provide a default for sunrise and sunset times instead of using the custom times. |
Isn't that what sunrisesunsetlib-java could do? |
No, unfortunately sunsetsunriselib-java needs a location and a timezone in which to return the time. See https://github.com/mikereedell/sunrisesunsetlib-java/blob/master/src/main/java/com/luckycatlabs/sunrisesunset/SunriseSunsetCalculator.java. |
See #29 The location preference doesn't yet affect the actual sun time calculations, nor does it update automatically when sun mode is set.
|
This addresses the first part of your comment on #33, and also reflects my latest thinking about how states should work. Essentially, there should only be on/off. You can manually toggle the filter on/off; red moon also includes settings to automatically turn the filter on and off at certain times. The app does not distinguish between a manual or automatic start/stop. Added to top post:
This makes both the code base and the user interface way simpler. Profiles become a part of settings, not connected to state:
|
See #29 The location is now updated silently when: * The user selects the sun mode * The filter is automatically turned on or off Furthermore the location is explicitly updated when the user taps the LocationPreference. The AutomaticFilterChangeReceiver has been simplified, since it doesn't have to find the sunset nor a location anymore, but just reads the current on and off times. The on and off times are saved in the keys off the new FilterTimePreferences. They change to sunrise and sunset times when the sun mode is selected, automatically backing up the custom times. When the location fails to update when it has been explicitly called by the user, a toast with a notice is displayed. When the user selects the sun mode with a unset location, sensible default sunrise and sunset values are set as turn on and off times.
|
Should the filter automatically turn on at the set time if the user has disabled Red Moon? |
No. If Red Moon is disabled, the Red Moon service should be off, there should be no notification, etc. I have used the language "pause/resume" across this thread to be consistent about what functionality I'm talking about and so it's confusing to have an item in here for changing that vocab, so I moved that part to its own issue, #35. |
|
Added:
|
|
Added:
|
Great, thanks for the quick answer.
Could you elaborate your reasoning on this? I'm afraid users might be confused as to why they are unable to edit any settings.
With switched on, do you mean when the user first opens the app or when the user first presses the top switch? |
|
(What's a FAB, anyway ?) |
The reason is, it provides a VERY strong visual queue that this switch enables and disables ALL functionality. It's the same reason we gray out the "Location" setting when using custom times. Sure, we could technically set the location, but the setting isn't in use, so we gray it out. The top switch is always visible. If it's the only toggle-able thing, I think it should be clear. Particularly, after the user has toggled it ONCE, seeing all the settings suddenly become un-gray will be such strong feedback that they will never be confused again. It is a good point, though, that the first time a user opens the app (or if a different user is borrowing the phone and opens the app) they may be confused. Added a few lines to the top post.
I mean any time the top switch moves from 'off' to 'on'. As noted, this is not the long-term plan (if you set automatic filter and then disable Red Moon, then enable it again, the filter should be off if it's night and on if it's day). However, that functionality is #34, and I'd rather not hold up the next release for it :) |
See #29 The doesn't yet toggle the filter.
See #29 The user can now toggle pause/resume with the floating action button and toggle disable/enable with the switch in the app bar. When Red Moon is disabled, there is no notification and all settings are grayed out. When Red Moon is enabled and the filter is paused, the settings are accessible and there is a notification in the notification tray, but the filter is not running. When Red Moon is enabled and the filter is resumed, the settings are accessible and there is a notification in the notificaton tray and the filter is running. The filter will still be turned automatically when Red Moon is enabled.
See #29 Red Moon will no longer startup on the set times if it is disabled (the switch in the app bar is off).
Is it important that the FAB disappears? I would think it provides an extra option for users who only want to see the notification if the filter is actually on and want a way to instantly enable Red Moon and turn on the filter manually.
I will look into how to do this. I'm not sure it will be easy to have an arrow pointing to the switch, since it can be in different places depending on the device (think RTL layouts). |
At the time I was thinking that the user should have to turn on the top-level switch to enable the app, period -- to force the user to understand the function of the top toggle (vs the FAB or notification).
It doesn't need to be an arrow*. For example, you could dim the whole screen except for a circle around the toggle, and maybe add some descriptive text, and that would do the job just as well. That said... I do still think it would be better to have the FAB disappear and a visual queue that guides you to turning on the top-level switch. However, if we kept the FAB, I wouldn't be worried about users finding a way to turn on the app anymore, so the visual queue is no longer needed. That is to say, I think it's a nice-to-have and outside the scope of this ticket. Almost done! 😃 *The purpose is to highlight, "this is the action you are expected to take." As to what it should look like -- honestly that's a visual design thing that I don't have any special knowledge or strong feelings about. |
|
Just tested this out, and I have a few thoughts:
Mockup of the faded stuff:
After trying it, I do think it is confusing at first -- even with the FAB -- why all the settings are disabled. As I expected, after toggling the app bar switch (I might as well call it the right name) once, it was immediately clear what's going on. The FAB actually makes this worse: when you use the FAB to enable, there's so much activity that it's easy to miss the app bar switch turning on, which means the user may not learn what it does. So, I'll go back to what I said at first. See also: the animation
Just removing the FAB right away doesn't solve things -- it's still too difficult to notice the app bar slider. I made a super fast & lazy mockup, that I think does the job:
Implementation details:
|
See #29 The add/delete profile button now grays when Red Moon is disabled.
See #29 The preferences under the "Other" PreferenceCategory will no longer be disabled when Red Moon is disabled.
|
When Red Moon is disabled, the FAB fades out and a snackbar with help fades in. I chose this over a black overlay, because some settings remain accessible when Red Moon is disabled. Screenshot:
I feel v2.7.0 is more appropriate, since users can upgrade without loss of settings. If you agree it is ready, I will release the new version and close this issue. |
No strong feelings, sounds good!
One last thing: the snack bar needs a little more contrast with the background when the dark theme is enabled. Options I can think of: Lighten it a bit, darken it further, add a lighter gray line along the top.
|
I was thinking black overlay only on first run (once the user has toggled once, they'll remember how to replicate the behavior in the future), but I like this solution more. |
See #29 Change color of the help snackbar in the dark theme to white for more contrast.
Nice catch, I changed it to the standard android white when dark mode is enabled for contrast. |
|
Thank you so much for all your hard work! The UX a lot better now 😄 👍. |
|
@raatmarien just a small detail, you should replace the checkbox by a switch, Material Design specs say about checkboxes:
And about switches:
Source: Components – Selection controls |
|
@smichel17 Thanks! |
List of changes to consider this ticket closed:
(Replace the current message starting with "location service isn't enabled...")
The rest of this comment is out of date. It may still be useful for context.
Some of this (anything quoted) is pulling from the Material guidelines (settings and selection controls). The rest is from my experience as a UX designer (in training).
1. Clarify the how users interact with the app
Add a FAB & change notification, the top-level switch, startup settings, & the automatic filter backend.
I wrote out a bunch of reasons why the current behavior is confusing, but they're cluttering this section so I moved them down to the bottom of this post 0 so here we can focus on solutions.
The user doesn't distinguish between the service and the filter. They only care about 3 questions:
So here's a state hierarchy:
Each indentation level is a layer of abstraction, and we have controls at each layer. If you mix layers, you'll end up with settings in places that don't make sense1.
The user doesn't care if Red Moon is able to turn off the service in the background, nor if the service starts on boot or if service is able to restart across reboots -- they only care what state the app is in. So the question becomes, where do we control elements of each state, and which states should persist across reboot? Here are my conclusions:
Remove both 'Startup' settings. They both have to do with implementation details that users don't care about.
The top-level switch should enable/disable Red Moon. Its state should persist across reboot.
Add a FAB that pauses and resumes the filter. Its state should not persist across reboot.
Changes to the filter settings get their own section at the bottom.
2. Change "Dark theme" to a switch and remove the secondary text.
"Dark theme" is pretty universally understood.
Switches are pretty overrated; they're often more confusing than a checkbox would be. That said, they have their place on lone settings or when changing the setting has an immediate effect (like toggling wifi or switching theme). Dark theme is both.
3. Shuffle around settings under the 'automatic filter' header
The first 3 lines mimic Twilight's interface. 'Location' should be smaller than Twilight's and only show the coordinates in its secondary text.
Automatic filterFilter times[slider bar for viewing current times or setting them if 'custom' is selected]
[coordinates]
'Location' opens up a new activity that guides you through the process of picking your location. That screen has 4 options:
Requires location services
Estimate location from system date/time
0: It should be possible to understand how all settings will affect behavior without actually testing out different combinations of settings. It boils down to whether there a difference between a filter that's on but paused and a disabled filter. Ie, can the service be running and the filter be disabled? Related questions that follow:
My best guesses for the answers are:
Could you explain what the actual relationship between filter and service is? If it's different enough from my guess that implementing my suggestions would be difficult, I'll make some modifications.
1: It's pretty clear that the team behind Twilight did their homework for the design, but they got lost in the details. They decided "always on" should be at the manual-intervention level; I think it's a profile setting. They also decided "filter times" should be a global setting, when I think it's also a profile setting. Changing it is larger-scope than this ticket, though. I am only including changes here that I think should be uncontroversial.
The text was updated successfully, but these errors were encountered: