infocux Technologies
Daphne Chong talked about a recent project.
Usually been backend, but recently did a new an interesting site for twitter and the elections. First time looking at responsive design, found it really interesting.
Example of the Sydney Morning Herald. As you make the view port smaller, you have to scroll. If you pre tent to be an iPhone, get a completely different version. m version. Simpler, smaller, cut down experience for mobile. One set of content, optimise for two different sites for different devices.
This means two sets of code, two places where it is hosting. Have to keep them both in sync. As a dev, having to do the same thing more than once is irritating. What happens when you introduce a new device type? If you go super widescreen, lots of whitespace either side.
Summary: “Never show a horizontal scroll bar” – always fit content horizontally. Have a single site that does this. Never show the scroll bar, regardless of what screen size. Multiple versions is more complicated and expensive. This way, one site, happy developers.
Case study for #youdecide9. Coverage of the 2013 federal elections. It’s an experimental site with twitter integration, and responsive behaviour is baked in.
Notes from demo
- Top story bit, question that people can vote on.
- Featured tweets.
- Leaderboard. Secret formula with ranking for each politician.
- Twitter stream
- As you adjust, drops to two columns from 3.
- Hide some things so columns are not uneven.
- Then one column (what users see on mobile).
- Vote modules starts with 2 columns.
- Page reacts to the different properties do devices viewing it.
On Design
- Movement in the last year or two.
- Start with mobile first as it has the most limitations (tiny screen, processing power).
- If you know you have to cut things out, better to cut earlier.
- Mock up all layouts in parallel.
- 5 different layouts at least. Have to think about them all concurrently.
- E.g. of tweet box – had to put the description on the right, because on the left it stacks below.
- About 15% more effort to convert mobile site to the desktop.
- Comparatively not that much overhead, huge benefit in terms of maintenance cost.
- Downside: Need more time in design phase, more back and forth with designers.
On Optimising Content
- Semantic web: make it meaningful.
- Content is king! Content is the most important thing on the site.
- Site without styles still works. Still makes sense in a linear way – this is important for screen readers. These are the most limited devices accessing the web.
- Request images in largest sizes and adjust with CSS. Not efficient, asking for large images when only need a small one, but better than trying to request lots of them and pick the right one.
- Choose which bits are important – can get rid of some.
On Implementation and Testing
- Used @media screen.
- Use print to print in serif fonts.
- Supply queries – what is the size of the screen right now. phone/tablet 400/755.
- Decided to break when content didn’t look good anymore, rather than default.
- Orientation and aspect rations – lots of things you can do to your page to customise content.
- Can see if device is in colour. Screen reader means no colour. If no colour, don’t need CSS.
Testing
- Use viewport resized. Animates.
- Lots of manual testing, not a lot of automated testing is possible.
- BBC – wraith. Takes screenshots, highlights the differences in blue.
Things Learned
- Focused well on smaller devices, didn’t focus as well on larger devices.
- Whitespace on wide monitor. Didn’t change layout for widescreen, which is a shame. Left lots of content below the fold.
- 15% overhead. Interesting learning – something to put forward for new projects.
- Trying to balance design requirements and product with lean development.
- Didn’t implement all designs, could have had designers use that time differently.
- Usage shifts during the day, more desktop during the day, phone as people go home.