Learning Experiences as a Freelancer

I thought it might be useful to share some of my not-so-great experiences as a freelance web designer so that others can learn from my mistakes.

All Work and No Pay

What’s really frustrating is that I made the same mistake several times. That costly mistake was doing work and not getting paid for it. I’d get an enquiry for building a site by phone or email. I’d get straight back with some ideas and a quote and more often than not my quote would be accepted. I’d even have written confirmation that yes, they wanted to pay me for a website. On this basis I’d do the work and then when it came to sharing my design they’d say that they didn’t want to go ahead any more or that they’d found another designer.

It’s hard as a designer. You can get excited by a project. As soon as you finish speaking to the customer the ideas start flooding into your head and you want to capture that excitement and creativity there and then. Unfortunately, in my experience it often doesn’t actually materialise. They’re just not as serious about the project as you think they are.

My advice would be to assume that it’s just talk until you see some commitment, and by commitment I mean money. Ask for a deposit. It doesn’t have to be much, even £10 or $10 will do, but it’s just enough to prove that they’re serious. Don’t lift a finger until you’ve got a serious commitment. Trust me -you can’t afford to work for nothing.

The Price is Right

The other mistake I made was in my pricing. As I was fairly new to web design I thought I’d hit the low end of the market where I could compete on price and get lots of small cheap sites in my portfolio. It worked well for some customers but it’s surprising how many people expect you to travel to see them at your expense when you’re charging less than £100 for a website. The only way you can operate at the cheap end is by having very low outgoing costs.

Later, when I stopped being a full-time freelancer and moved into a permanent job I kept the web design going as a side line. At this point I could afford to be more picky about which projects I took on, and, without needing to be so competitive I raised my prices. In fact, I doubled my prices. Here’s the thing. I was expecting my number of enquiries to drop off. It didn’t. It pretty much doubled. I think that going too cheap was actually suggesting low quality or making people suspicious. Charging more can suggest higher quality and strangely provide some reassurance.

My advice would be to find the price that you think your service is worth and then double it. Serious customers want to buy quality services and with something like a website they’re looking for a long term relationship, not a quick handover.

Losing Focus

The third mistake I made was spending my time on the wrong things. I spent a lot of time trying to market myself rather than focusing on client work. I put a lot of hours into studying Google Analytics, SEO and building other sites to promote my main business. It would have been far more cost effective to just pay for advertising rather than commit this time. Trying to market myself by spending time and not money was a false economy. Focus on what you’re good at and pay others to do what they’re good at.

Hope that helps someone.

Super Fast Tree View in JavaScript

I thought I’d share a way of writing your JavaScript that will make a tree view hierarchy render and respond very quickly.

Firstly, the demo. I’ve got 100,000 items, quite a hefty data set, which is randomly generated in a function. You can change the number of items easily in the JS area. Click on the + or – icons to expand or collapse nodes.

See the Pen Super Fast JavaScript Data Tree by Chris Smith (@chris22smith) on CodePen.dark

It’s still quick, like instant, with 100,000 items. It can start to slow a little at a million but I’d say it’s still acceptable given that kind of data.

One Long List

The trick is in how the data is structured. It’s one big array, not hierarchical data with objects inside other objects. The reason for this is pretty simple, it’s all about iterations or looping. If you have a single array you can run through the whole list of items once. If it’s nested you have to get into loops inside other loops and it gets more complicated and takes longer. In fact, you’d be lucky for it to work at all without getting stack overflow errors.

JavaScript Magic

With a single array you can use the built in JavaScript Array methods, which are very fast – map(), filter() and some(). I’d definitely recommend reading up on these. All three work in IE9+ so hopefully you shouldn’t have to worry too much about browser support.

I use map() to convert each data item into a HTML list item which I can insert into the DOM. I use filter() to quickly find the children items of any item by returning a subset, and I use some() to see if an item has children. The beauty of some() is that once its found it child it stops iterating, saving time.

Easy on the DOM

The other part of this is keeping DOM manipulation to a minimum. Playing around with data in memory trivial for a browser but making changes to the DOM and rendering things on screen takes time. So, only the nodes that are needed right now exist in the DOM – there are not hidden items waiting on the sidelines. So, a new <ul> is added when you expand a node and the <ul> is removed when you collapse. A + icon is shown if the item has children of its own but we don’t know anything about how many it has or what they contain until it’s expanded.

More…

If you found this useful it might be worth looking at my older post Lightning Fast Filtering in JavaScript, which uses a lot of the same principles.

Stop Linking to Nowhere

Do you find yourself writing this kind of thing in your HTML?
<a href="#" onclick="doSomething()">Some action</a>

Does that href="#" make you feel slightly uncomfortable? Like it’s not really doing anything, a bit of a hack? You’d be dead right to think that.

Links are used like this all the time and there’s really no need. The intended purpose of links is to point to another location and provide navigation. That’s why the href is there. It’s pointing to another place but it’s often left pointing nowhere.

It’s probably worth pointing out that using href="#" doesn’t actually do nothing. It adds a # onto your current location, changing the URL, so when you then click the back button it appears to do nothing but is actually going back to the last location, the URL without the #. If you do use href="#" and an onclick event be sure to use event.preventDefault() with it to prevent this location change.

Links get used in this way mainly because we want the styling and the interactivity. Hovering a link gives visual cues – underline changes, cursor changes so it’s easy for a user to see it’s something they can interact with.

So, what’s the alternative? If you’re just performing an action, use a button. It has the visual cues. It doesn’t have any hacky href="#" nonsense. It can be styled however you wish if the default styling is too full-on. It can even be styled to look exactly like a link, though personally I think there’s value in differentiating between navigation and actions.

And there’s more… You get some more benefits for free with a button.

You have a disabled property. You can easily make your action unavailable. Not so easy with a link.

It’s more touch friendly. This depends on styling but out-of-the-box it’s a larger touch target.

It has an autofocus property so it can be in focus on page load without needing any JavaScript. Ready to go at the tap of the Enter key.

If you use links for navigation and buttons for actions you get every tool doing what it’s best at. You could cut your food with the side of your fork and raise it to your mouth on the side of your knife but why would you? This isn’t really so different.

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.