Looking out for the little guy

Published on 
Tags:

I am not a web designer.

I market myself as a web designer, because that’s what my clients think they want. In fact, what they want is a person who makes websites.

That’s what I am. I’m a person who makes websites. And apps too, if you’re feeling adventurous. I’m a UX designer, a UI designer, a front-end developer, a back-end developer, a hosting provider, a sysadmin, a copywriter and a marketer.

I’ve done all of the above individually, for different companies at different times, and also I’ve done all of them at the same time for a single client as part of a larger package, which I will refer to as “a website”.

Primarily, I work in front-end development. But to any client outside of “the web”, this means nothing. They don’t care about day rates, the tools I use, or the maintainability of my code; they want to give me a brief, and when the website is live, hand over a cheque for a pre-agreed amount.

There is much talk in the web community about the latest responsive trends, scalability tools and performance optimisations that should be used on the web; and much berating of those who shy away from them. This criticism is often short-sighted. Granted, the above are all important aspects in the building of a website, but they also cost money; money that the average client simply doesn’t have. But why should a lack of budget deny a client from receiving a website that employs good design principles?

The answer is in the base elements of the design; the layout and typography. Dan Donald talks about this at length in his great talk Flux and Flexibility. A well designed website could be as simple as a single column layout, with a good typographic base. Inherently responsive, a design such as this could easily catapult a small business into the modern era of web design, for very little cost.

But instead of this, too many designers concentrate on adding embellishments that add nothing more than zeroes to the price of the site. They may be eye catching, and no doubt will appeal to the client, but by placing these front and centre in mockups and prototypes, when it comes the time to remove features in order to fit a project within budget, these are the features which the client will want to keep.

But there are many aspects of web design that clients might not fully understand; responsiveness, performance optimisation, maintainability, accessibility. Why would any client choose these as features of their website, when the fancy lick of paint that masks them looks so appealing?

The answer is progressive enhancement. Not in the development sense, but in the process through which the website is designed and built. When creating mockups and agreeing quotes, start with that simple, single column layout. Explain that although such a design may not be the most modern, or the most eye catching, it is functional and inclusive across all devices, connection speeds and ability levels. Explain that embellishments cost extra, and add to a simple base, rather than removing features from an over-ambitious mockup.

If we were all to work in this way, the even the smallest of budgets could allow access to well designed, well implemented sites. Clients would not be disappointed when their users complain of lack of support for their device, or inaccessibility.

And why shouldn’t they be allowed access to good design? People laugh at clients who come to them with budgets in the range of hundreds, rather than thousands; but this is unnecessary. A website can be built in a couple of hours. It won’t win any awards, but if built properly and populated with the right content, it will be functional, and more than likely meet the clients needs.

So think about this the next time a small, local business comes to you for a quote. Spend the time to talk to them, and remember that whilst a simple website built in a couple of hours might not be up to your usual standard of work, it might just be the best thing that’s ever happened to that particular business.

Things about CSS that make me want to put my face in a blender

Published on 
Tags:

Padding

When you enter a margin value such as:

margin: 12% 24%;

the vertical value is taken as a percentage of the height of the parent and the horizontal value is taken as a percentage of the width of the parent. This makes sense.

If I enter the same values as padding:

padding: 12% 24%;

the vertical value is taken from the width of the element (horizontal), and the horizontal value is taken from the height of the element (vertical). This is stupid.

The only time this has ever been of any use to me whatsoever in four years of writing CSS has been when forcing the aspect ratio of an element like so:

height: 0;
padding: 0 0 50%;  /* Forces a 2:1 aspect ratio. */

You know what would be far more useful? Make the horizontal and vertical the right way around, and give us an aspect ratio property. Not only would this make aspect ratios an actualproperthing™ rather than a hack, it also allow us to finally vertically center things properly.

/* 25% of the element's height will be
    whitespace above and below its children,
    making them vertically centered (Hurrah!) */
padding: 25% 0;

/* The elements width will be double that
    of its height, which is determined by
    the flow of content. */
height: auto;
width: auto;
aspect-ratio: 1 2;

Exes and Whys?

margin: Y X;
padding: Y X;
border: Y X;
outline: Y X;
background-position: X Y;
transform: translate(X, Y);
transform: scale(X, Y);

Why, dear God, Why???

Fixed positioned elements

I set some elements at a certain size.

.parent {
  width: 50%;
}
    .parent .child {
      width: 30%;
    }

.child is 30% of the width of it’s parent. Nice and easy. Then I add position: fixed; to the child.

.parent {
  width: 50%;
}
    .parent .child {
      width: 30%;
      position: fixed;
    }

Boom! .child has now doubled in width. That makes sense doesn’t it? No.

Borders

I only ever use solid borders, because anything else is harder to see than a true word in the Daily Mail.

I want to write

border: blue;

and have it give me a 1px wide, solid blue border.

border: 5px blue;

gives me a 5px, solid blue border. Easy peasy.

Posititioning

background-position: top center;

is a nice easy way to position a background. At the moment, to absolutely position an element in this way, I have to do this:

width: 300px;
position: absolute;
top: 0;
left: 50%;
margin-left: -150px;

If the width is dynamic, the above is impossible without a javascript hack. This would be better:

position: top center;  /* Boom! */

I build my own tools, and you should too

Published on 
Tags:

Originally published on Everyday Designer

Sharing makes the web a better place. Thousands of hours of design and development time are put in each week, creating resources for the community to use; and use them they do. You can’t visit a site nowadays that isn’t using a free, open-source tool of some sort. Bootstrap? Check. jQuery? Check. WordPress? You betcha.

They’re all great resources, that allow you to throw yourself into a new project without having to think too much about the technical aspects of what you’re doing – as such, beginners love them. But what happens when you want to stop being a beginner and start taking control of the code you’re writing?

Last year I released a CSS grid framework called Melody. As I’m now working on version 2, I wanted to explain my experiences building and releasing a resource that other people now use, and why I think it’s something you should do yourself.

Why bother?

There are thousands of other frameworks out there, so why did I decide to build my own?

First of all, I was jumping between frameworks the second a new one came out. Why? Because the ones I was using didn’t really meet my needs, they all involved compromises. I wanted something to allow for really quick prototyping, that was still flexible and robust enough to be used as production code.

Second, rather than relying on something magical to do my work for me, I wanted to really understand what was going on beneath the surface.

And lastly, I wanted to give something back to a community that has happily given away free resources for years, without which I would never have been able to learn my craft.

What did I learn?

I learnt a lot.

I learnt the importance of separating and commenting my code so that it’s easily accessible to others – something I’d always been terrible with. Developers are a fussy bunch and if your code is not up to scratch, they’ll tell you. This kind of feedback is invaluable for a rookie.

I learnt about specificity, and finding better ways to write non-invasive code so that the framework doesn’t interfere with the code of the app or site that’s built on it. If you’re having to modify a framework to get it to work for you, or implement hacks to override portions of it, you’d be better off not using a framework in the first place.

I learnt about proper typesetting using a baseline in order to add some useable typographic styles to the framework. The rules I used can be applied to design of all kinds, not just the web, and using them has hugely increased the quality of my work.

And finally, I learnt about optimisation, and trying to do as much as possible with as little code as possible. The current version of Melody is just 8kb before minification. The new version is even smaller. The small file size makes a huge difference when you’re serving content over a slow connection.

What else is good?

Aside from the great learning opportunity, there have been other benefits too. It’s got me some valuable exposure, and it looks great in my portfolio. I’ve had one client tell me outright that it was the deciding factor in me getting a job – creating a tool rather than just using one shows that you really understand what you’re doing.

Developing the framework has also sped up my workflow. Because I built it, I know the best ways to implement it. I very rarely wireframe any more – in the traditional sense at least – instead opting to whip up a layout in CSS just as quickly, which gives me a real, responsive prototype to show to my clients.

And by far the best part is that I’ve met some great people, who having used Melody, want to show me the sites and apps that they’ve built with it, and to say thanks. It feels great to know you’re helping people make awesome stuff.

It’s not all rosy though…

As with any released tool there’s the inevitable wave of support requests. Generally, I enjoy dealing with these but on days when I’ve already got a full inbox to deal with, it does add to the pressure.

There’s also the risk of complacency. Having spent time developing the framework, I now jump straight into using it, even for those projects where it may not be the best fit. No matter how good a developer you are, there’s no such thing as a one-size-fits-all solution. You’ll still have to compromise or modify your tool occasionally, but having built it yourself, you’ll know straight away how and where to do it.

So what’s next?

Since taking the plunge, I’ve built and released a number of other tools. Whereas before I’d look for a tool or a plugin to solve a problem, I now try and develop my own solutions first.

If you can think of anything you need, no matter how small, find the time, and build it.

It doesn’t matter whether you release it to the public, because most of all, it’s about taking control of the code you’re writing. When you’re working on a project with a tight deadline, you don’t want to be wasting time filing bug reports or support requests. Use code that you’ve written yourself, and therefore understand, and instead of relying on a third party to help you get out of a problem you can just dive in and fix it yourself.

You’ll learn a ton of new stuff and make your life a lot easier in future.

Screenreaders and the web

Published on 
Tags:

Mention alt text to a room of web developers and you’ll likely start an argument. Should they be ignored for decorative images? Should they ever be left blank? And is anyone brave enough to say alt=" "?

Everyone has their own methods for implementing accessibility. Some are innovative, some are better than others, some are downright lazy. All however, are less than ideal, as every screenreader reads assets, code and content differently.

An alt attribute on an image is a prime example. If empty, some screenreaders will announce “Image” and nothing else. Some will announce the filename. Some will announce the title if one is present. Some will ignore the image altogether. And when included, an alt attribute is often a cop-out, an afterthought thrown in to please those who get angry about this sort of thing. Take a look at the below image:

Portrait of James Dinsdale

Those of you readers who are blessed with sight have just been treated to the pretty face of yours truly. However those users without sight simply heard “Portrait of James Dinsdale”. Where is the additional context that sighted readers enjoy? Where is the description, telling those who cannot deduce it by looking my age, race, approximate height, eye colour, hair colour, clothes, facial expression, surroundings. All these things are detected by sighted users in a matter of seconds, but for a user using a screenreader they will never be privy to this information, as alt text never goes into as much detail.

For textual content also, the mechanical, impersonal voices employed by screenreaders do little to convey the tone, emphasis and thought lovingly put into the article by the author. Where is the long pause after that poignant sentence? Where is the different voices and accents that we readers imagine when reading a written conversation? Where is the correct pronunciation when reading a name, or a word in a different language slipped into a paragraph?

In other forms of media, additional context is readily provided. Many books and magazines have audiobook counterparts for those users with poor or no sight; audible descriptions are provided for films and television programs; transcripts are provided for video and podcasts to assist the hard of hearing, but the web falls a long way behind these forms when it comes to providing a totally immersive experience for all, regardless of ability. Great steps have been made, no doubt, but more could be done.

What the web needs, is an audio attribute for images and content. The value of this attribute would be the path to an audio file, in which an image is described in detail by a real person, or an article is read aloud by the author, in exactly the context intended. Image alt attributes would still have a place, providing a short description allowing the user to then make a decision as to whether or not they would like to hear the full description. If they decide to hear more information, the audio file is downloaded and played in the background.

Yes, creating audio files for every body of text or image on a website would be a lot of work, but not every item would require it. An address, for example, does not need quite the same joie de vivre as an enthusiastic, thought-provoking article. But for important elements within a web page this would provide a much more personal experience to non-sighted users, something which is currently lacking.

If anyone knows where I can go to recommend this sort of thing be implemented into accessibility specifications I’d love to know about it.