Posts Tagged ‘design’

If you have a website, it is not enough to talk about “mobile-first design” anymore. We need to talk about mobile-first navigation, too.

The days of desktop computer terminals are gone. They’re not going anywhere, but most internet access is on a mobile device today. And has been for four years. We all design websites on these big laptop screens, but that isn’t how anybody else is looking at it.

So, we all started adopting mobile-first design.

You make the website look brilliant on a mobile, then re-arrange everything with CSS media queries so that it looks good on a desktop, too. Some people did it because they wanted to offer their users the best experience they could, others because Google announced they would be demoting sites that were not mobile friendly.

What about navigation, though?

Pages that you can read on a mobile device are a big improvement. But we forgot about navigation.

Take a look at The Washington Post’s website:

They have put a hamburger menu icon in the top left. Which is what a lot of websites do.

What’s wrong with this? It puts the menu icon in the on exact place that the majority of users cannot reach with their thumb:

Not great then.

Recently, though, there has been a move to clamp down on this. The UX community has begun to beat the drum of mobile-first navigation. Which is a good thing, because it is about time.

Thinking mobile-first

While web designers have been slow to adapt, app designers have not. Because they actually apps, no doubt. Take a look at most of them and you will see the navigation is on the bottom. Where your thumb is.

Here is the Facebook app, for example:

The NHS’s Change4Life website has embraced this principle, too. On the desktop, you get the navigation at the top:

But when you shrink your device to mobile size, the navigation fixes itself to the bottom:

Welcome to a much better world.

Logotype is a book by Michael Evamy. Here is the description:

Logotype is the definitive modern collection of logotypes, monograms and other text-based corporate marks. Featuring more than 1,300 international typographic identities, by around 250 design studios, this is an indispensable handbook for every design studio, providing a valuable resource to draw on in branding and corporate identity projects.

It is literally just that. A big book of logos. There is nothing else in here. No real commentary on logos or review of what works well and why it works. Just lots of logos.

It comes in a regular and mini size. The regular seemed to be out of stock. The mini size does have incredibly tiny print. However, as someone with average eyesight, I was able to read it fine by moving my face closer to the page. If your eyesight isn’t so good, you will struggle.

Office sinks are often badly designed. Why? Because they have the bowl, and then a soap dispenser mounted on the wall not over the bowl.

Most people will turn the tap on, wet their hands, go for some soap, and then wash it off. This means that there is water on their hands when they reach for the soap, slashing it underneath. This is not under the sink and thus water ends up on the counter.

It seems to happen in almost every office I have worked in. By the end of the way the counter is a pond. This creates mopping up for the cleaning staff to do and means if you cannot put anything down on the sink counter.

I appreciate it is not the biggest problem in the world, but I think that as a society we need to come up with a better solution to the sink soap dispenser problem. Like just having a bigger bowl, putting the dispenser directly over it, or having a dispenser bottle instead.

This could well be a lot less funny to people who haven’t worked in a design agency. But I nearly fell of my chair laughing at the Santa brand book.

Having worked on a lot of different projects at a lot of different companies over the years, there are some issues that recur time after time. These are problems that maybe we just don’t have satisfactory patterns for, or developers have a blind spot for. But whatever the reason, they certainly merit more attention in order to reduce how frequently they arise.

Below, I’ve listed three with some suggestions as to how to help mitigate them.

Caching

Caching is essential to good performance in most applications. Remember your ABC – Always Be Caching. Indeed, if you ever want to sound clever in a discussion about system architecture, say “have you thought about caching that?”. Caching is the solution to almost everything. But causes some problems too.

For the non-technical, caching is storing information in short term memory so it can be delivered faster. It’s like remembering things. You probably have a big pile of books at home, and you can’t remember most of them, so for most facts you have to look them up in a book. But you can remember a few things, so for the questions you get asked most, you memorise the facts so you can say them quicker. That’s basically what caching is.

The problem is that when you update something, the cache can end up serving the old content, rather than the new. This results in data being out of date and often results in web applications not appearing correctly because the HTML has updated, but the CSS and JavaScript happens.

Here are a few tips to help mitigate such problems:

• Have scripts to clear out your various caches. Make sure you know what/where the cache layers are.
• Understand what cache headers you are serving via you sending via your web server.
• Have a mechanism for changing files such as stylesheets and JavaScript when you release a new version.
• Turning caching off on dev environments is fine, but make sure you have it turned on on your staging/pre-production environment so you can spot potential problems.

Timezones

While Britain insisted that time starts and stops in Greenwich, we did allow the rest of the world to make adjustments at hourly (or even half-hourly) intervals based on where they are in the world. This has caused no end of headaches for software developers. Even within one country, one problem that comes up time after time is that systems go wrong when the clocks are changed for daylight savings.

Every six months it all goes wrong every six months and we promise to fix it by the next time the clocks change, but usually never do. Even Apple got it wrong on their iPhone alarm – twice!

Here are a few tips to help mitigate such problems:

• Set your servers to GMT/UTC and leave them there, regardless of where you are in the world and where DST is in effect or not.
• Use prper DateTime objects, and specify the timezone.
• When sending a DateTime string, use an ISO standard and be explicit as to what TimeZone it is in.
• Unit test DST changes, using a mock system time if required.
• Perform manual testing on the DST switch.

Load balancing

As systems scale, they inevitably need to spread across multiple processes, applications and bits of hardware. This brings a whole new layer of complexity, though, having to keep everything in sync. It’s very easy to lose consistency and that almost always ends in one thing – say it with me everyone, “race conditions”!

There are two common problems we find in this situation. The first is that one node stops working but the other one is working fine, or maybe something as simple as one node having old code on it. You get intermittent problems but when you try it it works fine or at least works fine 50% of the time. It could be that it is hitting the working node but at other times is hitting the other.

Here are a few tips to help mitigate such problems:

• Ensure you can (and ideally do automatically) test individual nodes.
• Use a tool like Chef or Puppet to make sure all your nodes are consistent.
• Have the ability to easily take out nodes that are not working.
• Aggregate your logging where possible so you don’t have to tail them on each individual node.

The second is race conditions. This is particularly prevalent when using a master and slave database setup. You will write the update to the master than query for it the results – but because your second query is a read, it will be passed to the slave, which may nor may not have updated yet with the new information.

Here are a few tips to help mitigate such problems:

• Have the ability to manually specify master or slave so time critical reads can be pointed at the master.
• Ensuring your staging/pre-production environment load balances everywhere your production environment does so you can spot potential issues.
• Where possible, rely on one server for the time as different machines can become slightly out of sync.

Last Thursday, the Trinity Leeds shopping centre opened. On Friday, it snowed. This presented quite a few problems for the new shopping centre, whose website claims it is the largest in the UK, even though we know that’s not the case (as if it wasn’t obvious to anyone who was walked around Meadowhall, that in itself is only the 8th biggest).

Snow settles on the roof
The large glass roof that covers the centre over will no doubt be magical in ideal conditions, but with a lot of it being fairly flat, the snow just settles on top of it. As a consequence, it almost felt a little gloomy over the weekend because all you could see when you looked up was a thick layer of snow.

It’s very cold
The centre isn’t actually enclosed, it just has a roof over it. The result is that when it is cold, it is cold inside as well because there is nothing to keep the heat in. This would be fine, but at least one of the restaurants has most of their seating outside, which is then rendered useless by our wintery conditions.

It snows inside the centre
Another rather unfortunate consequence of not having a sealed roof is that when it snows outside, it snows inside as well. Walking though the centre on Saturday felt like just being outside as as much snow seemed to be falling inside as it was outside.

If you’re interested in good user experience design (and who isn’t, right!) then it might be good to get the perspective of someone who actually studies users – someone like a psychologist for example. Luckily, one such psychologist is interested in such matters and has written rather a good article about it.

Over at UX Magazine, Susan Weinschenk has written The Psychologist’s View of UX Design and it provides a very useful breakdown of a lot of UX areas and how she views them. Well worth a read.

Still writing regular CSS? Pfft, you’re living in the dark ages! These days it’s all about two new technologies that are almost identical, so I’m going to discuss them in the same post.

The idea is dynamic stylesheets – bringing concepts we use every day in regular programming and implementing them in stylesheets to avoid duplication and make everything cleaner, nicer and more up to update with current paradigms.

So what can you do with these tools? Here is a quick overview…

Variables

Using a colour everywhere that you might want to change later? No worries, just save it as a variable and if you do need to change it at a later date, you just update the variable and it will be changed everywhere.

@myColour: #FFCC00;

.header { background: @myColour; }
.footer { background: @myColour; }

Mixins

Inheritance! What a sexy thing to have in CSS. No longer do you have to place loads of DOM references in lots of different places. Now you can just write it once and included it wherever else you need it.

.bigBorder { border: #FF99CC 10px solid; padding: 5px; }
.header { .bigBorder; background: @myColour; }
.footer { .bigBorder; background: @myColour; }

Nested rules

This one is a huge time saver! How many times have you had to reference half a dozen elements in one DOM reference? Probably very rarely, but certainly two or three tags is the every day reality. No longer though, because you can now nest your rules.

.header {
	.bigBorder
	
	a {
		font-size: 200%;
	}

In this example, the 200% font size will only apply to a tags inside .header, just as if you had done .header a in your DOM reference.

Operations

Want to make a header colour slightly darker? No worries, just add two colours together.

@mainColour: #FFCC00;

.header { background: @mainColour + #333333; }

But these are just a few of the features of these languages. They allow you to do a lot more – including things like full blown functions that you can pass parameters into, guards and much more.

The main difference between LESS and SASS is that LESS is a client-side JavaScript library (although has now been ported to Node) – you send the browser your .less file and include a JavaScript library that converts it. Meanwhile, SASS is a Ruby Gem that compiles a stylesheet to send to the client each time you edit your .sass file.

To find out more, visit the LESS and SASS websites.

The secret is, it never looks good.

So you’ve designed your perfect homepage. The only problem is that it doesn’t fit on anyone’s screen but yours. Suddenly you are finding you have to redesign your site so it is more accessable to everyone and your amazing designs and idea’s are laid to waste.

When first building your website you need to decide how wide your going to make it. If its just formatted text going across the screen then you are ok, but for most of us, we need to set a width for our tables and layers which is bound to cause problems somewhere along the line.

100% width

The easier way to make a site fit is to set the width to 100%. It will stretch across any screen so no problems you say. However its not as simple. Designing a site with 100% width is not always that easy as you have to make sure everything will squash down – no point using 100% width if your images won’t let it go down futher than 900 pixels.

You still really need to pick a width as any images and menu’s that make your site wide will set the width for you. People on 640 X 480 screens with browsers in shrunk mode would probably like your site to squash down to about 400 pixels. Test if your site will do that (though don’t worry if it won’t).

100% width works good for sites such as Microsoft.com and Worfolk.biz who have a lot of product information and so use text with can go across the screen and still squash down easily.

700 pixels width

This is the site I use for most of my sites. I use it because I can fit a banner into it and still have room for a 200 pixels wide logo next to it. The only problem with doing this is that its slightly too big for people with 640 X 480 screens and slightly too small for 800 X 600 screens. I consider it a nice balance though.

A lot of sites go for a 800 pixels wide screen so that it wil fit on a 800 X 600 screen now as people using 640 X 480 are become rarer quickly – I’ve been using 1024 X 780 for years now. Ever Yahoo is now to big to fix on a 640 X 480 and has been for a while too.

A fixed width site works well for sites which have content in the right place, all neat and correctly laid out in sections such as Msn.com or Mworld.us.

Other options

MSN use javascript to show hide layers. If you read Java Junky (MXL Magazine column) then you will know what this is about. Bascially if the browsers screen is big enough, they add extra information dowen the left column – Full screen your browser on one of the channels and then shrink it to a fairly small size. Some content should disappear (probably the channels menu) from the right hand side.

They also have a script on their homepage so that it rearrages the content for people with 640 X 480 screens so it fits on them while using up the space nicely on a 800 X 640 screen.

Conclusion

If you site isn’t almost all text then go for a set width such as 700 or 800. If you don’t have any menu bars or extra content down the side then you might even want to go for 600 pixels like Worfolk Online uses (or used to use depending on whether it has changed since I wrote this). Test it out on different screen sizes and see what looks good. Check out what the competition does. When you’ve found something you like – stick with it.