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.

First past the post

Published on 
Tags:

There have been two exciting new products doing the rounds recently. The first is Execute, a fantastic book by Drew Wilson and Josh Long. It is about “executing on ideas immediately when inspired rather than following the normal rules”. The second is Medium. Created by Twitter founder Ev Williams, it is an online magazine, open to contributions from the public.

I only managed to pick up Execute this week. I read it cover to cover in under two hours. I really wish this book had been written 2 years ago, when I first had the idea for a website very similiar to Medium, called The Branch.

The idea was almost the same, anybody can submit articles and assign categories to them. Readers can then subscribe to a category, an author or a group of authors, and each are presented as individual collections or “magazines” within the interface. I even had plans drawn up to give a percentage of advertising revenue back to the authors.

The interface for article creation was fairly innovative, and aimed primarily at those with no knowledge of HTML, without resorting to other languages like Markdown or Textile. You can see some screenshots of the interface on Loviv (link dead).

The problem? I wasted time. I tried to build this mammoth interface all by myself, around my daily work. I completely redesigned the site three times, as having stared at it for so long I grew bored of it. I strived to create the perfect experience, and never finished, rather than concentrating on ensuring that the product shipped.

When Medium was announced publicly and went into private beta, I immediately pulled the plug. The team at Medium managed to pull off exactly the vision I was striving towards, to allow anybody to easily create articles in a beautifully typographic way. They did it with a better design, ethos and infrastructure than I did, and with the traction and publicity that Medium has gained since being announced, there was no way that my product was going to compete.

What I should have done, as suggested in the Execute book, was put aside the time to work towards the goal I had. I should have been unafraid to ask for help, rather than trying to go it alone in secret, for fear of the idea being stolen. Had I done that two years ago, I may have been able to get the site live long before Medium came into existence. Instead, I have two years of wasted evenings, with nothing to show at the end of it.

Since the day I pulled the plug, I’ve been far more focused when I come up with an idea. I actually ended up reusing the name and domain I had for The Branch for another exciting project which I built in a little under two weeks, and am now immensely proud of and enjoy maintaining.

Since reading Execute, I now know exactly where I went wrong, and will use the approaches recommended by Drew and Josh when I next come up with a great idea.

I’d recommend this book to anyone who works on projects in their spare time, it’ll save you a whole lot of headaches. Go buy it now.

Show your personality

Published on 
Tags:

    I’ve seen countless blog posts, magazine articles and comment pieces from people complaining about the impersonal nature of the email. Well, I think I may have found the culprit.

    How many times have you received a one or two word email - “Thanks” or “Sounds Great!” - followed by 10-15 lines of Name, Job Title, Address, Contact Information etc. etc. Some may even go so far as to add legal information, or request that you refrain from printing the email in order to save trees. I receive countless numbers of these emails, not just professionally, but from people I have known for years, and for whom I have all the information in the signature block memorised.

    Google recently announced that signature blocks and company logos make up more than 40% of all storage on gmail. That’s a ridiculous amount of data for something that rarely even gets read.

    The problem is, now that signature blocks have become so commonplace, that we forgo important facets of human interaction when emailing people.

    Take this for an example: if you were to meet someone in a bar would you introduce yourself straight away, or hand them your business card at the end of the conversation? On the telephone, would you finish talking, exchange salutations, and then spend a few minutes reciting your contact information?

    If someone is emailing you directly, chances are they already know your name and job title; they certainly already know your email address, yet it’s still recited in every message in the conversation. If you’re emailing a stranger, rather than including this information in a footer, begin your message by introducing yourself. Let the reader know who you are and what you do, so that they can get a picture in their head of why you are emailing them and why they should take notice.

    The same can be said for those times when you want your telephone or Skype contact details to be available to the recipient. Rather than expecting the person to find this information, add a line into your message: “Feel free to give me a call if you’d like, my number is…” or “Let’s talk on the phone some time”. Leave them in no doubt that you are happy for them to use this method of communication to contact you.

    It’s also worth noting that many popular web-based email clients actually hide signature blocks from the conversation, so any contact information that is not part of the message itself is easily overlooked.

    The majority of emails could be much more thoughtful messages, and with these added personal touches could become, instead of a necessary burden, a form of communication that harks back to the good old days when it was a joy to receive and respond to them.

    I miss those days.

    Frameworks

    Published on 
    Tags:

    There are plenty of programming languages out there. Everyone has their favourite, and many, like me, probably have a list as long as their arm of languages they’d like to learn. Every language has a selection of frameworks, designed to make them easier to build apps with. Many are incredibly useful. jQuery for instance, has taken the web design world by storm, and it’s quite rare to see a site nowadays that doesn’t make use of it. Laravel and CodeIgniter for PHP are very highly regarded, as is Rails for Ruby development.

    The problem is, with many of these, it’s easier to learn and use the framework than it is to use the base language itself. I myself was guilty of this when I first started learning jQuery many years ago. It’s only within the last year that I’ve taken the time to actually learn and understand the JavaScript code underneath it. And you know what? Since doing that I’ve found that in a number of instances, where before I would have jumped straight into jQuery without thinking, I now use vanilla JavaScript as much as possible.

    The same can be said for other languages. The best way to learn how to use a language is to learn the vanilla language first. With PHP, if you jump straight into Laravel or CodeIgniter, you’ll likely be lost when looking at vanilla PHP and trying to use one of the additional functions from the framework. All my PHP and Ruby development is done vanilla, no framework. I simply don’t currently work on applications on the sort of scale at which a framework would give me any benefit. That doesn’t make me a bad person.

    Learn the language first, and any of the frameworks will be almost second nature, and you can choose the right tool for the job, rather than relying on a huge framework when all you need are a few simple server-side calls.

    Frameworks should be a tool allowing you to do the best job you can, not a mandated starting point.