organicmaps/organicmaps-tmp

Archived

Fork 1

[ios] Update Launch Screen to support dark mode #3215

Merged

euf merged 1 commit from ios-launchscreen into master

2024-07-01 09:38:29 +00:00

euf commented

2022-08-19 21:03:08 +00:00

(Migrated from github.com)

Since LaunchScreen can not run any code, UI was recreated manually.
It required carefully using AutoLayout to make similar button positions.
Although not 100% pixel perfect, it’s almost identical to real UI,
as can be seen with Simulator while trying on different devices.

In order to support Dark Mode, several assets had to be duplicated:

btn_get_position_both.imageset
btn_layers_both.imageset
btn_zoom_in_both.imageset
btn_zoom_out_both.imageset

This is necessary for iOS to choose between light and dark appearance.
For this reason also added 3 colorsets with values from Colors.swift.
All additions are in a separate Media.xcassets in Storyboard folder.
This duplication is extra 135 Kb, which seems okay for this task.

Closes: organicmaps/organicmaps#3049

Human Interface Guidelines suggests showing app’s UI on launch screen. https://developer.apple.com/design/human-interface-guidelines/patterns/launching/#launch-screens It was done by adding interface elements to `LaunchScreen.storyboard`. Since LaunchScreen can not run any code, UI was recreated manually. It required carefully using AutoLayout to make similar button positions. Although not 100% pixel perfect, it’s almost identical to real UI, as can be seen with Simulator while trying on different devices. In order to support Dark Mode, several assets had to be duplicated: - btn_get_position_both.imageset - btn_layers_both.imageset - btn_zoom_in_both.imageset - btn_zoom_out_both.imageset This is necessary for iOS to choose between light and dark appearance. For this reason also added 3 colorsets with values from `Colors.swift`. All additions are in a separate `Media.xcassets` in `Storyboard` folder. This duplication is extra 135 Kb, which seems okay for this task. Closes: https://git.omaps.dev/organicmaps/organicmaps/issues/3049

biodranik commented

2022-08-21 21:15:41 +00:00

(Migrated from github.com)

Wasn't there already a launch screen? Can you please share screenshots before and after your changes for light and dark modes?
Is this duplication really necessary? How to avoid it?

1. Wasn't there already a launch screen? Can you please share screenshots before and after your changes for light and dark modes? 2. Is this duplication really necessary? How to avoid it?

euf commented

2022-08-22 14:11:28 +00:00

(Migrated from github.com)

Wasn't there already a launch screen? Can you please share screenshots before and after your changes for light and dark modes?

Technically there was a launch screen, but it was completely empty, just filled with map background color for light mode. I believe the improvement is huge bucause:

Adding night mode background fill helps avoiding light flash on launch
Adding UI elements is consistent with Apple HIG and improves user experience by making the app to feel more responsive.

Light mode, vertical orientation, before vs. after:

Night mode, horizonal orientation, before vs. after:

In my opinion it's totally worth having 135 Kb of duplicating resources for a much smoother launch experience.

Is this duplication really necessary? How to avoid it?

As far as I can tell, the only way to avoid duplication is to fully switch from separate imagesets (btn_zoom_in_dark and btn_zoom_in_light) to combined dark/light resources (like btn_zoom_in_both), as I did for this task. I guess it will require some changes in MWM theming engine to properly handle this type of xcassets. Unfortunately I am not a professional iOS developer, it's just a hobby for me, so I believe a more experienced contributor such as @AntonM030481 would be able to give better estimates.

> 1. Wasn't there already a launch screen? Can you please share screenshots before and after your changes for light and dark modes? Technically there was a launch screen, but it was completely empty, just filled with map background color for light mode. I believe the improvement is huge bucause: - Adding night mode background fill helps avoiding light flash on launch - Adding UI elements is consistent with Apple HIG and improves user experience by making the app to feel more responsive. **Light mode, vertical orientation, before vs. after:** <img src="https://user-images.githubusercontent.com/11754264/185933529-86f278f2-4fdb-4cf3-bfb9-b6e907ab76b1.gif" width="200"> <img src="https://user-images.githubusercontent.com/11754264/185933590-dd5f5e37-e3b5-461c-b1c1-847d95312333.gif" width="200"> **Night mode, horizonal orientation, before vs. after:** <img src="https://user-images.githubusercontent.com/11754264/185934567-e6c4e48e-f503-4e19-8186-fbd18c61584e.gif" width="200"> <img src="https://user-images.githubusercontent.com/11754264/185934686-b26f7354-833c-4e11-aca7-8ebe053cf6f7.gif" width="200"> In my opinion it's totally worth having 135 Kb of duplicating resources for a much smoother launch experience. > 2. Is this duplication really necessary? How to avoid it? As far as I can tell, the only way to avoid duplication is to fully switch from separate imagesets (`btn_zoom_in_dark` and `btn_zoom_in_light`) to combined dark/light resources (like `btn_zoom_in_both`), as I did for this task. I guess it will require some changes in MWM theming engine to properly handle this type of xcassets. Unfortunately I am not a professional iOS developer, it's just a hobby for me, so I believe a more experienced contributor such as @AntonM030481 would be able to give better estimates.

biodranik commented

2022-08-22 20:51:01 +00:00

(Migrated from github.com)

Thanks for the gifs!

From our past experience, especially on slower devices, displaying the user interface motivates users to start touching it and get frustrated without any feedback. Also, jumping buttons after the interface is loaded do not look great. And they require a lot of work every time the interface is modified (yes, we plan to change/improve it soon).

so...

Would it be possible to minimize the change and only add dark background when the dark theme is enabled?

Thanks for the gifs! 1. From our past experience, especially on slower devices, displaying the user interface motivates users to start touching it and get frustrated without any feedback. Also, jumping buttons after the interface is loaded do not look great. And they require a lot of work every time the interface is modified (yes, we plan to change/improve it soon). so... 2. Would it be possible to minimize the change and only add dark background when the dark theme is enabled?

euf commented

2022-08-23 11:50:08 +00:00

(Migrated from github.com)

I agree with your points.

LaunchScreen was updated: all buttons are removed, only empty tab area is shown.
No resources are duplicated now.

Please see attached gifs.

I agree with your points. LaunchScreen was updated: all buttons are removed, only empty tab area is shown. No resources are duplicated now. Please see attached gifs. <img src="https://user-images.githubusercontent.com/11754264/186150486-d35d5847-758d-456f-ac2f-b7d4ecf2392d.gif" width="200"> <img src="https://user-images.githubusercontent.com/11754264/186150514-fc5c9624-23e5-4b96-a852-f174924d0f4d.gif" width="200">

biodranik commented

2022-08-27 21:11:51 +00:00

(Migrated from github.com)

Thanks! Can you please also remove the toolbar? Actually, we plan to remove it soon to allow users to see more maps on the screen.

euf commented

2022-08-28 08:33:09 +00:00

(Migrated from github.com)

@biodranik Thanks for your suggestion! Personally I would argue it is better to keep the toolbar area at the moment.

When UI refactoring really happens, one could easily delete the toolbar from the LaunchScreen.storyboard in XCode by just clicking it in the editor (aka Interface Builder) and pressing Backspace. I would happily do that myself to keep UI consistent (just tag me in a relevant issue).

For now, I believe keeping in line with Apple HIG is better UX than preparing for further changes in advance. What do you think?

Side note: I’d really like to take part in UI improvement discussion. Is it going to follow Android approach here? organicmaps/organicmaps#2905 (comment)

@biodranik Thanks for your suggestion! Personally I would argue it is better to keep the toolbar area at the moment. When UI refactoring really happens, one could easily delete the toolbar from the LaunchScreen.storyboard in XCode by just clicking it in the editor (aka Interface Builder) and pressing Backspace. I would happily do that myself to keep UI consistent (just tag me in a relevant issue). For now, I believe keeping in line with Apple HIG is better UX than preparing for further changes in advance. What do you think? Side note: I’d really like to take part in UI improvement discussion. Is it going to follow Android approach here? https://git.omaps.dev/organicmaps/organicmaps/pulls/2905#issuecomment-1221557670

biodranik commented

2022-08-28 20:50:21 +00:00

(Migrated from github.com)

For now, I believe keeping in line with Apple HIG is better UX than preparing for further changes in advance. What do you think?

We try to avoid unnecessary work because our resources are very limited. We're grateful for any help, but at the moment it's still hard to rely on contributors in all cases.
It is just a guideline, with a great idea behind it. But it should be carefully used in reality (as I mentioned before, users will be disappointed if they start clicking on non-working buttons).
In our case, the main OM philosophy is simplicity. Fewer changes, less work, and less complex implementation = faster app and easier to support code.
Empty toolbar doesn't look great on the splash. Considering it (hopefully) be removed soon, it doesn't make sense to introduce it now, if it was absent for many years already.

Is it going to follow Android approach here? #2905

Yes. We like to see the full map like it was done 10 years ago:

What are your arguments for the toolbar? Did you see how much space it takes on iPhone X and alike devices with a larger safe area?

> For now, I believe keeping in line with Apple HIG is better UX than preparing for further changes in advance. What do you think? 1. We try to avoid unnecessary work because our resources are very limited. We're grateful for any help, but at the moment it's still hard to rely on contributors in all cases. 2. It is just a guideline, with a great idea behind it. But it should be carefully used in reality (as I mentioned before, users will be disappointed if they start clicking on non-working buttons). 3. In our case, the main OM philosophy is simplicity. Fewer changes, less work, and less complex implementation = faster app and easier to support code. 4. Empty toolbar doesn't look great on the splash. Considering it (hopefully) be removed soon, it doesn't make sense to introduce it now, if it was absent for many years already. > Is it going to follow Android approach here? #2905 Yes. We like to see the full map like it was done 10 years ago: ![image](https://user-images.githubusercontent.com/170263/187093799-ba64231e-3c87-4e12-b51d-8b754a5e7bd3.png) What are your arguments for the toolbar? Did you see how much space it takes on iPhone X and alike devices with a larger safe area?

👍 1

euf commented

2022-09-03 19:52:05 +00:00

(Migrated from github.com)

@biodranik Thank you for a detailed explanation of your points.

I updated the launch screen. Now it doesn't have an empty tab bar, just an empty screen filled with a map background color depending on dark/light mode. It felt a little empty, so I added a small logo in the center as a compromise between HIG requirements and Android splashscreen.

Please see light vertical vs dark horizontal:

As for the toolbar as a part of UI, at the moment I have no arguments for it. I guess it would be really better to use buttons instead, since it helps to show more map.

@biodranik Thank you for a detailed explanation of your points. I updated the launch screen. Now it doesn't have an empty tab bar, just an empty screen filled with a map background color depending on dark/light mode. It felt a little empty, so I added a small logo in the center as a compromise between HIG requirements and Android splashscreen. Please see light vertical vs dark horizontal: <img src="https://user-images.githubusercontent.com/11754264/188285553-d33a2499-2e20-4b6b-a33f-89a9591dc7e5.gif" width=45%> <img src="https://user-images.githubusercontent.com/11754264/188285558-b8625bd9-fe7f-4881-ac3a-6c7de4584e58.gif" width=45%> As for the toolbar as a part of UI, at the moment I have no arguments for it. I guess it would be really better to use buttons instead, since it helps to show more map.

👍 1

biodranik commented

2022-09-03 20:05:01 +00:00

(Migrated from github.com)

Thanks! Not sure yet about the single icon, it doesn't look perfect. I have an idea: let's move in steps.

Merge your changes without the logo. It's a simple and clear improvement compared to the current situation, without making users angry.
Experiment on the splash screen. I have a feeling that an android-like splash with a logo, Organic Maps text, and localized "Map data from OpenStreetMap" would be better than an empty screen. But it requires some testing, maybe even beta testing. And on most modern devices the startup time is very fast, so users may not have enough time to read it. So maybe it will just distract them. That's why it should be tested first )

Thanks! Not sure yet about the single icon, it doesn't look perfect. I have an idea: let's move in steps. 1. Merge your changes _without_ the logo. It's a simple and clear improvement compared to the current situation, without making users angry. 2. Experiment on the splash screen. I have a feeling that an android-like splash with a logo, Organic Maps text, and localized "Map data from OpenStreetMap" would be better than an empty screen. But it requires some testing, maybe even beta testing. And on most modern devices the startup time is very fast, so users may not have enough time to read it. So maybe it will just distract them. That's why it should be tested first )

euf commented

2022-09-05 12:00:30 +00:00

(Migrated from github.com)

@biodranik

If you don't mind, before we merge changes without the logo, I'd like to show you another attempt at making the launch screen less empty. I recorded a screencast of Apple Maps and Google Maps and slowed animations ×5, please have a look:

https://user-images.githubusercontent.com/11754264/188442021-e95e3d15-e43f-485c-a4a6-2617f1c78b9e.MP4

https://user-images.githubusercontent.com/11754264/188442065-732b4da9-bf19-44b6-be1e-c9e38f7205a2.MP4

As you can see, they both use a grid at launch. I tried the same approach, what so you think?

I believe this grid helps to avoid user confusion on slow devices: the screen is not completely empty (as if the application hangs), but shows a placeholder for map.

Frankly speaking, I am really sure that android-like splash should be avoided on iOS. It really goes against best practices and makes an app feel less native, just like using material design in UI instead of iOS native components. I do agree that there should be no text on the launch screen since it takes just a fraction of second on modern devices. This is also one of the recommendations of Apple HIG by the way :)

I'm sorry that this simple launch screen issue took so much of your time. Hope you are not tired of discussing small details like this one. I'm really a big fan of Organic Maps and hope to do some good for the project!

@biodranik 1. If you don't mind, before we merge changes without the logo, I'd like to show you another attempt at making the launch screen less empty. I recorded a screencast of Apple Maps and Google Maps and slowed animations ×5, please have a look: https://user-images.githubusercontent.com/11754264/188442021-e95e3d15-e43f-485c-a4a6-2617f1c78b9e.MP4 https://user-images.githubusercontent.com/11754264/188442065-732b4da9-bf19-44b6-be1e-c9e38f7205a2.MP4 As you can see, they both use a grid at launch. I tried the same approach, what so you think? <img src="https://user-images.githubusercontent.com/11754264/188442478-e9800bd3-da9d-4bd8-9d37-cf17eb534a36.gif" width=45%> <img src="https://user-images.githubusercontent.com/11754264/188442507-f87620f1-c885-4947-827a-d612758cc373.gif" width=45%> I believe this grid helps to avoid user confusion on slow devices: the screen is not completely empty (as if the application hangs), but shows a placeholder for map. 2. Frankly speaking, I am really sure that android-like splash should be avoided on iOS. It really goes against best practices and makes an app feel less native, just like using material design in UI instead of iOS native components. I do agree that there should be no text on the launch screen since it takes just a fraction of second on modern devices. This is also one of the recommendations of Apple HIG by the way :) I'm sorry that this simple launch screen issue took so much of your time. Hope you are not tired of discussing small details like this one. I'm really a big fan of Organic Maps and hope to do some good for the project!

euf commented

2022-09-19 08:55:28 +00:00

(Migrated from github.com)

@biodranik Sorry to bother you, did you have a chance to look at my previous message?

biodranik commented

2022-10-02 12:59:36 +00:00

(Migrated from github.com)

Grid is a no-go. It is strongly associated with online maps and will confuse users.
Splash Screen is a very useful feature on slow devices, where users can get the most important piece of information we need them to know, to save us a lot of time on support requests and to avoid receiving negative reviews in stores, for example, when users do not know that we take all maps data from OSM and blame us for any gaps in this data.
On fast devices a simple background color is enough.

1. Grid is a no-go. It is strongly associated with online maps and will confuse users. 2. Splash Screen is a very useful feature on slow devices, where users can get the most important piece of information we need them to know, to save us a lot of time on support requests and to avoid receiving negative reviews in stores, for example, when users do not know that we take all maps data from OSM and blame us for any gaps in this data. 3. On fast devices a simple background color is enough.

biodranik commented

2022-10-19 08:41:58 +00:00

(Migrated from github.com)

@euf let's move step by step and incrementally improve what we already have by adding an appropriate background to the night theme. I want to clarify though:

There is a system setting about the light/dark mode.
There is an option in OM to force light/dark mode.

Is it possible to implement the dark mode splash background, so it will respect the OM setting, not the system setting?
Of course, later we'll improve OM so it will appropriately handle the system theme settings.

@euf let's move step by step and incrementally improve what we already have by adding an appropriate background to the night theme. I want to clarify though: 1. There is a system setting about the light/dark mode. 2. There is an option in OM to force light/dark mode. Is it possible to implement the dark mode splash background, so it will respect the OM setting, not the system setting? Of course, later we'll improve OM so it will appropriately handle the system theme settings.

biodranik (Migrated from github.com) approved these changes 2024-06-30 12:09:51 +00:00

biodranik (Migrated from github.com) left a comment

Thanks! A simple yet good start. LGTM

@kirylkaveryn WDYT?

Thanks! A simple yet good start. LGTM @kirylkaveryn WDYT?

This repo is archived. You cannot comment on pull requests.

No reviewers

biodranik