MrQwest

Blog

Breakpoints led by design, not device

It’s funny that quite often, you have good ideas whilst in the shower… Maybe it’s caused by the shower massaging your head / brain or some other magic, but I tend to find that good ideas quite often appear whilst having a shower.

This morning, whilst in the shower, I was thinking about responsive design as I’m going through the process of learning it properly for my 12412 January project.

What follows is a bit of a brain-dump. Just some thoughts I’ve had this morning. It may well be a silly idea, it may well be current practice, but it’s an idea none-the-less.

Both Stephanie Reiger and Jeffrey Zeldman have blogged recently about breakpoints and how working on a specific set of px-based breakpoints aren’t a good idea because of the immensely large current set of screen resolutions used by smart phones & other devices these days.

This got me thinking. We shouldn’t be basing our breakpoints on a device, a range of devices or all devices, but “the content”. Making your design fluid will mean it’ll resize with the ebb & flow of the viewport. Big screen? no problem. iPhone? You’re covered.

That idea is suitable for single column websites, in fact, it’s remarkably easy in it’s basic form but when you add columns to your design, making it fluid becomes a bit more difficult.

This is where media queries and breakpoints tend to come in. Some designers will set a breakpoint at 480px to then remove all the floats to the design so then everything becomes linear. You’ll have the logo at the top, followed by navigation, content, sidebar, footer all in a single column.

But why set it to 480px?

Why not open the full multi-column site on your desktop and then slowly reduce the width of the browser until the layout feels uncomfortable, and set your breakpoint there.

Let your breakpoints be led by the design and the context! Not the device.

What are your thoughts?

12 Devs of Xmas

I honestly thought I had previously written about the 12 Devs of Xmas but apparently not!

The 12 Devs project was a collaboration between Adam Onishi, Clinton Montague and myself and was loosely based on the idea that we’d offer an article or introduction to a new technology or tool each day for the 12 days of Christmas (see what we did there?)

What started off as an innocent tweet back in mid-November about wanting to give back to the web community led to Adam getting in contact – He had been having similar ideas so we decided to collaborate on something.

Clinton works with Adam and they had discussed learning opportunities through 2012 so it seemed a decent fit to get Clinton on board to!

We were soon coming up with a list of 9 other authors (Adam, Clinton & myself all wanted to author an article!) who we thought could get involved and would also bring something interesting to the table.

As with all things of this nature (and bearing in mind we had less than 6 weeks from that first tweet until the first article would go live), we had a few hiccups along the way but in the end, we received and published 12 fantastic articles about 12 really interesting technologies, tools or techniques that should help any web developer or freelancer in 2012.

Here’s a list of the articles: –

A wide variety of topics, as I’m sure you can tell.

It was actually really interesting to work with Adam and Clinton along with all the authors and curate a whole bunch of articles, along with the pitfalls that come with it. Producing the 12Devs took a fair amount of time, many emails, and many many proof-reads of each article to make sure it read correctly.

So just to round off this post, thank you to Adam & Clinton as they done most of the work. Thank you to Alice Reeves who proof-read the articles and made sure they made sense and thank you to Tom Bevan who worked wonders with the design. Without you guys, the 12Devs would have been nothing!

Same time next year?

Blog Comments

Something I’ve been pondering over the past couple of weeks is whether I keep comments open on this site or not.

I can see the value of having comments on a blog post as it helps to clarify points, answer questions or extend the discussion, but there’s also a time factor in moderating comments and dealing with spam.

My route of thinking has also led me to think that the current way of commenting on blogs is broken. Twitter has killed the blog commenting system as its easier to comment on twitter now rather than fill out log in details and jump through hoops trying to guess what letters / numbers appear in Captcha forms.

Yes, twitter unfortunately tends to take the comments away from the blog post but on the plus side, it opens these comments up to a whole new audience (mutual followers et al) so it can then create discussions, ideas and debates which is a good thing.

The problem with this issue though is that these twitter discussions soon lose context, but crucially, are soon lost in the internet blackhole. With twitters ‘unique’ search, after a week or so, tweets soon disappear from the search records; which means you can’t track twitter discussions on your site as comments because they’ll no longer appear once they’ve been culled from twitters search db.

You could get around this by using the twitter API to search through the twitter fire-hose, pull in the relevant tweets (by hashtag or link) and store them in your own db but that seems like a hell of a lot of effort.

Disqus is another option. It’s a third party commenting system. Sign up, embed their code on your site and away you go. It allows for central user signup / logins and works across a plethora of sites… but you’re now relying on a third-party for your comments. If their service goes down, you’ve lost your comments.

I’m sure there are many more answers to this question so I’d be interested in hearing your thoughts.

Do you think comments are still relevant on blogs? Are they still needed?

12412

Back in November, I wrote about another project I’m involved in. I’m working with Stephen Fulljames and Paul Adam Davis on the 12412 project.

It’s a cracking idea that Stephen had originally, and both Paul and myself jumped at the chance of being involved. I’ve a real thirst for knowledge (when time permits) so this was ideal for me.

The idea is that you pick or choose 12 different technologies, tools or techniques and learn a new one each month for 2012. Be it a new javascript framework, a new HTML technique or even just trying a new style in your illustration. It really does depend on what you want to learn.

There are no hard and fast rules either. We realise that people are busy, that you’ve got a lot on and sometimes you don’t have the time to dedicate towards learning something new, which is why the 12412 project is flexible. You can decide when and what you want to learn. If you’re only able to dedicate a small amount of time, take some months off! If you’re learning something particularly big like CodeIgniter, span it across two or three months!

No rules, just pure learning at your own speed!

The only thing we ask you to do is to blog your new found skills on the 12412.org website or on your own blog. Write a post about how you’re doing, what you’ve learnt and how you’ve learnt it. What resources you’ve used and what you’ve found helpful!

This is so you can help others looking into learning the same thing.

It’s a crowd-sourced community based learning project :) We all learn off each other!

With that said, (and following in Amber’s footsteps) I’ll give you an idea on what I want to learn over the next 12 months. This list isn’t a rule nor is it definite but it’s something I’ll strive towards!

Responsive layouts (learn properly) – This is January’s project.
Basic JavaScript and jQuery
Basic PHP and CodeIgniter
HTML5 API’s like geolocation and localStorage
Node would be incredibly nice to learn but depends on my experience with JavaScript
JSON
RESTful

If you want to get your learn on in 2012, then why not join us on 12412.org and get learning! Stephen actually wrote a great post on Tools & Technologies which may give you an idea of stuff to learn.

What would you want to learn?

Getting started

I posted an article yesterday about stripping back the design here and starting afresh. I wanted to remove the old grid system & design and start with a blank canvas.

That process started last night and is still on-going but I didn’t want to leave the site in a complete unfinished state so I’ve added a couple of nice typefaces courtesy of TypeKit (Proxima Nova for the headings, and the sweet FF Meta Serif for the body text).

I’ve also made the site fluid and responsive using a mixture of percentages for layout and media queries to adjust the design dependant on the device used to view. It’s not perfect and still needs work but this is what I’ve done so far:

body {
	width:90%; 
	margin:0 auto;
	}

This sets the width of the document to 90% and centres it on the page. This is great for mobile devices as it creates a margin around the edge of the body so the content doesn’t run up to the edge of the page.

That’s great, but for larger screens, that’d make line lengths far too long to be even remotely comfortable to read.

Using Media Queries, I’ve set the following:

/*****
    601px to 2100px MQ
*****/
@media screen and (min-width: 601px) and (max-width: 2100px) {
	body {
		max-width:960px;
		width:80%;
		}

This changes the code for screen widths above 601px. Essentially it sets the body width to 80% (again giving margins) but crucially, sets the maximum width of the body to 960px. 960 is a nice number and has worked well for 960.gs so I thought I’d stick with it. Doing this will mean that the line lengths will remain relatively short even on a large screen.

I may still play around with type-sizes between media queries but I’m happy so far :)

Addendum

I’ve since changed my max-width unit from px to em thanks to a comment from Phil Wareham over on 12412.org as it’s a more fluid unit and its size is dependant on the users default setting rather than a unit I’ve set! My stylesheet is now max-width:60em;. The 60em comes from my original 960px divided by 16, which is the browser standard.