[idea] Mobile UI #14: Alternate Main Screen Layout

[Bocio]

Previous idea here:
Mobile UI #1: general layout
Mobile UI #2: default action for main screen button
Mobile UI #3: Dive list item layout
Mobile UI #4: Dive list different layouts and menu option
Mobile UI #5: Sidebar
Mobile UI #6: Dive detail title
Mobile UI #7: Dive list EOL and Swipe To Refresh
Mobile UI #8: Sidebar Header
Mobile UI #9: Settings page
Mobile UI #10: Title Bar
Mobile UI #11: Edit Dive / New Dive layout
Mobile UI #12: Auto-save pattern
Mobile UI #13: User Auth management

Most of mockups made with moqups and are online at: (https://app.moqups.com/Bocio/3SSyFCoEwP)

Despite the brand new Subsurface mobile is still in early beta I have some spare time to add more confusion with an alternate layout for the main screen.
Until now, main remarks to new ideas on App UI are:

• Android action Bar is our enemy because it wastes a lot of screen space.
• Subsurface users have short thumbs so the Action Bar is far far away.
• Users want the most common used actions/features ready at hand without digging into menus or stretching their thumbs to reach the infamous Action Bar.
• For the aforementioned points, most used actions tends to stay on the main sidebar item level regardless of their semantic affinity.
• Current Title Bar is cousin's Action Bar. Despite being thinner it is nearly useless displaying only a sort of breadcrumb.

So we have a Short blanket syndrome: "While I cover my Neck, I expose my Feet, and if I cover my Feet, I expose my Neck. Ugh!"

A note on current Action Button and screen space

Right now I have the hamburger icon and the Action Button with a right (+) button. Even if I can see the dive behind them I consider that space wasted. Usually I have to slide dive list upward to properly see and select the last bottom dive item. Hence my:

Extreme proposal

• We remove the Title bar. Our menu structure and info displayed are very straightforward. IMHO there's no need to help the user understanding where he is. Moreover current impl sucks.
• We remove the huge Action Button from bottom screen,
• We add the infamous Action bar on bottom screen. It occupies the same vertical space (maybe less) of the current hamburger + action button.
  For the happiness of fast thumb guys the new Lower Action Bar will have several small buttons for each of the most used actions/features. IMHO a good start could be:

1. Download from DC
2. Add new dive
3. Start/stop GPS
4. Search
   In my mockup I added a three point icon that on Android means "options". This could be useful for screen context based options/actions i.e. see this [idea] Mobile UI #4: Dive list different layouts and menu option #428

N.B.
I did not elaborate further my idea but it's obvious that Lower Action bar icons should change or enabled/disabled based on the context (screen) we are (i.e. while viewing a dive detail I have an "edit dive" icon instead of "add new dive" icon). Anyway this is just a starting point.

I got this idea form the DU screen recorder, a swifty Android app for phone screencast. They have an upper thin bar with all the functions implemented as tabs. While they do not have a sidebar I thought that a similar solution on the lower part of the screen is worthwhile for our needs.

You can see it in cation here: https://www.youtube.com/watch?v=IuGCgQnZqw4

[dirkhh]

This simply isn't what the toolkit that we use suggests. I will agree that this is a visually attractive solution. We could manually implement that and just ignore the "action button design" implemented in Kirigami.

Food for thought.

Thanks, @Bocio

[Bocio]

Considering that I know nothing about QT. What do you mean "suggests"?
I thought in QT it was a TabBar with a TabBar Button.

Bye

[dirkhh]

We use Kirigami for the mobile app. Kirigami's design philosophy is why we have no menu bar on top and why we have the global drawer with the hamburger button to open and why we have the main action button with up to two side buttons.
We are always free to ignore their design philosophy and do our own, but on these key items we had decided to follow them.

[Bocio]

Ok clear.
It's a shame because I'm convinced that this solution fulfills all our needs. But then we have to do some compromise.

[dirkhh]

Let me be clear - if someone has the time to create an implementation of your idea, I'll happily try it. I'm not against it at all. It's just not something that our toolkit gives us without extra work. That's all.