1st February 2014
Being a dad to 3 young kids under the age of 4 has taught me plenty of valuable lessons in such a short space of time. It has affected my everyday behaviour too. Just over a year ago, my son started going through the developmental phase in his life where he was repeating every single word he heard. Every. Damn. Word.
As a result, I have cleaned up my language when I’m home and in their company. A stubbed toe off the fireplace is no longer accompanied by a loud f-word, it’s usually followed by an animated "Ouch!" or a "Fff-ouch!" in some particularly painful instances.
Having kids has made me more aware of when I turn the air blue. Now when I swear it’s followed by a reflex reaction of guilt “Did the kids hear that?” and then I usually think “That was unnecessary.” During some stressful occasions when the kids aren’t present there are times where I feel “That f-bomb was entirely necessary and justified. I feel better after that.”
If you’ve read my writing before, you’ll notice that I rarely swear. This is a conscious decision for two reasons:
I wanted to title this post “Watch your fucking mouth”. It’s an ironic quote from Nicholas Cage in the ridiculously fun action-thriller Face Off. It’s my favourite line from the movie and it would have been an edgy, ironic title and it might have made a few people laugh along the way.
The problem is a URL like http://www.jordanm.co.uk/post/01234567/watch-your-fucking-mouth wouldn’t stand a chance against a web filter. Some web filters might even block my domain from future browsing sessions. I’d hate to think that my content was being blocked because of something completely within my control and preventable. For me accessibility comes first and if some users can’t even access my domain then that’s an accessibility fail at the first hurdle.
Most web filters look for blacklisted words, search terms and URLs. Some offer real-time content filtering which means they probably have the capability to scrape your page for profanity and block it from the reader if they are accessing your page from a filtered network.
My good friend Chris Armstrong suggested the potential for new semantics that might allow the user to hide profanity and still enjoy the content.
@jordanmoore it does raise a question around accessibility actually…what if there was a <swear> tag, that a user could show/hide in browser?— Chris Armstrong (@Armstrong) January 30, 2014
To me this underlines the superfluous nature of foul language in web writing. If the content reads fluently with inline
At it’s worst foul language is used to give weight to a weak point that requires extra leverage. For example:
"In a lot of cases it isn’t necessary to support IE7."
A pretty weak and obvious statement, right? How about:
"Fuck IE7, we need to stop supporting it."
All of a sudden, a weak statement has a certain air of gravitas about it. It’s the same concept, just delivered differently. It’s an easy way of making something sound more compelling than it actually is.
Now let me make this clear: I am not anti-swearing, nor am I telling people not to swear. You are your own person and you should feel to write whatever you like. I’m not even anti-swearing on the web because one of my favourite posts, Fuck You by Brad Frost, contains a fair amount of it, but it forms the crux of the issue he is pointing out and hey, it works really well. It strikes a chord instead of feeling forced.
My point is to think about your audience. Web and parental filters are barriers that we don’t talk about very much. When they scour the web like sniffer dogs seeking to censor parts of the web I’d rather not draw their attention to the scent.
19th December 2013
The “view full site” link has fostered a negative behavioural trait. When faced with problems on a dedicated mobile site users have a tendency to look for the full site link like some sort of safety net.
How often have you arrived on a broken link on a dedicated mobile site from a search engine and looked for the full site link in an attempt to solve the problem? It’s instinctive among web savvy people, but I have witnessed people outside of our industry perform the same behavioural trait in a similar unconscious manner.
The sad truth is “view full site” can also be used by web developers as a safety net if the small screen experience isn’t good enough. The pinch-to-zoom fallback is there when a poor implementation fails and lazy web developers capitalise on the user’s newfound habits of correcting such website issues by clicking this magical link.
This leaves responsive designers in a difficult position. We are already on the back foot when the user arrives at our lovingly tailored responsive experience — we have to convince the user that our responsive design is the full experience after years of being misled to think they are getting half a product by dedicated mobile sites overzealous in removing content and stripping back features
Part of the problem is that from the average user’s perspective a dedicated mobile site may not look too different to a responsive site on the surface. If they run into problems with our design or perhaps they expected to see some content that is missing because it was simply overlooked, do they feel misled by default?
So how do we fix this problem? By continuing to fight the good fight with ubiquitous experiences and earning back the user’s trust over time — it’s not going to be a quick fix. Bad habits take time to eradicate. The great content swindle needs to stop.
15th December 2013
I’m not going to make any grand statements like “newsletters are broken”, newsletters are still a great way of bringing content to the reader rather than asking the reader to come to the content; and that’s a powerful thing when RSS usage is dwindling. When I built Tickertape, I wanted to fix a few things about how newsletters are both presented and read by their readers.
The design objectives for Tickertape are as follows:
Only quality writing and resources should feature in Tickertape. Each digest aims to have around 5 links, but this target is flexible — it has to be. Quality content will never be compromised in favour of filling a link quota. If another Tickertape issue is ready for release but it contains only 2 or 3 quality links then that’s absolutely fine.
Traditional industry publications typically have a daily, weekly, bi-weekly or monthly schedule, Tickertape doesn’t. It’s a frequent publication. The content dictates the publication date rather than the schedule - otherwise quality suffers to meet a release date.
Tickertape is all about relevant content. The links are ordered by date from newest to oldest — some might be as recent as today, some might be yesterday — just relevant, informative content from the best authors on the web.
Usually industry newsletters provide relevant content, I wanted to build on that with Tickertape. The dates are published in a relative format to help you quickly identify recent content.
Compatible email clients take relevance a step further. Items you have already read appear different to items you haven’t read. The articles you have already read before the issue arrives in your inbox appear in a dimmed grey in contrast to new content. This helps you quickly see how relevant the current issue is to you. Whether the items are all exciting new content you haven’t read, or if it’s content you can quickly tell if you’ve already read then Tickertape has done it’s job in letting you decide if you want to read or not and get on with your day. It’s disposable in the best sense of the word.
Personally this is my favourite feature. “Slow” is generally considered to be a bad thing on the web — I think we can embrace “slow” as a benefit and use it effectively.
Think about the typical email newsletter — does it always arrive at a convenient time where you are ready to read it? Probably not. There are many occasions where I have opened an email, scanned the contents and thought — I’ll read that later, only never to return to the email.
Sometimes marking it as unread is enough of an indicator to come back to it, but sometimes your initial guess of where and when later might be mightn’t correlate with your current situation.
Imagine a scenario where I open a newsletter in the morning before work. I mark it as unread to come back to it later this evening when I have a few hours to spare only to find that later that day I ended up resting and avoiding emails. This is a common situation and Tickertape approaches the problem differently.
Tickertape allows you to send the articles from the current issue to Readmill, iBooks or your Kindle1 meaning you can pick up the current issue of Tickertape when it’s convenient for you to do so. No marking as unread, flagging or tagging.
Newsletters have become comfortable with their current format. Tickertape reimagines how we use email content with quality, relevant and timely content.
10th December 2013
Now for something a little different. With Christmas around the corner I thought I’d share a collection of great gift ideas for your fellow web designer.
Fifty Three are best known for their impeccably designed and critically acclaimed Paper app for iPad. Now Paper has a hardware companion — Pencil. The milled, graphite brushed aluminium finish provides a good grip that compliments the carpenter pencil form and the eraser on the opposite end of the point does exactly as you’d expect in the app.
Available from Fifty Three
This is a really neat idea. Slate is a portable desk that houses your laptop and a mobile device on your lap whilst providing you with space to take notes or even use a mouse. The holes beneath the space for your laptop helps keep your legs and your computer cool.
Available on Kickstarter
A must for the responsive web designer. This device stand from Vanamco houses up to 6 devices leaving a gutter for USB and charging cables.
Available from Vanamco
Sketches are an interface designer’s best friend. They’re quick and easy to produce — devices however are not. When producing mobile UIs it helps to frame them but this takes away a lot of the flow and spontaneity that sketching brings. UINK.it solves that allowing you to stamp device templates anywhere you want.
Available on Kickstarter
Those wireframes aren’t going to draw themselves. This exquisite drafting pencil produces the perfect weight for fast wireframe production.
Available from JetPens
Gridbooks produce high quality notebooks for wireframing. Their Web Book features a 15-point dot grid that divides vertically into two, three, four, five and six columns with horizontal grids that can adapt to two, three, four, six, eight, twelve and sixteen columns. The opposing page features space for notes like objectives and goals to help keep you focused and produce great looking wireframes ready for sign-off.
Available from Gridbooks
Mental Notes are a set of 50 cards designed as both reference and brainstorming tool for psychological design. The first set of 5000 cards went in a flash, so make sure to get notified of when new batches arrive so you don’t miss out.
Available from Get Mental Notes
Five Simple Steps’ popular Pocket Guides series have made the transition from digital to physical format seamlessly. The first set of books features works from The Standardistas, Brian Suda, Rachel Andrew and Joe Leech. You’ll also receive the digital editions when you buy the paperback versions.
Available from Five Simple Steps
The quality of Hoefler & Frere-Jones’ typefaces speak for themselves. Their long awaited web fonts service arrived earlier this year and the time taken to port their elegant library for the web shows in their ScreenSmart fonts. With packages starting from $99 per year it’s easy on the wallet too.
Available from Hoefler & Frere-Jones
4th December 2013
After watching Indie Game: The Movie during Channel 4’s video games night I couldn’t help but notice the parallels between game design and web design. There are elements of this that I have noticed before, but I thought I’d share some of the facets of video games that aren’t spoken about so often in relation to our industry.
Note that this isn’t a discussion about gamification, rather a look at how game design applies to the web.
Pong is perhaps one of the greatest examples of usability for a digital product. The original Pong arcade box featured two knobs. A knob on one side of the box for player one and one on the other side for player two. Twisting the knob on the either side moved the corresponding on screen paddle up and down.
The box had no instructions. The player was left to learn the behaviour and play.
More complex games that require extra behaviours to progress (let’s use Tomb Raider as an example) produce scenarios where environmental situations encourage you to recall certain behaviours, perform the input combination on the controller to trigger the behaviour and progress. In fact most games are essentially sequences of pattern recognition.
One of the most enjoyable facets of gaming is when the player is in a state of flow1 and they perform the actions almost instinctively. The game then feels more rewarding to play because the player is progressing at the ideal pacing and feels more at one with the game when difficulty level and ability level are in perfect synergy.
Repetition plays a key role in establishing these actions in the user’s mind. If you strip the surface texture graphics and reduce the polygon count in Tomb Raider, you would notice that the environments would look quite similar in that they can all be traversed using the same character behaviours but in varied and more challenging ways — the foundations remain the same from the first level through to the end.
There are many lessons we can learn from how games are designed and built and apply the findings to the web. Input combinations that trigger specific actions could appear in the form of gestures or even as part of a visual language. Think about how games teach you to subconsciously perform such actions using techniques like pacing and repetition to help engrain them in the user’s intuition.
You might think that kind of thinking could lead to a deviation from established web design patterns” - it all depends on the implementation. Imagine a first person shooter that didn’t bind the fire action to the right shoulder button on a controller or the left mouse button and instead required you to press a button like ’x’. It would be infuriating because it simply doesn’t feel right. Design patterns occur in games too, they’re just sometimes hard to spot because they almost feel like second nature — which is a very good thing.
We can learn a lot from point-and-click adventure games. Not even in regards to the nature of the input for the genre — my favourite point-and-click adventure was Grim Fandango which was labelled a point-and-click adventure even though it was controlled entirely by keyboard — I’m talking about how they are structured in terms of their narratives.
All good stories have a beginning, a middle and an end. Point-and-click adventures are (mostly) linear stories made up of sequences that require item collection and puzzle solving to advance to the next sequence. The difference between the web and point-and-click adventures is that the latter wants you to struggle to advance, but not too much. In most cases on the web, that’s not what we want to do, but there are certainly elements from this genre that we can learn from and apply to the web. Adventure games are trying to funnel the user down the linear story without leaving you completely stuck, otherwise the user is less likely to feel compelled to finish the game. It’s the in-between bits that hold this narrative flow together that interests me the most — when the player starts to struggle the game has a job on its hands to keep the player interested and help them back into the narrative so the game can tell its story.
Characters respond to changes in the dynamics of the game. If you are looking for a specific item to proceed to the next sequence and you’re having a hard time doing so, some specific characters will become aware of the situation at hand and perhaps provide help or hints when spoken to.
This sense of situational awareness can apply to the web too. As a user progresses through our own narrative, situational awareness can help the user progress to the next scene. Imagine a user adds an item to their cart in an e-commerce website — the dynamics of the situation have changed from when the user began on their journey and we can help them through to the end of the story. Perhaps the user digresses from the shop after deciding to read a rather interesting article on the store’s blog about how the store has been donating a portion of profits to charity. What if the blog post had a helpful block at the end to inform the user of the change in dynamics? Something to the effect of: “And you can help us donate too by buying that t-shirt in your cart. Would you like to do that now?”
Games speak to the players in plain English. No technical jargon like “Your session has expired” — something informative, clear and to the point, but not abrupt and not too long so that it wastes time either. Narrative content is hard.
We really should listen to video game designers and developers a lot more. I would love to see people like Raph Koster speak at web design conferences and talk about flow theory, establishing core gameplay and environmental mechanics and the similar challenges we face in both industries. When it comes to telling compelling stories and teaching users to perform instinctual reactions to scenarios, the games industry has been doing this for a long time and have left a lot of good examples for us to learn from.
28th November 2013
In the interest of openness I thought I’d share my set of design principles that I have been experimenting with for the last few weeks. They serve as a guide for design decisions and help me focus on good, honest values when making products for real people.
I’ll run through each principle individually below expanding on its meaning. Some have been borrowed and tweaked from elsewhere and noted in the footnotes.
A product should be useful. To be useful it needs to serve a specific need or a set of needs. The needs belong to the user and no-one else1. We need to know what the user needs through and through otherwise we’re making a product nobody wants.
To serve needs in the most efficient manner, the solution must be visualised clearly without obstruction. Obstruction may come in the form of the proposed platform for the product — it’s best to think without the distraction of how you’re going to solve the problem, rather think in terms of the impossible — how would it work if it worked like magic?
A design without content is, at best, a guess. It’s a guess at how it should look, how it should function, how it should feel. One big assumption. The content informs the design and the overall shape of the product. Preconceived notions of how a website should look must be ignored and trust placed in the content to lead the decision making. Content is an absolute which holds value to the user and must be treated with such esteem rather than being regarded as a commodity.
A simple product is more likely to be easier to use and rarely has complex problems to fix. Why design something complex? Superfluous design is nothing but exercise for the ego. Simple design is clear, useful and honest.
In every sense of the word. From screen readers to Kindles. IE7 to Chrome Canary. A simple product shouldn’t have to bend and break to work everywhere.
Take a device agnostic approach to delivering an experience that works where the web works for past, present and future devices, interfaces and scenarios. The best way to achieve this is by staying true to the nature of the web.
Where time and budget are fixed, scope needs to flex or else quality suffers3. Less important features can wait for another day, priority features shouldn’t be compromised for the sake of shipping with all features. It’s better to do one thing well.
The finished product should be useful, otherwise design hasn’t achieved anything — it’s solving imaginary problems. A useful product solves real problems for real people.
The finished product should resonate with people and touch their lives in a positive, meaningful way.
25th November 2013
Having authored work for Smashing Magazine in the past I know this for sure: they care a great deal about the quality of their content. They have an entire editorial team dedicated to scrutinising every word and every technical claim by contributors to their publication — which is an amazing thing because it is reflected in the high quality writing consumed by thousands every day.
Their book series is an extension of this quality going beyond the screen in the form of a beautifully presented collection of work from some of the web’s greatest thinkers. The Smashing Book 4: New Perspectives on Web Design is 480 pages long and geared towards the intermediate web designer (or developer). I felt right at home when I settled into the contents. The theme that runs throughout is the idea of looking at things from a new perspective.
This is evident in chapters from very qualified thinkers and doers like Harry Roberts. In his chapter on Modern CSS Architecture and Front-End Development Harry details the considerations for planning for today’s more complex web.
The book covers themes that fit a mature web. Nicholas Zakas' chapter on writing and maintaining future-friendly code is littered with useful takeaways. It's easy to get stuck in our web development bubble and write code simply to get things done — Nicholas reminds us the importance of communication and that our code is meant to be read by humans as well as computers.
Addy Osmani's chapter on finding and fixing mobile web rendering issues is another example of the level of detail each chapter covers. He covers everything from achieving the magical 60fps refresh rate for animations to paint and layout problems. The book really takes the themes from The Smashing Book 3 and evolves them to address the real everyday issues that arise from advancing our fundamental knowledge of topics like responsive web design, performance and typography.
Corey Vilhauer and Nishant Kothary's chapters deal with designing for the needs of real people — editors and users alike. Nishant delves into the psychology and behavioural patterns of stakeholders with useful, palpable advice on design reviews and achieving sign-off.
The closing chapter of the book sees my friend and mentor Christopher Murphy produce a rousing piece about creative spirit. Chris use his experience of educating in the field of web design (which I have had the privilege of experiencing first-hand) and dissects James Webb Young’s technique for producing ideas from 1965, expanding the key themes effortlessly which in turn results in an inventory for idea generation.
The Smashing Book 4 is excellent value for money. Imagine if the stellar line-up of authors and their valuable, relevant topics were presenting their work at a web conference — you would expect to pay at at least £250 for entry, a variable amount for travel depending on where you live and other living expenses for the duration of the conference. The Smashing Book 4 is conference quality topics in the palm of your hand, permanently committed to paper (or the medium of your choice) ready for you to consume whenever you want.
The web has grown up and The Smashing Book 4 is the perfect field guide for making and maintaining things for a future-friendly web.
23rd November 2013
Our tools are antisocial. They don’t talk to each other very much, or very well, or at all most of the time. One tool does the editing, one does the uploading and another lets you see the result on the web. Some tools are negotiators, like CodeKit. They try to help everyone get along by becoming the invisible glue holding the whole operation together.
I can live with some of this friction. I feel it most between browser and code editor though. Considering the code editor makes the stuff you see in the browser it’s funny how they barely speak to each other if at all in most cases.
What if Sublime Text1 had a detachable browser window docked on the side? Not only could that being browser and editor closer by visual proximity but imagine if it unlocked new capabilities that allowed them to talk to each other…
Style injections that allow you to see instant results and automatic page reloading for markup changes is one of the biggest time savers an application such as this could offer. We have already patched this behaviour with our negotiators like LiveReload and CodeKit, but if it worked straight out of the box with a hybrid browser and editor tool it would reload more reliably (i.e after CSS is preprocessed — I have had frustrating run-ins with compilers that can jump the gun).
I believe any CSS changes should be immediately reflected in the docked browser window without the need for saving the file in a way that doesn’t destruct the page — that would require a bit of intelligent logic when creating new style rules in the middle of a Stylesheet to assume a closing brace.
It should preprocess LESS and Sass files too and while we’re theorising — it should have the capability of doing that beyond the local environment (e.g over FTP).
This is an area our negotiators have mostly covered so it’s not the biggest pain point of web development.
Right clicking in the browser and inspecting element should bring you to the appropriate line in CSS inside the editor itself.
This is one of the biggest problems in web development workflows. The current behaviour allows you to inspect and make adjustments in the browser. While this is a good thing the boost in productivity is lost when you have to retrace your steps, copy and paste your code, save, reload, realise you didn’t retrieve all of your inspector changes, despair, recreate them again in the browser, meticulously retrieve your changes this time causing your workflow to slow to a snails pace and watch the perceived benefits of in-browser editing vaporise before your eyes, copy and paste your code into your editor, save, hesitate, hesitate a little more, then decide to open a new browser tab and leave the tab containing your ideal design state the hell alone, load the URL, and hope that it works.
This isn’t how it should be.
By bringing browser and editor together, the disconnect between both entities is non-existent and the issue with the workflow above is vanquished. No more copying and pasting and retrieving edits lost in code.
There are a couple of potential limitations: why favour CSS over DOM inspection when inspecting elements? I don’t necessarily think it should. Perhaps when an editor tab is open containing markup, inspect element should find the selected element in the markup and a shortcut key could help you cycle through other areas that it affects in CSS. This shortcut would also help solve the problem of navigating multiple CSS rules. Sublime Text’s minimap could become a temporary space during source inspection to show the affected areas in CSS and HTML, line numbers, file names and provide a visual shortcut to where we might want to go. Maybe even some quick edit abilities like Adobe Brackets would be useful in this space.
You’d think live editing would bring big changes to how we save work - it shouldn’t. Live edits, like editing in browser inspection tools, are only committed to code when saved in the editor. So if you change a page through the live editor and close without saving, your changes wouldn’t appear next time you loaded the project - which is exactly the way it should be.
One of my other gripes about current web development tools is that it’s difficult to roll back to a safe state. If you are working on a project and you make some heavy changes that mess up the code and design it’s a Cmd-Z marathon to find the last safe and stable state.
Milestones would help solve this problem. It’s a feature already present in Espresso and it’s super-useful. Before making major changes you could press a different hotkey instead of Cmd-S to save a milestone. You could optionally name the milestone and continue to make the major code changes knowing there is a saved state you could quickly roll back to if it all goes wrong.
For the browser element of this editor to be a true web design tool, it should allow you to switch between Trident, Gecko and Webkit2 rendering engines. The context menu shouldn’t change in each rendering engine, you should be allowed to inspect element and see the affected code in each browser to quickly diagnose layout issues and make changes in the code editor.
There have been attempts by integrated development environments to accomplish some of the concepts above, but no existing solution has truly met each pain point satisfyingly. I’m not a programmer so I don’t know how feasible it is to accomplish each point, all I know is as a front end developer at the coalface these problems begin to grate on you after a while and it needs fixed.
Insert your favourite code editor here. ↩
AKA Internet Explorer, Firefox and Chrome. I think that they should keep their rendering engine name so people know the technology behind the branded browsers as well as to cover potential issues that browser vendors might have building their browser into a hybrid browser and code editor. ↩
19th November 2013
Knowledge is a gift. Having a few years of experience in the web industry under my belt there are plenty of opportunities for prior knowledge to solve design problems. But knowledge comes with baggage. Knowledge stifles potential.
When approached with a design problem we have a tendency to try and solve the problem through the knowledge of our platform before writing a single line of code or painting a single pixel. We think about the restrictions and limitations that come with our platform and try to fit a solution to these requirements.
The problem is that this complicates the solution before we have even started. The solution has already been hindered by our understanding of the intended platform.
Starting from impossible means worrying about the details later. This helps you work with an unclouded view and see the solution more clearly.
Hailo is a common example of the importance of starting from impossible. The design problem was clear: hailing a taxi sucks. The success rate varies, sometimes you need to call the cab office and tell them where you are, sometimes it’s not even obvious where you are, sometimes the taxi driver gets lost on their way to pick you up, it’s hard to know how long it’ll be before you can get a taxi — it has the potential to become a whole host of frustrating problems.
I imagine the conversations at Hailo started from impossible: “If getting a cab worked like magic, how would it work?”
In the impossible scenario the taxi would know when you needed it and just appear wherever you are standing to take you where you wanted to go as if by magic. This is the solution to the design problem staring you right in the face! It’s important not to lose sight of it as you introduce real world limitations.
In Hailo’s case, their limitation was the platform and the device. How was the device to know the thoughts of the person who needed a taxi? The person could press a button to tell the device that they needed a taxi. How would the taxi know the person needed a ride? The taxi would have a communicator that could tell that the person pressed a button on their device. How would the person know that the taxi received their request and wants to pick them up? The taxi driver could also press a button telling the person’s device that they are on the way.
So in essence the design solution is an app with a “Pick me up” button and a confirmation message to tell them their taxi is on the way. It’s a beautifully simple solution to a frustrating problem. The user doesn’t need to worry about the communications between the device and the taxi, or about how the taxi uses the device’s location sensors to know where to pick them up. They just need to worry about pushing a button when they need a ride.
By removing the restrictions and the limitations that prior knowledge imposes on your thinking, imagining the impossible helps you to see the solution more clearly.
15th November 2013
The Chrome development team proudly announced that they addressed one of the most common complaints from responsive designers about their browser - Chrome now let’s you resize your browser down to 320 pixels wide1.
While it’s nice to resize down to the width of some popular mobile device screen widths it reminded me of some of the issues with relying on resizing a browser to test responsive designs.
Limitations with testing in a desktop browser:
There are more reasons, these are just the ones that spring to mind first. I’m not saying you should stay away from desktop browsers altogether for responsive design testing, in fact I find a narrow browser window a great foundation for making a start on responsive layouts — it’s part of my workflow.
Generally I find that using a desktop browser is good for quick layout tests — for example if something is badly broken it might be quickest to diagnose on a desktop browser, fix and test on real devices. It’s quick, it allows for page source inspection — it would be foolish not to make use of these tools.
The point I’m making is that there are testing limitations that you wouldn’t face with a suite of real devices2.
Jordan is a web designer passionate about responsive web design and content choreography. He as a penchant for typography having worked previously with the Typecast team.
He writes occasionally for .net Magazine and Smashing Magazine and currently works for Eyekiller in Bangor, Northern Ireland. You can follow him on twitter @jordanmoore
Available for freelance projects in early 2014