Just processing some photos from a lovely visit to Christchurch and Muddiford. Nothing quite like a coastal walk on a nice day for clearing the head.
Walking around Hengistbury Head
Zoë
I must have taken this boat’s picture every visit to Christchurch - just love it’s weathered tones
I thought Oliver had a bit of a CSI/NYPD look about him
I got Jane to pose between beach huts - great leading lines
Responsive design. A real hot topic, and one of the interesting things that has come out of improvements in browser technology combined with the constant creative pushing of designers and developers to make the most of the power and limitations of HTML and CSS3.
Before starting a website redesign process recently at work, I thought it was a good time to suggest to our stakeholders that we design responsively. My initial aims were, having read the wonderful ‘Mobile First’ by Luke Wroblewski, to try a mobile first approach, as this would both help prioritise content and provide a framework to help settle some design decisions, as well as look at a responsive design. We had already planned on a content audit and rewrite to slim down the monolithic beast that was our old site, so it seemed a good time to go the responsive route.
In the past, having developed process-heavy web applications rather than content focused websites, stakeholders were often more concerned with just the desktop experience, things like tablets and iPhones were not a common sight, and both developers/stakeholders felt that mobile was a ‘nice to have’ feature that often got shelved when a deadline loomed.
To my surprise, I was really pleased when one of the stakeholders approached me and asked whether the website design would work on their smartphones with little prompting from myself. The concept of a fixed desktop browser truly is on the way out it seems.
The designers we were working with went through the design process, and after several iterations came up with a lovely set of designs, one for mobile devices, one for ‘desktop’ sized browsers, with some options for screens with larger real estate, with the collective idea that site elements would reflow between the designs.
We started the Drupal build, and this is where the challenges started. I’d recently just bought a Nexus 7, and started looking around the office to see what others things people were using. Turns out, all sorts of phones (several generations of iPhone, and also iPad, plus a bevvy of Android devices).
As development progressed, I soon realised that the designs that had been delivered worked perfectly at specific viewports (small, big), but just didn’t look quite right on things in between, and my nice idea of content reflow wasn’t going to work without a lot more effort.
Herein lies the problem. We were designing responsively for specific device widths from the get go. By the end of the project, who knows what new devices (and viewports widths and heights) would have been unleashed on the world?
My epiphany came late in development, when I was getting frustrated wrangling with different targeted media queries for specific viewports, each containing a huge number of selectors.
When coding up responsive CSS, design around content, not specific devices.
I realise that it is impossible to design and test on all devices, but by designing around content, more often than not you will find that things just work on different devices, often even if you haven’t specifically targeted them.
Responsive design is hard but very worthwhile, and while it certainly adds massively to the time needed to create a site, by starting with the focus on the content, not devices, you can ease the site creation process on all levels.
Further to this, I’ve started a list of tips, and will be adding to them as I go.
After launching our most recent site, www.nominet.org.uk, I was really pleased to see it featured in .net magazine. I answered a few questions for Paul Lloyd, and as these got edited down by the magazine due to limited column inches, I thought I would publish my responses to Paul’s questions in full.
Why did you choose a responsive approach? While responsive design is definitely not a panacea, because we were already working on reducing/rewriting the website content, it made real sense to try a responsive approach. Going the responsive route provided us with a framework to prioritise features with stakeholders, forced us to keep things simple, and display our content in a nicer way on a variety of devices.
Knowing that you wanted to go responsive, did your design process adapt to accomplish this?
It had to. When we were sketching ideas for the site out with our designers, everything had to have a mobile representation that worked with the same content.
Ideas that worked on the desktop often didn’t work so well on mobile, so we had to keep both at the forefront of our minds.
What was the relationship between the designers and developers working on this project? Would you change anything about that on future projects?
Really good. The key really was lots of initial communication/face-to-face time. Sitting developers and designers down together very early on to brainstorm over several days really helped iron out some initial challenges.
We worked with an agency (Nomensa) who provided us design comps based on our initial workshops and also worked with our stakeholders improving site copy, and we did all the development (Drupal build, a responsive custom theme, HTML/CSS and further design changes).
In terms of changing things, probably more prototyping. Some things that look good on a design often have issues when you come to use them in a browser. We were under tight time constraints, so did the best with the time at hand.
Did you encounter any tricky problems during the design of this site? How did you solve them?
Our initial designs catered for both desktop and mobile, but there are a lot of sizes in-between to consider, and trying to get things (like landing page tiles) to reflow nicely between the two took more time than we anticipated.
To save our developers from having to cater for dozens of different devices, rather than targeting specific tablet breakpoints, we just resized the browser and added targeted media queries to specific page elements when things started looking wrong. Working to a grid really helped.
Aside from layout, what other considerations did you make for users visiting the site on mobile devices?
Navigation was a big concern. We tried a variety of navigation patterns, and ended up going for something that resized down to mobile, then switched to a left nav flyout Brad Frost’s list of navigation patterns was very useful).
It’s still not quite perfect, and we are trying a few other options to improve it for a future version. Navigation is easy on smaller sites, but when you have a deeper IA with potentially long page titles it becomes a real challenge.
Did you learn anything during this design that you’d apply to future responsive projects?
We found grouping targeted media queries under specific styles made CSS maintenance much easier. CSS Preprocessors really helped for setting things like colour variables and handling vendor specific properties consistently, however it made writing unnecessarily complex CSS selectors a little too easy.
There are a lot of people in the web community railing for/against LESS and SASS, but really they are just tools and it’s just down to how you use them - for good or for evil.
Building on this, for future projects I think we will be looking using a combination of using more modular CSS and style guides at an early stage to help with prototyping.
Responsive design is hard to get right, and while it wasn’t our first responsive project, it was the largest and most challenging so far. There are some really interesting discussions happening right now on the web on things like how to deal with proper responsive images and deeper optimisation on several levels, and as a developer it’s easy to get obsessed with these things.
However you have to get the basics right first to make the most impact - good copy, a good IA/navigation and keeping content as simple and relevant to your user as possible.
I have yet to get hold of a copy of the magazine, but a friend kindly sent me a quick snap of it.
As it’s a dark cold Sunday, I’m in editing some brighter photos from a recent trip to Bath in better weather for Zoë’s birthday. We visited Westonbirt arboretum (where the majority of these were shot) and Bath. Best viewed large on Flickr (click through).
Here are my favourites:
As it’s a bit of a wet Sunday, and I can’t go out with my camera today, time for a quick blog post.
I thought I’d summarise some of the things I’ve been reading/looking at this week - have a look through the list below and see if anything interests you.
a cloud based cross-platform site testing tool across many browsers. On the surface looks to to potentially save a lot of VM hassle. It also allows for local testing, something that many other browser testing tool do not (i.e. a site would have to be live on the web to test).
one of the big challenges in any MV*/MVC framework is avoiding mixing up business logic in your templates - this article shows some of the things one can do using knockout to remedy this.
The good folk at HappyCog go into some detail on how they are setting up their user testing lab - something I am in the process of doing at work, and some real valuable insights.
Some valuable insights by Nicholas C. Zakas on negativity, and how being nice to people can open up unexpected opportunities.
While I don’t think that this is as opposed to SMACSS as it makes out, it’s an interesting read. For me parts of this with “SMACSS”:http://smacss.com/ can work well together.
Nick Jones covers something I have been dealing with recently - that you should start ignoring self-doubt and start trusting you instincts.
Nice looking mind mapping tool in JS.
A good look at how prototyping can improve help get sign off with clients, and help with the collaborative process.
The title of this post is deliberately ambiguous, as I both wanted to add some tips based on my experiences, and also profess that I am new to this all, being mainly a landscape photographer, so it’s a journey of discovery (Based on some text I wrote in 2011 on a now defunct posterous blog).
It all started last year when I found out my friend was performing in London during the afternoon, and I wanted to go and see the Vivian Meier street photography exhibition (well worth it) in the morning, so I decided to lug my SLR and iPhone up to Brixton to take some pictures. Being a landscape photographer I realised I there was a lot to learn about street photography, so I set to work reading up as much as I could on the bus on the way up to London.
After looking at Vivian’s pictures of Chicago, I emerged out onto the street energised and inspired, and was determined to take a few pictures in the hour I had before I had to make my way to the theatre.
The marvels of daily life are exciting; no movie director can arrange the unexpected that you find in the street.” – Robert Doisneau
After a bit of googling, it turns out my good friend Haje has already been doing some street photography, and his results were excellent.
If I wasn’t on my iPhone, I would have looked more at the settings he used, and given them more thought. Use a narrow aperture of you want to get everything in the scene in, and a wide aperture if you want to isolate your subjects. I’m a big fan of wide apertures with lots of bokeh, but I think the next time I go out I might well try some shots with a slightly deeper depth of field, maybe with some manual settings (I was shooting primarily in AV mode).
I pretty much shot wide open in AV mode, but with some hindsight as the sun was so bright what I should have done was underexpose shots by a stop or two and maybe considered shooting in manual mode.
A quick search on Google gave me some interesting discussions on what settings to use - a common technique (which I didn’t but should have used) was set my ISO to 400, and preset my focal distance to about 10 feet or go for the hyperfocal distance:
Street photographers traditionally will set the lens at its hyperfocal distance. This distance depends on the lens focal length and the aperture but the basic idea is that it is the closest distance setting for which subjects at infinity are still acceptably sharp. With fast film and a sunny day, you will probably be able to expose at f/16. With a 35mm lens focussed to, say, 9 feet, subjects between 4.5 feet and infinity will be acceptably sharp (where “acceptable” means “if the person viewing the final photograph doesn’t stick his eyes right up against it”). (from photo.net)
The benefit that static settings give you is that you can work super quickly - look for pictures constantly, and when you see one, lift the camera up and press the button - no fiddling with settings needed. If you can shoot Raw that’s even better, as you have more latitude for processing.
Having watched the three stunning videos on street photography which make up ‘Documenting the Human Condition’ by the ridiculously talented Chris Weeks (ignore the fact that they could be a leica advert - they are beautifully shot and both informative and fascinating, and there’s lots you can take away from it using any camera), one thing I noticed was the willingness to really be open and confident about what you are doing. All the photographers he covered weren’t standing at the end of the street with a long lens, sniping away (which IMO is very wrong).
In ‘Documenting the Human Condition’ the street photographers were walking around and intermingling with life on the street, holding their cameras in clear view, purposefully looking for interesting situations and patterns, and smoothly taking shots. As they say, it’s easier to ask for permission than forgiveness, and as long as you are reasonably sensitive about not invading anyone’s personal space, and as long as you are relaxed and not acting like you shouldn’t be taking pictures, people generally will be a little curious, but not too bothered.
The thing I found hard is that acting like the photographers were in the previously mentioned videos is hard, and you need balls of steel in terms of confidence. Part of me wishes that my camera was a little smaller, as people were eyeing it up suspiciously as it was a large SLR.
Eric Kim (a talented street photographer and avid blogger) also has some good tips on not looking like a creep and becoming fearless.
There’s nothing more likely to put people’s shackles up than a photographer that is looking shifty and taking shots quickly from a distance. By acting in a calm, quick, purposeful and confident manner, I found that people didn’t have a chance to put their ‘photo face’ on, and if they really had an issue with you taking their picture, they really let you know, at which point if they asked me to delete pics I happily obliged. I found snapping away confidently and they following it up with direct eye contact and a little smile worked wonders.
There is a lot of confusion in the media with people’s rights to shoot on the street, but for the most part it is fine on public property. You can find out more on your right to shoot in the street here. I’m only starting out with street photography, and still have lots to learn, but find the whole process really challenging, slightly scary and yet very exciting, and look forward to doing more. Give it a go - get out there and challenge yourself.
I’ve started thinking of things that would help with designing/developing around content in the browser, and built up a list of tips. Some I’ve tried and tested, some I’m just getting into (like OO CSS/style tiles).
OK OK - not CSS per-se, but less content means less CSS. If you’re working on improving an older site, before the design phase starts make your content earn it’s place. Often with older sites over the years business can slowly add more and more business related content without thinking of the users needs, and what once was an initial small site can spiral out of control easily. Justify whether content deserves to be in your new site (does it supports your user? does it support your business’s new site goals? is it still relevant?).
Prototype if you can, and use real content instead of Lipsum text. See your titles at actual word length rather than the imagined ones that always fit, and think about potential minimum and maximum content sizes, and how they might view on a smaller or larger screen.
Professional copywriters/content people are worth their weight in gold. Not only do they bring a laser like focus on content, but they don’t have any of the political baggage/bias that comes as being a regular employee, so can act in a neutral way when dealing with difficult stakeholders. Plus, however good you think your command of english and writing good copy is, theirs is better - they’re trained, like expert little content-ninjas, and do it all the time.
There’s loads of good writing on the web about prototyping in HTML and CSS and style tiles - the sooner you can get tangible things in front of clients the better - fail fast and find out what doesn’t work before you get to the development stage.
Design around your content in a small viewport, resize larger bit by bit and add in targeted media queries when things start to look strange. Benefit: you’re not designing for specific devices, so your site is likely to flow better on other (untested!) devices.
Rather than have a single media query for lots of elements at the foot of your stylesheet, inline or “bubble up” your CSS media queries under your CSS element declarations. Benefit: Easy maintenance. You will find that (if you use fluid widths where possible) you will end up with far less media queries than you think. Inlining media queries saves you from the whiplash one gets zipping to the bottom of a css file when comparing styles.
Try writing OO (Object oriented) CSS (watch this great video from Harry Roberts on large scale CSS architecture), and don’t be afraid to use multiple classes on elements if it means you can reuse things. If you start with your mobile CSS as a baseline, then you can layer on adjusted styles as your viewport gets larger.
Benefit: Better, cleaner, more modular CSS. Check out both @csswizardry on OO CSS and guidelines and @snookca on SMACSS as they have lots of great info on OO CSS out there.
There are lots of good grid systems out there (both responsive and fixed). When using Drupal I’ve found that I didn’t always have control of the markup for some of Drupal generated output. Making design elements use different grid columns classes when you couldn’t modify class names in your markup easily was a challenge.
I looked at things like frameless, cssgrid and [“]blueprint](http://www.blueprintcss.org/) but ended up rolling my own. Rather than using the CSS grid classes directly in the markup, I created a separate grid stylesheet with grid classes, then added my existing css classes alongside grid classes in the grid css directly.
1
| |
Benefit: This kept the markup nice and clean, the grid stays neatly out of your markup, and sits just in your CSS. This then allows you to override specific elements using media queries. Need to change it in the future? just one place to edit.
Bit of an obvious one, but the thing I love about the web industry is the willingness of people to share their thoughts online and help move things forward.
A few of the great resources for developing/designing around the responsive web, content and CSS:
Know any more good resources? Want to chat about responsive design? Find me on twitter and say hello….