Re-evaluate main navigation

[bertob]

Currently there are three main views

• Home
• Local

• Federated

  and 6 secondary ones in the sidebar

• Notifications
• DMs
• Bookmarks
• Favorites
• Lists
• Search

When the leaflet is unfolded this works because all of these are accessible, so it doesn't matter that much where something is:

However, when the leaflet is folded suddenly the priorities for what's visible and what isn't are pretty weird. In particular:

• Lots of people, especially those on larger instances, never ever use Local and Federated. Literally any of the other views in the sidebar would be more useful to have available than these two.
• There's no notification indicator or easy way to get to notifications (unless you open the sidebar)
• Search is only accessible from the sidebar

Potential solutions

1. Keep everything as-is, but add notifications (and DMs? Maybe combined into a single view?) to the main nav
2. Move Local and Federated to the sidebar, and move Notifications, DMs, and Search to the main nav
3. Make Home/Local/Federated a secondary level of navigation within the view when the leaflet is folded, rather than the primary one (e.g. using an action bar)

Build context:

• Distro: Fedora
• App version: git master
• Build type: Flatpak in Builder

[bleakgrey]

Search is only accessible from the sidebar

Maybe it can be a button in the header bar, just like it already is in 1.0?

Keep everything as-is, but add notifications (and DMs? Maybe combined into a single view?) to the main nav.

I have an idea. Tootle is intended to work in background by default (even though it's NYI in the GTK4 port branch for now) and display desktop notifications as soon as they are announced by the instance. The toasts can have action buttons (like "Read" or "Accept follow request"). Basically, if this tab can be effectively replaced with the OS notification drawer, does it really make sense to have a separate tab for them?

Also, another solution would be an ability to edit visible tabs in Preferences, or something like that.

[bertob]

Maybe it can be a button in the header bar, just like it already is in 1.0?

Sure, that would probably be needed anyway since the search UI currently changes the switcher.

I have an idea. Tootle is intended to work in background by default (even though it's NYI in the GTK4 port branch for now) and display desktop notifications as soon as they are announced by the instance. The toasts can have action buttons (like "Read" or "Accept follow request"). Basically, if this tab can be effectively replaced with the OS notification drawer, does it really make sense to have a separate tab for them?

I don't think that can work, no. You'll always need an in-app notification list.

Also, another solution would be an ability to edit visible tabs in Preferences, or something like that.

I mean generally that kind of approach is a band-aid rather than a solution for the problem at hand :)

That said, if you feel that there are enough people out there who actually use Local and Federated (I don't have any data, but personally I have doubts that's the case) it could be a separate mode.

So by default you'd have something like

• Home
• Notifications
• DMs
• Search

and then there'd be a toggle in preferences which changes it to

• Home
• Local
• Federated

I have no idea if it'd be worth it in terms of maintenance effort for two separate modes vs. how many users care about this though. IMO the most important thing is having a sane default experience with easy access to notifications/DMs/search.

[bleakgrey]

I'm torn too. It's a bit of a chore to maintain two modes, but imo it's not completely pointless.

For example, the official iOS app for Mastodon hides Local and Federated timelines by default with no option to revert that behavior, and it did cause quite a bit of backlash.

Speaking from personal experience, I genuinely find these timelines useful, and their absence would feel like a deficiency in the app functionality.

[bertob]

I mean if you feel like the 2 modes direction makes sense and can work maintenance wise go for it, I'm certainly not an expert on Mastodon or how most people use it.

That said, I wouldn't do it pre-emptively because there might be a backlash, that's not a usually a good way to approach product decisions :)

[bertob]

Also, it's not like we'd be removing the Local/Federated timelines, they'd just be one click away, and only on mobile. With that in mind maybe it'd be better to keep things simple and stick to a single layout?

[bleakgrey]

3. Make Home/Local/Federated a secondary level of navigation within the view

Due to how the app works internally, this definitely would be over-engineering. Besides, it's a rather unpopular choice - I found just one client that does this, Metatext.

Perhaps this could be a viable choice for an iPhone client, but it will create a third bar on a Pinephone where there isn't much vertical space to work with already.

1. Keep everything as-is, but add notifications

Can do. This is how things used to be in 1.0, so this would be an expected and easy solution which requires little effort (if at all).

Tusky, Husky, and iMast stick to this layout, so it's a relatively popular choice.

Move Local and Federated to the sidebar, and move Notifications, DMs, and Search to the main nav

I can see why it might be the most suitable choice for an average user, and I found multiple mobile clients that do something similar with their start screens: Mastodon for iOS, Toot!, Mast, and Amaroq.

I don't have a strong preference, but all things considered I'd go for 2. with an option to select up to 4 tabs for the start screen. This way, it can present the most adequate layout by default while not being too opinionated and imposing. Not having to maintain 2 separate modes is certainly a plus too :)

What are your thoughts?

[bertob]

option to select up to 4 tabs for the start screen.

2. sounds like the best option to me as well, but what do you mean by this? An option to change what's in the main navigation? Isn't that even more complicated than just 2 discrete modes?

[bleakgrey]

These two tweaks require roughly the same amount of effort, but only one of them is flexible enough to satisfy everyone :D

2.0 is quite modular already, and it's possible to make something like this with no effort at all:

Given a proper configuration UI, it can just work.

[bleakgrey]

Perhaps it won't hurt to leave some pictures here for clarity. For example, here's how GNOME Settings handles input source editing:

Tootle can provide a similar list in Preferences, but for "places" it can navigate to.

[bertob]

I guess you'd need two separate lists, with a way to move items between them?

[bleakgrey]

Just one will do, I think? Moving items between two separate lists doesn't seem phone-friendly to me.

[bertob]

I mean if you have just one how do you determine which ones go in the main nav? Just having it be the first 3 or 4 seems weird.

What I meant wasn't drag and drop, but just an explicit button to move to the other list (e.g. an up/down arrow or star/unstar).

[bleakgrey]

What about this?

When Edit is pressed, we can present a dialog with a list of available places. Since there's only so much space in the tab switcher, we can make a boxed list with a fixed number of rows.

[bertob]

Not sure, that makes it look like you're supposed to fill all four slots.

[gitSaptarshi]

@bleakgrey I understand what you are saying. You want to present a list where all navigation tabs are present. But the user have to choose only a fixed number of tabs (let's say maximum 3 tabs from 5 options in the list). So that any user can have their most preferred 3 tabs . Its flexible that a user can choose to have between minimum 1 tab to maximum of 3 tabs.