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.

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:

• wxNotebook
• wxToolbook
• wxTreebook

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:

• CListBox
• CListCtrl

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?

Jucey

I discovered Juce via the rather handy list on Wikipedia. It's actually really easy to get started with and provides lots of documentation for the burgeoning front end developer. And like any decent GUI toolkit it's cross compatible on Windows, Linux and Mac (and even iPhone).

And that's why I'm talking about it today. Where most GUI toolkits seek to wrap the native functionality of the platform or at least emulate it in some way, Juce has it's own look and feel (which is actually quite similar to OS X) which it maintains across all platforms.

This has the end result that (for the most part at least) an application developed with Juce will look the same no matter if it was run on Windows or Linux or OS X. This also means it won't blend in with your standard window decorations.

I'm in 2 minds about whether this is a good idea or not. On the one hand, variety is what keeps things new and interesting, and if you can pull it off well, like Google Chrome or Steam, you can get away with it. There's also the idea that if you have to use the program in an unfamiliar OS you won't succumb to culture shock doing so.

But on the other hand, consistency (across your platform of choice) with window decorations makes new programs easier to figure out and understand, and can also make them feel a lot more polished and professional. I've downloaded many applications from Sourceforge that are perfectly good at what they do, but because they've used a GUI toolkit that draws the widgets differently from the native application, it can stick out like a sore thumb. Take BoncEnc - it's a fantastic program that I use to rip my CDs for playing on my MP3 player, but it doesn't invoke confidence to look at. The strangely thin menu buttons (and drop down items), and the title bar with it's minutiae minimise/maximise/close buttons - it just feels so out of date.

Another thing that Juce does is adopt the OS X traffic light system for the close/minimise/maximise buttons. Unfortunately (in Windows at least, and probably Linux too) to stay consistent with the standard order of these buttons the colour order is amber->green->red. Also, in my personal opinion, I don't really consider "maximise window" to be the opposite of "close window". For me, it would be "Run", but that's not really applicable in this context. In the standard Windows XP theme, the close button is indeed red, but the other two are just blue, the same as the rest of the window decorations.

Customising the Visual studio debugger

If you delve deep into the bowels of your install of visual studio you might come across autoexp.dat. "What does this file do?" you might ask. Well, you're in luck.

The default behaviour of the windows that display the contents of your variables (autos/locals/watch) in visual studio is, if it's a basic type, such as an int or a float, to display it as is.
If it's a struct or a class, then allow the user to navigate it's structure revealing all variables contained within.

The autoexp.dat file allows for the customisation of this process (and if you look in the file you'll notice Microsoft has already pre-populated it with lots of entries, predominantly for things in the c++ standard library).

Why would you want to customise something if the default behaviour is perfectly acceptable?
Well, here's an example. Say you've got a 3D Maths Vector class which contains 3 floats: X, Y and Z. It's also got all the usual functions you need for doing all the various things you might with a vector, such as dot and cross products etc.
You might then think of a great idea to include some common vectors as static const members to the class. These could include a definition for "UP" where you have Y=1, or another could simply be "ZERO" for when you want a comparison but don't want the overhead [or hassle] of creating a new instance.

It's a good plan, but has the unfortunate side effect of bloating the debugger display to showing you all of your constants every time you expand a vector variable.

In steps autoexp.dat, and here's a simple example of how to write a definition:

;-----------------------------------------------------------
; Vector3d
;-----------------------------------------------------------
Vector3d{
  preview
  (
    #(
      "[",
      $e.x,
      ",",
      $e.y,
      ",",
      $e.z,
      "]"
    )
  )
  children
  (  
    #(
      X                 : $e.x,
      Y                 : $e.y,
      Z                 : $e.z,
      [actual members]  : [$e,!]
    )
  )
}

First things first, any line that begins with a ";" is treated as a comment and ignored.

Next you have the name of the type you wish to define. In this case it's my 3d vector class. This also supports templates, so "SomeType<*>" is perfectly acceptable, as is template specialisation, e.g. "SomeType".

You'll notice the opening brace "{" is immediately after the type rather than on it's own line. This is because the parser is very unstable and prone to breaking easily. If there is any space between the type and the brace, it just doesn't work.

Next you have your categories. In the example I've given there's "preview" and "children", but there's also "stringview" available, should you require it.

Preview defines what is displayed in the value box for the main type. In this case it will be "[X,Y,Z]" where X, Y and Z are floating point numbers. $e means display in scientific notation should the number be large or small enough to warrant. If you take a look at the top of the autoexp.dat file, you will notice that you have a choice of several different types. $f for instance should allow you to display the number as a standard floating point and never factorise into scientific notation, though, again for me at least, the parser preferred to crash rather than work with anything other than $e.

The "#()" notation simply means here is a comma delimited list of values.

The Children section defines what should be displayed when the user expands the variable. As you can see I include the three members of the vector and an escape clause, if for some reason I need to see the original default formatting of the variable.

I learned everything myself from this wonderful post over at virtualdub.org.

wxAUI

These guys know what I'm talking about when I mention tearaway windows and customisable easy to use interfaces. Take a look at the example video found here: http://www.kirix.com/labs/wxaui/screenshots.html

Playing around with it briefly using wxPython was reasonably painless and showed how easy it was to accomplish something like this relatively quickly. Unfortunately it also showed up some instabilities in the latest build.

I'm going to have a play around with wxWidgets in C++, see if it has the same issues I experienced with the python wrapper. If that doesn't work I guess I'll start looking at other widget systems.

X-Com: Apocalypse

This is one of my favourite games. It's also quite an old one, being released in the early years of Windows 95 but actually designed for DOS, meaning there are a few standard UI conventions we take for granted on modern systems that aren't present.

The screen shots you see are of the game running though DOSBox 0.72 which itself has been loaded through Steam. As such there are a few graphical artefacts in the game that I cannot contest to being caused by the game it self or the emulation.

By way of a quick gameplay summary, X Com: Apocalypse is a strategy game where you have to save a city from an alien menace. There are two main modes of play in the game, the first is the city scape view, where you manage your agents, research new equipment, buy stuff and fight any invading UFOs. Should the UFOs make it past your defences you'll have to send your agents in to clean up the place - which is where the second game mode occurs. This second game mode is the tactical view, which shows your agents on the ground along with all the bad guys.

First up, it's the loading screen which you can see on the left here. My save game naming scheme aside, you'll notice each save game is automatically given the in-game date and time (which is why it's 74 odd years in the future) so you know which save game was the last. Unfortunately, there is an issue with the game which can cause this to be a bit unclear. When you send agents in to a location and it switches from city to tactical view, the tactical view has the exact same time as when you left the city view. Which makes sense, as that's when the agents got there.
Now, you can spend ages in tactical mode, but due to the nature of the game and the time controls generally only 5-10 minutes (on average) will have elapsed of in game time for any given mission. Unfortunately, when you return to the cityscape, the time has reset back to the time you entered the tactical mode. The mission is still complete, but the agents are returning to base technically before they've even done anything.
My immediate reaction after completing a mission is to save a game. But if you've also saved the game during the tactical mission, you'll be in a position where your most recent save is dated prior to earlier ones.

There are two issues with this. Obviously the game is doing the correct thing in returning to the time at which the mission started, but:

• The agents should remain in the building and "out of play" until the same amount of time passes in the cityscape as did in the mission. This isn't strictly a UI issue but it's related and I felt it worth mentioning.
• The save games need to be given the real world date and time, either in-addition to, or instead of the in-game time. I think this should be a standard feature of any game that offers you multiple save slots. In fact, a lot of games nowadays are keeping count of your total play time, which would be a suitable alternative to displaying date and time (see Mass Effect).

Next we have the Cityscape. The lower half of the screen is occupied by what you see in the screenshot here. Time controls on the right, various info screen buttons on the left and a whole bunch of tabs for the different aspects of x-com management that can crop up whilst defending the city from an evil menace.

For the most part the interface is perfectly serviceable, and considering you can take your time whilst the game is paused mean's it's fine. But that doesn't mean it's great.

There's a lot going on when you first look at the controls. The bar in the centre lists all the vehicles, agents, researchers, corporations, ufos et al depending on the highlighted tab and when you have a lot (as seen in the screenshot) it can get a bit unwieldy. If you take training agents - newly hired ones have no training option specified, and to do so, you must select them from the long horizontal bar and then press one of the two training buttons on the bottom right. However, if you can't remember what your new trainee looks like after you've hired him (or her), you have to click on each face in turn until you find one without any training option specified. Later on in the game this isn't too big a problem as agent ranks are displayed and so the rookies are easily separated from the crowd.

There's no reason why you couldn't put the training options in another menu, either with the equip screen or on it's own. Trying to bribe/influence other corporations is also similarly clunky.

Moving on, there is a rather large oversight on the part of the developers. One big thing about the game is how quickly you respond to invasions. Basically, the longer you leave it after the aliens have beamed down into a building, the harder it'll be for you to clean house. When the klaxon's sound you're presented with a screen not dissimilar to this one. Where you're expected to pick which agents you want to go and deal with the infestation.

One of the things you can do to improve matters later in the game is purchase multiple bases throughout the city and spread your agents out throughout them so you can send the closest to deal with the threats as they happen. Problem is, there's no map on display telling you where it's happening. There's just the name of the warehouse it's happening at, which could be anywhere as sometimes there are two or three identical warehouses dotted amongst the city.

You can of course choose to not send anyone, quit out of the menu to see where it is, and then manually send the agents in. But then, what's the point in the menu in the first place?

Other problems with the menu include:

• You'll notice there are two columns there, one for agents in your numerous bases, and one for those assigned to vehicles. But there's only one scrollbar (and this being the days of DOS, your mouse wheel does nothing). This scrollbar scrolls both columns at the same time, so if you want an agent from the bottom of column A to be assigned to a vehicle at the top of column B it can be a bit of a pain as you have to drag and drop them. Thankfully all highlighted agents move as one, so it's only an issue if you're wanting to move one agent by themselves.
• Vehicles have a maximum occupancy. If you drag more agents to a vehicle than can physically fit, those left over won't be assigned and stay in the base (but still selected). If you're not careful, you can end up sending people to the target building on foot, which can take a very long time.

There are a bunch of other niggles as well. Scrollbars don't scroll in terms of items, but in pixels, so you can end up with one half of an item showing at the bottom  and top of a menu.

When dragging items in the equip agent screen the items snap to grid, not to locations. If you see the thing being dragged in the screen shot, you can place that anywhere on the empty hand slot and it'll snap in place, but whilst it's being dragged, it treats it like a grid (like the backpack area it's hovering over).

What it should do is snap to the centre of the hand area reaffirming to the player that it will go there when the mouse button is released.

When you are in tactical view, if you wish to change what a character is holding (be it a grenade, or medikit) you have to open the equip agent screen, drag the items around and exit back to tactical view. Then, once you've thrown the grenade or healed your agent's wound, you have to go back into the equip menu to restore whatever it was they were holding before.

Now what you really want is some kind of pre-configured layouts that you can switch between with the click of a button. I'm constantly throwing grenades in this game, and it's a very tedious and clumsy method for doing so.

It does do nice things however - if you look to the left, you can see the agent's skills. The bits at the end of the bar indicate how much they have improved since they were first hired.

Speed is partially empty, turning into an outline at the end, this represents encumbrance, due to the agent's relatively low strength.

I fear I have rambled on far too much. So I shall leave you with this for now. But I shall return tomorrow with more UI annoyances!