Are WinRT apps 'tablet apps'?

[phailyoor]

Hence why I stated earlier that there is nothing that prevents the developer from creating a standard right-click context menu. It is the developers choice to either implement or not implement the menu function.

It's not a failure in the OS since it can be done. It's up to each dev to decide if they want to implement it or not.

A developer can implement it with a maximum of 6 items. It's also unnecessarily difficult and heavily discouraged.

As in-right click is supposed to open the app bar. If the dev can't figure out how to make that work with touch, then an actual context menu is allowed, but it's a really bad idea and makes the Microsoft Metro gods sad.

Right click done the Metro way....

[Calum Veteran]

A developer can implement it with a maximum of 6 items. It's also unnecessarily difficult and heavily discouraged.

As in-right click is supposed to open the app bar. If the dev can't figure out how to make that work with touch, then an actual context menu is allowed, but it's a really bad idea and makes the Microsoft Metro gods sad.

Perhaps some developers should think of more useful ways to present the options on the UI then? I'm a developer, and I cannot think of any scenario in which I'd add a context menu that holds more than 6 items, if I wanted to create a decent app. In my opinion, the new "Metro" apps are going in the right direction, by moving away from concepts such as the context menu and the menu bar. However, even though I feel the platform is moving away from context menus, our points still stand that developers can implement them if they'd like. I don't believe a maximum of 6 items is too limiting, nor do I believe the lack of support for submenus is a problem, as I dislike the UI element; I don't believe it's as efficient as what else is available.

Do you have a scenario in which you wanted to include more than 6 items in a context menu, when developing an app? If so, I'd like to hear it.

I'm not saying you're wrong. Perhaps the context menu concept is more superior than other methods of displaying options (e.g. placing certain options on the app bar). But I currently don't think it is, so this is just my view :)

[redfish]

A developer can implement it with a maximum of 6 items. It's also unnecessarily difficult and heavily discouraged.

As in-right click is supposed to open the app bar. If the dev can't figure out how to make that work with touch, then an actual context menu is allowed, but it's a really bad idea and makes the Microsoft Metro gods sad.

I think Microsoft would discourage it not only because of touch because they don't want Metro to be 'power-user' oriented, they want it to be primarily for friendly, consumer-oriented apps. Overloading and overusing context menus is one thing that intimidates casual users.

[phailyoor]

Perhaps some developers should think of more useful ways to present the options on the UI then? I'm a developer, and I cannot think of any scenario in which I'd add a context menu that holds more than 6 items, if I wanted to create a decent app. In my opinion, the new "Metro" apps are going in the right direction, by moving away from concepts such as the context menu and menu bars. However, even though I feel the platform is moving away from context menus, our points still stand that developers can implement them if they'd like. I don't believe a maximum of 6 items is too limiting.

Do you have a scenario in which you wanted to include more than 6 items in a context menu, when developing an app? If so, I'd like to hear it.

Try opening the desktop and right clicking on something. For just a random file in explorer, I regularly use 8 of the context menu options. In word, I use about that many. In firefox, I use most of the options. I can spend all day naming desktop apps with more than 6 context menu options. For most of them, putting the options somewhere else in the UI would be slower for the end user.

[Shane Nokes]

A developer can implement it with a maximum of 6 items. It's also unnecessarily difficult and heavily discouraged.

As in-right click is supposed to open the app bar. If the dev can't figure out how to make that work with touch, then an actual context menu is allowed, but it's a really bad idea and makes the Microsoft Metro gods sad.

Right click done the Metro way....

Mind posting up that bit of official guidance since you are posting it as such? ;)

Try opening the desktop and right clicking on something. For just a random file in explorer, I regularly use 8 of the context menu options. In word, I use about that many. In firefox, I use most of the options. I can spend all day naming desktop apps with more than 6 context menu options. For most of them, putting the options somewhere else in the UI would be slower for the end user.

Which 8 items do you regularly use in every possible combination of usage?

I ask because the original point of the 'context' menu was to provide only contextual options.

So if you've highlighted some text, what 8 options would you use on that highlighted text in IE desktop?

[phailyoor]

Which 8 items do you regularly use in every possible combination of usage?

I quoted 8 for the number of options I use in explorer:

7-zip(with multiple sub options)

edit with notepad ++

send to(again, sub options)

cut

copy

paste

rename

properties

See this doc:

http://msdn.microsoft.com/en-us/library/windows/apps/hh465308.aspx

Pay attention to this part:

Don't add a command to the context menu when direct manipulation or selection is possible

That means that if the item is selectable by touch(besides text) then the app bar must be used.

[Shane Nokes]

I quoted 8 for the number of options I use in explorer:

7-zip(with multiple sub options)

edit with notepad ++

send to(again, sub options)

cut

copy

paste

rename

properties

Properties isn't needed if highlighting text for text editing operation...so that's one off the list.

7-zip isn't needed if handling text editing operations.

Rename isn't needed if handling text editing operations.

So that would be 5.

If handling selection of a folder then having edit with notepad ++ wouldn't be necessary. So that would be 7.

Now 2 of those options are add-in options from other programs...also you are using these in desktop mode....not metro.

Can you tell me in Metro any items beyond 6 would be needed in apps...don't try to mix the environments to make your point.

[phailyoor]

Properties isn't needed if highlighting text for text editing operation...so that's one off the list.

7-zip isn't needed if handling text editing operations.

Rename isn't needed if handling text editing operations.

So that would be 5.

If handling selection of a folder then having edit with notepad ++ wouldn't be necessary. So that would be 7.

Now 2 of those options are add-in options from other programs...also you are using these in desktop mode....not metro.

As I said, my quoted value of 8 was for the file explorer. I'll give you eight in another app if you really insist. In fact, I don't need 8 options in IE, but I need them in a lot of other things.

Can you tell me in Metro any items beyond 6 would be needed in apps...don't try to mix the environments to make your point.

Considering that only extremely basic metro apps exist, no, I can't. I think desktop gives a few scenarios where so many options would be useful though. Maybe when some more metro apps start cropping up that limit will get a bit tigher.

[phailyoor]

Seriously, though. This doesn't matter.

The fact is, MS is pushing for the app bar(at the bottom of the screen) to be used when the situation clearly calls for a context menu. Try right clicking something in the start screen. A context menu SHOULD pop up, but instead, the app bar comes up. That is a fact.

[Shane Nokes]

Seriously, though. This doesn't matter.

The fact is, MS is pushing for the app bar(at the bottom of the screen) to be used when the situation clearly calls for a context menu. Try right clicking something in the start screen. A context menu SHOULD pop up, but instead, the app bar comes up. That is a fact.

You're still missing the point that I was making earlier.

A context menu should be contextual. Why show options that do not apply in situations?

That's the point some of us are making. Metro only shows what makes sense to show at the time. It's up to the developer to decide how they want to implement the menus, However, the guideline is that only valid contextual options be shown.

[phailyoor]

You're still missing the point that I was making earlier.

A context menu should be contextual. Why show options that do not apply in situations?

That's the point some of us are making. Metro only shows what makes sense to show at the time. It's up to the developer to decide how they want to implement the menus, However, the guideline is that only valid contextual options be shown.

The guideline is that a context menu should not be shown when using the app-bar is possible. This has nothing to do with the actual nature of the commands themselves.

[Shane Nokes]

The guideline is that a context menu should not be shown when using the app-bar is possible. This has nothing to do with the actual nature of the commands themselves.

...or when it doesn't make sense.

That's why it's there in IE, and why it's there in Mail. There are cases where using the context bar does make sense. MS has shown this with their own apps.

The point is why should commands be shown at a time when it doesn't make sense? I shouldn't show text editing options if I'm on a picture, and I shouldn't show save picture if I'm working with text.

That's why it's ok to have shorter menus. The options can all be there, but only so many are shown at a time because they are the only options that are contextual to the activity being performed.

[phailyoor]

...or when it doesn't make sense.

That's why it's there in IE, and why it's there in Mail. There are cases where using the context bar does make sense. MS has shown this with their own apps.

The point is why should commands be shown at a time when it doesn't make sense? I shouldn't show text editing options if I'm on a picture, and I shouldn't show save picture if I'm working with text.

That's why it's ok to have shorter menus. The options can all be there, but only so many are shown at a time because they are the only options that are contextual to the activity being performed.

Does the app bar make sense in the start screen? Not with a mouse.

Does the app bar make sense in mail? Not with a mouse.

Does the app bar make sense in skydrive? Not with a mouse.

[Shane Nokes]

Does the app bar make sense in the start screen? Not with a mouse.

Does the app bar make sense in mail? Not with a mouse.

Does the app bar make sense in skydrive? Not with a mouse.

1 & 3. Sure, for the way I use them it makes sense to me.

2. Mail has a regular context menu built-in and we've already discussed this. It comes up if you have text selected.

So for the times it makes sense to have an older style context menu it comes up, and for the times to makes sense to have an app bar that has a ton of functionality (more than the old context menu had) that comes up.

I think if you're arguing that point then you're not quite clear on what the Metro guidelines are addressing. :)

[redfish]

Does the app bar make sense in the start screen? Not with a mouse.

Does the app bar make sense in mail? Not with a mouse.

Does the app bar make sense in skydrive? Not with a mouse.

I'm not sure what any of this has to do with the input-method.

Metro is designed to focus on content, which is why all the commands aren't immediately visible, and consumer-friendly, which is why it doesn't rely on heavily populated context menus. Touch will be a promoted use for the content-centered, consumer-friendly apps, but its not entirely the point.

I do expect for most regular mouse-and-keyboard users, Desktop apps will remain popular for a long time, just because mouse-and-keyboard users will tend to be power users -- people who are doing more advanced tasks. To repeat, not because Metro apps are less usable with that input, but they just aren't designed for power users. But in my previous post http://www.neowin.ne...#entry595145147 I outlined a couple of usage scenarios for Metro apps on mouse-and-keyboard computers that I think will be pretty common regardless.

[phailyoor]

I'm not sure what any of this has to do with the input-method.

Because the app bar is being used when a context menu should be. When you right click something and want to, say, unpin it, that's a context sensitive action. It should pop up near my mouse cursor, so I don't have to move it all the way to the bottom of my gigantic 30'' display. Sure, the app bar works fine in touch, but it's a real WTF moment when the context commands pop up on the other side of the screen.

To be clear, in the scenarios I listed, a context menu is the appropriate UI control for a mouse user. Instead, the app bar is used.

[redfish]

Because the app bar is being used when a context menu should be. When you right click something and want to, say, unpin it, that's a context sensitive action. It should pop up near my mouse cursor, so I don't have to move it all the way to the bottom of my gigantic 30'' display. Sure, the app bar works fine in touch, but it's a real WTF moment when the context commands pop up on the other side of the screen.

It doesn't need to work that way just because its one way that makes sense. Remember that you can select multiple items by right click, so you wouldn't necessarily want the context menu to pop up anyway, because it would get in the way.

[thenetavenger]

No, WinRT are not 'tablet apps'

There should NOT even be a poll about it, as you can't vote on whether a fact is true or not. If it is not true, it is no longer a fact.

WinRT is a development framework. This is not up for debate, and has NOTHING to do with what form factor or device the framework is running.

This is not the most accurate article, but at least it dispels the insanity of 'Tablet Apps'.

http://en.wikipedia.org/wiki/WinRT

Technically WinRT was originally Windows Runtime, but is now a generic reference for any new UI App, which includes XAML/HTML Apps and Windows Library for Javascript Apps.

For example with WinRT, you can write an completely functional App in XAML with no coding. (Just like WP7) You can also write a complete App in HTML/HTML5 that has no actual code, just CSS and events, etc.

The only 'relation' to WinRT Apps to a Tablet is that to obtain Microsoft Store approval, they must be usable on a Tablet in addition to a Desktop. They don't have to be Tablet friendly even, just 'usable' with the common access to Tablet controls.

So you can create a WinRT app that has tiny buttons that are hard to 'touch' and it would still be a WinRT App and still could be certified by Microsoft.

I am appalled that people are still STUCK ON THE IGNORANT mindset that ModernUI Apps are for Tablets and only work well on Tablets.

To be accurate, they work best with a keyboard first and foremost, then a mouse, then a tablet. (With gaming Apps being the exception to this order of usability, as Cut the Rope isn't keyboard friendly, but mouse friendly.)

With the New UI, the keyboard is a fast way to navigate the start screen and 99% of the Apps out there. All you need is the WinKey, Tab, Enter, and Arrow Keys to operate very visual Modern UI Apps.

This is also the irony, as Microsoft has brought keyboard control to overly graphical applications that a keyboard never worked well with before in traditional desktop Applications.

Tablets are irrelevant, touch screen is irrelevant (but nice), even a Stylus is irrelevant (again nice).

My main systems are Keyboard Mouse, and I am just as productive on them than the touch and Tablet systems I use. (And the majority of Apps I've been using are WinRT aka Metro/Modern/New UI based.

Touch is great and handy, but it isn't enough of a 'difference' nor it is harder for a keyboard and mouse that I have replaced my systems or monitors with touch devices. It is nice, but not important or necessary.

So get over two things...

1) Metro/Modern/New UI is not for Tablet or Touch Screen only, and work just as elegantly with a keyboard and mouse.

2) WinRT is a framework for Apps and has nothing to do with 'Tablets' other than having API support and consistent functionality for Touch/Pen devices.

So why the 'touch' direction for Windows 8?

Well, the reason Microsoft makes 'Tablet' support built into WinRT Apps and requires support to work on a Tablet is from the failings of Vista and Win7. Vista was fully touch/pen enabled, but nobody used the APIs or produced but a few Applications that used the technology.

Windows 7 added in an extensive new layer of touch and pen input driver and API support, like the ability to handle 50 points with size, angle, tilt, pressure, image, etc associated to every one of these points. Windows 7 also had a revamp of the Ink/Touch/Pen API technologies for traditional Win32 and .NET/WPF, and again, very few developers enabled them, even though it was just 'including' the library, and letting it inherit to the controls in the App. There were a few Applications created with 'touch' or 'pen' but they didn't much traction or support outside of their niche.

So Windows 7 was the most advanced 'touch' and 'pen' based OS in existence, and yet Microsoft could not get developers to use or incorporate the touch features. This is why the iPad and other technologies got traction, even though they have less 'touch' features than Windows 7. (The iPad can handle handwriting, or properly handle 50 touch points or get a shape or size of the area touched, and Windows 7 can, which is also used with the PixelSense, imaging touch technologies.)

So to ensure 'tablets' 'touch' 'pen' users are NOT left behind and to ensure Apps are made that 'consider' touch/pen input, Microsoft had made touch a required feature for Metro/Modern/New UI Apps, and the way the new framework, that has been generically adopted to be called WinRT, incorporates touch and pen support through the orient oriented nature of the framework. Meaning that developer don't have to think about 'touch' most of the time, it is just inherited and also returns inheritance of the functionality back to the framework.

So, No... And it is a fact that is not an opinion to be voted on...

Okay?

[phailyoor]

It doesn't need to work that way just because its one way that makes sense. Remember that you can select multiple items by right click, so you wouldn't necessarily want the context menu to pop up anyway, because it would get in the way.

It doesn't make sense because it's worse than a context menu(for mouse users). Yes, it does work despite it being worse. Also, the multi-right-click select is a lame excuse, considering that the only option you can do on a group of tiles is unpin. Also, we've been able to select multiple items with a mouse and KB fine in desktop, and still be able to context menu them afterwards.

No, WinRT are not 'tablet apps'

There should NOT even be a poll about it, as you can't vote on whether a fact is true or not. If it is not true, it is no longer a fact.

WinRT is a development framework.

[snip]

WinRT is a development framework that only works on a tablet OS, has limitations in creating good mouse/KB UI, instructions to design a UI for touch, and a store that will reject apps that aren't good with touch.

[redfish]

It doesn't make sense because it's worse than a context menu(for mouse users). Yes, it does work despite it being worse. Also, the multi-right-click select is a lame excuse, considering that the only option you can do on a group of tiles is unpin. Also, we've been able to select multiple items with a mouse and KB fine in desktop, and still be able to context menu them afterwards.

Yea, and remember in Windows 98, Microsoft played around with the idea of having a single-click open icons rather than a double click? I simply would argue again I think Metro is designed for non-power users, and the mechanics of Metro apps are designed to be simpler to understand for non-power users. Touch use is incidental to that.

WinRT is a development framework. This is not up for debate, and has NOTHING to do with what form factor or device the framework is running.

Actually I think this is even more important than it seems, since I expect the WinRT API to eventually be ported for use in Desktop apps, as I don't see Microsoft deprecating the Desktop anytime soon. WinRT will be a natural successor to the WPF/.NET libraries.

[phailyoor]

Yea, and remember in Windows 98, Microsoft played around with the idea of having a single-click open icons rather than a double click? I simply would argue again I think Metro is designed for non-power users, and the mechanics of Metro apps are designed to be simpler to understand for non-power users. Touch use is incidental to that.

I guess touch UI design does happen to be similar to dumbed down UI design. Should I start a thread "are WinRT apps 'stupid user apps'"

Actually I think this is even more important than it seems, since I expect the WinRT API to eventually be ported for use in Desktop apps, as I don't see Microsoft deprecating the Desktop anytime soon. WinRT will be a natural successor to the WPF/.NET libraries.

I'd welcome RT on desktop. It does have a lot of nice functions that would make desktop dev easier.

[redfish]

I guess touch UI design does happen to be similar to dumbed down UI design. Should I start a thread "are WinRT apps 'stupid user apps'"

I wouldn't say "stupid user" :) But have you wondered why Microsoft put the ribbon on Explorer, links to advanced management features (Disk Management, Event Viewer, etc..) on the Start context menu, and put back the "up one folder" button? I think they decided at one point in development that its okay to make Desktop apps more complicated, because its for power users. Everyone else will use Metro.