Jordan Moore MembershipRSS

In Flux

15th September 2013

I count myself lucky to work in such an exciting industry. When friends or family outside of web design circles ask me about my job I tell them that it is exciting. I often tell them that “No two days are the same”. In a recent moment of clarity I realised that there are very few parameters in our work that stay the same. The web as a medium changes every day, in fact it is changing all the time.

The television industry broadcasts to a specified aspect ratio. This aspect ratio fits the dimensions of TV sets and the broadcast is either squashed or stretched to fit the image depending on the size of the set. The viewer has limited control over what they see and how they see it. Using their remote control, they might have an option to change the aspect ratio from 16:9 to 4:3 which distorts the image and breaks the broadcaster’s intended design.

The newspaper industry generally operates to either broadsheet or tabloid sizes on a paper canvas. The reader has slightly more control than the TV viewer, they can fold the paper and take it with them or perhaps fold it to make it easier to hold and read. However this breaks the publisher’s intended design. The graphics and the text are broken between a line through the layout originating from the reader’s fold.

The web industry is more complex. The web is constantly in a state of flux. There are no absolutes. You could almost say that no two users computers are the same. Think about the parameters that affect how our work is observed: different screen widths and heights is an obvious example, but look deeper at the additional parameters that can affect screen size — in Chrome some users prefer to browse with the bookmarks bar in view, some without. Some people might have additional toolbars that reduce the viewing area further meaning their experience will be slightly different to someone else’s. Other factors that affect how someone sees our design include different colour profiles between browsers, different colour profiles between monitors, manually adjusted colours and contrasts, browser extensions that block advertisements, browser extensions that block design and show only the content, browser extensions that add functionality and manipulate designs like Skype’s phone number extension — just to name a few.

Under the hood of the browser a slight difference in the version number could introduce any number of tweaks that affect a user’s experience of a page — perhaps the javascript engine has been improved meaning user A’s computer presents your design better than user B’s computer. Maybe the font hinting has been tweaked between a revision number, Flash might be disabled or enabled, experimental features might be active or inactive, and diving deeper into version numbers — a browser version number might be the same between two computers but they might have different versions of Java™ or QuickTime plugins. I find it hard to believe that there are a wealth of identical environments viewing our designs, the notion of no two being the same doesn’t seem so far-fetched.

The mind-bending truth is that this is changing all the time at micro and macro levels. A plugin version number can change, a browser can update automatically, the web as a platform can change and is constantly changing. The only absolute is change.

We need to be ready to respond to change. Screen size is just one parameter, but look closer and you’ll find a host of differences that are not present in other media — this is what excites me about the web. We can be true to the nature of the web, adhere to the core values that change slower than the rest like fluidity, typography, engaging content and accept change.

Building for Content Choreography using Flexbox

17th June 2013

On July 14th 2011 Trent Walton published an article introducing the concept of Content Choreography. The article opened my mind and made me question some of the limitations we face in how we build responsive experiences. At the time content reordering and reflow hadn’t been widely explored beyond JavaScript-based solutions and I had been experimenting a lot with flexbox to reorder and arrange items horizontally for Typecast’s UI. When Trent spoke about content stacking, I started to think what was achievable for reordering content along the y-axis in a single column layout.

A tale of two syntaxes

The flexible box model landscape has been through a series of fundamental changes since its introduction in 2009. The original syntax for declaring the property in CSS is still recognised in a lot of today’s popular browsers. The following 3 years brought two significant changes to the syntax mainly around the language used to specify flexbox properties.

The flexbox specification has been finalised since I wrote about using flexbox to tackle content choreography concerns in May 2012 so it’s a good time to revisit the approach. Although the new flexbox syntax has been agreed it has not been widely implemented. Since the spec was settled we have witnessed the release of new mobile operating systems like iOS 6 that boasted numerous updates to Safari - one of which refrained from implementing the new syntax and reverted to the old 2009 syntax. At the time of writing it is unclear whether iOS 7 will feature the updated syntax. Android’s default browser still uses the old syntax although Chrome on Android uses the new syntax like its desktop counterpart. That leaves us in some sort of syntax-purgatory between the final specification and the 2009 syntax.

Luckily the changes between old and new flexbox won’t affect how we use it to reorder blocks of content, just how we write the code. Some repetition is required, much like writing vendor prefixes.

The bottom line is that flexbox is safe to use on the web today for content choreography. According to’s global browser usage statistics 76.52% of users would be able to view a flexbox-based solution to content choreography at the time of writing. 23.48% might seem like a considerable amount of people, but when we break that figure down further it’s not quite so big. 23.48% takes the desktop versions of Internet Explorer into consideration and we don’t intend to use this solution that demographic.

Content choreography using flexbox is most reliable at the first major breakpoint (usually in a single column). It’s also easiest at this level because we are (largely) dealing with moving element blocks around vertically on the y-axis. When we approach content choreography from this angle we can assume most desktop browsers won’t see our reordered page. Looking again at the browser statistics for flexbox support among mobile browsers only 14.4% of users won’t see choreographed content.

I don’t usually make decisions based on browser statistics, especially project-specific decisions, but for gauging a general sense of browser support for something previously thought of as an edge-case CSS property, I think it’s worth pointing out that it is as safe to use in this context as something trivial like the text-shadow property.

A note about screenreaders

Before we dive into code specifics, we need to talk about accessibility. Screen readers will not read an altered source order changed by flexbox. Instead they will read the original document order which makes for a jarring and confusing experience for users requiring a service like VoiceOver.

Some feel that for this reason it is better to make source order changes in JavaScript rather than CSS although others counter that this hinders innovation and screen readers simply must follow our lead in pushing the web forward as a platform.

I am firmly in favour of a CSS-based approach as this is fundamentally a layout change after the effect. Using JavaScript instead of CSS to achieve a layout goal that can otherwise be achieved in CSS feels like a Frankenstein approach. I feel it’s dragging us back to the dark ages instead of helping our platform mature. If we choose to remain stagnant on issues like this then it would be like encouraging the use of JavaScript for rollover states in 2013. The fact is we have flexbox at our disposal and specced for use in CSS, avoiding it is only going to encourage the makers of screen reading software to do the same.

A solution for past, present and future

Now that we have covered the fundamentals, there are a few simple considerations to account for when building with flexbox to achieve content choreography. I have found the following mindset helps:

All things considered the revised flexbox code for a definitive specification looks like something this1:

.container {
display: -moz-box;
display: -webkit-box;
display: -ms-flexbox;
display: -webkit-flex;
display: flex;
-moz-box-orient: vertical;
-webkit-box-orient: vertical;
-ms-flex-direction: column;
-webkit-flex-direction: column;
flex-direction: column;

.nav {
  -webkit-box-ordinal-group: 1;  
  -moz-box-ordinal-group: 1;  
  -ms-flex-order: 1;     
  -webkit-order: 1;  
  order: 1;


I have updated the original demo so it considers the new syntax.

Flexbox is no longer the volatile experimental property it once was, now that we have a final specification in place and widespread support on mobile devices flexbox is a robust solution for content choreography exactly where we want it to be — where space is confined and some layout adjustment is required.

  1. Inspiration heavily borrowed from Chris Coyier’s excellent Using Flexbox article 

The Science of Web Design

14th May 2013

I have a brief observation to make about the already saturated conversation of Photoshop vs designing in the browser. Flat compositions and designing with code are part of the same philosophy of web design, you just need to be mindful of how you use them.

Wireframes, assets and flat compositions are the theory in the science of web design. You can quickly draft wireframes, produce visual assets as smaller, more robust theories whereas complete flat compositions are a larger, riskier theory — an attempt at finding a theory of everything.

Code on the other hand is where the real science happens. Using our elements, we can design with what we know to be true and work with facts rather than theories. We can use this science as a way of designing with real materials instead of asking our clients to sign off on a theory of a design that we are then contractually obliged to try and recreate with science.

The theory part is still necessary — it can help inform the scientific part during the build when the theory itself is based upon evidence and scientific fact. In other words, the more you familiarise yourself with code, the better you can theorise how things work on the web and the quicker the overall design process becomes.

Just like science you will know what experiments will work and what experiments will fail. When it is necessary to conceptualise things it makes more sense to do so in short bursts and test frequently with your scientific materials — your code.

For the record, I don’t think there is a right or wrong design process. Some approaches simply take longer than others, but certain processes may be more comfortable for certain people. Your process is your process.

As the web has become a more diverse and unpredictable place I have learned that as with physics a web design theory of everything doesn’t exist yet — it may never exist. Even when we designed for the mythical fixed width web, our flat compositions didn’t really work. They were close but while elements like typography worked in theory they fell short in practice of the misleadingly optimal conditions of the boundless canvas of Photoshop. In more extreme cases we may have designed a component that looked beautiful in theory but simply couldn’t be recreated in code. It was always a misleading approach whether we designed for a fixed width or a responsive web.

There will always be a need for theories, although I feel we need to give up chasing rainbows for a unified theory of everything in web design. New design challenges will always arise where we need to produce new, smaller theories that are quicker to test and become fact. I find it works best when more elemental theories like design systems work together with the science of web design.

Beyond the Canvas

6th May 2013

When we design we generally do so in two dimensions — length and width. They are the physical constraints of what our technology is currently capable of. Our dimensional restraints are then realised on the devices used to experience our design.

Beyond the two dimensional screen exists the third dimension (and many other theorised dimensions) — the physical space in which our designs exist beyond the canvas. Here, all sorts of physical parameters affect how a person uses our design.

Consider the user’s physical space around them — perhaps they are lying on their side on the sofa or in bed and holding a mobile device with one hand. Can the design be enjoyed when a user’s is physically restricted from using two hands? Luke Wroblewski further elaborates on this idea in his Testing One Thumb, One Eyeball article detailing the test procedure for Polar.

If people can get things done in time sensitive, limited dexterity situations, they’ll be even more efficient when we have their full attention and two-hands focused on our designs.

In a separate article Luke details the reach of one thumb with the diagram below to show the considerations for positioning navigation. This is relevant to anything you want people to reach easily, for example if you had a single purpose web app, you might want to position the primary action in the safe zone just like Instagram does with their primary action (take picture).

Image from Luke Wroblewski’s Responsive Navigation: Optimizing for Touch Across Devices article

Beyond the canvas take into account where the thumb might hover while the device is in use. Sometimes people rest their thumb along the ridge of the hardware while others hover it over a portion of the screen poised to press something. This emphasises the importance of testing with real devices. Real hardware considers space in three dimensions whereas on-screen emulators put themselves into the two dimensional canvas free from physical distractions — it’s not really representative of the physical world we live in beyond the canvas.

Book Review: Combining Typefaces

26th April 2013

The craft of combining typefaces can feel like a daunting prospect. It’s easy to shy away from the adventurous cross-pollination of different typefaces and stick to families and superfamilies to achieve typographic harmony.

Thankfully Five Simple Steps’ latest addition to their helpful Pocket Guides series from Tim Brown seeks to offer reassurance and open-mindedness when it comes to making typographic decisions. Tim approaches the subject from a web designer’s perspective:

We need to think about compositions not as layouts, but as coordinated chunks of typeset elements that do specific jobs and exist in many states simultaneously shifting dynamically among those states.

The book itself is the living realisation of Tim’s own words. The methodology described within its pages is broken down into digestible chunks for quick reference and assurance. There are recurring themes of pausing, stepping back and patience. Combining typefaces is an intricate craft that is more rewarding with practice and knowledge about the faces you work with. Tim expresses the importance of absorbing the type, its purpose, its features, the relationships between spaces and rhythms at a micro and a macro level. The deeper you know about the characteristics of different typefaces and the content that the typefaces are going to represent, the easier it is to find harmony between both entities.

Here’s the bottom line: absorb the text and the author’s or client’s intentions with vigor, because it is integral to your success. If the visual decisions you make aren’t meaningfully connected to the ideas they represent, then your typeface combinations don’t matter.

It’s a purposely open-ended book, because with design there are few definitives. The skill of combining typefaces is nourished with learning from, documenting and critiquing work. A few years ago I naively believed there were certain formulas for this practice. After reading Tim’s words I am excited about looking at typography through a more meaningful lens. Combining Typefaces is valuable addition to any web designer’s desk — one that I’ll be keeping within reach.


30th March 2013

I have spent the majority of this week wrestling with my conscience over the concept of allowing a user to switch a responsive design off. After a few healthy discussions and debates I’m still leaning towards thinking it’s a good idea.

Even though we put our efforts into meticulously designing a good experience that scales across major breakpoints, a user on a small screen is stuck there with whatever breakpoint they get — and there’s nothing they can do about it. If this happened on a large screen in you could easily remedy the situation by resizing the browser window until you find something more comfortable for whatever reason1.

This is my overriding concern — there’s no way out. There’s no way out of a bad design, an incompatible plugin, a browser bug, missing content, the endless list of potential issues someone could potentially encounter with a website whether it is responsive or not.

Our intention should always be to provide the best experience2. We always say that mobile experiences should receive the same content as their desktop counterparts, I personally feel that we should offer them the same freedom of being able to break out of the breakpoint if the user finds it necessary.

As Alex Morris put it just over a year ago:

…with responsive it’s a one way street. You can’t opt out of the media query that’s driving this thing. And that really sucks, so you better be pretty sure you can pull this thing off sonny Jim.

People have told me things like “just don’t do bad design” — come on, that’s a no brainer. Nobody goes out to intentionally do bad design, and that’s certainly not the way to approach the toggling concept as if it is some sort of safety net. Bad design will happen anyway, user tested or not — you can’t test everyone in the world.

The other voice is telling me that this is all wrong (the little guy dressed in white with the halo — or my internet friend Stuart Robson).

I (unsurprisingly) think this is a cop-out. If you think that we should be giving the site visitor the option to turn off your device agnostic design so they get a desktop view. You’ve not done your job correctly in the first place.

As Jordan says he wants to turn off RWD on bad sites. Understandable as this is it should be something mitigated at the browser level.

I agree with what Stuart says about mitigating this to the browser, it is a browser problem. The browser is at fault. Responsive web design as a methodology isn’t at fault. Ideally this would be an issue solved at the browser level, but so would a lot of other things like responsive images — the onus is on us to take the initiative. It’s not going to happen if we simply wait for it to happen.

Maybe we should have this covered with our perfect designs, and it’s ok to leave the small screen user stuck in the experience we have tailored for them, but there’s just something about it that makes me feel a bit uncomfortable, a bit claustrophobic. I’m not suggesting we have an obtrusive switch that welcomes the user on entry, or that sits in view 100% of the time. Something that’s quiet, icon-based3, that sits out of the way in the footer that doesn’t encourage the user to think “this isn’t the full view, come to the land of full view where everything is unhidden!”

Realistically, this action will affect a small portion of users. Roger Johansson (who got me thinking about this in the first place) has implemented this before and said:

The stats I’ve seen show that very, very few use the switch.

That’s encouraging to hear, the last thing I want is to lead users into a mass exodus from a responsive design I have put so much thought and effort into. I just think if it helps the odd user out in doing something they happen to find more comfortable in a pinch and zoom environment for whatever reason then we should probably do it rather than prevent them from doing it.

  1. "For whatever reason" seems a good mantra when thinking about the users here. I would wager that if you design a good responsive implementation most people will prefer the responsive default anyway.Justin Avery made an excellent point relating to this (even though he opposes the idea of a switch) saying that after the user makes the switch they will get the same content in a less than optimal view. 

  2. I’m paraphrasing Alex here

  3. If you’re looking for ideas on what this icon might be, I think Andy Clarke is on to something

Thoughts on Toggling a Responsive Design On and Off

25th March 2013

Earlier today Roger Johansson posted an article about potential scenarios for disabling a responsive design along with a demo. As noted in the article, this isn’t new thinking as both Bruce Lawson, Chris Coyier and various others have spoken about it before — the purpose was to introduce the demo along with scenarios where it would be useful.

I can’t figure out what my stance is on the approach. I’m leaning more towards thinking that this is a good idea. Some view the inclusion of an off-switch as an admission of failure in the implementation of a responsive design — I’m not so sure it is. Chris Armstrong put it nicely on Twitter:

RWD involves making assumptions on the user’s behalf, why not allow them to be overriden?

I wish I had a toggle for the bad responsive designs, the ones that “don’t get it” (i.e they hide content and bastardise the experience rather than adapt it appropriately). Even if we have examined and tested our assumptions thoroughly, there is always a chance that we’ll get something wrong and I think users deserve a chance to undo something we impose on them (with good intent).

Roger’s article discusses the language around the toggle switch:

The trickiest part is probably what to call the switch. Phrases like “View desktop layout”, “Go to desktop version” and “View full site” seem like saying that what you’re currently viewing is missing something. So instead I called it “View fixed width layout” (and “View flexible width layout” to toggle back). I don’t really know if it helps end users understand the difference, but I think it’s a more accurate description than using “desktop” and “mobile”. Someone’s browser window being narrower than 960 pixels, or 1200 pixels, or wherever you choose to draw the line, does not necessarily mean they’re using a “mobile” device.

After years of m-dot websites users have been conditioned to feel that “View desktop site” means that the page is hiding something from them. That’s why I think trying to add language to the switch won’t work, it may create the feeling of deception that exists with many m-dot sites. Also using terms like “fluid” and “fixed” will mean nothing to the average user. The language would need to feel familiar and create an expectation — although in this situation, the user’s expectation is that the button will reveal a “full version” revealing the stuff that the page is hiding.

I think we could do something visually rather than give it confusing and misguided terms. I’m not saying this suggestion is the definitive approach, it’s more of a rough idea. The image below gives you an idea of what an icon might look like before and after it is toggled.

The left icon shows what it might look like in a standard responsive layout with the option to toggle a fixed width layout, the right shows how it would look from the fixed width layout if the user wanted to switch back to a responsive layout.

Again — this is just a rough idea using a couple of repurposed icons, if you do decide to implement an off switch, then I suggest trying a visual reference rather than potentially confusing wording.

The Discussion About Flat Design Has Gone a Bit F-… erm…

25th March 2013

All of the talk around flat design, flat UI’s, (the even more cringeworthy) almost flat design, flat showcases, what is “flat”, what isn’t flat is all getting a bit tiresome.

I haven’t mentioned it here simply because I believe it is a design style that doesn’t need labelled1. I’m struggling to put into words why it bothers me so much, not the visual style — which I happen to like a lot, although some of the bandwagon generated designs expose themselves in a simpler style for missing fundamental design principles — but rather the reference to it.

Here are some graphs that annoy me:

You could argue that searching for “flat UI” is steering the results somewhat as it’s a combination of words that didn’t exist together before flat design was a thing. Let’s see what “flat design” brings up:

A huge peak in 2013, as expected. There is lots of talk about it before this year too, although this could be discussions about interior design for apartments.

I’ll end with one of my favourite graphs — the mortal enemy of flat design:

Hopefully 2013 holds more interesting discussions in store other than a visual style lacking gradients and shadows.

  1. Apart from one reference to Noah Stokes implication that responsive web design is more or less equal to “flat design”. 

Under the Microscope

12th March 2013

When designing for small screens keep in mind that everything you do is under the microscope - design patterns, interactions, usability, speed — everything. These wonderful little devices that we cup in our hands offer a small, personal and intimate window in which to enjoy the web.

It is more important than ever that we get the little details right. A small screen space is limited in what we can show at any particular moment - and that’s what we are dealing with here, lots of tiny moments. By contrast a large screen offers plenty of room for design problems to hide or go mostly unnoticed. Small displays don’t allow that. They are unforgiving to poor design decisions which is why a lot of designers are quick to scrutinise and attack a poorly implemented responsive design. This type of scrutiny is more often than not about the design and technical aspects whereas users scrutinise with a different lens which generally concerns more important aspects content and value.

I suggest looking at a confined layout as a series of moments. Ask difficult questions of it: "Does this moment achieve what I want it to achieve?", "Does this particular moment offer any value?”, "Does this moment facilitate or distract from the overall message/objective/goal?", "Does this moment make sense independently or does it require the bigger picture to give it context?"

Our design decisions are magnified in this personal space. It’s a rewarding space that can offer intimacy and undivided attention - small screens deserve good experiences and a responsive approach1 can allow that good experience to permeate any device or dynamic that it is faced with.

  1. Aside: responsive design doesn’t just mean making things work on small displays. 

The Scourge of Social Plug-Ins

3rd March 2013

Maybe I am a bit of a control freak. When I make something, I want full editorial control over the visuals and the content. And maybe it’s the minimalist in me thinking “if it doesn’t add any value — remove it. Everything else is distraction”. I just can’t bring myself to switch on comments or social sharing buttons on this website — I can’t do it. I’ll start with those shiny little not-quite-visually-similar-enough social buttons that tally up how many times your page has been shared on their networks via their JavaScript generated buttons.

First of all, unless you are The Next Web, Mashable or another web giant attracting heaps of traffic on a daily basis, a social count button isn’t going to do you or your brand any favours. Picture this scenario: you arrive at a random article on this website, you notice social buttons and note that the article has been shared 0 times on Facebook, 1 time on Twitter and 0 on Google Plus. What is your first instinctive thought? Here’s what I think — if I spot the buttons before reading the content and notice that it hasn’t been shared, I immediately doubt the integrity of the author and the trust of the message from the website as a whole. I read a lot of articles on a daily basis and sometimes I’ll gauge the usefulness of article on the recency of the post vs the share count. Yes, it’s shallow, like judging a book by it’s cover although in my defence, there are a lot of “books” to get through, whether intentional or not a social button can read like a review.

I don’t want to tread over any ground that Oliver Reichenstein has already covered in his fantastic Sweep the Sleaze article and follow up (and you should read it next if you haven’t already) so I’ll talk about things from user perceptions rather than usage and mechanics1. A low button count is damaging. That’s my opinion and you’ll have trouble convincing me otherwise. The low count can be a result of people sharing the article by other means, like using the native sharing options in an operating system like iOS or just through good old fashioned manual sharing by copying and pasting a link into your preferred social network. These methods aren’t going to add anything to the button count, it’ll remain embarrassingly low like a poor review. According to Oliver Reichenstein’s piece around 20% links shared on websites he surveyed were completed via a social button, the other 80% were manual shares. So we can conclude that the ROI is poor.

As I mentioned before, if you are a running high traffic site and you want to use the buttons as some sort of demonstration of popularity, then I guess that’s a viable use case albeit a bit egotistical. I would wager though that the people that use them are passive sharers and wouldn’t add any value to the piece you want them to share and they probably don’t have the influence you would like to spread your message further and to the right people.

Social buttons are tools created by social networks to benefit… social networks. They want to take the conversation off your page and onto their network. I’m fine with that because I made the conscious decision to leave comments off on my website, but just think about that for your project.

Speaking of comments, they can be as damaging and in some cases more damaging than a poor share count. For comments to work right you need to stay out of the user’s way and that means leaving them completely unfiltered and moderating later. Obviously this leaves your site open to trolling — but that’s the nature of the beast, the danger of comment roulette.

Think about it this way — we are publishers. Would the New York Times let someone wander into their offices off the street and write an unsolicited remark at the end of one of their articles? Imagine reading the front page of the New York Times and at the end of a finely written piece you find the words “First!” or “Great article thanks!”. It just looks trashy. Compliments are nice to receive but to publicly display them amongst a list of generic back-pats just doesn’t sit right with me. I don’t need someone to essentially say “Good hustle Moore!” after my content.

By now you have probably guessed my opinion of comment models on the web — it’s not that I think the standard comments model is broken, I just feel like it’s not a one-size-fits-all solution. If I wanted to open up a commenting system for my website, I would potentially do something like this:

  1. Write the article (no brainer)
  2. Associate a hashtag with the article (or all articles) — a hook that I can look for on social networks
  3. Make the effort to find people’s opinions on the piece on social networks (if they use the hashtag, then this is step is easy, if not, so what — just keep looking. Valuable opinions are worth mining for)
  4. Revisit the article having gathered opinions and use the insightful thoughts to add value to my original content and credit the necessary people
  5. Profit

You might be thinking, that sounds like a lot of work — it is. But take note that while digging for opinions, I’m engaging with my audience, maybe asking them to elaborate on some comments, while building trust and integrity with my work. The beauty of an approach like this is that if something you write is completely wrong or you have missed a crucial point then you can find people that disagree (trolls or otherwise) engage with them and maybe even correct the original article with their views. The important part is you maintain full editorial control, not by altering their comments, but building upon their input and giving credit where it’s due.

People can add value to an article without the article being incorrect, they can elaborate on points which you can add to the end of the piece and improve it. I call it editorial comments.

When talking to clients about this stance on social interactions, I talk about it as part of a larger social media strategy. The old/common approach is a plug-in social media strategy — shiny buttons won’t carry out your social media strategy for you. You need to do that, it requires effort to do it properly. It’s not enough to slap some cheap JavaScript buttons onto your page and mark off the social media box of your project goals. A social button cannot become the voice of your brand, that’s a human’s job.

  1. They’re a performance hog too. In general a web page gains around 100kb of useless bloat with social media buttons (depending on how many networks you add). Update — in the spirit of editorial comments Jake Bresnehan mentioned on Twitter that Nicolas Gallagher has produced a lightweight social plugin script that weighs in at 4kb minified — a great deal lighter than the official editions. 

← Newer Articles Older Articles →

About Jordan Moore

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


By becoming a member you will help support my writing and the growth of this site as well as receive the Transcripts newsletter with interviews from the web's finest makers and Tickertape

Site ambassadors