Recently I’ve tested among other cases user's interaction with simple context menu “at place" and side menu on the right/bottom sides of large sensor screens (17 – 22”) — so it showed, that classic context menu appearing near touch zone is much more appreciated.
The reason was that classic context menu is classic (pardon the pan), so the users — in my case rather conservative — were expecting it to appear near touch area — making it almost direct manipulation.
Because the area of the screen is large, and the users tend to seat closer to it (‘cause they operate with it by hands), the view angle is larger than in typical keyboard-mouse interfaces, so sometimes they even didn’t notice, that something new appeared somewhere at the edge of the screen (especially for long and narrow menus at the bottom). It was also inconvenient to physically make big movements of hand through the screen to touch the context menu items at the edge.
Another reason to use classic context menu in my case was the possibility to add more items in future, and bottom menu had real limits to group and contain more than 7-10 items — even if it was possible to add more, grouping of items through delimiters or color coding was not as obvious as in the case of casual context menu rulers. That was also the reason, why radial menu was not considered. We also noticed in earlier projects, that radial menu users sometimes recognize as some kind of navigation controls, not as context to current element (and it didn’t contain any plus/minus/arrow icons!) — maybe because of similarity with Google Maps and local geoservices controls, that users were familiar with. So, the affordance of radial menu with icons was extremely low.
