{"id":1,"date":"2013-05-22T19:53:56","date_gmt":"2013-05-22T19:53:56","guid":{"rendered":"https:\/\/www.sebastianlenton.com\/?p=1"},"modified":"2013-07-09T14:05:17","modified_gmt":"2013-07-09T14:05:17","slug":"behind-the-scenes","status":"publish","type":"post","link":"https:\/\/www.sebastianlenton.com\/2013\/05\/behind-the-scenes\/","title":{"rendered":"Behind the Scenes"},"content":{"rendered":"

Hello, and welcome to my new site. I’ve been a web developer and designer for some five years now, both as a freelancer as well as having worked with agencies. If you’d like to read a bit more about me then you can do so here<\/a>, and do please\u00a0let me know<\/a> if you encounter any bugs or want to give me any feedback.<\/p>\n

With this first post I want to talk about my workflow whilst creating this site, and some of the processes and tools I used. My initial objective was simply to create a site which conveys my skills whilst being nice and easy to use across a range of devices, so I decided that\u00a0a simple design and content structure \u2014 with an emphasis on responsive design and performance \u2014 would help me meet this objective.<\/p>\n

<\/p>\n

Begin, Don’t End, With Content and Structure<\/h2>\n

Sometimes designers dive into the aesthetics of websites, without considering the content or required page structure until towards the end of the project \u2014 often with Lorem Ipsum text in place of final copy, and menus listing “page 1\u201d, “page 2\u201d, “page 3\u201d and so on.<\/p>\n

Where possible, web projects should begin \u2014 not end \u2014 with their content and structure, simply because a website’s content is overwhelmingly its most important component. By organising the page structure early you can get a better sense of whether the information is organised in a way which is easy to navigate, while working with prior knowledge of the required content and page structure means costly mistakes can be avoided at the design stage. Aesthetics and layout should\u00a0compliment the content, rather than merely enclosing it.<\/p>\n

In this case, I began by fleshing out a site structure diagram on paper which broadly stipulated which content and elements would go where, and how many pages would be required. I then quickly wrote some draft copy for each page \u2014 even if you’ve only got rough notes to work with, it’s still better than nothing!<\/p>\n

\"SketchedFollowing this I produced wireframes for each proposed page. This helped me visualise how the result would look in terms of layout, and is also pretty essential for designing responsively (the process of creating websites which are easy to read, regardless of whether you’re using a phone, desktop computer or whatever). This gave me an opportunity to refine my layout, menus and content structure before even beginning any “serious”, time-consuming work on a computer.<\/p>\n

Development Commences<\/h2>\n

At this point I had a fairly comprehensive plan of where I was going, so I began developing. My next stage was to produce what I refer to as a functional wireframe: a live, working version of the website which is accurate to my plan. This version of the site is reasonably complete with regard to layout and JavaScript interactions (not that I’ve used much JavaScript for this particular project) but doesn’t include any aesthetic design work with regard to colours, textures or typography.<\/p>\n

These don’t take too long to develop, and give a good indication of how the site will work in situ. The first step of this was to take a fresh WordPress install and simply add my draft content and page structure, before working on the markup and CSS required to build the page layout. The result is a prototype version of the website which conveys fairly accurately how it will work to the end user, how easy it is to navigate and how well it communicates its objectives. Again, potential problems which may not have been apparent at the planning stage can often be nipped in the bud, without wasting time polishing and completing elements which ultimately prove to not work well.<\/p>\n

With my prototype complete, only now do I fire up Photoshop. Since I’ve already wireframed the pages on paper and put together the basic layout in HTML and CSS using an IDE and my web browser, there’s simply no point in producing traditional static comps (and besides which, some argue that responsive design has mostly rendered the traditional Photoshop comp obsolete). These days I use Photoshop more to explore ideas, create textures, experiment with colour schemes and generally define an aesthetic which complements each project, similar to a mood board or style tile. Given that one of my aims with this project was fast loading and performance, I kept visual embellishments to a minimum.<\/p>\n

By this stage I was coming fairly close to a finished product. I continued to polish and refine, squashed a bug or two, tested across a variety of browsers and devices and reworked my original draft copy. And finally, after minifying my JS and CSS and polishing a little more, I deployed the finished product to my live web server.<\/p>\n

Technologies Used<\/h2>\n

Find below a list of tools, frameworks and technologies used to develop this site. If you’ve any experience with developing or designing websites then you will probably be familiar with most of these.<\/p>\n