You should separate the two actions. Use tabs just for selection and for adding a task you should stick the action to bottom of visible area. Your tasks can be viewed by scrolling within the tabs and add action
Here is the wire-frame of concept explained above.
You point out that there is a surplus of criticism and a scarcity of alternatives to the hamburger menu.
Hamburger menus have been criticized because:
They hide links and content from the user instead of presenting the user with direct options.
The hamburger icon is placed at the top of the screen where users tend to ignore it.
The hamburger ...
Selection category and its action can be separate, as it likely to confuse most of the users. Having a clear separation between them will be more clear and it also standard practice for mobile. You may also want to consider any other actions that users might require on the screen and group them together. Have quickly modified the wireframe earlier shared by '...
Don't compromise your UX for the sake of following material design. Material design is meant to compliment your UX, not dictate it. So don't follow it to the word. 1st decide on what's the best user experience and then decide on which and how much of googles material design guidelines you are going to use.
I believe Tab Bars are a much more user-friendly approach than the "hamburger" button.
"Hamburger" buttons hide the menu options, and many times users wouldn't even know some of these options exist if they don't open the menu. Sure, "About Us" and "Contact" are expected, but what if you have other offerings? Different sections?
People are not unfamiliar to ...
Stack exchange uses an "inbox" that changes to a # when you have notices. G+ uses a circle w/ a bell, which changes to a circle w/ a #. Another possibility would be a mail icon (or mailbox). Personally I kind of like the idea of a circle with a 0 in it, or whatever # of notices they have.
According to the recent updates of Google Material design,
here's where material talks about tabs usage and it forbids using nested tabs:
Although Google puts a lot of effort to make the best UX, the bottom line is that if tests give you better results with nested tabs, then use them.
But you can also think about using alternatives like drop down menus or ...
Exis ran an A/B test on this topic.
In his case the result was that the text menu with a border (making it very obvious that it's a button which you press to view the menu) worked best. Who would've figured ;)
Full article: https://web.archive.org/web/20160711135801/http://exisweb.net/mobile-menu-abtest
Like with most questions like this, the tl;dr is: It depends.
The correct navigational pattern is largely contingent upon three things:
App structure (IA)
Leaf page functionality (IxD)
Desire to enforce prioritization by the product team (Organizational)
If your app is structured such that you can support fewer than 5 first-tier leaf pages, ...
Always use labels for your icons if you can. This greatly helps icon usability.
Here's a snippet of an article by the Nielson Norman Group on icon usability.
A user’s understanding of an icon is based on previous experience. Due
to the absence of a standard usage for most icons, text labels are
necessary to communicate the meaning and reduce ...
Is it better to show the text along the Icons? (I thought it would get too chaotic if too much information is presented at once, like "less is more")
Check more information about this subject here: When to use icons vs. icons with text vs. just text links?
Basically a user’s understanding of an icon is based on previous experience. Due to the absence of a ...
So your question is basically How to ensure the contrast of both active and inactive elements while keeping the color harmony?
There are several approaches there:
Playing with opacity - the approach you have taken - and while using that, ensure the contrast is sufficient by removing all color, turning the image to grayscale. If you can't see the inactive ...
Yes, it is the same with iOS and the tab bar should be visible everywhere.
Don't hide a tab bar when people navigate to different areas in your app. A tab bar enables global navigation for your app, so it should remain visible everywhere.
The more menu on a bottom navigation menu is actually a rather common navigation pattern. Yelp, Yahoo fantasy football, Band are a few apps just on my phone that use this navigation paradigm.
There are pros and cons to any navigation approach, the main con of a bottom navigation bar being that it uses more screen real estate than say your typical off ...
Keep in mind that the guidelines that Google proposed for Material Design are just that: guidelines. They won't be able to help you in all situations, but they are good enough to give you a jump start.
Is this ok?
The Material Design guidelines has a few different recommendations for handling this situation. Right now you have two levels of navigation:
Ultimately, no, it doesn't make a difference, but there is an argument for having the home button on the left.
Left-to-Right Languages and the Concept of 'Returning' or 'Going Back' Home
Design conventions for left-to-right languages put things that happen in the past in a virtual space to the left, and things will happen in the future in a similar space ...
Material design guidelines rightly points out your problem:
The bottom navigation bar enables quick movement from deep in one topic to the top of another topic. Keep it available as the user descends the hierarchy, either by showing it persistently, or by concealing and revealing it upon scroll.
The bottom navigation bar shouldn’t be used for:
On mobile, enclosing a touch element within another touch element should be avoided if possible.
Differences in displays, touch sensors, and user anatomy can make it difficult for some users to activate the desired region consistently.
The layouts by Shaz and Yobuddy adhere to this principle, so I would lean toward either of them. Shaz's layout is simpler, ...
I have two suggestions to consider so please read through and consider the arguments for each.
Floating Action Button
A floating action button button provides the primary action for the screen on which it appears. I strongly recommend this approach however you've expressed concern about using these in the question so allow me to address them:
I like your idea but I would say "it depends".
If you plan to have the tabs visible at all times and scroll the tasks within the tab (I assume there are more tasks than one screen can hold) without any header within the tab itself, then the tab is the correct place. If you want to decrease users' surprise with the function of the button (many may expect ...
Acceptable maybe, but I don't recommend it.
If people are looking for a way to add a new task, it could be not so easy to find since the button has no label nor any contextual clue. This design could be subject to inattentional blindness: People will not see the plus icon since they don't need the tab switch. This can be the case for people that know they ...
I see a problem in the meaning of this place.
An action button on a tab suggests that you can interact with the tab when the tab is inactive.
The most common example is the close tab button in a browser. Another option is the new tab button at the end of the tab bar of a browser. Another possible button on such a tab would be "duplicate tab".
When you ...
The back button should do just that: go back. Viewing in the collection is an entirely new action (unless you were just in the collection). Therefore, consider simply adding an action button to this UI.
Please forgive the awful paintjob
It is better to show an icon with text. Many people are not familiar with all icons. The primary task of an icon is to help users where they need to go and browse for the data they are looking for.
For icons with labels, users were able to correctly predict what would happen when they tapped the icon 88% of the time.
Icons can make or break the usability.
As you said:
But this is against Apple UX Guidelines of using UITabBarController, as there should be just one TabBarController throughout the App.
Therefore bottom tabbar is out since you already have a main tabbar.
Since I don't have the full back story, I'm assuming Timeline, Plans, Conservation and Budgets are the page sub-links.
Here are some ...
What you're describing sounds like the "Tab" + menu UI used on the Semantic UI framework, specifically on this page. The behavior of the tabs and the right menu seems pretty similar to what you're describing.
I don't know a specific name for the style, but it seems to be a fixed div with in-page navigation. You put a fixed div at the top of the page with a menu and then each div is named such as
<a name="Section 1" />
Then, at the top of your page, in the menu bar (your fixed ), you'd put the link to that section:
<a href=”#Section 1”>...