I'm publicily rebuilding this site - you can find out more by reading this blog post
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?
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?
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?