rdjpalmer-blog

[rdjpalmer-blog]

Project process, part one: ground work

Let’s discuss process. Specifically process for design projects. I completed my first freelance design project recently, and felt it a good idea to get the process I went through down, so I can refine it and potentially help you lot in a similar situation to me.

I’m going to talk about my process through examples of the project I completed, so here’s a little background info on the project:

A brand identity and Tumblr theme for Cardiff based, Personal Trainer, Kain Owen (or Kain Owen Strength and Fitness Coaching).

In this part, I’m going to talk “ground work”—that’s the leg work you have to do to get the project in a place where both you and the client are on the same page, a contract is signed and you’re ready to roll!

Getting started

Every project starts with a conversation. It has to; no-one really knows what they want until it goes down on paper and feels somewhat finalised. I found it extremely useful to start with the client’s vision. Their current status, their ambitions, and everything in between. Use this knowledge as a platform to lead the conversation to talk specifically about the project: what the desired outcomes are (not the “deliverables”, more on this later), are there any impacting factors you should know about, and the super important detail of budget and cost. Whatever you do, make sure you at least talk budget! Don’t push to have one there and then, just make sure you plant the seed so you can write the agreed cost into the contract.

Initial mood board

Prior to the meeting, Kain was tasked with putting a mood board together (using niice.co), so after getting to know Kain’s vision and (what he believes is) his aim for the project, we went through it, talking about the merits of the images he had included. I did this with the intention of getting an insight into his actual desired outcome for the project. What’s nice about it is that it also doubles up as a great starting point for the aesthetic I would need to immerse myself in, in order to successfully meet Kain’s needs.

Outcomes not deliverables

Note I say outcomes rather than deliverables. While in this project there were deliverables (logo, business card, style guide and a Tumblr theme), they’re not the important part of early stage conversations. Ideally, you want to figure out the problem you’re trying solve and match the medium you solve it with to the problem. In Kain’s case, he needed a brand identity, so the typical deliverables of a logo, business card and style guide make complete sense. Kain also wanted to boost his web presence and has a really fun writing style. A blog made sense. I recommended Tumblr as it matched his budget, was super quick to set up and provided a great basis while he built a library of content. He’s likely to out grow the platform due to it’s simplicity, but at this stage, simplicity is exactly what he needs.

Be skeptical

Also note that early in the conversation, I’m skeptical as to whether or not the client knows exactly what they want in terms of outcomes; I’m not doing that to be a dick, but rather intentionally doing so to ensure I lead the conversation down a route which will get them talking about the necessary things so I can form my own opinion as to what will solve the problems they’re trying to solve.

Kill it with a contract

The next part is to get the project moving, but that can’t be done until all the terms are agree and a contract is signed. I went away, put a contract together, using a modified version of ‘Contract Killer’ by Stuff & Nonsense, with all the details I knew were agreed so far, and put a supporting presentation together to show my understanding of the project so far, and explain to Kain his options. Remember how skeptical I was before? It’ll all come out in the wash as you put these together.

Prices redacted

In this period, you should maintain conversation with the client, agree a budget and put some options together for them to choose between. In Kain’s case, the ideal set of deliverables weren’t possible for his budget so I put two options together; one which matched his budget and another which stretched it yet gave him exactly what he wanted. I found the key thing here was to let the client choose between the two. Once they’ve chosen, finish up the contract with the newly agreed details and set to work!

In summary…

Keeping this short, the steps I take at this stage are pretty simple:

Gauge the clients expectations through conversation

Get them to do some of the research for you

Look at the required outcomes first. Deliverables will match up to these and help you produce the right work for the project.

Sign a contract

Always maintain a conversation with the client!

In part two, I’ll be talking further research, concept development and execution. In the mean while, check out the KOSFC project on my portfolio!

[rdjpalmer-blog]

Preparing to write CSS

Quite recently I've been looking at how best to write Nudjed's CSS. I've looked at everything. Folder structure, CSS pre-processors, style guides and pattern librarys. You name it, I've looked at it (… probably). I thought it would be best to share the love, so here's a bunch of articles I've found helpful during this process.

Before we delve straight into the articles, here's the difference* between a style guide and a pattern library:

*I got these from a quick google.

Style guide

A style guide is a set of standards for the writing and design of documents, either for general use or for a specific publication, organization, or field. A style guide establishes and enforces style to improve communication. - Wikipedia

Pattern library

A pattern library is a collection of user interface design patterns. The site UI-Patterns described these user interface design patterns as: Recurring solutions that solve common design problems. - Paul Boag on boagworld

So in the context of this article, a style guide is a standard of how to write CSS. A pattern library is a library of components with their relevant mark up, CSS and JavaScript.

Lonely Planet

Ian Feather wrote a bunch of articles on Lonely Planet's frontend, a couple of which were super helpful during my exploration of CSS architecture.

Lonely Planet's CSS

Lonely Planet's “a maintainable ~~style guide~~ pattern library”

Lonely Planet's ~~style guide~~ pattern library

Note while Ian writes style guide, his articles talk about something much more akin to a pattern library than a style guide. Regardless, you can still get a great insight from them.

Mark Otto and GitHub

Mark's gone and written some great articles on GitHub's CSS. His insights kicked this all off, and given his prestige (Twitter, Bootstrap and GitHub!), you'd be crazy to ignore any of it.

Code guide: Standards for developing flexible, durable, and sustainable HTML and CSS.

GitHub's CSS

GitHub's style guide

Ghost

Following GitHub's and Lonely Planet's lead, Ghost's Paul Davis shared with us how Ghost writes CSS. A notable feature of Ghost's CSS is the reverse on common practices, such as semantic naming conventions and grid systems.

Medium

The great thing about Medium sharing their thoughts about their CSS is how deep Jacob makes the rabbit hole feel with such a pleasant read. Once you're done reading about the process he went through to “fix” their CSS, make sure you check their style guide.

Axiomatic CSS and Lobotomized Owls by Haydon Pickering

The previous articles are fantastic, but they're all missing something. Lobotomised Owls.

* + *

That's one badass selector name, with a selector to match. Seriously though, Axiomatic CSS and Lobotomized Owls is a must read. The principles Haydon speaks of here are going to provide the foundation of Nudjed's CSS.

If you're down with it, also check his effortless style presentation at CSS Day. I saw this first, and it was quite the eye opener.

Other resources

We could talk about this all day, and expect me to continue in a “how Nudjed writes CSS” post sometime soon. Meanwhile, heres a load of links to other resources around writing CSS, style guides and pattern libraries:

Pattern libraries

Pattern Lab

Pattern Lab's resource page

Getting started with Pattern Libraries by Anna Debenham

Mailchimp's Pattern Library

Style guides

Google's HTML style guide

Google's CSS style guide

BBC's HTML style guide

BBC's CSS style guide

csswizardy's cssguidelines

CSS-Tricks' style guide resources

[rdjpalmer-blog]

How to change the page title when the window loses focus

I’ve been following Little Big Details on tumblr for a fair amount of time now. It never ceases to amaze me some of the great details that my fellow designers have come up with in their applications and websites.

One that particularly caught my eye is the title change on InVision’s blog when you change tab, or the page loses focus. My instant reaction was break it down and try to recreate it, and potentially for use on my own blog.

Starting with InVision’s implementation, I scoured through their JavaScript for a little hint of how to do it. I started by searching for the string "Don't forget to read this...", which led me to this:

var j=g.find("title").text(),k="Don't forget to read this...";h.on("focus",function(){c(j),setTimeout(function(){c("."),c(j)},1e3)}).on("blur",function(){c(k)});

As suspected, the implementation has something to do with focus and blur events. On each event they toggle the title between the original string and a hard coded (what can you do?) variant of “Don't forget to read this...”.

The rest of the code isn't that useful, but we’ve a great starting point.

I started following InVision's lead by using jQuery. I setup two variables, originalTitle and blurredTitle.

var originalTitle = $('head').find('title').text(), blurredTitle = 'READ ME!';

I’m not 100% sure on the usage of jQuery for this. The vanilla code is much simpler.

var originalTitle = document.title, blurredTitle = 'READ ME!';

Easy.

Next we want to setup the focus and blur events for so we can toggle the title’s text between the two states. Assigning functions to the window's focus and blur events is simple: window.onfocus and window.onblur.

var originalTitle = document.title, blurredTitle = 'READ ME!'; window.onblur = function () { // change to blur title } window.onfocus = function() { // change title back }

Changing the title is as easy as assigning a value to document.title too.

var originalTitle = document.title, blurredTitle = 'READ ME!'; window.onblur = function () { document.title = blurredTitle; } window.onfocus = function() { document.title = originalTitle; }

Remember I mentioned about the hard coded blurredTitle earlier? Let's fix that by making it a data attribute on the title tag so the content is independant of the JavaScript and can be different per page.

HTML

<title data-alt-title="READ ME!">Page title</title>

JavaScript

var originalTitle = document.title, blurredTitle = document.getElementsByTagName('title')[0].getAttribute('data-alt-title'); window.onblur = function () { document.title = blurredTitle; } window.onfocus = function() { document.title = originalTitle; }

Now this works as we'd like. Sadly, we leave ourselves open to other libraries and plugins conflicting with our code. To minimise the chance of any conflicts, we need to preserve any functions already assigned to the events. We can then run the original functions at the end of our code.

var originalTitle = document.title, blurredTitle = 'READ ME!'; // Funcs already assigned to the events var onBlurEvents = window.onblur, onFocusEvents = window.onfocus; window.onblur = function () { document.title = blurredTitle; if(onBlurEvents) { onBlurEvents(); } } window.onfocus = function() { document.title = originalTitle; if(onFocusEvents) { onFocusEvents(); } }

Note the addition of a check for assignment to the two events. I've not done much cross-browser testing, so I may be wrong, but they return null by default in Chrome so checking their current state should be enough. If it turns out a particular browser doesn't return null then may be worth changing it. Perhaps to a type check, e.g. if(typeof() === 'function')?

As I said, I've not done much testing, and theres not that much info out their on window.onblur support*. Thankfully the feature is a nice addition, so if it lacks support, I'm not overly bothered.

*w3schools does say it has "complete" support.

[rdjpalmer-blog]

Learnings from Nudjed’s first UX sprint

Recently, I undertook what we at Nudjed have dubbed a "UX sprint". A UX (User Experience) sprint is an opportunity to focus on the user and how we can improve our product for them.

This is a partial insight into the process that’s come out of the first sprint:

Sketch, sketch, sketch

Building interactive prototypes is time consuming and expensive; sketching is quick and cheap. In an afternoon of sketching you can solve more problems than in a couple of days of building prototypes of any kind.

Focus your sketching on smaller, easy to understand problems. Break down larger problems and work on the smaller issues individually.

Think HUGE

Forget the limits and sketch ideas by the boat load. At this stage, go big or go home. Your ideas might be off-brand, or completely impossible to implement but right now no idea is a bad idea. The more ideas you have at this stage, the better the understanding you’ll have of the problem at hand. A key thing to remember here is to always consider device and context throughout this process!


*An example of a Nudjed concept whiteboard*

Grab your buddy

Once you've got your boat load, pull someone else in. Idea generation and sketching becomes a tonne easier with someone to bounce ideas off. They can be a fellow designer, or a subject matter expert. In fact, it can be almost anyone who understands what you're trying to achieve and brings some form of experience to the table.

Kill them with fire

Now you’ve got your buddy, its time to refine the ideas. The premise here is to keep sketching and refining until you’ve whittled it down into a single solid idea, or a maybe a few. Don't rush to discard ideas unrelated to the problem at hand just yet. If they’re super fucking cool, make sure you record them; you never know when they might be useful. Otherwise, kill them with fire. Well, rub or cross it out.

Prepare to test

Once you’ve got solid ideas, prepare to test. You can’t test ideas, so this is where you begin to prototype your ideas into tangible, testable assets. Prototypes can range from POP prototypes or Invision based mockups, to straight up HTML/CSS/JavaScript. The trick here is to match the fidelity to the idea’s requirements—but more on prototyping another time. At Nudjed, it’s still early days, and we're still sketching, prototyping and testing. Once we're a bit further along, expect follow up posts with more of our learnings!

[rdjpalmer-blog]

Production only code (with build tools)

We're all too accustomed to sinking time into making a site production-ready, be it removing development friendly meta tags, like noindex, nofollow, or continuous switching of a site's assets to .min.

I originally wrote this with GruntJS, but have recently (02/12/14) updated it to include a GulpJS version. Not interested in Grunt? Jump straight to the Gulp.

With GruntJS

Luckily, production specific code is a complete breeze with GruntJS.

Using Grunt Env and Grunt Preprocess we'll be able to turn on production-specific code with ease, just by setting a variable and putting a few clever HTML comments into our file. Thanks Jarrod!

Lets see the code

Grunt Env will let us specify a variable, called an environment variable, to use with the Grunt tasks.

Let's start by defining two variables, for a development and production build:

'env': { 'dev': { 'NODE_ENV': 'DEVELOPMENT' }, 'prod': { 'NODE_ENV': 'PRODUCTION' } }

When we run env:prod, the environment variable is set to PRODUCTION. The same goes for env:dev, where the variable is set to DEVELOPMENT. Great, what next? We add env:prod to the start of our Grunt task:

grunt.registerTask('production', ['env:prod', 'otherTasks']);

This won't do much on its own. Let's start to use our new environment variable with Grunt Preprocess.

Grunt Preprocess modified "files based off environment configuration". Lets look at a typical setup for the Preprocess task:

Updated 02/12/14

For some (unknown) reason, I wrote the original assuming you guys would be processing index.html into the same folder as the original “preprocessed” file. The best way to avoid destruction here is to build your files into a separate distribution folder, like so:

'preprocess': { 'index': { 'src': './src/index.html', 'dest': './dist' } }

Grunt Preprocess will take the variable, and strip out lines of code from preprocess.index.html. It does this by using a little logic within some HTML comments. Once finished, it will create index.html for us.

We process preprocess.index.html rather than index.html as we don't want to remove the unwanted lines from the original file. Instead, we want to leave that in tact and create a new version to avoid being destructive.

Note, if you want the file to be overwritten to overwrite the original file, take a look at the inline option for Grunt Preprocess.

For now, let's add this to the Grunt task:

grunt.registerTask('production', ['env:prod', 'preprocess:index', 'otherTasks']);

Grunt Env must come before Grunt Preprocess here. If this is not the case, the variable will not be set and the Grunt Preprocess won't know our desired outcome.

Setting up the HTML

Time to setup preprocess.index.html index.html. As said before, the processing relies on some clever HTML comments to figure out what code to keep and what code to strip.

The HTML comments become if statements checking for NODE_ENV's value (as per the Grunt Env task). The comment syntax is super simple, and we write them like so:

<!-- @if NODE_ENV == 'DEVELOPMENT' --> <!-- @endif --> <!-- @if NODE_ENV == 'PRODUCTION' --> <!-- @endif -->

Until we put code between these comments, running preprocess on the above snippet will actually do sweet fuck all. Let's do that now. Say we have this head:

<head> <!-- @if NODE_ENV == 'DEVELOPMENT' --> <meta name="robots" content="noindex, nofollow"> <script src="/path/to/script.js"></script> <!-- @endif --> <!-- @if NODE_ENV == 'PRODUCTION' --> <meta name="robots" content="index, follow"> <script src="/path/to/script.min.js"></script> <!-- @endif --> </head>

Running env:prod and preprocess:index produces an index.html file where it's head tag's mark up looks like so:

<head> <meta name="robots" content="index, follow"> <script src="/path/to/script.min.js"></script> </head>

Nice! No risk of noindex, nofollow making it into production. We also get a link to production-ready, minified JavaScript. By running env:dev instead, we get noindex, nofollow and debug-friendly JavaScript.

And thats it, production (and development) friendly code in less than 20 lines.

With GulpJS - 27/11/14 Update

Shortly after I wrote the original version of this article, I received one sassy tweet from @_iest:

@rdjpalmer bro do you even gulp

— Iestyn Williams (@_iest) November 6, 2014

After a quick play with Gulp, it was time to look at reproducing the technique found in this article.

Thankfully, reproducing the same outcome with Gulp is just as simple, thanks to Jason Sandmeyer and his Gulp version of the preprocess task. An added bonus is that it's even easier to set up with Gulp than it is Grunt. Heres how:

Before we get into the Gulp Preprocess magic, let's set up a JavaScript function which accepts an options object.

var processAsset = function processAsset(options) { // code will go here };

Now let's set up a Gulp task to run the function.

var processAsset = function processAsset(options) { // code will go here }; gulp.task('production' function() { processAsset(); });

Here, what we want to do is pass in the options. It's effectively going to dictate the environment we're building for (just like Grunt Env), the location of the original file and the destination for the output.

var processAsset = function processAsset(options) { // code will go here }; gulp.task('production' function() { processAsset({ 'development': false, 'src': './src/index.html', 'dest': './dist' }); });

Sweet. Now we're ready to unleash Gulp Preprocess. If you're familiar with Gulp, this is going to be unbelievably easy (or quite believable, given just how easy it is).

var processAsset = function processAsset(options) { var env; if(options.development) { env = 'development' } else { env = 'production'; } gulp.src(options.src) .pipe(preprocess({ 'content': { 'NODE_ENV': env } }) .pipe(gulp.dest(options.dest)); }; gulp.task('production' function() { processAsset({ 'development': false, 'src': './src/index.html', 'dest': './dist' }); });

Excellent. Now let's set up the HTML in the same way as we do with Grunt. I'll jump straight to the final example here. If you want more info on setting up the HTML, check it out above.

<head> <!-- @if NODE_ENV == 'DEVELOPMENT' --> <meta name="robots" content="noindex, nofollow"> <script src="/path/to/script.js"></script> <!-- @endif --> <!-- @if NODE_ENV == 'PRODUCTION' --> <meta name="robots" content="index, follow"> <script src="/path/to/script.min.js"></script> <!-- @endif --> </head>

By running the gulp task we set up, we'd end up with just the production code, making index.html look like this:

<head> <meta name="robots" content="index, follow"> <script src="/path/to/script.min.js"></script> </head>

Just like with Grunt, we get the benefits of production code (like noindex, nofollow and minified code) in production, and all the debugging goodness in development. We may get it with a few more lines of code, but they're much more familiar for JavaScript writers. Woohoo!

[rdjpalmer-blog]

What IS the point?

A quick FYI

You'll notice if you browse through my blog, you'll see an old post from about two, maybe three, years ago explaining the premise of this blog.

Since that time I've graduated, had a stint working for Eysys and am now working for Nudjed as a User Experience Developer. Needless to say, I won't be blogging about university work, but most of the other topics of user interface design, frontend development & graphic design still stand.

Let's hope I keep the blogging up this time...

[rdjpalmer-blog]

Oops! Shouldn't have said that

I had planned on giving an overview of Creative Futures and the session I attended—preferably telling you all how good the event was and what to take away from it. Instead (after writing a first draft of the above), I keep finding myself hanging on to one key detail that Kevin Ward, Editor of the South Wales Argus, decided to tell the creatives of tomorrow.

When asked about potential job opportunities, internships and placements, Kevin gave the typical “media friendly” answer—get in touch with the department you’d like experience with and it’ll be up to them. That’s fine, it’s even expected.

This progressed to talking about potential design jobs at the Argus. It turns out that they are few and far between, which again isn’t surprising considering the economical environment we’re currently living in (recession is awesome).

Where the real problem is however, the opportunities are actually there. Kevin went on to inform the attendees—largely consisting of final year advertising design students (my fellow graduates-to-be), all vying for experience and work—that the paper outsources all of the advert designs to India. Ouch.

Now, don’t get me wrong, its great of him to be honest like that—we wouldn’t want to get out hopes up now would we? But, why outsource it in the first place? Sure it’s cheaper, but when you’ve effectively got a chance to pitch to the talent of tomorrow, “come work for us, it won’t be amazing, but at least you’ll be getting relevant experience!”, logic would say take it. 

Hell, even from a PR perspective, taking on students on a temporary or part-time basis is so much better than outsourcing to another country. 

“We care about the future of this country, we want to promote local growth!”—nothing would say this better than students from the soon-to-be University of South Wales getting experience from South Wales’ largest newspaper.

Now this is obviously just my opinion, and I'm sure Kevin & the Argus has plenty of other reasons behind their decision to outsource, but I honestly don't think that it's a great idea, for the reputation of the paper or student aspirations, to openly say it without some meaty justification.

Until next time!

Rich

P.S. I'll be more positive next time—a review of the recent Port80 Localhost!

[rdjpalmer-blog]

The blog… what’s the point?

I’m not going to bore you all with typical ‘first post’ entries (bet all bloggers say that!), but instead just give you all a brief overview as to I plan on covering in the near future. I plan on starting with weekly updates of my latest university project; my final major project. I’ve been working on it for a little over a week so far, though most of that was spent contemplating what I’m going to do with it. I’m currently constructing the brief for the project, which I’ll be uploading with my next post in a weeks time (if I get it signed off, that is!). Aside from this, I hope I’ll find some time to talk about user experience—the topic of my critical paper (read: short dissertation), user interface design, front-end development and what you might expect from an Advertising Design student, advertisements! If you want to know more about me, or take a look at some of my (old) work… check out [my portfolio](http://rdjpalmer.com), otherwise [follow me on twitter](http://twitter.com/rdjpalmer) and chirp at me!