During every big project I work on, I seem to spend a lot of time thinking through how the next one will be SO much better. It’s always going to be perfect, next time.
Designing in code
The project I’m working on at the moment is the first site I’ve designed completely in the browser using HTML/CSS. There are no Photoshop/Fireworks design files. I also rejected all products like
MACAW (that I gushed about previously) as actually being a hindrance rather than helpful.
Even though I’m fundamentally a designer not a coder, I’m going to persevere with this approach going forward – with perhaps a little more sketching to get things started. It can seem painful at first, but with time the process speeds up. All those latter design changes and final tweaks are a positive delight to do in the code rather than across many Photoshop pages.
The code doesn’t have to be great. In fact, I’m currently considering it disposable. Just as Photoshop / Fireworks files are disposable (and take up far more disk space in the process). Longer term this may change.
SASS / Compass / Susy
I will continue to use
SASS and get better. SASS gives the power to store palette settings in variables and use maths to create intelligent, justifiable colour combinations and variations (as well as a ton of other advantages).
Using
Compass was a great aid to designing in the browser this time. It speeds up the creation of high fidelity design by adding a powerful set of mixins for quickly creating gradients, rounding, shadows etc. Next time I will know it better, and remember to use it.
Susy offers a powerful, flexible SASS grid system without the bloat associated with full-blown frameworks. I’ve not used it yet, but hopefully it will ease some of the fiddling that went on this time with my custom grid, and make things faster when it comes to layout experimentation.
Live reload
Next time I will ensure I have live reload working as I style. This started well with my current project Using Codekit and a Chrome extension, but it stopped working and I never invested the time to fix it. Ideally this would be across devices too, as I’ve seen demonstrated with GhostLab. I’ve heard a lot of good things about using Grunt for this purpose too, so may have to explore the possibilities there.
Systems not templates
I must stop designing and thinking in terms of individual page templates. Instead I need to think and design in terms of ‘modules’ or blocks of elements that can work as part of a greater system of pages – the ‘atomic’ principle as Brad Frost called it.
We’re not designing pages, we’re designing systems of components.—Stephen Hay
Pattern Library
This modular / atomic / system approach needs to be documented and recorded as the project progresses, rather than at the end using an intelligent process that I haven’t yet worked out.
Modularisation with PHP
PHP allows me to break up the design code into intelligent modules so no part of the design needs repeating. It allows text variables for common content elements if needed and tons of functionality for creating design prototypes. I will do this better next time.
GIT
Designing in the browser means that my design is mostly code and small assets. This can be kept in a GIT repository and be version controlled and shared with co-workers. (OK so there MAY be a couple of small Photoshop/Illustrator files for any specific artwork, but that will depend on the project). My current project I used GIT to store the code, but kept forgetting about it. I will try harder next time.
No more lost work as Adobe software crashes under the strain.
Content first
I will use Statamic to put together a mini site using actual content. Statamic allows fast creation of content sections and taxonomies using simple markdown files. This mini site will be fully navigable and utilise a wide selection of actual content covering extreme cases to inform the design more accurately.
Unlike other flat file systems I’ve used such as Jekyll and Docpad, Statamic does not need to be ‘generated’ – as this is done on the fly with PHP, making the whole process seamless, and a little magical. Markdown pages can be added, and they instantly form part of the content/IA.
HTML wireframes
I’ve been using Axure for several years for creating interactive wireframes. Trying to wireframe responsively has proved to be so painful in Axure (and every other way I’ve tried) that it simply makes no sense any longer.
The Susy grid, SASS and HTML make responsive wire framing much simpler. In my next project my Statamic content site will become the responsive wireframe, then get skinned and progressively enhanced.
Wearable up
I will create the extra narrow mobile layout design first. This is what the client will see first too. They will get used to thinking about their new site from the smallest screens upwards. The client will prioritise their content accordingly and understand how content moves from mobile up to very large desktop widths.
Clients must not be so focussed on the desktop. It’s what they’ve come to expect to see as their working day is spent looking at sites on desktop machines. They must stop thinking like this. They will see the desktop layout emerge as the design is progressively enhanced and the screen gets wider. At that point much more important issues will have already been decided upon.
Simpler is better
I’ve already rejected mega menus and carousels from future projects (where I can help it). These are cumbersome and lazy. If navigation can’t be expressed simply on limited screen devices, then it needs rethinking.
If something is important enough to be featured in a carousel, why then hide it? In my experience, carousels are mostly used to keep marketing people, and those who can’t prioritise content, happy. They also make little sense at mobile, in terms of layout, usability and download size.
I will take simpler approaches to solving design and usability problems. This will enhance user experience not detract from it.
URLs not JPGs
In my current project I failed to design mobile up – in fact I went a bit mad and did the complete opposite – a super-wide 1600px layout first. As a result I could not give my client a simple URL to demonstrate the design, as my responsive considerations (even at regular desktop widths) were a little half-baked. I was also worried about browser issues and used Awesome screenshot for Chrome to output full page jpegs (which is what they would have received from Photoshop).
Next time, clients will be instructed to use their mobiles to look at the initial mobile designs and Chrome or Safari to look at desktop width designs. They will do this looking at URLs not at pictures.
Finally
In my next project my client will not be allowed to upload images with text on using their CMS. There will be a clear note of this in the CMS “Do not upload images with text on – IT IS AGAINST THE LAW !! (ok, will probably explain the lack of accessibility and spidering etc). If only there were cleverer ways to stop this using OCR as a test.
If text is important and useful it should be actual text. If it has been forced into an image, there must be a fundamental problem in the layout of other elements on that page.
After a project is complete, once all of the design justification and negotiation is done with, the sudden appearance of huge, purple, Comic Sans on a home page banner makes a mockery of the whole design process.
Next time
Ok so my next project won’t be perfect either. But in each new project we must attempt incremental improvements as the landscape beneath us changes.
As the web constantly evolves, so must our design process and the way we think as designers.