search

dwyl / app

Clear your mind. Organise your life. Ignore distractions. Focus on what matters.
http://dwyl.github.io/app/
143 stars 22 forks source link

Feat: Basic App Navigation #305

Closed nelsonic closed 1 year ago

nelsonic commented 1 year ago

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

image

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

Todo

LuchoTurtle commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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.

image

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)

image

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 commented 1 year ago

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

SimonLab commented 1 year ago

First thought coming to mind:

Hope this help

seaneady commented 1 year ago
image

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 commented 1 year ago

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 commented 1 year ago

@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".

image

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

As noted in by https://github.com/dwyl/learn-wireframing/issues/13 image

What do you think of this?

image

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:

image

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:

image

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?

image

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: https://github.com/dwyl/app/issues/307 🙏

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

nelsonic commented 1 year ago

@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: https://github.com/dwyl/mvp/issues/221#issuecomment-1404384279
  2. Once they've unlocked the Nav Menu they will see the Feature Tour option #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 commented 1 year ago

The colors "ones defined by the selected theme" ... ? :man_shrugging:

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: image 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 commented 1 year ago

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: https://github.com/dwyl/product-roadmap/issues/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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

nelsonic commented 1 year ago

@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: https://github.com/dwyl/app/pull/302#issuecomment-1436460497