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.