Openhab-android: Remove "side menu" from the app

[kaikreuzer]

In a rush of adding support for openHAB 2, Victor had introduced the side menu in the app as a first start, which adds "Discovery" and "Binding" menus - the implementation has been left very rudimentary though since then and I doubt that they are being used by anyone.

What is more, to not have such an empty menu with just 2 entries, the sitemaps were added there as well as an alternative way to setting them in the configuration. This is actually pretty counterproductive, because it leads people to believe that they should/could use sitemaps as a navigational element, to quickly switch between them. Instead, their intended use is to be set in the configuration and not to be changed by the user.

[kubawolanin]

I believe same applies to openhab.windows. @NicoVermeir FYI.

[mueller-ma]

Discovery and bindings could be moved to the action bar or we move the action bar menu to the side menu.

[FlorianSW]

I kind of like the navigation drawer, because it's a more intuitive way for navigating _thorugh_ the app (e.g. the settings menu should be there, too, as well as the "About", I think). The toolbar menu, for me, is more something which should contain contextual menu items, which only applies and are only available for the current activity/fragment.

Also, just to mention: If we ever implement, in openhab-cloud, something to use different OH2 instances with one account, the sitemaps selection in the navigation drawer is the central point to switch between instances. However, this is not merged, yet.

[mueller-ma]

Could we move "Clear icon cache" and "Write nfc tag" to settings and merge "About" and "openHAB info"?

[kvoit]

I guess I was "lead to believe I could use sitemaps as navigational elements", though I also do that in the web UI.
So what is the indented way?

[mueller-ma]

Sitemaps are not intended for navigation. You can create mutliple sitemaps for different people, devices or for testing.

[FlorianSW]

Even if it is not intended for navigation, I think, even for the "intended" usage of sitemaps, having a setting to select the sitemap is way too complicated. Having it in the navigation drawer is, by definition, a good practive, as it allows the user to navigate through different destinations of the app. However, selecting the default sitemap can maybe be moved to the settings menu, though, even if, or maybe exactly because, it already appears when a connection is opened to a new local/remote URL.

I would agree with moving the "Write NFC Tag" to the settings menu, however, I never used it so far, so probably I don't know, how much and when it is intended to be used.

Clearing the image cache is most likely something most users doesn't need at all over the time, which is why this option could also be moved to the "Display settings" in the settings menu.

I totally agree, that the "About" and "openHAB info" entries could be merged to a new activity or fragment, where all the provided information is available. The entry, which could be only "About", should then be moved to the navigation drawer in my opinion. This new page could also hold the version information, which is currently part of the settings menu.

I also wrote similar things on my PR, which also proposes to move the settings menu from the options to the navigation drawer: https://github.com/openhab/openhab.android/pull/404#issuecomment-340221020

[mueller-ma]

I would agree with moving the "Write NFC Tag" to the settings menu, however, I never used it so far, so probably I don't know, how much and when it is intended to be used.

I think it is used once to "connect" nfc tag and item, but not used regularly.

I totally agree, that the "About" and "openHAB info" entries could be merged to a new activity or fragment

The app https://github.com/grote/Transportr has a very nice about screen:




They are using https://github.com/mikepenz/AboutLibraries for creating the libaries tab.

[FlorianSW]

Two screenshots from PR #433:

[lolodomo]

Is there a reason to have 2 different menus. The navigation menu at left looks good. Why not merging the two menus in the navigation menu (side menu) ? I agree with @FlorianSW suggestions to move most of the entries of the top right menu to the settings dialog. It will remain the Preference menu entry and I think this one could be moved to the side menu at left ?

[kaikreuzer]

May I suggest to only discuss one issue at a time?
This issue here is about removing the existing hamburger menu as neither "sitemap selection" nor "discovery" or "bindings" are helpful here.
Any improvements/refactorings of the existing settings menu should probably be best discussed in https://github.com/openhab/openhab.android/pull/404.

[FlorianSW]

@kaikreuzer In my opinion the discussions are very well suited into this issue as well. If we decide to rebuilt how the navigation in the app should happen, it would be waste to first remove the left navigation menu and then re-adding it, wouldn't it? :)

From what you said with the "sitemap selection" and "discovery" as well as the "bindings" menu aren't very helpful here: Do we actually have any data about that? Do we know, how users use these navigation elements? I think, even if it wasn't intended to be used as such, if users use the sitemaps in another way on a mobile device as they would do on a computer, it wouldn't be very clever to simply remove it?

Also: Even if the site menu contains only the "Settings" and "About" menu, in my opinion it is better placed there.

What I want to say is: Before simply removing the navigation drawer, I would love to discuss, how we can rebuilt the navigation of the app to better fit the users expectations (=> as the user sees the menu entries in other apps).

[kaikreuzer]

What I want to say is: Before simply removing the navigation drawer, I would love to discuss, how we can rebuilt the navigation of the app to better fit the users expectations

No, these are two steps. Removing menus that must not be there is the first easy step, for which I gave the reasons in https://github.com/openhab/openhab.android/issues/392#issue-262112603 (and no, the code will still be out there, so I don't see an issue in first removing it and potentially with #404 adding a new side menu with anyhow a completely different content).

[digitaldan]

@kai to be clear, your request is that we remove the hamburger menu completely and then in another issue refactor the drop down menu? Are you against using a side menu to contain what is currently in the dropdown, but refactored in a way that makes sense? I do think using the side menu to hold what is currently in the dropdown would be more consistent with other android apps (like my inbox app from google).

[kaikreuzer]

Yes, independently of whether or not we refactor the content of the dropdown menu to become a hamburger menu (as suggested in #404), the current content of the hamburger menu should be removed. That's why I would prefer to treat it as two separate steps. The second step would then be clear to merely "change the settings menu style from drop-down to hamburger".

[Dracrius]

I completely disagree with @kaikreuzer and the removal of sitemap selection from the side menu!!! @FlorianSW is right as I use this to quickly switch between my Status/ Maintenance sitemaps and my Main sitemap. I can understand in most instances this is not the intention but my Android is what I use for debugging because of the sitemap side menu please do not kill a VERY good feature! I'd also like to say I agree with @digitaldan that there should be no discussion of removing the side menu only repurposing it as the "Hamburger" menu is an Android design standard.

[digitaldan]

@kaikreuzer do you feel strongly about removing the sitemaps still after @Dracrius comment? I am worried that others may be dependent on this feature whether it was intended for that use or not.

[digitaldan]

@kaikreuzer , just getting back to this. I'm unclear what to do here. It sounds like there is support for keeping the existing sitemaps functionality in the side menu, which is also how the IOS app works. Would you be against keeping the sitemaps here, but removing the discovery and bindings menu from the app? I'm ok with this approach.

[kaikreuzer]

@digitaldan Ok for me to remove discovery+bindings only for now, but everyone should be aware that if he is using sitemaps for navigation, that this is not the purpose of them and those parts should rather be aggregated into a single sitemap. All further evolution should be done having this in mind.

[Dracrius]

I personally do not use them for navigation but for ease of use!! I don't want my partner or her parent's for instance messing around in my maintenance sitemap that is purely meant to display everything I need for trouble shooting rule firing off wrong and such so I'd setup there app with my main sitemap! It is convenient and the only reason I love the app for maintenance!

I'm also not going to make a sitemap just for me that has a maintenance link as this would take away from the clean interface I have built for myself and prefer to use 9 times out of 10!!! Some users are going to like to have different sitemaps for different use cases I think this should be excepted not fought! These situations result in users using the sitemap menu maybe a few times a day, once for an at work sitemap, maybe a driving one and finally a home one. I don't use it this way but I can see it being used that way and it makes more sense then having a sitemap that starts at a Driving, Home or Work Screen. I don't use it this way myself yet but I wouldn't be surprised if someone did!

[kubawolanin]

I also did like the convenience of the sitemaps in the side menu. Simply because I could access them even if I was deep down inside the Frames ;-)
Seeing that discussion I started working on merging my sitemaps (specific for different areas) into one massive sitemap.

I remembered one photo that @ThomDietrich shown on his presentation during Smart Home Day. It was this photo I believe - it pretty much sums up the discussion evolving around the side menu sitemaps ;-)

[mueller-ma]

What do you think about #1554?
It adds a switch preference to show/hide all sitemaps in the drawer. It's disabled by default.

[kaikreuzer]

Sounds like a decent compromise.