The views and opinions expressed within are not those of National Museums Scotland. This site is in no way affiliated with National Museums Scotland or the website www.nms.ac.uk

First of all, the disclaimer: I am not a designer. If I were to make claim to being anything creative it's an illustrator but there's a huge difference between the two (I've always said that an illustrator makes the thing to go on the t-shirt, the designer says where on the t-shirt it goes). Despite the recent trend for everyone to call themselves web designers, I'm still going to go by web developer. I make things.

Bearing that in mind, there are still quite a few web design and UX tips and techniques I've picked up along the way which can be applied to most sites and not interfere with the mysterious ways of designers.

Recently, I've been reworking templates for National Museums Scotland for faster load times and better SEO and I'll illustrate what I'm talking about with a couple of examples from there. The brief on these templates is that the content can't really change and there are some chunks that the CMS generates which can't be changed. Note: the NMS templates are completely finished yet and those that are haven't been rolled out across the whole site but sticking with that whole release early, release often way of doing things, these little incremental improvements can be applied without affecting too much else.

For reference, here are before and after screen grabs of two of the templates.

• 
• 
• 
• 

Some people will find these tips blatantly obvious but the fact that pages still get made without considering these means they do need reiterating.

Link the Logo

The web's been around for a few years now and there are a few conventions users have gotten used to. One of them is that the logo is a link that takes you back to the home page. It doesn't harm anything to have a link there so even if 99% of visitors don't use it, why annoy the 1% who do?

Don't link to the search

From the moment the visitor decides they want to search your site for something, the most important thing is to get the results in front of them as quickly as possible. It therefore makes for a better experience if you bring the results one step closer to them. Rather than requiring the user to click on a link to get to the search form to do their search to get the results, put the search box on every page. They fill it in and go to the results page. If the user wants to take advantage of any advanced search features you may have, they can modify their search from the results page.

Line up

• 
• 

I'm sure there's more to design than this but there are a couple of well tested rules I recommend any non-designer to learn:

1. If it doesn't line up, make it line up.
2. If it's already lined up, make it not.

That and a subscription to iStock and you're done...

Make the hit area as big as possible

• 
• 

From the gateway page for Our Museums, there are two ways the user could go. They were either looking for opening times (in which case, they're done), or they want to find out more information about the individual museums on their own pages. To that end, it makes sense to make the next step as easy as possible and bascially turn the content this page into six huge buttons. To keep everything semantic, JavaScript has been used here to extract the destinations from each of the links and apply them to the whole panel area (it'll default to linked text and image with JavaScript disabled). As you can see, doing this changes the hit area for each museum from a line of text to a veritable barn door.

White text on a white background is not good

• 
• 

Actually, I'm not sure whether it's the fact that the link wasn't as readable as it could have been or the fact that to go home requires poking her in the eye that upset me most. Either way, if you do need to use an image that has a light bit underneath some light text and you can't shuffle it along like here, a quick wipe with the burn tool in Photoshop works wonders.

Underline links

I'm not going to get into the debate over whether or not designers hate underlines but for a high-traffic, public sector with an extremely varied demographic, I'd recommend using them. As Paul Boag mentions, what you do with your design and your solutions for various usability issues depends on the audience. A graphic designer's portfolio might very well eschew underlines when denoting links, a government site probably shouldn't. Especially when you remember that you should never rely on colour alone to convey information, including whether not a piece of text is a link.

Titles are titles of something

• 
• 

If you have a title, it generally refers to the thing below it, not the thing above it. Make sure you keep titles and the things they are titles of together.

Avoid disparate navigation

• 
• 

Again, another of the rules of web that has evolved over the last several years: Sections go along the top, navigation down the side. To keep consistent with the rest of the site the horizontal museum links were brought down and integrated with the rest of the navigation. This maybe isn't the most illustrative example but, basically, don't have a top nav, left nav, right nav and several others when you could have just one.

Only a fraction

There we are, a few handy little tips for your next build project. This hasn't gone into any issues of column width, line-height - or leading (pronounced /ˈlɛdɪŋ/) as designers call it, hover states or any of the myriad other things it could, just a few of the more important and easy-to-do ones.

Wherein our intrepid hero learns some Objective-C and figures out the easy bits are actually quite hard.

A couple of days ago, I decided to give myself a little software development task to write a Twitter Growl view. Growl is a centralised notification system for Mac OS X that lots of other applications can use so that there's one consistent way of showing notifications.

Background

The idea behind this little experiment wasn't to have tweets appear as growl notifications, there are already plenty of apps that do this, the idea was to have growl notifications sent to Twitter. Some friends have started organising a crowdsourced Friday afternoon playlist via Spotify and I thought it'd be handy if Spotify tweeted each song as it started. The easiest way I could think of doing this was to tap into the fact that Spotify sends a Growl notification on track start and get the Growl display plugin to tweet it as well ^[1].

Build

I downloaded the Growl Display Plugin Sample 1.2 [Zip - 186 KB] from the developer downloads page and the MGTwitterEngine library. I then downloaded Xcode so I could do the development. I have to point out here that this was my first foray into Objective-C programming and, indeed, my first attempt at anything vaguely C-related since I wrote a command-line calculator about 12 years ago. If I do it wrong, please forgive me.

The first thing to do was open the sample project in Xcode, figure out what files do what, etc. There is very little documentation on how Growl views or display styles work so I pretty much just spend an hour reading all the source from top to bottom. Here's a quick summary:

Sample_Prefix.pch

Pre-compiled header. Stuff that's included before every pre-compiled file

Growl/

Folder containing standard Growl stuff. Don't need to touch.

GrowlSampleDisplay.h

Header file, didn't need to change anything

GrowlSampleDisplay.m

Class for setting up things. Again, didn't touch ^[2].

GrowlSamplePrefs.h

Defining default preference values and naming functions to handle them. More on this later.

GrowlSamplePrefs.m

The actual functions mentioned in the previous header file

GrowlSampleWindowController.h

Not doing anything visual, really so I didn't need to mess around with this

GrowlSampleWindowController.m

As above

GrowlSampleWindowView.h

Declaring objects needed for execution

GrowlSampleWindowView.m

Instantiating the objects then actually using them later on.

Again, I'm not used to doing this stuff so if I'm using the wrong terminology, just pretend I'm not.

I then dragged the MGTwitterEngine library into the project drawer, saved and built. At this point it successfully did nothing different which is what I was hoping it would do. Well, it popped up the 'This is a Preview of the Sample Display' message using the MusicVideo style which is what it does when you don't screw with it.

The next thing was to include the MGTwitterEngine. In GrowlSampleWindowController.h, #import "MGTwitterEngine.h" and create a new object. I just followed the instructions in the README but be sure to follow all of them. If you get errors about LibXML not being installed or YAJL not working, don't worry, you just need to make sure you set USE_LIBXML to 0 in all the places you're supposed to. GrowlSampleWindowController.h now contains this:

#import "GrowlDisplayWindowController.h"
#import "MGTwitterEngine.h"

@class GrowlBirdWindowView;

@interface GrowlBirdWindowController : GrowlDisplayWindowController {
	CGFloat						frameHeight;
	NSInteger					priority;
	NSPoint						frameOrigin;
	MGTwitterEngine *twitterEngine;
}
@end

In GrowlSampleWindowController.m, I then instantiated the new object:

  @implementation GrowlBirdWindowController
  - (id) init {
  	  :
  	  :
      twitterEngine = [[MGTwitterEngine alloc] initWithDelegate:self];
	    [twitterEngine setUsername:@"growlbirdtest" password:@"testgrowlbird"];
	  }
	  :

And then modified the setNotification function to also send an update:

- (void) setNotification: (GrowlApplicationNotification *) theNotification {
    :
	[view setTitle:title];
	[view setText:text];
  NSLog(@"sendUpdate: connectionIdentifier = %@", [twitterEngine sendUpdate:[NSString stringWithFormat:@"%@, %@", title, text]]); // The new line
  :
  }

That was enough to get growl to send messages to appear on http://twitter.com/growlbirdtest but it doesn't make it that useful for anybody else, to be honest. The next thing to figure out was the preferences.

Preferences

Without documentation, this took a bit longer that I expected. To start off changing the english version before worrying about localization, find the GrowlBirdPrefs.xib in resources/en.lproj/ and open it. Interface Builder will launch then you can double-click on 'Window' and see the layout of the preference pane. Search in the Library for 'text' and drag a text field into the window then spend about half and hour clicking round the interface. Open up the various inspectors (right-click on an object), look through the different tabs, click between the newly added text field and the sliders and drop-downs that are already there just to see what's different. Once I was a bit familiar, I opened the connections tab so that I could bind the value of the text field to the value 'twitterUsername' in my code. I checked 'value', Bind to 'File's Owner' and entered 'twitterUsername' in Model Key Path. I then repeated this for twitterPassword using a Secure Text Field from the Library. The option nextKeyView is used to say which item is tabbed to next when you're navigating with the keyboard so to keep things tidy, I dragged lines from nextKeyView from each of them to the right places in the layout.

Back in the code, I added new default preferences in GrowlSamplePrefs.h:

  #define Sample_USERNAME_PREF		@"Username"
  #define Sample_DEFAULT_USERNAME		@"growlbirdtest"

  #define Sample_PASSWORD_PREF		@"Password"
  #define Sample_DEFAULT_PASSWORD		@"testgrowlbird"
  :
  :
  @interface GrowlBirdPrefs : NSPreferencePane {
  	IBOutlet NSSlider *slider_opacity;
  	IBOutlet NSString *twitterUsername;
  	IBOutlet NSString *twitterPassword;
  }

and named some handlers for them:

  - (NSString *) twitterUsername;
  - (void) setTwitterUsername:(NSString *)value;
  - (NSString *) twitterPassword;
  - (void) setTwitterPassword:(NSString *)value;

Be careful here, I got confused and didn't have the same spelling here for twitterUsername and twitterPassword as I had put in the interface builder as I hadn't realised the two were directly connected. They are. Obviously. The next thing to do is to write the code for these handlers:

  - (NSString *) twitterUsername {
  	NSString *value = nil;
  	READ_GROWL_PREF_VALUE(Sample_USERNAME_PREF, SamplePrefDomain, NSString *, &value);
  	return value;
  }
  - (void) setTwitterUsername:(NSString *)value {
  	WRITE_GROWL_PREF_VALUE(Sample_USERNAME_PREF, value, SamplePrefDomain);
  	UPDATE_GROWL_PREFS();
  }
  - (NSString *) twitterPassword {
  	NSString *value = nil;
  	READ_GROWL_PREF_VALUE(Sample_PASSWORD_PREF, SamplePrefDomain, NSString *, &value);
  	return value;
  }
  - (void) setTwitterPassword:(NSString *)value {
  	WRITE_GROWL_PREF_VALUE(Sample_PASSWORD_PREF, value, SamplePrefDomain);
  	UPDATE_GROWL_PREFS();
  }

Build and reinstall and this will now show the same preference pane as before but with two new text fields which allow you to enter your username and password. In fact, build at several stages along the way. Every time you make a change, in fact. If something breaks, check the error log to see if it's something predictable that should have broken at that point or if you've done something wrong. Also, keep the OS X log app Console open in the background. It will spew out error messages if you do something wrong. It's also good to have your code write out console messages to keep a track on what your code is doing like so:

  - (NSString *) twitterPassword {
  	NSString *value = nil;
  	READ_GROWL_PREF_VALUE(Bird_PASSWORD_PREF, SamplePrefDomain, NSString *, &value);
  	NSLog(@"twitterPassword = %@", value);
  	return value;
  }

You'll notice we're still sending messages to the growlbirdtest account because, even though we are reading and saving the username and password, we're not doing anything with them. That's easily remedied by editing GrowlSampleWindowView.m again and replacing the hard-coded login details with a couple of lines to read from the preferences or fall back on the default:

  twitterEngine = [[MGTwitterEngine alloc] initWithDelegate:self];
	NSString *twitter_username = Bird_DEFAULT_USERNAME;
	NSString *twitter_password = Bird_DEFAULT_PASSWORD;
	READ_GROWL_PREF_VALUE(Bird_USERNAME_PREF, SamplePrefDomain, NSString *, &twitter_username);
	READ_GROWL_PREF_VALUE(Bird_PASSWORD_PREF, SamplePrefDomain, NSString *, &twitter_password);
	[twitterEngine setUsername:twitter_username password:twitter_password];
	NSLog(@"Twitter Login: username = %@", twitter_username);

And, hooray! It works and posts to the account for which you entered details. Sort of. Some apps double-post. I haven't figured out why yet.

Renaming

After all that, the final bit (which I thought would be the easiest) was to rename the growlView from 'Sample' to 'Bird'. I have read that in the latest version of Xcode (which presumably comes with Snow Leopard), there's a global 'Rename' which will do all the relevant stuff for you. If you don't have that, you'll need to read 'On the Renaming of Xcode Projects' and do everything there. If you're still finding your growlView is called Sample, manually open every Info.plist you can find, 'Get Info' on everything, scour through the settings for the different build environments (Debug and Release)... It took longer to rename the project than to actually build it.

You should now have a completed, installable growlView/Growl View/Growl Display/growlStyle/whatever it's actually called. You can export the current Git project to have a look around or you can just download the finished GrowlBird.zip [Zip - 228KB] if you like. Note, the Git project isn't guaranteed buildable at any moment in time, I might break it. The localisations still need done and the layout of the prefPane isn't the greatest, either.