Google Analytics – Why You Should Replace IDs in URLs

Google Analytics is brilliant at tracking things like Page Views for a website. It logs the URL and then keeps a count of how may times that URL is requested. Great, right? Not always.

There’s a problem. Dynamic sites that use IDs in their URLs generate a lot of different URLs. A typical example might be a site being made up of list and details screens, so the URL for a list screen might end in /List/. For a details page there’s probably one template with the data changing dynamically and the ID for that item is probably in the URL, something like /Details/123 or /Details?id=123.

This means that Google Analytics sees every visit to a different item’s details as a different screen. This is ideal for some data analysis, like seeing which item is viewed most but not so great when you want to look at something like the performance of that template. Having hundreds of different URLs makes it impossible to analyse the template as a single screen.

Good news. It’s quite easy to set up another view to show the aggregated data using filters.

  1. Go to the Admin area and create a new view.
  2. Find Filters and add a new filter.
  3. Add a Filter Name.
  4. Select a Filter Type of Custom.
  5. Use the Search and Replace option.
  6. Select a Filter Field of Request URI.
  7. The Search String needs to match the ID. You can use regex to match any patterns so if you know your ID is 3-5 digits long you can use [0-9]{3,5}. If it varies you could use a wildcard, like id=*.
  8. Add a Replace String. I use something to represent what’s being replaced, like ID. This gives me a URL like /Details/ID or /Details?id=ID. If you’ve used a wildcard in the Search String with part of the URL you can replace this too, like id=ID.

Here’s an example of replacing a GUID in the URL:

Google Analytics Filtering screenshotThe full regex needed is:

[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}

An added bonus. When you look at your reports in Google Analytics you’ll no longer see URLs like /Details/aace7226-0576-4a0f-9b39-bb549a53ee11 but just /Details/GUID. Much easier to understand, especially if your URL contains several IDs or GUIDs.

Hope this helps you analyse your screens, templates or UIs rather than just the data requested.

Experiment: Font Size vs Colour Contrast

One of the things I’ve learned early on in web accessibility is the importance of colour contrast to make things easy to read on screen. High contrast is good but the size of text is also a factor. If it’s larger it’s easier to read even if the contrast drops.

At the same time, having very large text with high contrast is quite “full on”. It can feel a bit like you’re being shouted at. Oppressive is the word I’d use.

This got me thinking. I wonder if we can scale colour contrast with font size so that it always feels good. It’s really an extension of responsive design.

So, I tried it in CodePen.

See the Pen Font Size vs Color Contrast by Chris Smith (@chris22smith) on CodePen.1248

I’ve just done some very crude maths to make the RGB colour proportional to the font-size. As the font gets larger so do the RGB values, and vice versa.

I’m sure there’s probably some beautiful golden formula for getting the optimum contrast at every size but I wouldn’t really know how to go about finding these optimum settings. This experiment seems to prove that the general idea is sound though.

Please feel free to play around with it, take it further and let me know how you get on.

Making Icons Accessible

I’ve been using the excellent Font Awesome for a few years and it’s become part of almost every new design that I do. For a long time I’ve just slapped my icon down on the page, styled it and added a click event where needed. Job done.

Having spent some time looking a bit more deeply into accessibility, I can now see that this is not a great approach. There’s more to consider. If you can’t see it what is it actually doing?

Here’s how I approach using icons now. It may not be the perfect solution but it’s certainly a lot closer than most use cases I see. The way I use HTML depends on the use case.

If the icon is purely decorative – there in addition to text, e.g. a floppy disk icon next to the word “Save” on a button, then I think we can reasonably just forget about it and hide it for non screen users. A simple aria-hidden=”true” attribute should do.

<button><i class="fa fa-save" aria-hidden="true"></i> Save</button>

If it is there as an indicator, in place of a label, like where a hotel might have icons for TV, bath, etc. then we can use an <span> to wrap it. Inside the span we add our icon and another span with a text alternative. We show the icon and hide the inner span for screens, show the text only for other media.

Finally, if the icon is interactive and acts like a link or button, let’s make it a link or button. Like the previous example, use the <button> or <a> tag to wrap the icon and a span text alternative and show/hide for the appropriate media. This has the added bonus of making it possible to tab to the icon and so use just the keyboard to navigate the page. It also handles the icon’s active state and visited in the case of a link.

Alternatively, if you didn’t want to add a span with text inside your button or link, you could use the aria-label attribute to provide a text alternative.

One little tip. If you use an icon inside a link or button, do not leave whitespace between the outer wrapper element and the inner icon as you may get unwanted effects in the styling, such as underlined spaces either side of your icon. Keep it tight.

A New Found Appreciation for Images on the Web

I’ve been putting images in web pages for years. Nearly 2 decades now. For most of that time it has been quite easy. Add your source and the dimensions and BOOM, there you go. There was always some work around optimising images outside of your page but once in there, easy.

Then, with higher pixel densities it started getting a bit harder and we had to work it out with media queries and srcset. Now SVG is widely supported, all this fussing around with different versions for different resolutions has gone away, at least for simple graphics.

I’ve recently been doing some design work on an Android app and it’s a very different way of doing things with images. For example, I’ve created a splash screen for while the app is loading. It’s a full page, wide logo in the centre, coloured background.

On the web, I’d just set the background colour and then centre the SVG logo, probably with flexbox, and use a flex-basis of 80% or some margin to give it a flexible width.

On Android, I’ve had to provide the splash screen image as a series of PNG files. 5 different resolutions, varying from 480×320 up to 1920×1280, and then in both orientations, 10 files in all. The clever part is that at the point of installing the app the Android device will only get the files appropriate for its size and pixel density but it means a lot of messing around with assets.

It’s been a similar story for icons too. Multiple resolutions. You want a different colour? That’s a separate PNG.

I’m making it sound worse than it actually is. Luckily there are great tools that let you import a single image and export all the variations you could need.

But it does make you think about the differences between platforms. To me, the web browser, with it’s ability to resize on the fly, use SVG, recolour, apply filters, transform and animate in CSS makes Android image support feel very primitive.

How to Be a Good Designer

I’ve been designing web sites and user interfaces for quite a long time now and thought I’d try to pass on what I think it takes to be a good designer. This isn’t about design techniques or theory, just how to interact with other people.

Rule 1. Don’t be a dick.
That’s really it. Don’t let your ego take over. You will inevitably have to present your work to others. Don’t presume that because you’re the designer that your opinion is worth more than anyone else’s. It’s a collaborative process and if you start feeling that you know best it will stop you listening to others. This leads neatly into…

Rule 2. Listen to others.
This isn’t because you have to or to be polite. If you actually listen and understand people’s views, opinions and concerns you can learn how to adapt your designs to meet their needs or explain how there might be a different solution to the problem.

Rule 3. Explain your thinking.
Don’t just present a design and let others judge it. Explain clearly all of the design decisions you have made. If you can justify these and articulate them clearly people will understand, you’ll have more of a conversation and, in turn, their feedback will be more constructive. It will also give them more faith in you – you don’t do things on a whim but your decisions are well thought out.

Rule 4. You don’t have to win.
It’s ok to not get your way. It’s important to show that you respect others’ opinions and concede to try their ideas. If their idea really was wrong it will come out over time and the next time they will be more inclined to trust your view.