Revamp mobile UI

[tobyzerner]

I've been thinking about this for a while... Flarum's mobile UI can be a little annoying sometimes:

• You can only access the hamburger menu (and consequently search, notifications, log out, etc.) when you're on the homepage – not from any other page.
• Notifications, which are pretty important, are two taps away (hamburger > notifications). Would be better if they were one tap away.
• Whenever I want to filter by a certain tag, I instinctively press the hamburger button. Cannot unlearn. It's not obvious that you need to press the "All Discussions" title, especially when the hamburger button is right next to it.
• Search is hidden and cramped in the hamburger menu.

The solution? A tab bar.

Google have just come around to this way of thinking too. Really, hamburger menus suck as a primary means of navigation.

Here's what I propose:

(Don't mind the out-of-date discussion list styles! I based this mockup on some old mockup files I had lying around :P)

The four tabs are inspired by Facebook's mobile web interface:

• Home is the equivalent of clicking the forum title. It takes you to the forum's default route. We could potentially allow this icon to be replaced with a custom brand icon.
• Search shows a blank page with a search box, ready to show you suggestions as you type.
• Notifications shows the notifications page. (I also want to merge Flags into Notifications and add the ability to filter the notifications list by type so you can still see a list of just flags. But I'll make another issue for that later.)
• More shows a page with the forum title/logo, the user menu, and any other links in the header.

Additionally, discussion list sort-by and "mark all as read" would go into a dropdown menu.

The tab bar would be the same on every page, stuck to the top when scrolling down, with the current tab (if any) highlighted. When viewing a discussion, there would be an additional sticky bar below the tab bar with the reply button and the post index/count.

Technically speaking, we can probably make this work with (more or less) the same component structure/markup as the desktop UI uses currently:

Desktop	Mobile
Header	Tab bar
Forum logo	Home tab
Primary header links	(hidden)
Search box	Search tab, linking to a mobile-only page
Notifications dropdown	Notifications tab, linking to a mobile-only page
(hidden)	More tab, linking to a mobile-only page

Any thoughts?

[luceos]

What's the difference between the tripple dot next to all discussions and the menu in the tab? I find that confusing.

For the rest it looks really good.

[tobyzerner]

@luceos The hamburger menu tab is a global site menu - it shows a page with the forum title/logo, the user menu, and any other links found in the desktop header. The ellipsis next to all discussions is the controls that you usually see above the discussion list (sort by latest, mark all as read).

We could make it a cog icon instead of an ellipsis? That might make more sense.

[luceos]

We could make it a cog icon instead of an ellipsis

That would probably make more sense. Hamburger vs tripple dots don't differ that much in their meaning, at least not to me.

[dcsjapan]

Really, hamburger menus suck as a primary means of navigation.

I agree ... the only time that works is for a site with something that you want visitors to really focus on, such as artwork surrounded by a lot of white space.

I like this layout, with the same reservation that @luceos expressed about the ellipsis. It works when it appears next to a conversation title (in which case it has a different meaning altogether), but in this context I'm not sure what to expect when I click it. It would be better to avoid it, due to the fact that it's being used with another meaning in the desktop layout.

I'm not sure about the cog either ... to me, that says "settings" such as notification preferences and such. Again, this could be confusing; another type of icon might be better:

• sort doesn't cover "Mark all" but it does cover the rest of the controls.
• check-square-o is the reverse, and probably a poorer choice.
• th-list could mean generic index controls ... though it may be too similar to the hamburger.

There are probably some other possibilities worth considering. But please take this with a grain of salt; I don't use mobile apps enough to have good instincts where their design is concerned.

That said, I really like the tabs across the top. It's slick enough that people may stop asking if you'll ever do a Flarum mobile app. 😃

[franzliedke]

Well, "more" could also be the simple text.

I like it. But shouldn't this menu bar at the bottom, where it's easier to reach with the thumb?

[dcsjapan]

shouldn't this menu bar at the bottom, where it's easier to reach with the thumb?

See, that never occurred to me. But it's an interesting idea, not only for the ergonomics, but also because the non-alignment of the right- and leftmost tab icons with the icons below looks a bit awkward. Moving the tabs to the bottom would alleviate that as well.

Is it common to put tabs on the bottom in mobile apps? It does seem a sensible thing to do.

[moutonnoireu]

Is it common to put tabs on the bottom in mobile apps? It does seem a sensible thing to do.

That's a very insteresting thought, it always bothered me that people kept thinking that a mobile usage should be the same as a desktop usage. That's just wrong, you need to think in terms of usability before all. And, putting a menu at the top of the screen when the mobile's screen are being much and much bigger is keeping this wrong idea of "same thing across all devices", no, stop beating the dead horse, he's tired of it, now.

The funny thing is that 3 day ago, google started to encourage to put the menu in the bottom of the screen, where the thing should have been all that time, damn iOS guideline, eh.

So, i'm in favor of putting the menu at the bottom of the screen or making it swypable and it's the best case, both.

We could make it a cog icon instead of an ellipsis?

Cog = settings, can't do that.

[tobyzerner]

Ellipsis/cog button

OK, I think it's pretty clear that putting the sort/mark as read controls under a menu isn't going to work. How about this alternative:

Tab bar at the bottom

In an ideal world, absolutely!

Unfortunately we don't live in an ideal world, but rather a world where Safari on iOS reveals its toolbar when you tap on the bottom of the viewport. A second tap is required to interact with an element on the page.

There is no workaround for this, so we simply can't have the tab bar on the bottom – it must stay on the top. Presumably this is the reason why Facebook have their tab bar on the top of the mobile web app too, because on their mobile native app, the tabs are moved to the bottom.

[dcsjapan]

How about this alternative:

That looks very nice! Making the All Discussions button bigger seems like a good idea.

That button will use the tag color when a tag is selected, right? How about coloring the New Discussion icon in Flarum orange, to match the appearance of the button in the desktop layout?

[meetdilip]

Can I ask for a wider " Start Discussion " button in mobile UI ? Something like in screen shot below

[luceos]

The mark all read link is very risky. What if you tap on it by accident? I'm not too sure about having them right under the all discussions. Fat fingers and links 😁

[franzliedke]

For future reference: we need to revisit the discoverability of the sorting dropdown, once this is implemented (as explained by Toby in flarum/lang-english#94 (comment)).

[gurjyot]

Guys any update on this issue? Since nowadays 80% web traffic is from mobiles, thus is update would make a lot of sense.
Right now the mobile users are not having the best time on Flarum due to that hidden search and hidden logo.

[ekici23]

The mobile interface also requires this kind of update

[askvortsov1]

Is this something that's remotely in progress? If not, I might be interested in working on it.

[franzliedke]

We don't have immediate plans to tackle this, no. You may, of course, send PRs. The smaller, the more iterative, the better. 😉

But really, if you want to have the most impact in moving Flarum towards stable, your best bet is helping out with the extender API (#1891) - from what I've seen, you seem to know your way around PHP. (That said, we value any contributions - and you can feel free to tackle whatever is most interesting to you. However, our roadmap influences how much attention we can give to community contributions.)

[askvortsov1]

Noted. I'm fairly new to this project, and have a bad habit of wanting to jump into absolutely everything :)

[shawny43]

Maybe we needs to get the menu at bottom for one handed operations.

[askvortsov1]

I did some research and thinking today on this, prompted by https://discuss.flarum.org/d/26283-short-surveyfeedback-from-first-time-users/5. A few immediate observations (all of this is purely about mobile):

• Phones are getting bigger and taller. Accordingly, it's more and more of a pain to access elements at the top of a page (see the "new thumb-zone mapping") charts at https://www.smashingmagazine.com/2019/08/bottom-navigation-pattern-mobile-web-pages/
• When using a forum, the vast majority of time will be spent across:
  • Reading content. You'll generally do this with your eyes on the top part of your screen, and your thumb scrolling on the bottom part. Flarum is mostly fine here, although there's stuff that could be better (most notably, Floating discussion title #433)
  • Writing content. You'll go this with a 2 handed grip, typing on a mobile keyboard (bottom half of screen) while looking (again) at the top half of the screen. Flarum is alright here, and will get better with Reply composer window sometimes outside the edge of the screen, on mobile framework#1670 and Composer is partially hidden on small mobile screens when keyboard is open framework#2628, which makes the composer taller (more space to see what you're writing + formatting buttons closer to thumb)
  • Navigating, triggering actions, etc. With all due respect, Flarum sucks at this right now, as ALL controls are at the top. To switch pages, start writing a post, etc, I need to either hold my phone with 2 hands, or do this weird thing where I tilt my screen or drop my phone a bit down in my hand so I'm holding it at about the halfway mark. Now that I've realized I do this, it's quite annoying that I have to.
• Flarum's current "UI Bar" (the one at the top) has MORE than enough space for more buttons; case in point, there's an extra save button coming from drafts when the composer is open on discuss.flarum.org, I don't see why we don't use that. The buttons displayed could depend on the page, but clear candidates include search, notifications, etc
• The "back" button is stupid (at least IMO). Removing it in favor of the hamburger nav was my second ever pull request in Flarum. Right now, when on a discussion page, users have no way to log in/signup unless they go back to the homepage first. Plus, the vast majority of devices/browsers have some form of gesture based navigation.
• There is A LOT currently crammed under the hamburger nav, that would be nice to have more accessible. Some of it (site-wide non-forum links) probably makes sense. Others (search, notifications, maybe some user stuff?) would be nice to bring out.

Additionally, a few thoughts on the above UI proposal:

• Keeping nav at the top fixes none of this. I think we need to accept that Safari mobile is, and will continue to be, an anti-productive force in mobile web development, and learn to cope with it. app.ft.com deals with this issue by forcing the Safari bottom nav to always be open. (Alternatively https://medium.com/butternut-engineering/sticky-bottom-navigation-7b6038bd27b6) I'd vote to do the same here and bring down the menu to the bottom.
• In the proposal above, it looks like start discussion / sidebar nav are separate. This looks nice when scrolled up like that, but needing to scroll all the way to the top to navigate/post is even worse than needing to reach all the way to the top. Alternatively, if it's part of the header structure and scrolls as the user scrolls, that's a LOT of room taken up by nav components.

I propose starting with the following changes:

• Move the top nav bar, exactly as it is, down to the bottom of the screen, force the Safari bottom menu open to avoid having to click twice
• Remove the "back" button, replace it with a hamburger dropdown always. We'd need to figure out how this affects the discussion pane on desktop though (maybe some other element on the left hand side?)
• Add support for 2 more buttons (one on either side) to that nav bar, use one for search, another for something else (notifications? Session dropdown? (maybe that should contain notifications on mobile?))
• If a user is not signed in, replace the "start discussion" icon with a "login" one.
• Evaluate whether ellipses is the best option for the "actions" button present on discussion / user pages
• If possible when the composer is open, the ui bar should go to the top, so that the keyboard is as close as possible. That's a later optimization though.

[meetdilip]

Not everyone is buying a big-screen phone. But whatever be screen size, the old Windows XP taught us a lot. Flarum can by default or by opt-in add a " Start Button ". As suggested before there will be issues with different screen size while choosing the local of the Start Button. When placed on left-bottom-corner, it will be a bit hard on right-hand users with a large screen.

I think a button which can expand to give options as described above will be a useful one

[tolgaaaltas]

Not everyone is buying a big-screen phone. But whatever be screen size, the old Windows XP taught us a lot. Flarum can by default or by opt-in add a " Start Button ". As suggested before there will be issues with different screen size while choosing the local of the Start Button. When placed on left-bottom-corner, it will be a bit hard on right-hand users with a large screen.

I think a button which can expand to give options as described above will be a useful one

It's looks like Office Mobile's bottom bar. I think it's looking good but i'm not a bottom bar fan on web sites. Most of mobile browser has a bottom navigation bar, when you browsing in a page they are hiding on interface. When they hiding on interface, sticky bottom bar moving without animation and it feels website as lagly.

[zerosonesfun]

At first I saw @askvortsov1’s comments and I was against a bottom nav bar. I’ve personally had small issues with these on my iPhone. Largely due to this black bar you’ll see in the following screenshot.

iOS does this, and other phones/browsers could do similar things in the future. And so, anything at the bottom could be a risk.

But, I like bottom navigations/options.

You could at least put the post counter at the bottom. And anytime something like All Discussions with arrows shows, it could be at the bottom, making way for a logo visible at the top.

That’s my biggest request. Let the site name or logo be visible at the top.

A possible option for those against anything at the bottom is something like the following. There’s always a logo and always a hamburger menu. Then other things below that.

.....................LOGO...................🍔
—————————————————-
All Discussions.............⏳ ♻️ ☑️

Although, I was just in the Twitter app and no logo is shown. Because, you know you’re in the Twitter app. I go back and forth about whether or not a logo/site name should be visible at all times or not.

[zerosonesfun]

I like this. Notice how tall the bottom menu is. This is necessary due to iPhone’s black gesture bar.

[zerosonesfun]

Scratch dev.to as the example. I was just reading the news and realized that Google News is a better example. It has the user profile and search icon. Plus, an interesting idea... grid menu (maybe for tags or something?)

[askvortsov1]

I wanted to add a few thoughts to https://github.com/flarum/core/issues/867#issuecomment-785483209

I've been thinking a bit about general mobile layout. On a phone screen, we can have:

1. A top bar
2. The page content (which depends on the page, so let's not talk about it here)
3. A bottom bar
4. Floating bubbles / chat heads
5. The hamburger nav menu

I don't think (4) would be appropriate for Flarum's minimalistic approach. However, I think we should discuss how we could take advantage of the other features. A few thoughts:

• A bottom bar could be dedicated to controls that the user would interact with often. This could include the "actions" dropdown on discussion/user pages, the "new post / reply" button, search, maybe hamburger nav?)
• The top bar could include information elements (logo/current page controls) and elements that the user rarely interacts with (notifications, profile dropdown)
• Anything that doesn't fit into these could go to the hamburger menu

[luceos]

@askvortsov1 I like that proposal. Would the dropdown allow vertical scrolling it would solve some issues with (future) extensions demanding an entry in discussion controls or on other pages.

[askvortsov1]

Would the dropdown allow vertical scrolling it would solve some issues with (future) extensions demanding an entry in discussion controls or on other pages.

I don't see why not, I don't think we should limit ourselves to the vertical space immediately on the screen.

[davwheat]

A bottom bar could [...] include the "actions" dropdown on discussion/user pages, the "new post / reply" button, search, maybe hamburger nav?)

I don't like the idea of new post/reply being on the bottom nav alongside other navigation options. Bottom navs, in mobile apps, are used for navigation, not for taking actions.

Using something like a Floating Action Button is more appropriate, similar to the example(s) here: https://material.io/components/app-bars-bottom#behavior

I'm a fairly big fan of inset FABs. I haven't looked into how they can be implemented in CSS, but I'd assume it'd be with clip paths, or similar.

[askvortsov1]

Using something like a Floating Action Button is more appropriate

I would be alright with this. If we centralize the controls for all (or most) actions in one place consistently across pages, but separately from nav, that would make things really clear to users.

On a somewhat tangential note, we should consider using some form of extender-based system to register / manage these entries. I'm not sure that just pulling elements with relevant CSS classes like we do now for the buttons and top nav is the best approach.

[davwheat]

Don't we use item lists for that? Or do you mean some easier way for admins to edit the list of controls?