Feat: Basic App Navigation

[nelsonic]

Navigation is simultaneously "boring" and essential.
Here's something I threw together:

Direct link to Figma layout:
https://www.figma.com/file/WrpkKGJNYZbeCzMRDVtvQLbC/dwyl-app?node-id=1516%3A4909

Todo

• Please share your feedback by commenting on this. 💬 🙏
• If you feel confident in your Flutter skills and want to pick this up, again, please comment! 🧑‍💻 🙏
  • We're going to create a dedicated repo for experimenting with Navigation. 🆕
    • Once we have the "Basic Nav" working flawlessly we will look into "Dynamic Nav" Feat: Dynamic Top Nav #300 🏝️

[LuchoTurtle]

Looks good! Though I have a question regarding how it will scale as more options are added.
How should sub-menus be constrained when there are multiple actions one user can partake? Should there even be sub-menus in such cases?

[LuchoTurtle]

Not gonna pick this up now since I want to go over https://github.com/dwyl/phoenix-chat-example/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc first 👍

[nelsonic]

@LuchoTurtle thanks for the feedback + follow-up question. 👌
Here are some answers. Hope they are helpful. 🤞

Scaling 🚀

The in-app Nav menu will only have a handful of items so I'm not concerned about about scaling.
But in the experiment it would be good to test with ~30 menu links and vertical scrolling.

Sub-menus ⬇️

The quick answer is: or now ... we won't need sub-menus.
The longer answer is: if you can describe the use-case for sub-menus (and there definitely is one!)
you are very welcome to exercise your Fimga skills 👨‍🎨 to illustrate a sub-menu (e.g. up to 2 levels of nesting)

Please don't take this sketch as "this is what we're definitely doing". We aren't!!
I'm just sketching what we could do. But for now I honestly don't think we need sub-menus.
Again, very happy for anyone else reading this to suggest the sub-menu use-case. 🙏 (please open a new issue!)

By far the most interesting thing about the "Basic Nav"
that I would like to explore in more detail is "Feature Tour". 💭

[nelsonic]

@iteles, @SimonLab, @Stephanymtr and @seaneady very keen to get your feedback/thoughts on this. 💬 🙏

[SimonLab]

First thought coming to mind:

• I'm not sure about the black/white colours. I think I would keep the ones defined by the selected theme, https://docs.flutter.dev/cookbook/design/themes
• Progressive UI/UX (show when necessary) makes sense on specific elements (ex, only show filter buttons when there are items to filter), however for the menu I would expect it to be displayed from the start, especially if there is settings as we expect to be always there.
• We might want to define what we want to display on the menu first, do we need one at our current stage?
• What do you mean by "feature tour"? Guiding people inside the app on how to use the features? I personally not a fan of the in-app guides. At the moment I don't think we have any features requiring a tour to be able to be used. We could have a Q/A or documentation page, videos, if a feature is complex to use but it's something I would build after some feedback or when we have "How to..." type of questions.

Hope this help

[seaneady]

I have one question about the above condition (and it's entirely possible/probable that I'm misunderstanding this); How will the user discover the features that unlock new menu items if they aren't listed on the menu?

[seaneady]

Another comment I have regarding the sub-menus is that the screen will become very 'crowded' if multiple submenus are opened simultaneously, making it confusing to read the screen. Perhaps a feature that only allows one sub-menu at a time could be worth considering.

Otherwise, I think it looks very intuitive and easy to follow.

[nelsonic]

@SimonLab thanks for your feedback; insightful as always. 👌

Black & White?

I don't think we're "married" to this color scheme at all. Very happy to UX-test it.
Simply using this as a placeholder for "high contrast" and "low distraction".

"Near-black" and "Near-White"?

As noted in by dwyl/learn-wireframing#13

What do you think of this?

The colors "ones defined by the selected theme" ... ? 🤷‍♂️
We are defining the theme. We aren't using an off-the-shelf one.

Progressive UI/UX

In Super Mario Bros, you don't go from Zero to Fighting the "Boss" in a the first minute:

There are levels ("worlds") and you gradually build up your knowledge & skills
until you have the dexterity to confront Bowser.
The "player" doesn't know that Bowser even exists for their first 10 minutes of playing.

Showing the "player" everything is overwhelming and off-putting.
The best game design gradually (progressively) introduces "skills" to the player.
Yes, there are games where they throw everything at you at once.
But they are considerably less successful.

Consider the UX in the first screen of MineCraft:

There's only one action you perform: place a single type of block.
https://www.ign.com/wikis/minecraft/Survival_Guide:_Things_to_Do_First_in_Minecraft

They don't overwhelm the player with the full range of tools and materials.

This isn't just a "hunch" of mine. It's a well-established design/UX pattern in game dev.
We're simply bringing it over to App Dev and it will be a breath of fresh air
to all the 95% of younger kids who will immediately appreciate it when they see it!

Settings are Not Relevant to the Beginner

There's no point showing people the Menu until they have completed their first item.

At some point the future we might discover that the "killer feature" of our SuperApp is something else.
We will only know that once we have something to start testing.

My hypothesis this: great minimalist UX design is: don't show people the stuff that isn't relevant to them.

No Menu?

Minimalism and focus is our super power. 🦸‍♀️
Until the person has input some text the Nav Menu is an irrelevant distraction to them.
We don't just want to "nudge" them to start using the App.
We want to not waste any of the the person's time.
If in the first 5 seconds they don't know exactly what to do,
we want them to quit the App, DELETE it and move on with their day.
I know this might sound bonkers. Why would we waste the opportunity to get someone using the App?
Simple: we only want the people that "GET it".
People who are after bells and whistles can use something else.
People who appreciate minimalism will immediately appreciate what we're doing.
I would much rather have 100 people that adore our UI/UX than have 10000 who are indifferent.
See: https://a16z.com/2020/02/06/1000-true-fans-try-100/

Feature Tour

The App Navigation is not the place to discuss this. Please share your thoughts on: #307 🙏

Hope that answers your questions. And that we can move forward with building the flutter-nav-demo-app. 🤞

[nelsonic]

@seaneady thanks for taking time to read and reply. 🙌
Very much appreciate your perspective on this. 💡

Discovering/Unlocking Features

The features of the App can be unlocked in 2 ways:

1. As the person uses the App new features are gradually unlocked.
   This is best illustrated in the Tags Progressive UX in: Add "create new tag" when tag search for not found mvp#221 (comment)
2. Once they've unlocked the Nav Menu they will see the Feature Tour option Feat: Feature Tour 🪄  #307.
   if they finish watching the Feature Tour for a specific feature e.g. "Working with other people"
   then the People Nav Menu item will be visible
   and they will be able to share items or lists with other people.

Sub-menus

This is a bit of a distraction. as noted above: we don't need sub-menus yet.
I agree! it's very easy to get menus horribly wrong (poor UI/UX) ...
So we want to avoid it as long as possible and keep our Menu single-level.
When we have a legit use-case (new issue please 🙏) for a sub-menu.
Then we need to make the effort to research and design it so that it doesn't suck.
One sub-menu at a time. Agreed.
For now, zero sub-menus. 👌

Thanks again for your feedback. 🙇

@iteles your thoughts? 💭 🙏

[SimonLab]

The colors "ones defined by the selected theme" ... ? 🤷‍♂️

What I mean is that after defining which colours/theme we want to use (teal, near black...), we can let Flutter manages how to apply them to the widget:

see https://api.flutter.dev/flutter/material/ColorScheme-class.html

For example Using Theme.of(context).colorScheme.secondary to apply the chosen color on the container

Container(
  color: Theme.of(context).colorScheme.secondary,
  child: Text(
    'Text with a background color',
    style: Theme.of(context).textTheme.titleLarge,
  ),
),

I was just wondering if the near black/white apply to the menu will contrast too much with the theme colour of the other elements.
Happy to be wrong.

I'm also happy to be wrong with the progressive UI/UX. I also think people are used (wrongly?) to see UI element on the screen by using other application and the menu icon might be one. It makes sense for games to have a "discovery" phase/level as they can be complex to understand how to play, I'm just not sure about mobile applications, I don't want the app to be too "patronising" either towards the person, again happy to implement all the progressive UI/UX features to prove me wrong.

Agree with sub menu, I don't think we should have any at the moment.

[nelsonic]

Agreed. Happy to let Flutter manage the color scheme once we've clearly defined it. 👍

"Progressive UI/UX" is not a question of "right" or "wrong"; it's about understanding how people learn
and applying that knowledge to building something that is immediately intuitive/obvious to them.
People are inundated with extremely poor UI/UX, as noted in: dwyl/product-roadmap#43
There are many "successful" Apps that have horrible UX anti-patterns.
They are "successful" despite their poor UX not because of it.
In most cases they have poor-UX-blindness; they don't even see it!

[LuchoTurtle]

I'm going to start working on this now.
@nelsonic do you want me to create a new repo for this spike?
Or do you want this to be added to an all-purpose "Navigation" repo?

[nelsonic]

@LuchoTurtle good question. ❓
Please use: https://github.com/dwyl/flutter-navigation-menu-demo 🙏
The idea is to demo this one feature in isolation from the rest of the App. 📱
That way when we want to build something more advanced like search-based menu item discovery 🔍
sub/nested menus, we have a standalone repo where we can experiment with it. 🧪

[nelsonic]

Please try to time-box this and get something working as quick as you can while writing down everything you learn along the way. Create your branch and PR ASAP and push your code regularly. 🧑‍💻

[LuchoTurtle]

As I'm thinking on how I'll be developing this, I thought about something. I get the idea of progressive UX/UI, onboarding the user only after he performs some action (in this case, complete a todo item).

But hiding the menu option until the user is "forced to complete an action" will make it so that the user will only be able to change settings after this. This will probably create confusion. Users will think there is no way to change settings, as they don't know that they have to perform and action to access it. I don't think this "gatekeeping" is necessarily good UX.

If I wanted to change the theme of the app straight away, I couldn't nor would I have a way to know that I could perform such an action because I have to create an item and complete it.

[LuchoTurtle]

@nelsonic I feel like this should be marked as completed, since https://github.com/dwyl/flutter-navigation-menu-demo is done.

[nelsonic]

@LuchoTurtle indeed the demo is reasonably complete. 🎉 (thanks!)
But it is yet to be tested by people other than you and I ⏳
and still hasn't been integrated into the App. 📱
See: #302 (comment)