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.

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.

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?

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.

Relatively directional

Take a look at the video of Dragon Age on the left. More specifically take a look at the Mini-map in the top right hand corner when the camera pans around a character (this happens most after the 45 second mark).

You'll notice that the highlighted field of view changes to reflect where the camera is pointing, but the map itself stays fixed with up as north.

Now take a look at this video of Grand Theft Auto 4 on the right. You'll notice there is no marker indicating where the camera is currently facing, but instead the map itself rotates so that up is forward.

This difference in UI functionality is probably more down to the fact that Dragon Age was developed primarily as a PC game (as opposed to say, Mass Effect) and as such has quite a few similarities with the real time strategy genre (you'll notice in the video above - if you watch it all the way through - that the player pauses to order his troops around the battlefield).

Usually in an RTS game, the mini-map will display up as north, and overlay a marker with the camera's orientation and position.

In the version of the game for 360, the game has been retrofitted to work on a control pad, and for the most part it works fine, but this change means it's closer again to Mass Effect than your typical RTS, played predominately from the 3rd person perspective of your character.
What this means for the mini-map at least is that you'll look on the map for the exit to the room you're currently occupying, see that it is on your left and then get momentarily stumped by the lack of door in the west wall. You then of course realise that it wasn't left but east.

You'll notice for instance, that any good SatNav will display driving instructions in a manner relative to the driver - before Google Navigation, I was stuck with Google Maps, which is a great program, but as the name would imply it is as useful as giving a driver an A-Z with a route drawn out on it's pages. Driving south for instance means that a turn to the west is actually to the right, which is (generally speaking) the opposite of what you expect, convention placing the west to the left.

So, in summary, relativity is king.

Zoom and the RTS

Source: Wikipedia

With everyone talking about Starcraft 2, I thought I'd take the opportunity to mention a feature I've only seen a very small number of real time strategy games: Zoom.

I'm talking about the kind of zoom that allows you to start in the thick of the action, camera on the ground, and with a scroll of the mouse wheel you're transported up an away until you can see the entire map at once.

Then, with a second spin of the mouse wheel, you're sent to a different part of the battlefield, giving orders to your support troops or a secondary base.

In fact, this method of navigating the map becomes second nature incredibly quickly, that the more traditional methods of moving the camera about the place (scrolling when the cursor reaches the edge of the map, arrow keys, bookmark hotkeys) are quickly forgotten.

Yet, despite this, most RTS games still conform to the old methods, a mini-map in the corner, a camera that's relatively fixed in position, the only zoom available being one that lowers the camera slightly and alters the angle.
Supreme commander, in an act of brazen showing off, allows you to turn on a mini-map (which is disabled by default) which is actually a second view port identical to the main one you play the game through, so if you want you can even zoom in to ground level with the mini-map. Of course, this kind of functionality isn't without performance costs, which is why it's disabled by default. A mini-map is also relatively superfluous when you're used to zooming out to see what's going on at a global scale.

I sincerely hope that this becomes a standard "can not do without" feature for RTS games, as I find trying to do without in a game of Company of Heroes (which is a very good game) exacerbating at times - so cut off, do I feel, from the big picture, without my zoom.

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.