Tuesday, 9 August 2011

Radial Menus

I love Radial menus. They're a great example of adapting a user interface around the limitations of the joypad.
You've more than likely come across them if you played any of a dozen relatively recent AAA titles, Mass Effect with it's radial pause menu, and of course its famous dialogue menu.

The recent shooter Brink, from developer Splash Damage has a particularly noteworthy implementation:

(Unfortunately I only have the PC version, so I can't speak with complete authority to the console versions, but I would be surprised if they differed significantly.)

If you look at the video of the menu in action you'll notice a few cool things going on.

Firstly, the world is blurred to draw attention to the menu and to minimise distractions (It also looks pretty).

Secondly, when the player highlights an option, the camera turns to focus at the real world location of the objective that option represents. It's a really nice subtle reinforcement of where the player needs to go, and so (hopefully) he or she will be less likely to get lost afterwards.

The icons are also quite clear and simple and easily identifiable and also come with a short text description of what the task entails. Unfortunately the text is sometimes too long to fit and so becomes a small scrolling textbox when highlighted. There is also an additional icon showing the reward for doing this mission.
All this can become too much noise on the screen (you can even see in the video that the bottom right option's description is overlapping the kill event notifications).

I have a few suggestions for how I might go about improving it if given the chance:

Integrate the Yin Yang reward icon and value with the menu option itself rather than have it floating above and separate. There's lots of empty space on each button, it could easily be done.

There's no difference between the icons for "capture the enemy health command post" and "capture the supply command post". Possibly a flag or symbol added to the icon that changes to indicate current ownership might be better than specifying "enemy" in text.
Also, I understand that they are "Command Posts", but surely the name can be shortened to "Health Post" or "Supply Post".

I'd consider moving the text description to inside the circle and only display the description of the currently highlighted option. This would mean that a player couldn't see every choice at a glance, they'd have to go through each option in turn (which would be bad) before deciding, but I think that the icons could be made more descriptive and do a better job than scrolling text boxes.
Of course this is the kind of thing you'd need to experiment with to see if it's actually possible, and no matter how good your icons eventually are at conveying the information required, it would mean a tougher difficulty curve (however slight).
However, I think you could get around that by displaying the text in a similar manner to how it is now for the first X minutes of play (whilst the player learns to associate icons with meaning), and then switch them off.
I'd be curious to know if that would work, or if it'd leave player's feeling like they've suddenly been thrown in the dark.

Friday, 7 January 2011

TV Remotes: Part 1

UI design isn't limited to the digital. Take a look at this poor excuse for button layout for a Hitachi TV.

The first thing you'll notice is the big giant "wheel" in the middle, which is how they've chosen to organise the standard channel up/down and volume +/- buttons. It's not really a wheel so much as it is a large 4 directional rocker.
Generally speaking I think you'll probably find that most TV remotes will have two separate vertical 2 way rocker buttons side by side, somewhere near the middle, for these functions.
  You could think of it as a little attempt at innovation, which is always a good thing, regardless as to how well it accomplishes it's goals, however, in this instance, I don't think it's necessarily done anything to improve upon more common designs.
  I don't think there's anything particular about volume controls that mean it's more intuitive to have it laid out horizontally and channel controls vertically. I actually suspect that since it goes against the grain you'd actually end up changing channels when you mean to up the volume a little bit.

I actually reckon there should be an established standard for this kind of thing. Channel Up/Down on the Left, Volume on the right. In the same way that any computer program should have next on the right and previous on the next (for the most part).

However, that's minor compared to this: The other, smaller wheel at the top, which is used for navigating the on screen display for the TV (switching input sources, changing display settings etc).
  To bring up the menu, you press the big button in the middle marked "M". Each setting screen has a "store" option at the bottom to save the options once you've changed them, so you have to select that and then press "OK" (just to the bottom left of the wheel at the top).
  This is the wrong way around! The OK button should be the the large one in the centre as it should be the most prominent. When you go to store your changed settings, the urge is to press the large button in the middle, but unfortunately it acts as a back button once you're within a menu, removing your changes once pressed.
  Being forced to repeat every menu change twice due to familiarity with the other remotes in your house can be frustrating to no end.

There'll be more TV remote evaluation to come!

Monday, 20 December 2010

Crimes against UI Design: Global Agenda

Sometimes games just don't seem to care when it comes to the UI. Take Global Agenda, for instance, an otherwise pretty decent mmo/rpg/tps/thing.

Lets start with the equipment screen, as it's generally one of the more used menus in the game - along the bottom you have a list of categories and item slots that belong to the currently selected category.

To the right you have a list of available items that can be equipped in the current slot.

For some reason, the developers have decided it's a good idea to only display item stats when the mouse cursor is hovering over the icon of an item. At the very least the tooltip could have been displayed when the cursor was over any part of the item's inventory listing and not just the icon.
But that's tackling the problem from the wrong angle, what would have been a much better solution would have been to display the important stats in the inventory listing, rather than the tooltip, so that you can quickly and easily compare the various items you have at your disposal.
I don't think "Generation 1" is particularly important information to know at-a-glance (and "Assault boosts" is just plain redundant information, since I know that I have selected the "Boost" item slot and that my character is an agent of the Assault class).

You'll notice a little spanner icon beneath some of the item slots, this is how modifications are applied. I had to seek help when I first wanted to install a weapon mod because I couldn't for the life of me figure out how to do it. Surely I should be able to click on a mod in my inventory and select "apply to slot x" from a drop down list or something similar? Nope, I must click this tiny little button, select "modify" (the other option being to repair a damaged item) and then find the item I want from a secondary inventory view.

Buying and selling in the NPC shops doesn't fare any better. Immediately you'll notice that there is a difference in how the items are displayed between your inventory and the shop's.

It's actually quite hard figuring out which items of yours you want to sell, given that you have to hover the cursor over the icons to see what it does. The only information you are given at-a-glance is the colour of the text, which indicates how rare the item is.

There is no value listed with an item in your inventory (even if you hover the cursor over the icon), you have to click the sell button to see how much you'll get for it.

A lot of the items you receive whilst playing the game have no function in and of themselves and are just building blocks for crafting items, unfortunately there's no way of telling if these components are something you want to keep when you're at this screen.
Though having said that I'm not sure if many games provide you that kind of information when you're at a shop about to sell them, so it might be asking a bit much - but it's definitely the kind of feature that should be considered when implementing a crafting system into a game.

The auction house is another example of just how little information the UI gives you.

When you first open it up you are presented with a blank screen. If you attempt to search for something, you are told to first select a category. Of course, that by itself isn't enough: you must select a category and then hit search to actually display anything at all.
Which seems backwards to me, the auction should by default display all things currently for sale (or at least the first page or so). The category listings on the left should then be used to filter the items on auction and then, if you so require it, you can use the search to narrow it down further - with or without a category selected, who's to say you know which category the item you have in mind belongs to?

It's also very unclear as to how bidding actually works - surely the developers have seen ebay? That's a great source of inspiration when looking to develop some kind of in-game auction system!

Like I said at the beginning of this post, the game itself is perfectly fine, it's just got a horrendous menu system that clearly wasn't given the attention it deserved during development.

Thursday, 9 September 2010

Improvements in Chromium Metallurgy

It's been a week or so now since Google released version 6 of Chrome and so I thought it would be a good time to take note of the improvements they've made to the UI.

I actually find it tantamount to genius that they have been able to yet further minimise the already minimal interface further - they have removed the "go" button (which was always pointless - for any browser, as they all seemed to have them at one point or another - once finished typing an address, people press enter, they don't switch to the mouse to press a gui button).
That leaves the stop button, which they have moved to the left of the address bar and integrated with the reload button. This comes as a welcome change to me, as all other browsers that I've known have had the stop button on the left and for some reason I've not been able to adjust to Chome's original placement of the control.

They've also combined the two different drop down menus that used to be to the right of the address bar into a single menu. I always found the separation of the options to be rather arbitrary and always ended searching the wrong menu anyway for the option I wanted, so again, points to the developers for recognising that.

The the bookmark star has moved to the other side of the address bar which I didn't understand at first until I remembered that due to it's previous proximity to the home button I was constantly creating bookmarks to pages I didn't want. I guess they suffered from the same problem.

The other changes are just subtle tweaks to the look and feel that they claim "make it easier on the eyes", but seeing as I don't think it was ever particularly hard on the eyes in the first place, it's a strange way of mentioning that you've updated the look slightly to make it feel fresh and new again (any product or company that has had a life span of longer than a few months is guilty of this - just take a look at this to see what  mean).

So this all goes to show that there is always room for improvement if you know where to look.

Wednesday, 25 August 2010

Social Divergence

Twitter and Facebook are essentially very similar social networks these days. The only real thing separating them  is for which social groups they are used for.

So it is no surprise that their Android applications are close to identical in many respects. The desktop widgets are in fact identical, aside from a few aesthetic differences.

For both, each status update or tweet is sectioned off in it's own individual box. The profile pic for the original poster is in a column on the left with their name to the right along with the body of the post and any additional information, such as time it was posted and number of comments of likes (in the case of Facebook), at the bottom.

Now as you are probably already aware of it's very common for things like pictures, videos and URLs to be the main contents of a post, and it is in how they are treated that these respective apps differ.

Twitter treats it almost like you would expect a web page to work - tapping a person's name takes you to their profile, a URL to the respective web page (or application in the case of things like the Youtube app).

It also has a drop-down menu of sorts on the right that allows you to do standard Twitter actions such as @reply or retweet.

Facebook on the other hand, does something slightly differently. Instead of individual elements the whole box is one area that can be tapped on. A single tap takes you to the status update itself where you can comment on it if you want. A long press pops up a menu with a list of options related to the status update. For instance, any URL included in the message is given it's own selectable item in the menu.

This is much better than twitter's method, as the text is so small, my giant fingers often have difficulty tapping on URLs - especially if they're directly underneath the tweeter's username as that is also a link that takes you to their profile.

Unfortunately Facebook breaks it's own rules as any photos shared with the status update must be tapped directly if you want to look at them, and they're not included in the long press menu. So points will be deducted for breaking consistency here.

I think Facebook definitely have the right approach here - touch screens can't be designed expecting a high fidelity input. Large clickable areas should be the order of the day.

Wednesday, 11 August 2010

GUI Toolkits and the art of Documentation

For an API designed to empower you with the ability to create graphical interfaces for your applications, the documentation for wxWidgets is really lacking when it comes to graphical aids.

For the most part, the reference documentation for wxWidgets is complete, only the newer/lesser used/incomplete features lack documentation. It's also got pretty good descriptions on how you're meant to use certain classes.

However, it seems straightforward to me, that when creating something visual from pre-defined building blocks, it would be helpful to have an example of what those building blocks might look like. For instance, take a look at the following items:

When reading the documentation, it's not hard to figure out what a "notebook" probably is (though of course, until you actually use it, or see it in action it's not for definite). A "toolbook" though? Not sure what that is, apparently it uses a toolbar instead of tabs. How does that work? Thankfully there's a sample in the SDK which demos all of the various "book" widgets. At which point it becomes obvious what a "toolbook" is and you start kicking yourself for not realising from the off. Though you wouldn't have had this confusion in the first place if the documentation had some pictures or diagrams to show you exactly what it is.

Though in that instance we were able to rely on the presence of a sample to inform us that's not necessarily always the case. But in either case, it would be nice not to have to compile some source code in order to know what a certain widget looks like.

It's not as though this problem is limited to wxWidgets either. Here's the official MSDN documentation for a couple of widgets:
They've gone to great lengths to describe how these two similarly named but very different widgets look and operate and yet there is not one image to assist the description. A picture is worth a thousand words became a cliché for good reason, don't forget. Juce also does exactly the same thing. Perhaps it's unfair to judge their documentation when a lot of it is actually generated from the source code - but there's no reason why they couldn't have a separate page with a bunch of reference screenshots (which they could then link to from the main docs).

Is it just me that finds this to be an incredibly obvious oversight?

Thursday, 5 August 2010

CrunchGear: Reports Of The Mouse’s Death Have Been Greatly Exaggerated

An Excellent article on the supposed "End of the mouse": Reports Of The Mouse’s Death Have Been Greatly Exaggerated - an article with which I share quite a few of the sentiments.