Fixing the WP10 UI concept video

[anon(5325154)]

Been a long time fan of WP, and like a lot of fans I'm not liking the direction MS seems to be taking the platform in regards to the UI.

A recent video explains the "logic" of putting navigation and hamburger at the top, and getting rid of pivot pages in the process. I think we can do better than that though. Here's a concept video I made to show how we can introduce elements like the hamburger and swipe actions, but still maintain the uniqueness and usability of Windows Phone.

https://youtu.be/LM4qgU008N8

 

[mjyumping]

Interesting, sadly my Windows 10 phone couldnt play videos in youtube

 

[Spectrum90]

The appbar at the bottom takes a lot of room for things that aren't frequently used, and break the immersive experience of the app. Move those things to the hamburger menu.
Only use the bottom for commands when they're really useful in specific pages of an app.

Swiping sucks for navigation. Swiping is better for interacting with content. Swiping to open the hamburger menu is not very useful and hard to discover, I never use it on Android.
Don't use swiping from the sides for different kind of behaviors, that confuse the user.

Interesting, I helped you to fix your weak design and we have Windows 10 again.

 

[a5cent]

I appreciate your effort, but not the non-solution.

This doesn't actually solve any of the navigational problems MS has a valid interest in solving. It's actually more likely to compound the problems, since it combines all the problematic elements of both pivots and hamburgers.

• with many sections, I'd say anything above four, the pivots become a pain to use. It's not a general concept that always works.
• the hamburger button is exactly where all the opponents don't want it.
• if you're going to misuse the pivot for navigation, then this is basically just useless redundancy. For an app that works fine with the pivot you might as well omit the hamburger menu as it then serves no purpose
• most importantly, the entire approach still doesn't free up left/right swipes for the app's use. If this were to be the standard approach, then you'd be forcing every app developer to choose between (a) supporting navigation as the standard recommends, or (b) being able to use left/right swiping gestures for app specific purposes. No app requirement should require a developer to break UI standards. If that's a common choice, then it's a bad standard. That's why this solution isn't one. It doesn't provide a standardized approach that works for every app. It's actually just making the failures of metro worse.

We've already seen concepts that do a better job at solving all of these problems, like this one (the details are debatable, the general concept is good however):

http://forums.windowscentral.com/wi...oncept-combining-hamburger-ellipsis-menu.html

Pivots can/should be retained (the user interaction model, not necessarily how they are presented, i.e. text size, cutoff text, etc) as a mechanism for those apps that want them, as they do make sense in many scenarios. However, they don't suffice as a general way to navigate between different pages of an app. They should be reserved for filtering/sorting lists in simple apps that have no use for left/right swiping gestures.

 

[Spectrum90]

We've already seen concepts that do a better job at solving all of these problems, like this one (the details are debatable, the general concept is good however):

http://forums.windowscentral.com/wi...oncept-combining-hamburger-ellipsis-menu.html

Tabs in the app and tabs in the menu? That concept is even worse.

 

[a5cent]

Tabs in the app and tabs in the menu? That concept is even worse.

Like I said, the details are debatable, but the general concept is good. It solves all of the navigation related problems in a way that actually works:

• it doesn't use left/right swiping gestures for navigation, leaving those gestures for use by the app
• it doesn't add any extra chrome to the UI, not even an extra button (neither a hamburger button on top, nor a button in the bottom app bar), staying true to the content over chrome philosophy.
• it fits in nicely with the things WP users already expect to find in the ellipsis menu (app-level features that aren't specific to the current page)
• it can host any number of entries. With more entries the menu becomes taller, with fewer it's shorter. If the app has only three such entries, then all of them stay at the bottom of the screen, making them easily accessible when using the phone with only one hand, even on large phones.
• the OS can automatically map the contents of the navigational menu to a side bar, when the app runs on a larger screen, without the developer having to do anything at all.
• I can go on, but I'll leave it at that for now

Unless a solution addresses all of those issues (and two or three others I've omitted for brevity), it's not a solution.

The only two points I've seen you make against the concept I linked to (beyond the usual "I'm confused and I just don't like it", which I couldn't care less about) are these:

• it's a two stage menu (A: swipe up from bottom app bar to open, B: swipe to the desired section, C: tap the desired menu entry)
• having two pivots on screen at the same time (as shown in the concept images) is confusing

For an app that requires a navigational section, I'd assume that to be what the bottom app bar opens up to by default, meaning most of the time there will be no extra swipe. The extra swipe to access something like the options section seems tolerable to me. Office for Mobile does something very similar, so we'll be getting used to two stage menus either way. In another thread you stated you weren't aware of MS taking that approach in Office Mobile. You probably missed it because it's not implemented using a Pivot, but with a Flyout menu. That Flyout menu provides access to multiple sections of the ribbon (home, insert, design, review, etc). That's actually a three stage menu (tapping to open the Flyout is an extra step), so this is actually better than Office for Mobile's approach.

As for your point that you find it confusing to potentially have two pivots on screen at the same time (as shown in the concept), well, I partially understand that. I just don't think it's a huge problem that anybody with a little imagination couldn't easily solve. Already today UI elements from the underlying app remain visible when the bottom app bar is opened. I've never heard anybody say they were confused by that. Even the most mentally challenged user will eventually realize that taping anywhere outside the menu won't do anything except close it, but I agree that doing something more can't hurt. Maybe the OS could apply a slight darken and shrink-effect to whatever is on screen when the menu is opened, like it already does for flyout menus. That would provide an extra visual cue as to what elements can be manipulated when the menu is opened. Even if somebody is so deranged as to not intuitively grasp what's going on, the fact that the OS won't allow touch input to manipulate the app's pivot while the menu is opened seems like a perfectly suitable safeguard that will eventually explain itself to anyone and everyone.

 

[Spectrum90]

[*]it doesn't add any extra chrome to the UI, not even an extra button (neither a hamburger button on top, nor a button in the bottom app bar), staying true to the content over chrome philosophy.
[*]it can host any number of entries. With more entries the menu becomes taller, with fewer it's shorter. If the app has only three such entries, then all of them stay at the bottom of the screen, making them easily accessible when using the phone with only one hand, even on large phones.

The app bar is useless chrome most of the time, 9%-15% of screen real estate wasted in things that aren't used frequently. Developers should only put things at the bottom when It's really useful. Most of the time move those things to the top where there is plenty of room. Menus at the bottom aren't intuitive, confuse people, make difficult to sell the phones.

[*]it fits in nicely with the things WP users already expect to find in the ellipsis menu (app-level features that aren't specific to the current page)

It's more important to be consistent with the 97% of the users or even a higher percentage adding desktop users. The biggest part of the 3% of WP users can be forced to the new UI, they will adapt to it if It works well, there is no alternative for them.
Most people buys Windows phones because they're cheap and run better in low end hardware. Freak fans of Metro are an insignificant minority.

[*]the OS can automatically map the contents of the navigational menu to a side bar, when the app runs on a larger screen, without the developer having to do anything at all.

What you're proposing is the hamburger menu at the bottom without the beautiful icon. The only difference is the nonsensical tabs in the menu, or what you call "flyouts". As I already told you, multi-level menu was probably a last resort for a really complex app like office with hundreds or thousands features. Doesn't make sense to add such complexity to simpler apps.

As for your point that you find it confusing to potentially have two pivots on screen at the same time (as shown in the concept), well, I partially understand that. I just don't think it's a huge problem that anybody with a little imagination couldn't easily solve. Already today UI elements from the underlying app remain visible when the bottom app bar is opened. I've never heard anybody say they were confused by that. Even the most mentally challenged user will eventually realize that taping anywhere outside the menu won't do anything except close it, but I agree that doing something more can't hurt. Maybe the OS could apply a slight darken and shrink-effect to whatever is on screen when the menu is opened, like it already does for flyout menus. That would provide an extra visual cue as to what elements can be manipulated when the menu is opened. Even if somebody is so deranged as to not intuitively grasp what's going on, the fact that the OS won't allow touch input to manipulate the app's pivot while the menu is opened seems like a perfectly suitable safeguard that will eventually explain itself to anyone and everyone.

Before you finished saying that, the user already chose an Android/iOS phone. The UI should be transparent, the user won't spend a minute finding the way to archive their tasks in a messed up UI. If you really want to diverge from the worldwide adopted conventions, the new UI has to be amazingly superior. What you're proposing is actually inferior, for the reason expressed above.

 

[Donny James]

I don't see how swiping for navigation (Pivot) and Outlook's new swipe actions will work together without problems. For instance accidentally deleting an email when you wanted to navigate to the next pivot. Making a video and actually using the ideas in real life are two different things.

 

[a5cent]

...stuff...

Look, your arguments are either

(a)
based on your subjective aesthetic sensibilities which I couldn't care less about. Statements like "the beautiful hamburger menu" being an example. Ok, it's great that you think three horizontal bars are a thing of beauty, it's just completely irrelevant. I care about how a device is used, and not what you personally do or don't find beautiful.

(b)
based on a lack of understanding. For example, you have no idea what a Flyout menu is, so you suspect I'm inventing the terminology as I go along, and have completely misunderstood what I'm talking about as a result. Unfortunately, completely misunderstanding my argument doesn't stop you from vehemently arguing against it.

Everything else is just filler, using words like "nonsensical", "complexity" (for something pathetically simple), or "not intuitive" in ways that reveal themselves to be completely meaningless when ever so slightly questioned (I'm sorry, but moving unintuitive menus at the bottom of the screen to the top doesn't magically make them intuitive, that's BS). In general I have no problem with disagreements. I just want to be able to take the opposing views seriously. You're making it almost impossible for me to do that.

I'll gladly respond with more detail, but only after you've made the effort to understood my post and specifically addressed the issues I've raised. I really do try to understand your point of view, and I expect the same courtesy from you. Until then further discussion with you is just a waste of time.

 

[anon(5325154)]

I appreciate your effort, but not the non-solution.

This doesn't actually solve any of the navigational problems MS has a valid interest in solving. It's actually more likely to compound the problems, since it combines all the problematic elements of both pivots and hamburgers.

• with many sections, I'd say anything above four, the pivots become a pain to use. It's not a general concept that always works.
• the hamburger button is exactly where all the opponents don't want it.
• if you're going to misuse the pivot for navigation, then this is basically just useless redundancy. For an app that works fine with the pivot you might as well omit the hamburger menu as it then serves no purpose
• most importantly, the entire approach still doesn't free up left/right swipes for the app's use. If this were to be the standard approach, then you'd be forcing every app developer to choose between (a) supporting navigation as the standard recommends, or (b) being able to use left/right swiping gestures for app specific purposes. No app requirement should require a developer to break UI standards. If that's a common choice, then it's a bad standard. That's why this solution isn't one. It doesn't provide a standardized approach that works for every app. It's actually just making the failures of metro worse.

I do agree pivots should not be used if an app has more than 3-4 sections, which I should have been clear about. When there are more sections something else is needed; what that something else is, well that's what everyone's debating about. I supposed the first pane of a panoramic hub served that function, but that's another thing Microsoft is killing off in WP10.

For apps where pivots are working fine, yes a hamburger is redundant (I'm definitely no fan of it). But the fact is Microsoft seems hell-bent on putting a hamburger into every one of their universal apps. So this was just an idea how both pivot and hamburger might co-exist.

As for freeing up left/right swipes for app use, well, this concept does free up the right swipe for app to use, no? The developer isn't choosing between a or b. But I get where you're coming from, it's not a perfect solution since left swipe is still reserved for pivoting, which I did point out.

 

[anon(5325154)]

I don't see how swiping for navigation (Pivot) and Outlook's new swipe actions will work together without problems. For instance accidentally deleting an email when you wanted to navigate to the next pivot. Making a video and actually using the ideas in real life are two different things.

The idea was that swiping left moves the pivot, but swiping right doesn't, so it can be used by the app for an action (e.g. delete email). That does mean you can only advance the pivot in one direction, which from my own experience is acceptable if there aren't a lot of pages. And also you can't have left swipe action for the app, but as I said that's something we never had before anyways.

 

[Spectrum90]

(a)
based on your subjective aesthetic sensibilities which I couldn't care less about. Statements like "the beautiful hamburger menu" being an example. Ok, it's great that you think three horizontal bars are a thing of beauty, it's just completely irrelevant. I care about how a device is used, and not what you personally do or don't find beautiful.

That was a joke.
Although, beauty is important. People tend to agree to some extend about beauty, It's not a random phenomena. So, if most people think that Metro is unattractive and boring, Microsoft has a real problem.

Everything else is just filler, using words like "nonsensical", "complexity" (for something pathetically simple), or "not intuitive" in ways that reveal themselves to be completely meaningless when ever so slightly questioned (I'm sorry, but moving unintuitive menus at the bottom of the screen to the top doesn't magically make them intuitive, that's BS). In general I have no problem with disagreements. I just want to be able to take the opposing views seriously. You're making it almost impossible for me to do that.

You seem exasperated, your brain doesn't work well in that state. I explained to you two times why that concept is stupid, I don't know what else can I do for you.

 

[a5cent]

You seem exasperated, your brain doesn't work well in that state. I explained to you two times why that concept is stupid, I don't know what else can I do for you.

I agree. Trying to twist non-arguments into something logical is a very hard thing to do after all.

You have two points:
- you find it confusing that two pivots can appear on screen at the same time
- you don't like two stage menus

I explained why both aren't the big deal you're making them out to be. Since it's obvious you can't do anything for me, and that I can't do anything for you, it might just be better that we stop trying. That's my point.

 

[a5cent]

As for freeing up left/right swipes for app use, well, this concept does free up the right swipe for app to use, no? The developer isn't choosing between a or b. But I get where you're coming from, it's not a perfect solution since left swipe is still reserved for pivoting, which I did point out.

Maybe I'm misunderstanding you? I'll try again...

Any pivot based "navigational solution" requires the user to swipe left/right to change to other sections in the pivot. If that's what left/right swiping is for, then it can't be used for something else, like marking e-mails as read (like the new W10M e-mail client, which uses both left and right swiping gestures, right?) You can use swiping for either navigation or something else, like e-mail marking, but not both. If a developer wants both, then what you're proposing requires the dev to choose between:

a) using the left/right swipe for marking e-mails, and then re-inventing their own non-standard for navigation to other parts of the app
b) using the pivot and finding a different way to mark e-mails, or sacrificing that marking capability all together

IMHO that's not good enough. In that sense the hamburger menu (by itself without the pivot) is better. It doesn't require the dev to sacrifice left/right swiping. That's why combining the hamburger button and the pivot into a single control/concept would be a terrible mistake. It would actually make things worse, by standardizing on a navigational solution that has the negative aspects of both the pivot and the hamburger, without solving any of the actual problems.

EDIT: Sorry, I just now realized that you're proposing to free up one of the swiping gestures by limiting the directionality for navigation. I don't know how much I like that. It seems like a bit of a hack, that's ultimately just a partial solution. If there was no other way, then okay. I just think we already have better proposals.

 

[Spectrum90]

Since it's obvious you can't do anything for me, and that I can't do anything for you, it might just be better that we stop trying. That's my point.

Sure.

 

[Donny James]

The idea was that swiping left moves the pivot, but swiping right doesn't, so it can be used by the app for an action (e.g. delete email). That does mean you can only advance the pivot in one direction, which from my own experience is acceptable if there aren't a lot of pages. And also you can't have left swipe action for the app, but as I said that's something we never had before anyways.

But the the new Outlook app has both left and right swipe actions so this will still end being a problem. I don't think we can have both Pivot and swipe actions. The fact that this probably will pose a problem in the most basic of apps -The stock email app- is a big issue.

 

[anon(5325154)]

But the the new Outlook app has both left and right swipe actions so this will still end being a problem. I don't think we can have both Pivot and swipe actions. The fact that this probably will pose a problem in the most basic of apps -The stock email app- is a big issue.

But the new Outlook app features are not set in stone yet right? What I'm saying is that maybe we can get by with only one swipe action in one direction, i.e. swipe right to delete email (which btw is consistent with how you dismiss notifications).

It's true that we'll lose the quick swipe action to flag an email, or do we? Consider how it works on iOS [1], if you swipe (left in this case) on an email, it reveals buttons for More, Flag and Trash. Following through with the swipe will get you the default behavior which is to delete the email. If the Outlook app did this then we would get almost the same capability of having both left/right swipe actions for the price of one.

[1] http://cdn.iphonehacks.com/wp-content/uploads/2014/09/ios-8-mail-app-deletearhive.jpg

 

[manicottiK]

The problem with the proposed solution is that it's like King Solomon's ruling to split the baby in half. In this case, you're splitting the horizontal swipe gesture in half so that the OS gets one direction and the app gets the other. The use would simply get confused. Essentially, this idea would create one-way pivots. If I mistakenly swiped over, I'd need to make an indeterminate number of swipes away from where I wanted to be so that I could loop back to it.

If you're trying to keep a convenient tab-like control without content area swiping, I'd rather see MS add gesture awareness to the navigation bar (i.e., the Back, Windows, and Search button area). webOS had this for page navigation, but a user had to know the gestures to use the device. In what I'm proposing, users who don't know the gesture would simply interact with a multi-tab Windows phone the way that they do with iOS and Android while those of us who do know abut it could swipe from the bottom of the device. (Presumably, swiping would also be allowed in the tab header area and maybe in the app bar if the app has one.)

 

[anon(5325154)]

The problem with the proposed solution is that it's like King Solomon's ruling to split the baby in half. In this case, you're splitting the horizontal swipe gesture in half so that the OS gets one direction and the app gets the other. The use would simply get confused. Essentially, this idea would create one-way pivots. If I mistakenly swiped over, I'd need to make an indeterminate number of swipes away from where I wanted to be so that I could loop back to it.

I find in my daily use I normally swipe in one direction only, and if the app has only a few pivot pages looping back is not that big of a problem. Though I do agree the asymmetric gestures will probably cause confusion with users, but I still wanted to explore the idea to see if it can lead to something better.

If you're trying to keep a convenient tab-like control without content area swiping, I'd rather see MS add gesture awareness to the navigation bar (i.e., the Back, Windows, and Search button area). webOS had this for page navigation, but a user had to know the gestures to use the device. In what I'm proposing, users who don't know the gesture would simply interact with a multi-tab Windows phone the way that they do with iOS and Android while those of us who do know abut it could swipe from the bottom of the device. (Presumably, swiping would also be allowed in the tab header area and maybe in the app bar if the app has one.)

At one point I also considered to limit switching between pivots to the header area, I even went so far as to consider putting the headers at the bottom of the screen, but ultimately I thought that would look too weird. Making the nav bar gesture aware is an interesting idea, but would that necessitate having on-screen controls, which not all phones have? That aside, I think using gestures in the nav bar could be accident-prone; it's easy to press one of the buttons when you're trying to switch between pages.

 

[Jazmac]

Much respect to the OP. I'm always especially proud that we have people in this ecosystem that put in the extra effort to make this phone work. You guys have the vision and that can't be dismissed.