The last few days have been quite the journey for me. It was my first time in Newcastle, my first time attending any conference aside from Build, and the first time being involved with sponsoring an event. So many new experiences for me in such a short period of time, with high quality talks over the course of the day, but it was great to spend time talking with people about Get Invited. I loved it.

Sponsoring - Get Invited

The real highlight of the day was to be an official sponsor for the event, complete with our own exhibit that allowed Kyle Gawley and myself could demo Get Invited for attendees. We've spoken to people about Get Invited before, but never as a sponsor. We had a few minor kinks in the run up to Industry Conference, but things went smoothly on the day, and it was great to spend time speaking with people interested in using what we've built, catching up with friends working in the same area as ourselves, and talking with a represantive from a local accelerator programme.

Getting to talk with people about Get Invited was a real joy for me, and the feedback we got from people was positive. We also got input on how to work through some of the issues we’re currently experiencing. It's one of the truly great things about our industry, the openness we have and our willingness to share what we know with others. Something that Industry Conference attendees and speakers really demonstrated over the course of the day.

The Talks

There was a lot to learn at Industry Conference, and I'm sure that others picked up on things that I didn't pick up on. Below you will find my thoughts on each of the talks.

Rachel Andrew - Things Learned While Supporting Perch

Rachel was the first speaker of the day, and spoke about how supporting a product that can really help that product to grow and evolve. Interacting with customers is a way to see what they like about a service, but it also lets you see where things could be better, and where they could grow. In a world of free products it is this attention to customer needs that allows a paid-for product to stand out, simply making a good product that you charge for isn't enough.

This has really opened my eyes to some of the things that I, and my fellows at Get Invited, really need to start thinking about now. Having a great product isn't enough if people running into issues then have a bad experience. Everyone had bad experiences, and almost everyone talks about those experiences. The number of people who talk about the good experiences is much smaller, and in my own experience they also don't talk about them for as long.

In her talk she also spoke about the importance of getting the structure of supporting customers right from as early on as possible. As a product grows in popularity, the number of issues you get contacted about will too. A support structure that can't grow with your popularity is going to be a bad experience not just for the people giving support, but for those needing it. That's not a pleasant experience for anybody.

Harry Roberts - Architecting Scalable CSS

In my notes for this talk I jokingly referred to it as “Fixing Kyle’s CSS”. Kyle writes good code and good CSS, but I know from reading a lot of the things Harry writes that there is still a lot that both Kyle and myself could do to streamline things further. The talk didn't disappoint me. Some of what he wrote about were topics I'd already read from his site, but there was a great deal that I still picked up from listening to him.

I loved the idea of viewing CSS as similar to Lego. You can do so much with a single Lego set. You can make the set, but you can ignore the instructions and make a limitless amount of things with the bricks you get. And that is without mixing multiple kits together. You can achieve similar results with CSS. You could follow a guide/tutorial and make a specific thing but you could then turn around and, with that same knowledge, make something completely different.

Harry also spoke about the idea of breaking things down into components, and about the idea of having bits of CSS that do only one thing, but that do that one thing very well. You can mix and match these comonents together to make things, all without repeating a vast amount of style rules in your CSS. It's something that I try and do when I'm writing CSS but there is still room for me to improve. I think I need to focus on the idea of a Minimum Viable Component. If I have to write a few more components in my CSS, that I can then use as needed elsewhere, I don't think I'll mind. At all.

Finally he spoke about the importance of having a structure for the styles behind a site, and sticking to it. Having a structure, and a flow, to things is important. He also spoke about the idea of having a shame.css file that is where you put in temporary hacks that need to be sorted when an opportunity presents itself. I'd heard of it before, but still love the idea of it. We've got something similar working with Get Invited at the moment, as you can see in the admin panel's source code:

<link rel="stylesheet" href='http://journal.davidturner.name/"/themes/getinvited/css/last-minute-fixes-by-dave.css"' />

I plan to have that file gone within the next week.

Chris Murphy - We are Navigators

After a short break we had Chris Murphy, one of the founders of Get Invited and generally awesome guy, speaking about education in our industry. As someone who is involved, in a small capacity, with education for the web, much of what he spoke about resonates with me. His talk started with a five minute clip from the final moments of Dead Poets Society, using it to highlight the different approaches some people take to education.

The clip highlights that a good educator is able to truly help their students to grow as a person, to transform into something more. That this is something that education should be doing as, ultimately, education helps to shape the mind… an important thing to get right. Something that, sadly, hasn't been the case through much of my pre-university education. Even there it was only certain individuals who cared, or seemed interested, in the material they cover.

Chris spoke about how education isn't just about teaching, but about the ability to teach students how to learn, rather than how to do. Teaching a person how to do one thing is very limited, teaching people how to learn more about what they are doing lets that person develop, grow, and ultimately do what it is they want to do, rather than doing the one thing that they were taught to do. Education should create good people, not people good at one techincial skill.

I've studied under Chris for the last year and a half and, during this time, he has been someone who has helped me turn something that I am good at, and that I enjoy, into the beginnings of a business that allows me to get paid for doing the things I love to do. Educators could, and should, be more like this, and having gone through at least some of what he covered in his talk it serves as a further motivation for me to do what I can to help in the field of education.

I wouldn't be doing what I am doing now without help from people like Chris. Education needs more of the things that he is doing and I'm more committed than ever to doing what I can to help in that sector.

Ashley Baxter - Changing a Stagnant Industry

I'd heard that this was Ashley's first speaking engagement but there was no evidence of it from where I was sitting. Speaking of her journey from her education to running a business she had no understanding of, she delivered one hell of a talk about how she's accomplished everything she has. I can only imagine trying to get to grips with insurance, but the idea that achieving small things allows the bigger things to happen is something I have found to be very much true.

There are so many industries that have issues in them. Education was mentioned in the previous talk, and Ashley works in another: insurance. It's an industry that seems so archaic, using ancient software to operate, but that seems to be continually pushing to find the smallest price possible. Technology provides an opportunity to produce a better experience to customers, an experience worth more than the "lowest price possible" that others stive for. Good things are worth paying for.

Insurance isn't the only industry that suffers from these kinds of techonology-related issues, and an application of technology can give a new edge to comptetitors. I'd love to see more people or businesses harnessing technology to improve some of the most tedious of industries to make them better for the people working in them, and the people that use them.

I'd also like to take my hat off to Ashley for her ability to pick up Ruby so quickly. I've tried doing the same, as a developer of multiple things, and I simply cannot wrap my head around it so I have a great deal of respect for people that can make it work for them.

Noah Stokes - $50,000 Mistakes

Noah's talk covered his journey from Apple engineer through to setting up his own design studio, something that came from his lack of passion for what he was doing. A lot of what he talked about resonated with my own experiences in certain aspects of my professional life, experiences which have helped guide to to what I'm now doing professionally.

He also spoke about some of the other aspects of professional life, including something that I've heard multiple times before, that you will only get better by working at things and that you'll only ever get to do the work you want to do if you start doing the work you want to do.

Rasika Krishna - Cross-Cultural UX

Rasika's talk was an impressive talk for me, not just because of the content, but because of the fact she'd just flown in from Singapore. Her talk took a look at how different cultures can perceive a design. Many designers will, of course, be familiar with the impact of colour in a design, but her talk went a bit deeper taking a look into the principles of psychology, cultural groups, symbols, and the need for things to be a conversation when working with people.

I really liked hearing someone talk about things being more of a conversation when dealing with clients. Communication is an important aspect of things to get right, but it's also important to listen and to understand what is being said. I often find myself failing to do this. What a customer says is often worded in a way that we as designers don't get, but that makes perfect sense to people talking to us. We should learn to communicate better with customers and clients, and to guide them in ways that benefit both of us.

Oh, and the convention of naming icons in a manner such as "hamburger icon" is absurd. Can we stop that doing that kind of nonsense?

Josh Brewer - Redesigning Twitter

Josh spoke about the process used in designing the #newnewtwitter, a large scale design project encompassing all of twitter's public facing designs. He covered some of the problems they had, and some of the methods they used to solve them. He also empahsised the importance of not letting people fall into the trap of thinking design is magic. This is something I need to do a better job of handling with my own development work.

He also spoke about the importance of standardising the design tools used on a project. In my freelancing I often work with people using different tools, which is fine, but it can understandably become an issue when working with a team of people continually. Having a consistent design tool makes life a lot easier.

He also has me convinced that I need a plotter/printer so that I can attack all of Kyle's deisgn work with a red sharpie.

Jeremy Keith - What We Talk About When We Talk About The Web

Jeremy was a last minute speaker who stepped in to replace John Allsopp. Jeremy himself was the first to admit that his talk wouldn't be the same as one by Jeremy, but it was a talk that I greatly enjoyed. He broke the web down into the components that make the web work, and upon the importance of understanding how links and forms should work. It's already making me rethink a significant chunk of the functionality in the work I have been doing recently.

Whilst I agreed with a great deal of what Jeremy spoke about with regards to how links worked, that they should never perform an action instead serving to connect pages together, I really loved how he spoke with regards to making things work in the responsive web With the shift from designer-enforced dimensions to a fully fluid experience, with the rise of the smartphone, and with mobile data connections, optimising sites is even more important than ever. Some of what he pointed out I had heard about/read up on before, but some of the ideas were new, and I'll definitely be putting them to use going forward.

Community

I really enjoyed the talks and being there representing Get Invited, but the thing that I loved most about Industry Conference was the people there. The industry we work in has a great community, and I loved catching up with friends, finally meeting people I've spoken with for months on twitter, and making new friends at the fringe events that were put on over the time I was in Newcastle. I can't wait to do it again.

Styling Based on Attributes

This is something Chris Coyier has written about in the past in the past, styling elements that have certain attributes attached to them. This can work really well for providing styling defaults to mutliple classes at once, such as btn-large and btn-small by identifying that they both start with btn-.

It's possible to do more though with CSS by using content of selectors using CSS. This is something that A List Apart has covered when talking about styling things for print, showing URLs after links as a user can't click on a printed page. It's also a fundamental part of the clearfix hack that anyone on the web is likely to be familiar with.

We can do some pretty clever stuff with these two things. I've recently put it to work with regards to using icon characters from the Symbolset fonts. The CSS that they provide requires adding a lot of CSS classes to both your markup and in your stylesheet. I switched away from that to a set of Sass mixins that return characters, but it still requires that I add a chunk of CSS to my site to handle individual characters.

Then it struck me, I could switch to using an attribute on the HTML elements that I wanted to have these characters appear on. Something like this:

<a href='http://journal.davidturner.name/"/"' data-icon-standard="⌂">Home</a>

The important part of this is the HTML5 data- attribute on the link. It's got a standardised name for a specific type of character. I currently have two different attributes that I make use of:

1. data-icon-standard: I use this for characters from Symbolsets's SS-Standard font
2. data-icon-social: I use this for characters from Symbolsets's SS-Social font

This vastly simplifies the CSS I need to use to style these elements up. Previously each icon I wanted would have needed a new CSS class to add the right character for me. something like:

.home:before { content: '⌂'; }  
.email:before { content: '✉'; }
.plus:before { content: '+'; }

Add more characters to this and you can see that it could, quite rapidly, become quite unweildy. Instead I can add the specific characters to my markup, and have them added using CSS:

<a href='http://journal.davidturner.name/"/"' data-icon-standard="⌂">Home</a>  
<a href='http://journal.davidturner.name/"/"' data-icon-standard="✉">Email</a>
<a href='http://journal.davidturner.name/"/"' data-icon-standard="+">Add</a>

With this in place I can simplify my CSS to the following:

[data-icon-standard]:before {  
  content: attr(data-icon-standard);
  font-family: SSStandard;
}

This takes care of the character and sets the correct font. It might be a bit over the top for just a single icon, but if you find yourself using multiple icons over the course of a project this simplifies the addition of characters to a site quite a bit.

Let Me Know What You Think

This is something I've just started experiementing with, and you can see it on the navigation above but also in the footer below. I'd love to hear about how other people put this kind of thing to use, either in the comments on below on on twitter.

Yesterday marked a step forward for me, I've made some adjustments to the site. Some of them are quite noticeable, others are under the hood. All of it has been done with a goal in mind, that of getting me to be more active on the site.

Design

I've changed the overall design quite a bit as a part of the process of updating things, but I have maintained a consistent visual style. I look at it as more of an iteration than a redesign. What I had before wasn't bad, but I was capable of producing something better.

Text is now larger, and fills out across a larger area, the full column rather than the previous half column. A lot of what I do is text heavy, and keeping things constrained in such a small column was proving troublesome for the writing that I do.

As a part of this I have rethought how I want certain elements to appear in the design. I don't use graphics terribly often on my site, so when they do appear, I want them to stand out.

The same is true of certain other elements in my writing. In addition to images, code blocks and blockquotes are displayed across the full width of the site, though any written elements will be kept to the same width as other written content.

Development

I've also made a few adjustments to the site under the hood. I've stripped out my previous code syntax highlighter, PrettyPrint, and replaced it with the rather lovely prism syntax highlighter. It's a lot lighter, and supports (after a little work) all of the languages I write in.

This helps make things just a little bit snappier, but I really wanted to speed things up when it comes to loading content. I already cache my site, so that you're almost never loading something generated on the server side, but could I do better? Yes.

I already use jQuery on my site for certain things, which made implementing the pronto plugin an easy choice for me. Pronto allows a site to update just the main content of a site, rather than downloading the whole page each time. Smaller download, faster loading.

This required some tinkering with how my pages are generated. Pronto uses a JSON based structure to update the content, whilst the average page load will return a complete HTML page. Fortunately pronto makes the process of telling when JSON is needed quite easy.

Pronto attaches a GET variable of pronto when it's requesting a specific page. Using this I was able to determine whether or not to return JSON or HTML. I've also been able to cache the returned JSON, so everything should be pretty smooth. You can check out the pronto data for this page if you'd like.

I've also put some thought into how I'm going to be handling images on the site going forward. I'm a big fan of the adaptive images approach to handling images. Set a cookie that tells a script how large the screen viewing the site is, and use a script to process images so that the image is at an optimal size.

I've also become quite the fan of compressive images, the idea of making an image larger in terms of dimensions, but dropping the image quality right down, and then letting the browser scale the image down. This results in an image of comparable quality that is much smaller than a higher quality image would be.

I cannot overstate my love of ImageOptim. If you use images on the web, and use a Mac, you should be using this.

I've combined both of these approaches on my site. Smaller devices get smaller versions of the image, but they're still large images that get scaled down. The savings have been quite impressive. Each image on my portfolio was taken as a full screen image at 1920px by 1200px, cropped slightly, and then blown up to 200% of their original size to get a final size of 3840px by 2320px. They saved out at about 250kb, and when processed through ImageOptim this size was cut by about 50%. By contrast images saved at the original size, with a decent level fo quality, where coming in at sizes up to eight times this size. Madness!

I also managed to resolve a long standing issue with my site when dealing with the responsive versions of this site. The day before launching, ironically the day Opera announced it will be switching to webkit for their rendering engine, I managed to resolve an issue that I had been having with Opera displaying my responsive navigation.

Comments On

Finally, I've flipped the switch on site comments back over to on. I'm not sure that this will last, as spam bots seem to quite love harassing comment systems and I'm not sure that the hassle of dealing with them is worth the comment goodness I get. The quantiy of spam can get quite insane at times.

I'll likely be tweaking things over the forseeable future, and I'll be adding more content to the site as things progress. Feel free to sound off on things either on the comments below or hit me up on twitter.

Boiling Down Complexity

When trying to figure out how to get smart quotes working I spent a lot of time, probably too much looking back, in trying to find a PHP function, or library, to automagically convert quotations from the "standard" quotes to their curlier equivalents.

I couldn’t find one, and that forced me to think about how I’d go about doing it myself. Normally character replacement is easy, you would just call a str_replace() function in PHP and be done with it. The problem with quotes is that the characters I’d be searching for are the same on both sides when dealing with standard quotes, but different when you convert them to their curlier equivalent.

This caused me to consider the option of working out a way to convert every other match to the corresponding opening quote, and the remaining ones to the closing quote. This would work for double quotes, but would fail horrible when dealing with single quotes, courtesy of apostrophes.

In the end I was able to implement a solution courtesy of Tami Olsen who, as an author, had encountered similar issues in Microsoft Word. She suggested a solution that boiled down to looking for quotation marks with a space before or after them. A space before denotes that it is an opening quote. A space after denotes it is a closing one.

This, with a small number of edge cases that can also be processed, leaves remaining single quotes as apostrophes. I wrapped this up in a simple function and pushed it out to Get Invited. It worked perfectly. The code looked like:

function smartQuotes($str) {  
  $search = array(
                ' \'',
                '\' ',
                ' "',
                '" ',
                ' “\'',
                '\'” ',
                ' ‘"',
                ' "’',
                '...'
                );

  $replace = array(
                ' ‘',
                '’ ',
                ' “',
                '” ',
                ' “‘',
                '’" ',
                ' ‘“',
                ' ”’',
                '…'
                 );

  return str_replace('\'', '’', str_replace($search, $replace, $str));
}

Not Issue Free

After building this into Get Invited I was quite pleased with how it looked, and it vastly simplifies issues with getting smart quotes into written text, as the shortcuts for curly quotes aren't nearly as easy to remember as the commands for the more commonly used characters. So I coded it into my portfolio.

It broke things. Pretty badly. What was causing it to mess up? There's one difference between how Get Invited uses this function and how my portfolio does, and it's a major one. Get Invited only processes text using the function, but my own site uses a basic templating system and the function made changes to the whole template.

This would include any HTML that was included, in particular HTML attributes, which would then cause certain important aspects of my site, such as classes, to stop registering correctly.

I was able to find a workaround for this, though I'm not as happy with it as I would like to be. In order to resolve this issue I needed to add two regular expression filters to find text inside of HTML tags, in order to find the attribute quotations. I was then able to replace any text that had been turned into curly quotes in error back into the intended quotes. The final function looks like this:

function smartQuotes($str) {  
  $search = array(
                ' \'',
                '\' ',
                ' "',
                '" ',
                ' “\'',
                '\'” ',
                ' ‘"',
                ' "’',
                '...'
                );

  $replace = array(
                ' ‘',
                '’ ',
                ' “',
                '” ',
                ' “‘',
                '’" ',
                ' ‘“',
                ' ”’',
                '…'
                 );

  $str = str_replace('\'', '’', str_replace($search, $replace, $str));
  $str = preg_replace('/<([^<>]+)>/e', '>' . str_replace("”", '"', "$1") . '<', $str);
  $str = preg_replace('/<([^<>]+)>/e', '<' . str_replace("’", "\'", "$1") . '>', $str);
  return $str;
}

It works, but I feel that it could be better. I'd love to hear if anyone has any thoughts on how to improve this code, or alternatives that people have used in the past. You know where to find me.

It doesn't need to be this way, turning an idea into something tangible can be relatively quick, and the rewards for doing so can be immense. It allows you to test the idea, and determine its worth. It can weed out the bad ideas and help improve the good ones.

This is something that Chris Murphy, Kyle Gawley, and myself have done with Get Invited. We quickly built it up and used it earlier in the year for the University of Ulster's Festival of Art & Design, encompassing a whopping 23 events.

It was something of a trial by fire for the service, and for us, but it ultimately demonstrated the viability of our product, and was a sign that we were onto something. The project was able to progress as a result, rather than remaining an idea.

Without pushing ourselves to take our idea and make it real, we wouldn't have a product, and we wouldn't be ticketing for next week's Refresh Belfast. How did we get here? By not trying to be perfect before shipping.

Perfection is an Impossible Goal

It's impossible to create the perfect product. Perfect for what? Perfect for who? You can't please everybody, so you need to identify a market and work towards perfection for it. You aren't working to achieve perfection, but it helps provide direction.

Get Invited is designed to bring ticketing back to its very core. Getting tickets from the hands of you, an event organiser, into the hands of people that want to attend your events. No clutter, and no barriers.

This allowed us to strip away a lot of what other event organisers seem to be building in today, and to focus on the core of making ticketing great. It's simple, it's fast, and it doesn't ask for all of the personal details of your life. We started with the basics.

Good Enough is Good to Go

Get Invited isn't finished, it's not all we plan for it to be. It certainly wasn't when we first shipped it. What we shipped was very much a Minimum Viable Product, but that comes with a couple of key benefits:

1. It makes the project real.
2. It gets you feedback.

The former is a psychological thing, it lets you know that you've made something, because it's out there in the wild. The latter is much more important, it will let you know if what you've made is worth continuing. Having that conversation early can be a major time saver. If your project is a dud, you can stop there and invest your time in other projects.

Shipping a project will get you feedback that will help you improve what you're working on. That's right, improving. Once you've pushed a project live it doesn't just sit idly, it adapts and grows. Sometimes this is based on user feedback, but often times it's based upon internal decisions to improve or tweak aspects of what you are working on. These changes wouldn't be possible without shipping for two reasons:

1. You'd have no feedback.
2. You're guessing how your project will be used.

You can't make changes based on user feedback if you don't have any users. You simply can't. If you're working on a service, such as Get Invited, you also cannot know exactly how people will use your product.

An example of this happened with Refresh Belfast this week. Their event title made use of some quotes, and when it went live we all realised that it would be much nicer if they were converted to 'Smart Quotes' rather than the standard quotations around the text.

It is unlikely we would have encountered this issue without actual usage of Get Invited, and it has helped us to improve the service (and also my portfolio, expect a post on the code in the near future) as a result.

Shipping Makes It Tangible

This is all a long winded way of saying that if you don't ship your idea, then the idea doesn't mean anything. An idea is intangible, you can't hold it and you can't demonstrate it. It's harder to improve something you can't see. Pinning it down and building it makes it a tangible, real, thing.

There are people who are blessed with brilliant ideas, and gifted with the ability and the technology to be able share their ideas with a global audience. For some people it takes them a while to realise the benefits of getting things out there, but once they do they’re finally able to create their ideas, make them real, and share them with the world.

Don't bottle your ideas up. Just. Fucking. Ship. It.

Credits

The image used at the beginning of this article is taken from Andrew Power's Dribbble shot of a poster design, Real Artists Ship, which he made available as a wallpaper for download. His work is awesome, you should check it out.

In my original article on the project, I discussed the thought process behind it and how I took it from being an idea to being the web app that you can make use of today. I didn't really talk about how I built it, or any of the technical aspects of it.

Let's remedy that.

Goals

Every project has goals. The development of Simply Written was no different. The goals in this particular project were:

1. High quality output
2. Simplicity
3. Gets out of the way

Each of these goals impacts the work in some capacity.

High Quality Output

This goal serves as the bedrock of Simply Written. It's why I started the project. Digital books were being mangled by automating the process of digital book creation. Simply Written needed to get this right, otherwise it just contributes to the problem.

Simplicity

Simplicity in a service is difficult to get right, and is one of the key principles I have identified that help my work make people happier. Simplifying a process doesn't mean dumbing something down, it means removing complexity. I don't want users to have to jump through hoops and perform tricks in order to create.

Gets Out of the Way

This goal goes hand in hand with Simplicity. I don't want Simply Written to require hand-holding. I don't want the service I built to get in the way. It shouldn't be a tool that holds users back from creating. Microsoft Word can do that, I don't need to.

Problems

Simply Written's inspiration comes from a problem I encountered: Digital Books aren't being generated in a manner that provides a quality product. That serves as an encompassing problem, but it's not really a solvable problem as there are components that create it. To me, the problems are:

1. Content output quality sucks
2. Generating multiple formats

Content Output Quality Sucks

This is closely related to the original problem above. Digital books being generated quite often are sloppily done. They're being created from content aimed at being printed, and the end result suffers for this¹.

In addition the best of the digital book formats, ePub, suffers from such automation as there is no way to identify break points that could be used to create high quality ePub files. I'll talk about this later.

Generating Multiple Formats

As mentioned above, converting from a format meant for print to a digital format is messy. Doing the same for multiple formats isn't going to be any better. It's important to ensure that all the output formats are of a high quality. If it's not something I would be proud of, I don't want to make it available.

It's also important, to me, that content isn't converted between the different formats. The content should be slotted in to them. Conversion of content rarely ends well. I don't want to see that happen to content in Simply Written.

Having a System

I didn't just throw myself into building the current version of Simply Written. I did that for closed testing and, whilst it worked, it wasn't as good as it could have been. I was able to build upon some of what I learned during closed testing, along with other work I have done. The key things for Simply Written were:

1. Use a Framework
2. User Authorisation and Security

Use a Framework

Having a framework in place allows me to get the ball rolling quickly. Over the last two years I have been using/developing my own framework, called the Wee_ Framework², that provides a basic shell for web apps. It also provides me with a great deal of flexibility.

It's something of a Model & View framework, with a single file controlling what is loaded. I've tried many of the common MVC frameworks out there and the have always felt that they do more to get in my way than help me get things done.

User Authorisation and Security

Any service that handles user details should have this on the top of their "Get This Shit Right" list. Sadly it seems that not every service out there does. Ever since I started work on my first web app, ReferenceIt, I have worked to ensure that user information is secured.

The majority of information that I store is encrypted. Email addresses and passwords are stored in such a manner that if the system is somehow compromised that the information accessed is rendered useless. The only person who will ever know a user's password is the user. The way it should be.

Building a System

As mentioned above I didn't just build Simply Written, I thought things through to ensure that what I built would be of high quality. This required an understanding of what I wanted the site to have, and how I wanted the site to be.

The closed testing of Simply Written served as the first test for identifying the structure required for the service. Some of this was obvious, as there would have to be a user-only area. For the current version I was able to build on this to create a more fully formed structure.

Registration

I wanted to ensure that the process for registering for an account would let those who register immediately start writing. As a result the registration process asks for a decent amount of information, more than I would normally ask for. The information is important though, it is used in digital book publishing.

Every book has an author, every author has a name. Every digital book needs a method to create a unique identifier for a book, and the username allows this to be created with ease. Every account requires an email address and password to login, as email addresses are easier to remember than usernames.

Book Setup

With the information users provide on registration I am able to let them immediately start creating books. Digital books require a great deal of information, but getting started requires only one thing: a title. With that anyone can immediately start writing.

There is a collection of extra information available that is hidden from view. It's important information but isn't necessary for a book to be generated, and is all optional. Some of the more useful information is pre-populated at this point, but all of this information can be edited at any point.

Once a book has been created an extra piece of information can be added, a cover for the book. This isn't available when initially creating a book for technical reasons, and book covers are organised based on information about both the author and the book. The information needed to save the cover isn't available until the book has been created.

Users will also note that books are listed on this home section in order of most recently added. This sidebar allows users to re-order their books as they see fit. It can also be used to delete entire books if necessary. Obviously, deleting a book will delete all the chapters it contains.

Chapter Creation

Once you have created your book, you are taken to a book edit view. The structure is similar to that of the create book page, but with two notable differences:

1. A book cover can now be added
2. The sidebar now lists chapters, not books

The sidebar will adopt this view when you are handling a single book, allowing a user to quickly switch between chapters as necessary. As with the books, it is also possible to re-order and delete chapters as they desire.

Having just created a book, there will be no chapters created just yet. In place of a list of chapters will be a note letting the user know that there aren't any chapters, asking them if they would like to create one.

Creating content for chapters is much like writing content using Microsoft Word, or popular Content Management Systems like WordPress. I want to provide the best experience possible and doing this can involve providing a familiar experience. Not everything needs to be re-invented to provide an improvement.

Providing a High Quality Structure

The goal of simplifying the process of digital book creation isn't an easy one. Simplicity isn't an easy thing to achieve, there needs to be a solid structure in place to ensure that simplicity doesn't turn out to be a dumbed down process. It is important to ensure that you get this right from the start, as it can be very difficult to go back and fix this later without scrapping things.

To get books right there were two key areas that I needed to think about, and ensure that I handled them properly:

1. Content management
2. Output formats

Content is key to any form of book, printed or digital. If you handle content poorly or, worse, fail to store it properly then Simply Written would not be a service people would care for. Ensuring that content was handled appropriately formed one half of the puzzle I needed to solve.

The second half was the formats that digital books are typically formatted in. There's a small collection of key areas to get right: ePub, mobi (Kindle), and PDF. To provide a service that does justice to users, I needed to build a system that would allow Simply Written to provide these formats.

These areas formed the basic issue that I felt needed to be solved, that of allowing users to write content once and be able to publish it in the multiple digital formats required. How did I go about solving them?

Content Management

Solving the issue of content was one I put a lot of time into. It forms the basic inspiration of creating Simply Written. Taking a book formatted for print and trying to create a digital edition wasn't working.

Similarly I didn't want to take a book formatted for ePub use and try to and wrap it up as a mobi file. It wouldn't work, and if it did it would be poorly done and deliver a sub-par experience.

The solution to this problem came from looking at what these formats had in common. HTML is the underlying structure of the web, and digital books have a lot in common with the web. Content written in HTML would fit perfectly into both ePub and mobi formats, and PDF files can be easily created from HTML. I had a winner.

Formats

Handling digital book formats can be tricky. What works for ePub might, sometimes, work for mobi and PDF plays by a different set of rules entirely. As I mentioned in the original Simply Written Beta Launch, ePub and mobi files have a lot in common when it comes to building them.

An ePub file is essentially a zipped up collection of files and folders. The book's content is saved as XHTML files, it's styled using CSS and there are a collection of files that handle information about the book. It can be a bit messy when you dive into it, but as you progress things start to make a lot of sense.

To provide the best experience it is also important to properly separate content in the book. The most suitable manner to do this is by chapter. The reason for this is to provide a better experience for people reading the content.

To provide an example: If someone is reading a book that isn't split, digital book readers need to load content from the start of the book. This is fine when someone is starting a book. It's not so great if they're five chapters in. Then they have to wait.

Splitting a book into multiple smaller chunks allows the reading software to start from a more suitable start point, such as the beginning of the chapter the person is trying to read, and then load in extra content as needed.

A finished mobi file is rather mysterious, as it's a proprietary format owned by Amazon. There are tools you can use to extract the content from mobi files but don't. It's a terrifying and scary thing to look at³.

Fortunately you never need to look inside of these files, as the same structure you would use to create an ePub file can, with a few adjustments to some of the files that store information, be used to generate mobi files.

Some considerations need to be made for some files though, as all images are processed into mobi friendly content and, if you have any PNG files with transparent areas in them, the end result of this process is not a pretty one.

Generating Digital Books

Every part of Simply Written is important, but if any part serves as the cornerstone of the project it is the book generation process. Making it easy for users to register, create books, and write means nothing if the end result is of poor quality.

It should come as no surprise then that this is the part of Simply Written that took the longest to implement, and is the most tweaked part of the service as I continue to improve the quality of the content generated here.

To ensure that each format available (currently ePub and mobi) is of the highest quality, each has a separate book generation system. This means that I can optimise ePub files separate from mobi, and vice versa. The same will be true as additional formats (namely PDF) are added.

Each of these formats has slightly different structures and needs. Simply Written's book generators cater to these. They also deal with some of the more fiddly aspects of content styling for the various formats. The mobi format isn't nearly as flexible as ePub when it comes to CSS support, I do what I can to provide a consistent experience where it is suitable, and embrace difference when it's appropriate.

Moving Forward

I have put a great amount of time and effort into Simply Written to date, but there is still room for growth. At the moment there are three key things I will be implementing in the future:

1. PDF format
2. Image support
3. Charging a Fee

PDF Support

Of the three key formats for digital books, I currently handle two. The third, PDF, has proven to be a bit trickier. It's not that I have difficulty generating them, that part is surprisingly easy. The difficult part is generating PDF files with a quality of design that I expect from books my system will provide.

I'm a firm believer in not releasing a product until it is at a level you are happy with. PDF will happen, but only once it is of a high enough quality.

Image Support

So far I've added support for book covers to Simply Written. They're a bit easier to implement than images in a book's content, as I have more direct control over how a book cover is used. Graphics in the book's content become trickier to manage, which is why they're not included just yet.

Again this is a case of not wanting to implement something that isn't ready for use. I want it to be usable when it's implemented, not a mess.

Charging a Fee

Money makes the world go round. It pays for important things, like coffee, electricity, and internet connections. It also covers things like rent, travel, food, and hosting. I want to make things better for people, and that includes for myself.

By charging for the usage of Simply Written I am able to ensure that the service remains available, and it further motivates me to continue working on it. If I can't afford to keep a service running I won't, so it's in the best interests of everyone that uses the service that it's profitable.

Lots Done but More to Do

Simply Written has come a long way recently, but there is plenty more to be done. I hope to be able to dig a bit more into some aspects of what Simply Written does in the future, looking more closely at some of the technical aspects of the site.

Further Reading

• Introducing Simply Written

Footnotes

1. This really shouldn’t be tolerated in any aspect of content management. Trying to convert a poster into a web page doesn’t work. Why would anyone think it would with books? ↩

2. Wow, it’s hard to believe I started work on both Wee_ CMS and this framework two years ago. Time flies sometimes. ↩

3. Interesting note for the developer folks out there. Simply Written’s codebase weighs in at 23.4MB, the file that Amazon provides for creating mobi files weighs in at 20.5MB. Yikes! ↩

Sharing things online is great, but putting content up online isn't always the best medium for sharing. There are alternatives, most notably digital publications. They have a lot in common with online content, but creating the formats for them can be troublesome. I'd like to change that.

Meet Simply Written

Simply Written is a project I've been working on for quite some time now. The idea first appeared in the autumn of 2011, and the first real “demo” cropped up in January before it took a back seat to other projects. Last week I took the time to resolve this, and I feel it's now ready for sharing with the world.

At its core, Simply Written exists as a service, a system, to allow authors and writers to create content that can be wrapped up into multiple book formats with ease. Right now it works with ePub and mobi (Kindle uses the format) but I intend to add PDF support once I figure out the best approach to doing so.

In my experience most digital books aren't created, they are converted. This leads to sub-par books, as machines aren't good enough to get the conversion process right. We could sit and wait for them to become good enough, or we could use something that works now. You.

Simply Written uses you, as the author of your content, to work out how content should be structured. It processes what you write into a format that can be used in any of the popular digital media readers. Rather than converting content, it processes it, wrapping it up in the relevant code to make an ePub file, or a mobi file.

How?

Simply Written takes a complex process and simplifies it. It's actually not that difficult to create an ePub file from static HTML content. Working with mobi files is a bit trickier, there's some extra bits needed and some that need removed, but the format can be generated from the same content as an ePub file.

It is, however, tedious, and it takes up time. That time could be better spent writing, or having fun. So Simply Written takes the tedious parts of book creation and leaves you with the most fundamental area of digital book authoring, the authoring part. You create your content, and Simply Written will handle the rest.

Why?

Over the course of this year I have really grown to enjoy writing content, content that I believe is good. I have always enjoyed sitting down with a good book and getting lost in it. With the shift towards digital, and being able to carry a whole collection of books in my iPad, I have embraced digital books quite happily.

Unfortunately not everyone creating content has embraced it as much as I have, and many that have embraced it create sub-par versions of their printed books. I witnessed a few tweets about books published by Penguin, showcasing how badly structured the content was. I witnessed it first hand with one of Tami Olsen's books.

I owned a copy of her printed books, and really enjoyed them. Unfortunately the experience with the digital books wasn't nearly as good. They weren't responsive, I'd say they were sluggish. It made reading them less than enjoyable. A painful side effect of converting a PDF file into an ePub file. The result is sub-par, which frustrated me when trying to read them.

From Frustration to Prototype

Books deserve to be looked after regardless of the medium, and I decided to do something to prevent as many of these stories as I could. Over the months of November and December I pieced together a prototype that could be used for content authoring. It supported text-only content, and no covers could be added. It worked.

From the very start I knew that supporting the open format of ePub was vital to Simply Written. I also knew that supporting kindle devices would be important, as Amazon is a powerhouse in the sales department. I invested time in ensuring that these formats were crafted in a way that was valid, and provided a high quality of content.

With the structure in place I turned my attention to creating a platform for the actual authoring. Having a solid system for creating books means nothing if people don't have an enjoyable writing experience, as they won't use it. Sadly at this point my university studies, and work on Get Invited took over my life, and Simply Written became a lower priority in my work schedule.

From Prototype to Beta

This changed last week, when I decided I was going to undertake a solid week of development on a single project, and take it from where it was already to something I could share with the world. Simply Written was the obvious choice. It had sat neglected for too long, and I already had a solid idea for what I wanted to achieve.

The week consisted of a complete redesign of the site, and a major overhaul of the codebase. I've pieced together the key tweets I sent marking progress throughout the week in this storify story. All told, the week consisted of:

• Site design overhaul
• Site architecture overhaul
• Better book details
• Better authoring functionality
• Support for WYSIWYG and markdown editing
• Chapter and book organisation
• Chapter and book deletion
• Book cover support
• Inclusion of important book pages:
  • Title
  • Copyright
  • Dedication
  • Epigraph
• Improved book generation suporting new book features
• Account settings
• Allow chapters to have headings removed

Looking at that list is actually rather overwhelming, it's amazing what can be achieved in a short space of time if you break things down into smaller parts. I wanted to work towards a solid goal, of allowing for book creation, and the above list matches nicely with that goal.

It's not the final goal for Simply Written, as it doesn't allow for the addition of images inside of chapters, something that is beneficial in many types of content. Thus far Simply Written also lacks PDF generation. I realise that this is something that is needed but I don't want to add functionality until I am confident that it will meet user expectations. I will work it out though.

Beta Launch

I've had a few quieter launches of Simply Written, largely due to needing to show off progess during the last two semesters of university. Today marks a more public beta, as I feel that things have reached a level of stability and quality that I can open things up to a wider audience.

Today marks the public beta launch of Simply Written, and I invite you all to register and try it out. Try things out, make some books, and if you break things please hi@davidturner.name">let me know.

First Steps

Simply Written is only just starting out, but it is already being put to good use. I mentioned earlier that I encountered a sub-par experience with one of Tami Olsen's books. As much as she is an author, I also view her as a friend, and I believed that her books deserved better than they had received.

As a result of this I have been working with her to provide copies of her books in both ePub and mobi format that she can sell online. Those books are now ready for her to sell, and she plans to via both the iBookstore and Amazon. The book is now available on Amazon, both in the United Kingdom and the United States. Once they're available on the iBookstore I'll update this post with links there too.

The Goal, The Future

The goal for Simply Written is to allow authors to follow in Tami's steps, to author content that they can then sell online. To facilitate that there are some features that I want to add, but over time, so that I can get Simply Written out there. Iteration allows me to add new features as things progress and lets me get people using things now. Things I plan to add in the future:

• Adding images to chapters
• Multi-author support
• Billing for the system
• Book promotion system

I currently plan to charge for the service, but that's it. You get your books from Simply Written and any profits you make are yours. I don't have any plans to sell content directly from Simply Written, I believe that there are already services out there for handling that. I do want to provide a means to promote content authored using Simply Written.

Check It Out

To close, I'd love it if people would check out the beta. Write books, follow Simply Written or myself on twitter, and let me know what you think.

What Have I Done?

In the original topic laying out my plans for 2012, I covered several key areas that I wanted to focus on. In this post I thought it would make sense to maintain a similar structure. It makes things easier to measure against the original goals.

Education

2012 has been a year of split personalities on the education front, as I have found myself on both sides of the table. I have been a student on the MA course, but I have also been on the teaching side of things on the Interactive Multimedia Design Degree. It's been weird. It's been great.

On the student side of things I have received my marks for the first year of the course. I was pleasantly surprised with my marks, which placed me just shy of my goals for the year. This is in spite of a terrible apathy that swamped me in the week leading to deadlines for the year. This has obviously impacted my marks, but hasn't thrown things off balance as much as I had expected.

On the teaching side of things I greatly enjoyed my time with the first year Interactive Multimedia Design students, and will be expecting great things from them over the course of the next three years.

I am still unsure of my future in a role as an educator. With the final semester of my time on the MA drawing near I will need to focus on my work for it, but in the future I could see myself returning to this role in some capacity if it were an option.

Professional

As with 2011, this year has proven to be pretty packed with work to get done. Being a full time MA student really pushes you to be the best that you can be. It's helped me to really push forward with a web based ticketing system, Get Invited, alongside Mr Murphy and Mr Gawley.

This serves as the first step towards one of my goals for the year, to set up a business alongside Kyle. We have individual projects, ReferenceIt and Vizuali, but this is the first solid step towards meeting this goal.

The second key area I identified in my previous article was that I wanted to network more. I feel that I have, thus far, been modestly successful with this but I also feel I could do more. Baby steps.

I have also met my goal of starting to take a more active role in events, having spoken at Creative Camp 2012. Whilst it's only a single event thus far, I really enjoyed it and want to do similar things more often in the future.

One final area I discussed back in December, though in a more general manner, is the topic of writing. I wanted to write more. This is a goal I have made progress on, but have only recently really settled into a rhythm with. I have set myself the goal of writing an article a week, with the aim of publishing a post every Wednesday.

Having settled into this rhythm I have decided that I wanted to up my game. I used to do sketchwork, and I greatly enjoyed it, but I don't have the time for it that I used to. Now, with each article I write I have a secondary goal, that of producing a piece of artwork for each post. So far, so good.

Personal

Matters in my personal life have probably been the area in which things have least improved and, in some cases, have taken a turn for the worse. I have, to a limited extent, made progress regarding a balance between professional and personal lives. Unfortunately this currently seems to be an on/off switch, where I'm either working lots or not working at all. Not the best of situations, but it's still a start.

Money hasn't been as free flowing as it has in previous years, which has impacted my ability to travel. This is unforunate for a great many reasons, not the least of which because it served as an opportunity to get away from things and get some, almost always, much needed down time.

Exercise continues along at the same pace as it always has. It's better than nothing, but I still feel that this could, and should, be improved on. A starting point would be to work the mornings elsewhere, and walking to/from the location. Simply increasing the quantity of excercise would serve to improve matters.

Reading has improved. I tend to go through bursts of reading, consuming a handful of books in a few nights before taking a break. It's an enjoyable cycle, but I feel that I am still not reading enough.

Misc

Sadly nothing has changed with this aspect of things. The twitter handle @davidturner sits idle, three years of seeming inactivity and all. Which is slightly infuriating, but I'll continue to keep an eye on things and, if it ever becomes available, you can bet I'll be snapping it up.

Another Six Months

On the whole I think things have improved, but I dislike that some areas have stagnated or suffered in the first half of the year. It looks like I'll be upping my game in the second half of the year.

CSS & JavaScript

These are fundamental building blocks of the internet, alongside HTML and CSS adding visual effects to sites and JavaScript adding additional functionality and interaction to sites. As a result it isn't all that hard to see them becoming quite large files. Which isn't really ideal.

Whilst CSS and JavaScript are entirely different types of content, and are written differently, the approaches to optimising them overlap and, in some cases, are identical. The guidelines I follow are:

1. One CSS file, one JavaScript File
2. Always place CSS before JavaScript
3. CSS goes in the <head>, JavaScript before </body>
4. Compress and Minify content for deployment
5. CSS Preprocessors are awesome

As with all guidelines there are exceptions that I afford. I'll cover them in the relevant areas below.

One CSS File, One JavaScript File

I default to using a single CSS file and a single JavaScript file. This provides a maximum level of efficiency when it comes to loading. One HTTP request for CSS, one HTTP request for JavaScript and then we're good to go.

The big exception to this is when using a CDN (Content Delivery Network) to deliver JavaScript Libraries. These files generally aren't that small, and by using a CDN you can help mitigate some file loading times.

How? A CDN is a way to deliver certain files quickly in a global manner. If you're in Europe you get the file from Europe. The same is true in the Americas. But, better yet, these files are cached. So if someone else uses the same CDN as you to serve the same JavaScript file as you then the user doesn't have to download the same file when they visit your site. They have it already.

In addition to that it also lightens the load on your own site, as you're not having to serve a larger file that includes whichever library you're using.

Always Place CSS before JavaScript

JavaScript files block the rest of a site from loading. Whilst there are instances where this is fine (I'll touch on this in the next area) you always want to have the CSS ready to go when the body of a site is rendering. The alternative is that your site looks sloppy, as if you don't care about your users. That's never good.

Little things like this don't seem important, but can have unforseen consequences if you don't properly consider them. Which leads nicely to the next point.

CSS goes in the <head>, JavaScript before </body>

The order of files is important in terms of page loading and rendering times. JavaScript will, for the most part, block content beneath it from loading. This can cause pages to appear to be slower loading. So we want to ensure that doesn't happen.

An example of this in action is a project I worked on over a year ago, called ReferenceIt. There are a few key things to note. The first is in this cut down version of the <head> element:

<head>  
  <link rel="stylesheet" media="screen" href='http://journal.davidturner.name/"https://referenceit.org/-assets/css/site.live.css"' />
  <script src='http://journal.davidturner.name/"//cdnjs.cloudflare.com/ajax/libs/modernizr/2.5.3/modernizr.min.js"></script>' </head>

There are two things of note here. A single CSS file and, what's that, JavaScript? In my <head> element? Well, yes. Which leads to my first exception to this guideline. HTML5Shiv and Modernizr need to be in the <head> in order to get Internet Explorer to understand HTML5 elements.

If we carry on down the site we'll see that there's some more JavaScript waiting for us:

  <script src='http://journal.davidturner.name/"//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>'  
  <script src='http://journal.davidturner.name/"/-assets/js/site.live.js"></script>' </body>

This is the real JavaScript that's running on the site, and it's left until the very end of the site. This lets the rest of the content on the site load as quickly as possible before layering extra functionality on top of the site. This lets the user get straight to using the site, without waiting on things to finish downloading.

Compress and Minify Content for Deployment

There are really two different stages to a site. Development of the project and the live version of a project. Each has it's own nuances that need to be taken into consideration. For instance, when developing something you want to be able to quickly identify what is causing problems if something goes wrong.

By the time you're launching a project such problems shouldn't exist, which affords us the ability to make some savings in terms of space. We do this using the wonderful technologies of compression and minification.

I'll stick with the example I used above, ReferenceIt. You saw in the footer there was a reference to a file called site.live.js. You can view it here. As you can see, it's pretty clustered together. I didn't write this file. The file I wrote can be viewed here.

There's quite the difference in looks, isn't there? This is a principle I apply to both my JavaScript and my CSS, though it's much more effective with JavaScript as when minifying variable names can be reloaded. What does my CSS look like then? It looks a lot like this, though it starts out quite differently.

Why do this? The savings in terms of file size can mount up. The JavaScript I use isn't that large, but by serving it as a compressed and minified file, I make a saving of about 20-25%. Think about how much space could be saved with larger files.

Compressing and minifying JavaScript is simplified greatly using tools like CodeKit and LiveReload. CSS is a bit more fiddly. Compressing it, natively, usually requires a bit more in terms of manual effort. There's an alternative though, which I'll cover below.

CSS Preprocessors are Awesome

I mentioned above that the CSS for ReferenceIt starts out quite differently. That's because I didn't write it as CSS at all. Instead I used a language called LESS, a language that builds upon CSS but is compiled into the CSS that browsers know and love. Nowadays I use SASS/SCSS, but the principles remain the same.

Preprocessors allow you to us a load of fantastic things in addition to the CSS you know and love. The biggest features for me:

• Automatic CSS Compression
• Usage of Variables
• Mixins

Automatic CSS Minification

This is probably the biggest win for me. I can write CSS that is perfectly human readable and have it compressed into the file I want to be served to browsers. This makes tweaking things nice and easy too. Save, upload, done.

Usage of Variables

Variables are handy for a lot of things. I mainly use them to store colours and dimensions, which allows me to quickly change the layout or design of a site by changing just a few elements of code.

Mixins

Think of mixins as functions and you're pretty much there. Rather than writing multiple lines of border-radius CSS you can just call a function and have it work it all out for you. I use this with great results in 960-LESS, a flexible grid framework I now use in SCSS.

There's More

I couldn't do preprocessors justice in this post, there's too much to cover for it to be just a part of a larger topic. Chris Coyier has done a great series of articles on this topic however, and they are well worth a read:

• Musings on Preprocessing
• SASS vs. LESS

And That's A Wrap

I wanted to take a bit of a more in-depth look at ensuring that everything that can be done to save in terms of file space has been done. It's important to get this aspect of things right before I talk about the next area of how to optimise your site, which will be dealing with caching of files and a few other technical areas which go hand in hand with caching files.

As always your comments are appreciated, both below in the comments area and on twitter.

Images

Images are a tricky beast to tackle, especially when it comes to getting things 100% right. But there are steps we can take to ensure that we have done all that we can, even if it's not perfect. In a way it mirrors how the internet is itself pretty awesome, but still not perfect.

So when it comes to dealing with images where do we start? The three key areas I'd look at are:

1. Image Dimensions
2. Image Compression
3. Image Sprites

Image Dimensions

The larger an image is in terms of dimensions the larger the file size is going to be. It's an exponential growth too. A 100px by 100px image is going to be roughly a quarter of the size of a 200px by 200px image. It's a quarter of the size, both in terms of pixelage and size.

So don't use an image that is larger than it needs to be. If you're displaying an image at 300px by 200px then ensure the image is that size, not 600px by 400px. To highlight this I'm going to make an example of one of my partners in crime, Kyle Gawley.

On Kyle's portfolio site he has four images. Each one of them is scaled down by default (Note: Caveat down below). The images he uses for his latest work are scaled down from 400px by 200px to 288px by 144px. It's not that big of a difference in terms of size, right?

There is a difference though. Of the two versions of the Vizuali the largest is 11KB in size. The smaller graphic, which is the size at which the image is actually rendered, is 8KB. That's almost a 30% saving just for using a version of the image at the right size.

Take that 30% and multiply it by three images, and you can see that the savings can mount up. Every KB cut out is a slightly faster loading time. These savings can really mount up on the more graphical sites out there.

There *are* exceptions to this, as there are with everything. In the case of Kyle's site the images are rendered in full size, but only at certain breakpoints in his responsive design. This initally slipped past unnoticed. It serves, quite nicely, to re-enforce that these serve as *guidelines*. Once you understand them you can choose to break them.

Image Compression

Whilst cutting down on the dimensions of an image cuts down on the file size, we can go further. I touched upon the importance of compressing content last week, but spoke only in general terms. Let's get a bit more specific shall we?

The comparison I listed above of the two versions of the Vizuali image has been run through ImageOptim, an application that does all that it can to cut down on image file sizes. I've also taken the liberty of preserving an uncompressed version of the image so you can compare the two.

I don't pretend to understand the magic that makes software like ImageOptim work the way that it does, but a 16% saving on a 1000px by 300px image isn't something to be scoffed at. Again, even the smallest savings mount up, and it all comes together to create a faster site.

Image Sprites

Image sprites are worth considering only if you are using a lot of smaller graphics in a site. You don't want to be combining a series of photos into a sprite, but if you're using image based icons then it's something to think about.

Why would you do this? As it turns out it's better for a couple of reasons, which Chris Coyier talks about in more detail over in an article on CSS Tricks. But at a basic level the final image is smaller and it results in less HTTP requests.

Every HTTP request takes time as you're communicating with a server, waiting for a result, and then transferring the data so it can be displayed. The more requests you make the slower things can get. So if you can remove some of them by using an image sprite, it's worth doing.

The hardest part of using an image sprite is creating them. Back in my day you could spend days wrestling with pixels to get things just right. Forunately things have changed since then, and they've changed for the better.

When it comes to working with sprites my best advice is don't. Not until you've finalised the design. Changing sprites isn't a pleasant experience, and is one I would recommend avoiding. When you've finalised a design, use a tool like Sprite Cow to piece together all the images you need and help generate all the CSS you'll need.

What more could you want from a tool?

Image Alternatives

Not everything needs to be an image these days. Web technologies are continually evolving. And the people that use them are crafty devils. We have @font-face allowing for the use of fonts in the place of social icons, the advances in CSS3 allow you to combine images with CSS to create awesome results, and advances in browser technologies allow for increasing use of alternative technologies in place of standard images.

A lot of the alternatives are really widely supported, and those that aren't usually degrade in a way that doesn't completely ruin things. It really is a great time to be working on the web. I want to talk breifly about the following:

1. @font-face
2. CSS3
3. SVG

@font-face

Font face has become highly popular of late, with plenty of services such as typekit providing access to an ever increasing amount of fonts we can use online. The fonts can be used for more than just body text and headings. They can be used to create simple icons.

Above is a snap from a concept I'm tinkering with for a client site I'm currently redesigning. The icons for Facebook, Twitter, and YouTube are all icons displayed using @font-face. They've been put in place by some CSS to ensure that they make sense to users that are using assistive technologies. The icon is added to text that is currently hidden from view.

That is just one example. Think of how many buttons are used in services like email, or any other online system you're using. Quite a few of them use image sprites for these graphics, which is fine. But it's possible that they could be better if they looked at using an icon font instead.

CSS3

CSS3 has brought a lot of new things to the stylesheet. Many of them were only previously available if using images and a lot of dirty hacks. Lots of images in a great many cases. The power provided to us by these advances is immense.

BonBon Buttons provides a glimps of what is possible. An extreme case, but an amazing one. As recently as a few years ago these kinds of buttons would only have been possible using images. But these are pure CSS. Amazing.

Of course the power of CSS3 goes far beyond the ability to style buttons nicely. You have an immense set of tools at your fingertips that, if used well, can create amazing effects. The key is, and has always been, in consideration of when and how to apply such things.

SVG

SVG is one of those languages that has been around for a long time, but it's really starting to see some love on the internet. I'm not sure that I can really do SVG justice, as I am only just getting to grips with it. It allows for vector image use on the web without loading an image, as SVG is an XML based language.

The above is a mix of some CSS and a chunk of SVG. I used SVG for the bottom part of the join, the transparent white block with a semi-circle removed from it. I tried using a PNG file but, for reasons that escape me, I couldn't get an image that would work. As I mentioned, SVG is all code, and the code I used for this was:

<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="1000px" height="60px" viewBox="0 0 1000 60" style="enable-background:new 0 0 1000 60;" xml:space="preserve">  
  <path style="opacity:0.6;fill:#fff;" d="M553.501,0c-4.749,25.543-27.137,44.889-54.057,44.889
        c-26.919,0-49.307-19.346-54.056-44.889H0v60h1000V0H553.501z"/>
</svg>

That's not a lot of code. You can copy and paste it into your HTML and, so long as you don't have a white background, it'll work for you. All without loading in an external image.

Unfortunately I can't cover it in more detail, as I have only just begun to scratch the surface of what is possible. The potential is definitely there though.

And That's A Wrap

We are visual thinkers. If someone says “cheese” you conjure up an image of cheese, not the word itself. This makes images an important part of communicatin information online. Getting the right image is only half the battle however. Getting it to the user of your site is the rest.

I've taken a look at some of the key ways that you can help do this more efficiently, and I've also taken a look at some of the alternatives out there that you can consider for some things. Use what works to say what you want to say. Then make sure to say it.

Want to add something to what I've said? Chime in below on the comments or hit me up on twitter.

I have been pondering how best to go about this post. With the increasing fluidity of the web, some of the “best” practices are becoming more difficult to impliment efficiently. In researching for this article I myself discovered I could make a large saving in loading times. So this is more of a guide than a rulebook, since the best way for one site might not be the best way for another.

If you are interested in getting to grips with this aspect of site development, I'm going to start with some basics and work towards more complex aspects over a series of additional articles. I hope that by the end of the series everyone reading will have added a new tool to their belt, be that knowledge or an application that makes life easier.

The Basics

When it comes to getting a site loading as quickly as possible there are a lot of technical aspects to consider. There are also some very basic ones that are, sadly, too often overlooked:

• Number of Files
• File Size
• Ordering Files

These aren't necessarily things that can be completely controlled, there are always going to be lots of images in a photo gallery for example. Even with these kinds of sites there are aspects that you will have contol over.

Number of Files

All too often I see sites with code that looks like this:

<link type="text/css" rel="stylesheet" media="screen" href='http://journal.davidturner.name/"/style/style_reset.css"' />  
<link type="text/css" rel="stylesheet" media="screen" href='http://journal.davidturner.name/"/style/style_960.css"' />
<link type="text/css" rel="stylesheet" media="screen" href='http://journal.davidturner.name/"/style/style_structure.css"' />
<link type="text/css" rel="stylesheet" media="print" href='http://journal.davidturner.name/"/style/style_print.css"' />

In terms of styling a site there isn't anything wrong with this. In fact, when coding a site I've always found keeping some things separate to be a good thing, as it keeps them out of the way. When it comes to launching a site, however, it's not quite as ideal.

The reason for this is that each time you load a file the browser has to fetch that file, which takes time. It's not a large amount of time, but every millisecond counts. The more files you add the longer it takes for a site to load.

Solution: Combine Files for Launch

Keeping multiple files separate is fine for development of a site, but you want to combine them for launch. The above code could, with ease, be combined down to:

<link type="text/css" rel="stylesheet" media="screen" href='http://journal.davidturner.name/"/style/site.css"' />

Isn't that much nicer? As an added bonus, if you're using a CSS precompiler you can have it take care of this kind of thing for you.

File Size

Lots of files is a problem, but it's not the only problem. Files that are larger than they need to be cause problems too, and is probably the area in which most savings can be made. This applies largely to images, but it also applies to JavaScript, CSS, and even HTML. Writing code that is easy to read is always a good thing. But indenting code, via tabs or spaces, serves to bulk out files.

When it comes to a live site every saving is beneficial. Smaller size results in faster load times. Faster load times result in users getting to your content faster. This results in less users leaving before seeing your content. It also results in Google being slightly happier with your site too. Everyone wins.

Solution: Compress Content {#compress-content}

Compressing code results in files that are slightly smaller. Whilst small amounts of compression won't impact load times that much, these savings can build up. It also results in a saving in terms of bandwidth, which is a financial incentive for adopting this approach.

It's possible to go even further with JavaScript, using minification tools. When writing JavaScript it makes sense to name variables in a manner that makes sense to you. When deploying it to a server, it doesn't. The only difference between a variable named a and a variable named humanReadableVariable is the amount of space it takes up.

Images are the other area that vast savings can be made. The first area that you can make heavy savings is by ensuring that the size of the image is the size it needs to be. If you display a 400px by 400px at 200px by 200px, you're loading in four times the amount of data you need to. Never do that.

You can make even further savings though. Images almost always have extra information attached to them. Extra information takes up space. What can we do to get rid of that imformation? We use something to strip the excess data from the files.

ImageOptim is a Mac application that can take care of that for you, and generally removes all the bits of an image that serve to make files bigger than they need to be. For anyone on Windows RIOT seems to be similar.

For an application that handles everything, however, I would strongly recommend CodeKit. It can be used to compress files, minify JavaScript, and strip excess data from images. Unfortunately it's a Mac-only app, so not useful for those Windows using readers out there.

Update: Chris Grant suggests looking at LiveReload as a partial alternative for Window users. It doesn't handle all of the things CodeKit can, but it's a start. It can also serve as an alternative for Mac users as well.

Order of Files

The rules with the order of files seem to vary depending on who you ask. I follow a very strict set in the development work that I do. CSS in the <head> element, JavaScript goes right before the </body> tag. With two exceptions:

1. HTML5Shiv/Modernizr JavaScript goes before the </head> tag
2. Adaptive Images JavaScript typically goes before the </head> tag

Both of these exceptions exist for very good reasons. Both HTML5Shiv and Modernizr are used to ensure that HTML5 renders properly in older versions of Internet Explorer. For them to function they need to be loaded before the content of the site.

The logic behind the Adaptive Images JavaScript is to ensure maximum effectiveness. In order to achieve this the cookie it creates needs to be in place before any images start loading. To do this I typically insert the code before the </head> tag. The current exception is this site, as I explicitly wanted to be able to measure the dimensions of an element of the site.

Solution: CSS in the <head>, JavaScript before </body>

Ordering files like this, with the exceptions listed above, results in content rendering more quickly. Yes, it doesn't really change how quickly a page loads, but it changes the perception. The content is loaded more quickly, and the JavaScript functionality can be added on once it's loaded.

The Basics - Covered

When it comes to optimising a site to load quickly, the above are some of the most basic areas that can be looked at in order to improve things. These simple guidelines can get things going in the right direction pretty quickly. There's a great deal more to cover, and I intend to look at other areas in future articles, taking a more in-depth look at things as I go.

If you feel I've missed something out, disagree with what I've said, or just want some more detail on a particular area feel free to comment below or message me on twitter.

What's Next?

This post covers some of the basics of optimising your site so that it loads more quickly. I want to take a look things in more detail going forward. Next week I'll be taking a look at some further ways to optimise images for the web, as well as some alternatives.

I've made it a personal rule to always try something new when it comes to giving a presentation, and my most recent talk held true to this approach. In previous talks this meant trying something different with the presentation itself. This time I tried something a bit more technical, presenting from my iPad.

iOS Presenting - Background

The thought of using an iOS device for presenting has appealed to me for a while, but the standard methods for presenting require tethering your iPad to a projector. I don't like this, as I like being able to move around if I need to. In my limited presenting experience I've also found that being tied to a projector can result in the speaker standing in an awkward location, which is uncomfortable both for the speaker and those listening.

I realise that there are already ways around this, such as purchasing an Apple TV. Sadly this is a bit extreme for me given my current quantity of presentations.

I recently had the good fortune to be able to attend an event by some Apple representatives. It was on how technology is changing the way that education works, and how Apple are playing a major role in this. It touched on several points, many of which I had an interest in, but what really interested me was how they were able to demo iPad apps via their Mac. They were able to walk around with the iPad, completely cable free.

Reflection.app

Fortunately, over the course of the day, I was able to work out how they were managing this magic. They had an application, called Reflection, running on their Mac. This turned the machine into an Airplay receiver, which meant that they could display what was happening on their iPad via the Mac. Perfect!

OS X + Reflection.app + iOS

Having worked out the missing piece of the puzzle I needed to work out how everything would work together. Fortunately this wasn't nearly as difficult as I had anticipated, but there are a few tricks that I picked up that might be useful to others.

Create a Computer-to-Computer Network

When you're relying on a collection of different devices, and you need them to keep in touch, you'll want control over as much of what is going on as possible. How much of a disaster would it be for a wireless signal to die mid-presentation? How poor would your talk seem if what attendees were seeing was lagging behind what you're talking about.

Taking control of the wireless helps avoid both of these issues, as your iPad will be connected directly to your Mac. This does mean that, if you need an internet connection, that your computer will need to have a network cable hooked into it.

Prep Work

In the talks that I have given during my time on The Masters, I've had to get quite adept at walking in, setting up my machine for presenting, and getting to it. As a part of this I've realised how important it is to have as many things set up as possible in advance. With my new approach to presenting there are a few important things to take care of:

Get Connected: I don't want to be fiddling with settings when I should be talking. So connecting my iPad to my Mac before I'm meant to be speaking is important so that I'm as ready to go as possible.

Be Prepared to Get Started: When you're in front of people, set up the presentation ahead of time. When you're in front of people, ensure you're as ready to go as possible.

With the approach I have adopted for presenting I need to ensure that the projector mirrors my Mac's display. Rather than start opening System Preferences, Command+F1 is a quick toggle that switches mirroring on and off.

Give The Talk: Once you've got everything set up all that is left is for you to give the talk. This is what you're there to do after all. All the skills you've made use of still apply, but now you're just a little bit more mobile.

Niggling Issues

Sadly using iOS to present with isn't without issues, though they are relatively minor issues in my experience. The software I use, Keynote, is available both of OS X and iOS. Sadly they aren't quite as equal as I would like. Some builds don't work, most notably moving elements, which can cause issues especially if you build presentations on your Mac.

The biggest issue I've encountered is that Keynote for iOS isn't as flexible as it's OS X version. This means that there is no way for me, as a presenter, to see how long I have been speaking for. It also limits my ability to see notes for the presentation, as opting to see notes means I can no longer see what the next slide is.

Notes aren't that important to my talks, as I am quite well versed in what I talk about, but there are times when seeing some facts and figures would be nice. The real killer is that I can't see how long I've been speaking for. Timeframes are a rather important part of the talks that I give, so this is a rather important piece of information for me to have access to.

Wrapping Things Up

Trying new things in my presentation helps to keep me on my toes, and helps ensure that I'm upping my game as I immerse myself more and more in talking. As I've mentioned above, this new approach to presenting isn't without it's problems, but I much prefer those small issues to being tied to a specific patch of ground in order to see my slides.

It's not for everyone, but then nothing is. I'd love to hear how others give their presentations, so feel free to comment below or comment on twitter.

Things have changed quite a bit from then, for the better. My time at Fresh Made Media, and on the MA, has really emphasised the importance of working as a team with others. Last week I gave a talk on the topic of collaboration, and this article expands on it a little.

What is Collaboration?

The dictionary definition defines collaboration as:

The action of working with someone to produce or create something.

I don't think that's necessarily a fair, or accurate, definition for what collaboration is or how beneficial it can be. Collaboration, to me, is bringing together a team of like minded individuals to work towards a common goal. By bringing together a team like this it allows for a greater finished piece.

There are a few key areas that really sum out what collaboration is, the facets of collaboration if you will. I want to talk about each in turn before I give an example:

1. Teamwork
2. Skills
3. Balance
4. Delegation

Teamwork

This particular facet of collaboration is implied. You can't have collaboration in a team of one, as it's not really a team. By having a team you are able to bring different ideas to the table, different approaches. Being able to bounce ideas off of team members can result in some amazing things happening.

Skills

This is one of the fundamental benefits of working with others. You don't want ten developers working on a design project, and you don't want ten designers trying to code. By having a mix of both though, and by getting more skills involved, you become better able, as a team, to handle tasks.

Balance

Balance is important, in workload as well as in reward. By working with others you can make sure that each memeber of the team knows exactly where they stand, and what they are responsible for. This can create a peace of mind, knowing that everything is being taken care of by someone in the team.

Delegation

Alongside balance comes delegation. With a mix of skills in a team you will be able to ensure that the right person is handling each task. This allows the people with the relevant skills to deal with problems and tasks, which will almost always result in them being dealt with quickly.

Example - Music

Music is a fantastic example of collaboration. It's possible for individuals to create great music, but it is much rarer to hear of music created by just one person. More often than not truly great music is created by bringing together a group of such people. This could be into a band, or it could be bringing together the different sections of an orchestra.

Individually these people could create great music, but by bringing them together and having them work together towards a single goal, something far greater is created. By bringing together the individual members to create a band, you get groups like Pink Floyd or The Beatles.

You wouldn't, however, ask the lead vocalist to pick up a guitar, or the lead guitar to start playing the drums. Each member has a single focus which they excel at. The rest of the team augments that with their own particular skill. The same is true in collaboration.

Why Collaborate?

Collaboration is, as I mentioned above, bringing together like minded people in order to work towards a common goal. Why would you want to do this? Over the past year I have come to realise that there are a few reasons that have really rung true in my own experiences collaborating with others:

1. Delegation
2. Support
3. Skills
4. Gestalt

Delegation

Delegation is a key to collaboration. Ensuring that the right people are working on things allows everyone to focus on the areas that they excel at. It also removes concern from people that they might have to work on things they aren't suited to. This generally results in better work.

Support {#support}

Accidents happen. People get burned out. When this happens with an individual then they're out of action and their projects stall. When working as a part of a team this doesn't need to be the case. The other members of a team can continue to push forward, the momentum of the project isn't lost.

Skills

This is an important part of collaboration, and an area I want to expand on slightly. Skills is one of the main benefits of collaboration with others, you work with those whose skills compliment your own. Sometimes it's possible to create something individually, but with the right team you are capable of so much more.

When i was speaking with my friend Tami Olsen, an author and games designer, about the topic of collaboration she said something that really resonated with me about how much the skills of others can benefit a group project:

We're like colors… and those inner parts define us… and when we mix we make beautiful things… but if it's mostly me then it's not so beautiful.

To me this shows the real benefits of working with others. By adding in new skills, new talents, new ways of thinking and new approaches then it is possible to do things differently, and push to do more. Sometimes these new talents will just re-enforce current process but sometimes it will allow for improvement.

Gestalt

Gestalt, the idea the the whole can be greater than the sum of it's parts, and this can ring very true if you work with a team of people with the same motivations.

A single person, be it you, me, or any single person working on something, can only achieve so much by themselves. They are limited by their skills, their ideas, and their time. As a result they can only do the work of a single person.

By contrast a team of two people, with similar motivations, can push beyond the expected limits of two people. Because they are working together, it is possible to inspire people to push further in their work.

In theory this can scale to any size. A team of three could do more than you would expect of them if they have similar motivations. A team of people working towards a common goal will motivate one another to do more, to do it better. As a result the whole team benefits.

How to Collaborate?

I've spoken about what collaboration is, and why it might be beneficial to collaborate with others, but how do you go about collaborating with others? First things first we need to prioritise. What skills does the project need? In my own work there are a few key areas.

Identify Skills

Design and Development lie at the core of what I do. These two skills are fundamental to making any product that I will work on, and they are the skills most people acquire. But these two skills combined aren't enough. You can't create every colour with just red and yellow, you need blue as well.

Blue, in this case, represents Direction. Being able to design and develop something is only one part of the equation, being able to connect people together is a a vital skill, and one which can make the difference between a product with only a handful of users and one with thousands.

Work Together

Identifying skills is only one part of the equation that is collaboration though, you also need to utilise them. Above I displayed the skills that apply to my own work as a colection of separate entities. In practice this isn't how it plays out. The reality looks a little more like the following.

Nothing is truly independant in collaboration, there is always an overlap between the different skills involved. This overlap is what allows a group to push further, as individuals can interact with each other and help motivate each other to do more.

There is a certain amount of room for flexibility. The designer and developer will work together more than they would with the person directing things. The person directing a project can sometimes seem absent because they are reaching out to individuals that would benefit from using the end product.

Support Your Team

As I mentioned above, supporting the people you work with is an important part of collaboration. Accidents do happen. People do get burned out, and need a break. This could be you or it could be a member of your team. It's important to be there in the event that it does.

It is important for a few reasons. The first is that it keeps the momentum of the project going. The project doesn't have to stop because someone needs some time out. Having a group of people allows those who are still there to keep going.

Possibly more important is the fact that if a team can come together to help a member who needs a break, or has had an accident, then that person will feel valued. They'll feel a loyalty to the team. This is something that a lot of teams lack and it's something that shouldn't be underestimated.

Hakuna Matata

Despite the fantastic vocals in The Lion King, there's no guarantee that everything will run smoothly. A team that seems to be a good fit going into a project might turn out to not be the best of fits when you start working together. Sadly, it happens.

It's important to ensure that there is some kind of agreement between the members of the team going in regarding individual responsiblilites and expectations. Such agreements help to avoid issues going in... often times people who are most likely to cause issues won't be willing to enter into such agreements.

Two books in particular that I would recommend on this topic:

Design Professionalism
Design Is a Job

I have been fortunate with the people that I have worked with, in that there have never been any issues. I've always made a point of thinking of what I do as a job, and there are some great books out there on the topic.

Wrapping Up

Collaboration has, over the last year, really helped me to improve the quality of my work. My work with Kyle Gawley, in particular, have resulted in some spectacular pieces of work which I would never have been able to do without him.

Bringing together skilled individuals to work towards a single goal can produce some spectacular results. If you've got an idea that you want to see happen, but lack all of the skills to do so, find the people to help make it happen. And then make it happen.

It's not that I have nothing to write about, I've got plenty of topics to write about, focusing on my design principles as well as on projects and personal experiences. So what's stopping me?

Writer's Block

The big hurdle for me is getting started. I have a lot to write about... so much that I've been finding it difficult to focus on getting any individual piece done. I find it easy to bounce from coding project to coding project, but that approach doesn't work with writing. Writing deserves focus.

So I need to focus. How? They biggest thing for me, I believe, is to get away from my computing environment. On my Mac it is far too easy to allow myself to become sidetracked. Twitter, Facebook, TV, and instant messaging can all to easily get in the way of working.

I've taken steps to avoid such distractions, but when I find getting started difficult, it remains all too easy to allow these distractions to get in the way. Which doesn't help. Fortunately I have found other ways by which I can help myself to focus.

Change of Device

My Mac makes it all too easy to distract myself, to lose focus. I've found that by doing my work in other means I am much better able to do. There are two key approaches that I have found that let me make the progress I need to.

Paper

Paper is something dear to me. It lets me quickly fire ideas down. It lets me iterate it. It lets me do. Doing is important. Doing leads to progress, to improvement. This is the starting point in everything I do. It serves as the foundation for my work, before I start with the digital.

iPad

The iPad has increasingly become my companion in the work that I do. I'm fortunate that almost everything I work on is text in some form. Code, journal articles, presentations... these all start with words. The iPad is very good at letting me work on these things, and letting me do so with minimal external distractions.

Focus

Focus is what these two things have in common. Paper can only let you create. It doesn't have the facility to provide distractions. It doesn't let me produce finished work either, but it lets me start. Starting is important.

The iPad can provide distraction, but is much more focused than a computer. I can only have one app open before me, which forces a certain level of focus. It allows me to define, and refine, thoughts in a more solid form.

Both of these are very different, but they have two things in common. They let me focus. They let me do.

A Promise

I want to finish with a promise. This is as much to the people reading this as it is to myself writing this. I want to do more. I want to write more, and write more regularly. These are things I will be doing more. They are things I promise to do.

I do it publicly so that I am forced to follow through. An unseen promise means nothing. An unseen promise holds you to nothing. Putting this out there means I have to deliver. What about you? Is there anything you want to do,but haven't?

With my recent talk on the topic of simplicity at Creative Camp, I have realised that I should be documenting and talking about these fundamentals, or principles, in more detail. As such, this post will serve as a starting point for further articles that focus on each principle in more depth.

Making People Happier - An Introduction

There are fundamental principles that serve as key points in the work that I do. It has taken me a while to realise this, but they applied to my work even before I knew of them. My current knowledge will help me drive future work to even greater heights.

Each of these principles help me to produce software that makes users happier. These principles are:

• Discovery
• Automation
• Simplification
• Preservation

Each of these principles provides an area which I can focus on in my work and each helps, in some manner, to improve the quality of the products I am involved in. Not all principles can be applied to all products, so principles must be applied in a manner relevant to the work being undertaken.

In creating products that identify relevant principles, and adhere to them as closely as possible, I am able to produce a higher quality of product. Due to adhering to these principles, these products will also result in the people using them being happier.

The Four Principles

As I have laid out above, there are four key principles that apply to the products I have been working on. I will now talk about each in turn, expanding upon the logic behind each as well as the impact that they can have upon the products I am developing.

Discovery

In much of the work I undertake, I deal with data. Information. The internet is immeasurably vast, but it is possible to find, or discover, information. Search engines like Google help, but they are a very general tool – it’s hard to find very specific information.

Making it easier for people to find the information that they are after is important, be it a tweet with a specific hash tag, or the information needed to accurately generate a reference.

To take the example of twitter, this is a quote from an announcement they made just over six months ago, which I will refer to throughout my essay:

“Halfway through 2011, users on Twitter are now sending 200 million Tweets per day. For context on the speed of Twitter’s growth, in January of 2009, users sent two million Tweets a day, and one year ago they posted 65 million a day.”

This doesn’t just give an idea of the quantity of information that needs to be searched through, it also shows how rapidly this number is changing. According to TechCrunch this number was up to 250 million tweets per day mid-October.

Discovery of information in such a rapidly growing pool is very difficult. Finding specific information on an individual page can be difficult.

The products I create help make it easier to find the information that users are looking for. The result is that people can more speedily find the information that they want or need.

The end result of this is that people spend less time looking for information. This makes people happier.

Automation

Undertaking a task multiple times isn’t pleasant. It’s boring. Undertaking a boring task repetitively is never enjoyable, which results in lower productivity and lower levels of happiness.

When approaching product design I want to avoid both of these issues. Lower productivity and lower levels of happiness result in a poorer quality of work. What can I do to remove the boredom?

Automation handles these tasks efficiently, removing the need for human repetition entirely. By automating a process I am able to take a repetitive and tedious chore and remove it from workflows.

This is something computers are very well suited to. They are also suited to handling much larger tasks. To revisit twitter, which I discussed earlier, there are somewhere between 2400 and 2900 tweets being sent per second.

Filtering through these tweets would be an impossible task for a human. For a computer, however, it is a very simple task, and one it can handle as many times as is needed. Computers can take an impossible task and make it possible.

Software that automates tasks, therefore, removes tedious and repetitive tasks from the workflow of people. In the workplace this means that people are able to dedicate time to more important, or more rewarding, tasks. This increases productivity.

The results impact more than the workplace. By freeing up more time from tedious and repetitive tasks, it is also possible that people may find themselves with more time which they can spend as they see fit. This makes people happier.

Simplification

According to Wolfram Alpha, which provides answers to questions, there are roughly 13.71 billion indexed web pages online. That is an overwhelming amount of information to search through, and it only includes the indexed areas of the internet.

So how do we find what we need? How much information do we need to give out in order to do the things we view as necessary? The reality is that we don’t need all of the information that we think we do.

People think that they need the information, but it is very rarely the case that people find the time that is required to do anything with it. With this being the case, why collect it in the first place? People think they like choice.

Choice appeals to people, it lures them in. Jason Putnam talks about it in an article on the KISSmetrics blog. There is a drawback to choice as highlighted in a paper by Sheena Iyenga. Whilst choice can draw people in, it has a negative effect when it comes to deciding, causing them to freeze.

Simplification, therefore, makes sense. By removing unnecessary information, or steps from a process, distilling a process down to the core information needed, I am able to create a better experience for people.

By simplifying processes, I make it easier for people to complete tasks. This enables people to spend more time doing the things that they want to do. This makes people happier.

Preservation

In a world that is as growing by over 60,000 websites per day (according to research by Shane Snow), finding information is difficult. Keeping hold of that information is difficult too.

Keeping hold of your data is important, a topic that Jeremy Keith touched upon recently in his “All Our Yesterdays” talk at Build. Data doesn’t live forever, things do disappear.

Many people will have heard of the company Yahoo! and, probably, of GeoCities. GeoCities served as a home for almost a terabyte of data, until it was unceremoniously removed. That’s a lot of information that simply disappeared, and it could cause problems to lose something that we never thought could disappear.

This is something that I would like to help prevent with my own work. A lot of what I do deals with collecting information, but I also want to ensure that it’s not trapped in my system. I want to collect information and then let people use it however they would like.

The foundation of this will be allowing export of information in the formats that people understand. This allows people to take the information that is significant to them and use it elsewhere. It also means that they could, if they so desired, save this information elsewhere.

Information is valuable, but many people don’t realise this until after the information is lost to them. The products I am working on will, to the best of their ability, help mitigate such loss.

The end result of this is that people will have access to the information that matters to them, in a format they can use. This makes people happier.

Conclusion

As we have discussed, information is a valuable commodity and has a lot of power. There is much that can be done with information to make lives easier for people. The four principles I have identified better help me to achieve this.

__Discovery__, Automation, Simplification, and Preservation have provided me with a solid foundation for the work I have previously completed as well as with future projects. They have also helped me to identify a cohesion in my work that had previously gone unnoticed.

This foundation has helped me to produce a higher quality of work, and is key to the products I have been working on. It keeps my work focused on making life better for those that use them. It has also enabled me to identify other areas that I believe can be improved upon via the application of the principles I have discussed above.

The products I have developed, alongside others I am currently developing, allow me to work to make the lives of people better. This is something I care quite deeply about, and is something I intend to pursue, developing new products in the areas I have identified that can be improved.

Each of the products I am involved with work to this end, applying my four principles to solving problems. These products make lives easier for the people using them. This makes people happier.

References

• Sheena S. Iyenga, Mark R. Lepper, 09/03/2006, When Choice is Demotivating: Can One Desire Too Much of a Good Thing? [Columbia University in the City of New York], [online]. Available: http://www.columbia.edu/~ss957/articles/ChoiceisDemotivating.pdf [23/10/2011].
• Mark Masnick, 29/10/2010, Archive Of Geocities Released As A 1TB Torrent | Techdirt [Techdirt.], [online]. Available: http://www.techdirt.com/articles/20101029/03055711647/archive-of-geocities-released-as-a-1tb-torrent.shtml [02/01/2012].
• Joseph Putnam, 30/08/2011, Are You Losing Sales By Giving Customers Too Many Choices? [The @ KISSmetrics Marketing Blog], [online]. Available: http://blog.kissmetrics.com/too-many-choices/ [23/10/2011].
• Alexia Tsotsis, 17/10/2011, Twitter Is At 250 Million Tweets Per Day, iOS 5 Integration Made Signups Increase 3x | TechCrunch [TechCrunch], [online]. Available: http://techcrunch.com/2011/10/17/twitter-is-at-250-million-tweets-per-day/ [01/01/2012].
• Twitter, 30/06/2011, Twitter Blog: 200 million Tweets per day [Twitter Blog], [online]. Available: http://blog.twitter.com/2011/06/200-million-tweets-per-day.html [26/10/2011].
• Shane Snow, 26/03/2011, How Much Content Is On The Web? | The Content Strategist [Contently: Empowering and connecting quality writers and brands.], [online]. Available: http://contently.com/blog/how-much-content-is-on-the-web/ [02/01/2012].
• Wolfram Alpha, 02/01/2012, how many websites are there – Wolfram|Alpha [Wolfram|Alpha: Com- putational Knowledge Engine], [online]. Available: http://www.wolframalpha.com/input/?i=how+many+websites+are+there [02/01/2012].

Bibliography

• Sheena S. Iyenga, Mark R. Lepper, 09/03/2006, When Choice is Demotivating: Can One Desire Too Much of a Good Thing? [Columbia University in the City of New York], [online]. Available: http://www.columbia.edu/~ss957/articles/ChoiceisDemotivating.pdf [23/10/2011].
• Mark Masnick, 29/10/2010, Archive Of Geocities Released As A 1TB Torrent | Techdirt [Techdirt.], [online]. Available: http://www.techdirt.com/articles/20101029/03055711647/archive-of-geocities-released-as-a-1tb-torrent.shtml [02/01/2012].
• Joseph Putnam, 30/08/2011, Are You Losing Sales By Giving Customers Too Many Choices? [The @ KISSmetrics Marketing Blog], [online]. Available: http://blog.kissmetrics.com/too-many-choices/ [23/10/2011].
• Alexia Tsotsis, 17/10/2011, Twitter Is At 250 Million Tweets Per Day, iOS 5 Integration Made Signups Increase 3x | TechCrunch [TechCrunch], [online]. Available: http://techcrunch.com/2011/10/17/twitter-is-at-250-million-tweets-per-day/ [01/01/2012].
• Twitter, 30/06/2011, Twitter Blog: 200 million Tweets per day [Twitter Blog], [online]. Available: http://blog.twitter.com/2011/06/200-million-tweets-per-day.html [26/10/2011].
• Shane Snow, 26/03/2011, How Much Content Is On The Web? | The Content Strategist [Contently: Empowering and connecting quality writers and brands.], [online]. Available: http://contently.com/blog/how-much-content-is-on-the-web/ [02/01/2012].
• Wolfram Alpha, 02/01/2012, how many websites are there – Wolfram|Alpha [Wolfram|Alpha: Com- putational Knowledge Engine], [online]. Available: http://www.wolframalpha.com/input/?i=how+many+websites+are+there [02/01/2012]. Seth Godin, 03/11/2011, Seth’s Blog [Seth’s Blog], [online]. Available: http://sethgodin.typepad.com/ [03/11/2011].
• Jason Fried, David Heinemeier Hansson, 2010. Rework. 1st Edition New York: Crown Business.
• 37 Signals, 2006. Getting Real: The smarter, faster, easier way to build a successful web Application. 1st Edition Raleigh, N.C.: Lulu.
• 37 Signals, 04/11/2011, A design and usability blog: Signal vs. Noise (by 37signals) [37signals: Web-based collaboration apps for small business], [online]. Available: http://37signals.com/svn [04/11/2011].