LWS Flux Live(ish) Blog (#lwsflux)

Designing for the Responsive Web

A talk by Laura Kalbag (@laurakalbag).

Responsive Web Design is the natural evolution for web design. But the web is not an endless publishing platform. We’ve always known that there are different size screens, but we always locked it to one size. We know we need to be flexible, we need to stop thinking about averages and think about proper fluidity.

As designers we often push our creative ideas to the back of our mind. We try to focus on things that work. This talk is not technical at all. The slides are going to be interesting, a cross between Pictionary and Catchphrase. The talk is ignorant of technical difficulties on purpose.

Designers need to be able to write HTML and CSS. Knowing the code can constrain too much though while you’re creating. Try to forget this and think about the content, rather than worrying too much about technical difficulties too early on.

The first part of the project, you need to decide whether you’re going to sell responsive design.

So why bother?

It’s the easiest and cheapest. You’d be a bit daft not to think of optimising for different devices. It’s also future friendly. The web is going to exist on a lot of devices.

It’s also just fun. It’s good to have a challenge. We like learning, we like doing new things, so why not jump on the bandwagon?

Responsive Design as defined by Ethan Marcotte:

1. it has a fluid grid
2. flexible images
3. uses media queries

Adaptive sites (often described as a branch of Responsive Design): Multiple versions of a design, designed around specific break points.

To be honest, she doesn’t care. Laura likes to have flexible websites. It’s important that the website is reactive, it reacts accordingly to different devices. It doesn’t necessarily mean mobile. Natalie Downe thinks you can have a responsive website and a separate mobile site. It’s more about users and content.

Once you have an idea for a responsive design, you have to sell it to the client. The important thing is, you need to keep communication going, let them air their concerns. Let them know who it is it’s being designed for. Which devices, which techniques, will it be adaptive or responsive? Although it’s difficult talking to clients about these things.

Think about why you’re doing responsive design. Are you doing it because it’s trendy? Make sure you’re doing it for the right reasons. Beware when looking at site analytics, don’t infer too much from a device being “mobile”.

Another option when making a site responsive – don’t tell the client anything. Anna Debenham says it’s “like accessibililty, you’d do it anyway”.

When you get into a responsive design project you need to immerse yourself in the content. Sometimes you need to give the client a push, they aren’t often forthcoming with it. She’s jumped straight into the design and development phase because as you’re designing you’re also developing. There isn’t a strict order anymore.

Whatever you do, with mobile devices, don’t fall into the “users on the move” cliché. You can’t assume context. Screen size doesn’t dictate connection speed or context. Things like touch screens, you can assume a small amount, e.g. you need touch point big enough. Also, hover interactions don’t work on a touch screen (this is bad usability anyway).

Design for the known. The safe way is to always design around the screen width. If there’s a small screen width it’s probably going to be close to you, if it’s a large screen you’re probably sitting much further away. When you’re designing think about the content hierarchy. What’s your ‘king of content’? Put this right on the top for both large and small screens.

Which brings up, which do you put at the top? Branding or content? She would probably put branding at the top, you want people to know where they are.

Brad Frost has a good list of responsive navigation patterns: http://bradfrostweb.com/blog/web/responsive-nav-patterns/‹

Also, don’t throw away content just because someone’s on a small screen, you’re only going to frustrate people doing that. You *can* get rid of excess design. This is all about the content, it’s important to drop your ego and strip away the design.

A big challenge on the large screen is thinking how it relates to the small screens. What do you make the same on your sites? What do you make different? The way to do this is through a design system. This might sound highly involved but we sort of doing this in our head already.

In design systems the big thing that can really help is colour. It’s an instant way for people to tell they’re on your site.

Once on the smaller screen and you’ve thrown away the excess decorative elements, you’re often left with the typography. The proportions between the font size and the line height, you’re creating a feel across your whole site, through the design system.

The great thing about the design system is that you can reuse it. Use it to plan individual elements and how they relate to each other and the overall design.

There are two good resources for this:

Paul Lloyd: http://paulrobertlloyd.com/about/styleguide/

Dan Cederholm Pear Library: http://simplebits.com/notebook/2012/02/07/pears/

Lorem Ipsum - The most important part of design is what you’re deigning for. Lorem Ipsum is just guessing. You can’t use it with design systems. It would be just a collection of arbitrary stuff.

You can also differential though different layout. Grid systems are a good way to do this. Don’t fall into the pattern that you have to reuse the same grid across each of the layouts. All you need is symmetry, a three column grid can break down to a two or one column.

Break-points  - Making your sizes around specific devices is dangerous, what happens if the devices disappear? You don’t know what devices people use to browse your content, you do know the size of your content, so design for that.

Flexibility – you can use major and minor break-points. You can use the minor ones to keep things neat and tidy. This can help with readability.

Process – we’re moving away from print based workflow. We need to mock up and get feedback as a continuation. Part of the problem with this new design process is that we haven’t got the best tools for the job. Between the browser and Photoshop/Fireworks we haven’t got two things that work well together. The problem with working in the browser, how do we stay creative? She thinks, if she designs in the browser everything ends up in boxes because that’s what CSS is good at. Forget about being purist on designing in the browser, do what is most creative. Robby Mansen said “Designing in the browser doesn’t necessarily foster creativity”.

What about mobile first? She quite likes designing desktop first. That doesn’t mean she’s not thinking about how it might work on the mobile screen. Do whatever comes first. Do the thing that presents you with the most problems, start with the problems you need to solve.

Do you have to create a million mockups for every break-point? If you do too many, you’ll fall into a black hole of mockups.

There is no best process anyway. There is no magic bullet. The magic bullet might be realising that everybody is different. You just need to make sure you’re continually communicating with clients. Open up your process and make sure you’re not wasting time. Test your design. She does this through the DropBox app by loading PNG images full screen on her iPhone.

Speed – some think the process will take longer. You can’t expect it to take the same amount of time. But you’re creating something that’s so much more and so much better.

As part of developing this new process we need to not be scared to reevaluate it. We need to take what we did right and adopt it and know what we did wrong. Then share your processes and thinking. You need criticism.

CSS: The Boring Bits (Peter Gasston)

A talk by Peter Gasston (@stopsatgreen).

He changed the title of the talk from “CSS3: The Boring Bits” because he’s going to be covering some CSS4 as well.

When he was coming up with the talk, he was trying to think of some boring things. Matrix Revolutions came to mind. Also, Lord of the Rings. Both boring. Oh and Cold Play, he appreciates what they do, but with the best will in the world, they’re boring. Apple vs. Android, the debate is so boring.

People tend to get more excited about the flashy things in CSS. You’ll be able to do native filters, sepia colouring, blurring, live graphical things. Cross fading as well. It’s very cool that you can do this, but Peter can’t think of any use cases yet.

He’s interested in the boring bits of CSS that you’ll never see in Smashing Magazine. He’s going to talk through the stuff you’ll be using soon, some stuff that’s a little way off and some stuff that’s just proposals.

Backgrounds and Border

Note: This section is a record of the comments Peter made (as accurate as I could make it) not the code. For that we’ll link to his slides from here.

The four value background position, it’s just landed in Firefox. It gives you a whole lot more control over how you position your background images. Border corner shape and border clip. Both will be implemented quite soon. Border clip will enable you to make completely custom borders in CSS. However this is all too close to being too exciting.

Namespaces

In XML you can define namespaces. Where this is useful is in SVG. You can namespace your CSS using XML and SVG. Boring but useful.

Fonts

You’ll be able to load individual characters for each font. This is great as it improves loading times for your fonts.

Device Adaptation

Often we use the meta tag, but this is a very blunt instrument, it doesn’t work with tablets very well for example. You can set the viewport and set breakpoints instead.

Values

It doesn’t get more boring than this. The “rem” unit. In CSS you can use the “em” size, but this inherits it’s size relatively. With the “route em”, you don’t have to worry about the em inheriting font values. You can use this now, in everything except Internet Explorer before version 9.

“vh” is viewport height, “vw” is viewport width, “vmin”  this works in a few browsers, only some support it.

Attributes

attr() is fairly well supported across devices. An example of this would be attr(title) or attr(data-color color).

calc() is going to make layouts a lot lot easier.

cycle() – put a comma seperated list of values in here it will cycle through the styles. This means you won’t need to do loads of nested styles.

Selectors

Target – the new hotness. It you link to an internal part of the page, you can highlight the element that they’ve just selected. You can build full image galleries using CSS, no JavaScript required. The drawback is it messes up the back button.

:dir() is a way to style different languages depending on it’s direction.

:not() this is quite well implemented at the moment. His company is working for Spotify who use Chromium for their rendering engine of their application. He was able to use this selector. It’s incredibly powerful once you start using it e.g. div:not(.foo)

:nth-* is another way of iterating. The classic example is zebra striping on a table. Otherwise the only other way is to do it programmatically.

:matches() lets you put in a comma seperated list of simple selectors.

:link, :visited and now :any-link will work on any link on the page. You can go one stage further with :local-link just for links from this website.

:column() you can use this to style tables. You’ll be able to use this in Internet Explorer 10. :nth-column() and :nth-last-column()

:past, :current, :future you could use this on screen reader programmes to highlight things that haven’t been read and grey out things in the past (just an example, may not be a good one).

$E > F this is the parent selector. You can now select the element E where the element F is inside it.

You can also use data attributes.

Conclusion

He hopes he’s shown that boring can be exiting. Within a year and a half to two years, we’re going to be able to use this stuff. If you compare what we know now and what we will need to know in a few years, it’s going to totally change. Buy his book (it’s not boring)!

Node & Tell live blog

Live broadcast at http://live.forwardtechnology.co.uk for those who could not make the event.

First talk by George Ornbo (@shapeshed) – he’s writing a book about Node.js development.

Node tries to deal with quite ‘mad’ problems in programming where lots of things happen at the same time.

Many people see JavaScript as a joke language, but Apache (in real time programms) has to do a lot of work on the back end if utilised, so there is a trade-off to be made.

George shows a Node based ‘Hello World’ server code example.

Callbacks are crucial for node.js developers – they can be a bit tricky to get into initially, but they are well worth getting familiar with.

George shows an app which shows the number of tweets using words ‘love’ and ‘hate’ and displays them as a graph in real time with lots of events coming through per second.

George recommends:

• expressjs.com
• socket.io
• github.com/substack/dnode (blows mind)
• leftlogic.com/training#node (by Remy Sharp)

Q&A wraps up and people head over to the free pizza spot!

Arduino voting machine 

Mairead Buchan (@tiny_m) demonstrates the Arduino voting machine which received a lot of interesting views and smiles from developers

The tool picks up a lot of laughs from the developers in the room!

LNUG (London Node User Group) 

Andrew plugging the project, which has been built in node.js and the event is happening next week at Forward.

github.com/forward/lnug – open source code available to work on.

The whole thing is written in Coffee Script.

Andrew show Github page for Sizlate library which he is saying does a good job in separating concerns between different types of developers and designers on the project.

Check out mongoosejs.com as an ORM for MongoDB.

Simon Thompson 

Showing his app which enables him to drop events onto calendar of dates (by the looks of it).

Simon running through some express code which he has used for the app.

Simon talks about the hardest thing he had to do was to query the data using something like mongoose.js.

There doesn’t seem to be an awful lot of documentation available for mongoose.js.

LWS February: Node & Tell

General release tickets will be available from Friday 10 February at 1pm.

Read more here: http://lwsnode.eventbrite.com

As mentioned in January, this month we have a slightly different format, one main talk plus several short talks covering different projects from Node.js enthusiasts in our community.

An Introduction to Node.js

A talk by George Ornbo (@shapeshed). What do you get if you mix Google Chrome and the JavaScript programming language? A strangely beautiful love-child for creating fast, scalable network applications. Discover how JavaScript is bridging the gap between browsers and servers and making it easier than ever to create real-time games and applications.

George is a London-based hacker who started out as a fresh-faced front-end developer, grew some stubble and got sucked into the vortex of server-side development. He has worked with a number of startups including seatwave.com and londontaxiapp.com and spent three months in the Far East of Russia hacking in temperatures of -25°C. George is currently authoring Sams Teach Yourself Node.js in 24 Hours, a beginners book on Node.js. He blogs at shapeshed.com and works atpebblecode.com.

Short Talks

• Mairead Buchan (@tony_m) – Node and Arduino voting machine
• Andrew Nesbitt (@teabass) – London Node.js user group website
• Simon Thompson – Learning Node.js and NoSQL
• Daniel Knell (@danielknell) & Jason Grant (@flexewebs) – Free London, node.js powered mobile web app

Microframeworks and Data Driven Documents (#lwsjslibs) live blog

Daniel Knell (@danielknell) went over a short history of JavaScript.

He then mentioned how JQuery became a dominant framework but turned into a monolith.

This meant that JQuery soon became too big for most sites and purposes.

This gave rise to use of micro frameworks which do one job for each framework and keep things small.

This is the same approach to coding as how Unix people approach coding.

Q&A reaches earlier, so lots of question time is left. Conversation goes into free flow.

….

How can you maintain JavaScript classes and reuse code if you are using different frameworks if you are changing libraries?
Don’t change all libraries in all projects. Settle on ‘go to’ libraries for many different projects.
Things like ‘ender’ try to unify things anyway. Build against the ender interface and that way you can get code reuse.

What micro frameworks would you recommend?
There are a few good ones by authors of ‘ender’. There is a functional library called ‘valentine’ and ‘bonzo’ and ‘bean’ which are not too bad for events and DOM stuff.
‘Query’ and ‘Request’ which are spelt weirdly which are good for AJAX stuff. But it all depends on your use cases. Check out microjs.com for an index of frameworks. Use that as a first step.

Doesn’t gzipping remove the size and reduces things to 18K?
Yes, but micro framework approach brings things down to 7K.

But JQuery is going to make sure things are cross browser compliant, so why should I switch?
These things are going to get better and better in time, so it will become even better as more people contribute.

Doesn’t ‘ender’ do something special to ‘give things back’ to other frameworks, so this is extra work surely?
Ender is a node.js application, so it runs in the command line and piggy backs on NPN packaging, so when you build something with ‘ender’ it will download all frameworks via the NPM repository, save them to local machine, then combine them together with ender adapter and then run through uglify.js to give you compressed version.

Then you can add additional frameworks to your build and upload a single file to your live build.

Considering the difference is 10-15K, is it true that this makes difference to client side performance?
Yes and no. Theoretically it will be faster to load the microframework, but because of size of files will not be noticable as other factors. You will probably notice it in other areas.

But this defeats your point though?!
That was in the parsing of the file though.

The physical size of the files is not that different, I would say the interpretor is much more of a factor here?
Modern JS interpreters don’t really care about the size. Benefits come from reduced HTTP overheads.
CACHE sizes on some mobile devices also play a part. HTTP requests are the main issue here.

How does this differ from using JQuery and other JS stuff and splicing into the same JS file to deploy live?
It doesn’t make much difference, but micro frameworks means the file sizes are smaller and less information is served on each request, saving server bandwidth.

d3.js
Justin decided after trying many different things decided to use d3.js for his graphing purposes.

d3 mailing list is really nice and friendly, so when you are starting up with it, you will have an easy time.

Use presentations from HTML5 rocks, as it’s really nice.

d3.js is about code and not configuration, so it’s nice to work with.

d3.js uses little micro frameworks to build graphs with.

Justin showing a practical example of code.

There is a CSV parser built into d3 and it’s easy to work with CSVs using this library.

Justin shows a really nice example of a dynamically updating graph with transitions, that looks really nice and is rendered in SVG.

He followed by showing a whole bunch of live and dynamic diagrams which can only be understood if seen and cannot really be described in words.

Rick Shore library is built on top of d3 which is really handy, built in a micro framework fashion with easy way of creating common, standard graphs. 

All this stuff is really micro frameworky which is nice.

LWS January: Microframeworks and Data Driven Documents (#lwsjslibs)

Happy New Year! We have had a very exciting beginning of 2012 at LWS HQ and we have PLENTY of news to give you.

First, January’s event! This month, we’ve got two great talks on Microframeworks and Data-driven documents.

JavaScript Microframeworks

In recent years there has been an upwards trend in the use of JavaScript microframeworks – small, single purpose libraries — Daniel Knell (@danielknell) will be giving an introduction into what they are, what they can do for you, and where to get started using them in your own web applications.

Dan is a freelance technical architect and full stack developer who has helped numerous companies in achieving their technical goals.

Data-driven Documents

d3.is is a new JavaScript library for graphing, visualization, and working with data on the web. It uses code not configuration and is designed for the modern web. This talk will get you started with some code, and show you some pretty, inspirational examples.

Justin Cormack (@justincormack) first used the web in black and white when it was mainly at cern.ch. he has been trying to make it look nicer ever since.

Tickets

General release tickets will be available from Wednesday 18th January at 1pm from http://lwsjslibs.eventbrite.com

LWS December… and relax

On Monday 5 December we’re teaming up with the London .Net user group and are taking over part of The Shooting Star pub. Come, have a drink and meet some new people.

You’re welcome to sign up (or just come along): http://londongeekxmas2011.eventbrite.com/

We’ll be there from about 7pm onwards.

LWS Team (#lwsteam), Blog

Developing and Delivering (surviving as a developer in a National Museum)

Rich Barrett-Small

Rich is here to talk about his experience at the V&A and as an agency developer.

The V&A is a museum of the applied arts. The V&A has a website that has visitor numbers entering into the millions per year. They also have a diverse range of visitors, with different needs and abilities.

The website has two distinct visitors types, internal and external. Not every internal visitor has all of the evidence to say what an external visitor needs on the website, even though they don’t always know that.

Web development of any kind is a many-headed beast. Your first priority is usually to avoid being given spreadsheets my non-technical colleagues. Others priorities include, being a web designer, being a coder, being a lawyer (data protection etc). It’s a big job, or more of a syndrome. However having an overview of the web stack is what’s the greatest thing about being a web developer.

When Rich talks about web standards, he’s not just talking about the W3C, he’s thinking about programming practise and website performance. You’d think advocating for web standards in a public institution is easy. It’s not.

What are the practices they use to ensure high standards in the V&A? Public institutions like to buy proprietary software off the shelf. It often ends up that your in-house team fills the gap when the paid-for support doesn’t meet the standard.

He shows an example of a GUI they used to use. It’s really bad. It looks like some kind of database schema. Fortunately they didn’t ever roll this out to their website editors.

A software vendor often thinks they can create web enabled software by building a web interface on top of their existing software. Vendors often think they can port their desktop software to the web, they’re wrong:

“The last great thing written in C was Schubert’s 9th symphony”.

They set about modelling the data model in django.

They use MVC (model view controller). They’ve managed to extend their applications modularity to an extreme. They decided to ‘eat their own dog food’. They use symphony to keep their django implemtation inline. This kept them honest, if the V&A can use their API, anyone can.

They use a RESTful architecture (inspired by REST anyway), see the documentation:

http://www.vam.ac.uk/api

They use the HTML5 doctype and use a few of the APIs.

He shows some operating system stats. Over the last year Windows has dropped to under two thirds of visitors. Mac, iOS, Linux etc now account for one third.

Browsers, Internet Explorer is still the biggest, but is only 34%, decreasing dramatically. Firefox peaked at 27% in 2009, Chrome is increasing rapidly. This should make a good argument for supporting modern web standards right?

Most of the directors of the museum (and most of the rest of the staff) use Internet Explorer 8. This is a problem, there’s a battle to be had. You’re under pressure not to use progressive enhancement etc, it’s from these organisational challenges that most problems comes.

It’s worth while to make sure the key players in any problem are keeping up with where the project is going.

It’s hard to keep web standards if you can’t keep standards in human interaction. A lot of the time it’s about making the right technological choices up front. You need tools that make you agile, of course this is a loaded word.

A good analogy for working in a public institution is a round of golf. You occasionally hit a ball but most of the time you spend talking about things you’re interested in.

The (coding) Zone

It can take two hours to get there and 30secs to drop out. Creative people (designers and developers) need to sacrifice an hour or so to get there.

Testing

Baseline is to learn the testing suite for your app. Testing in production. Stress test your designs in CSS. Everyone loves a comp, but your design must scale as much as your infrastructure. Designing dawning rectangles [in Photoshop] is not web design in 2011.

Don’t virtualise you DB servers, it can get restrictive.

Caching

This shouldn’t be used to hide any shortcomings in your application. It should just be used to help out during times of exceptionally heavy traffic.

Accessibility

Web Content Accessibility Guidelines. You can roll standards development into your accessibility work.

Usability testing

Get someone to pay for this properly. Get someone to test this properly.

Final piece of advice: “stay hungry, stay peckish”.

Q&A

Q. For a company that uses IE everywhere, how do you get them to support the API?

A. The API is for the V&A first and foremost. The web team has shown the usefulness of the API across the museum with interactive displays etc over time.

Q. Everything is publicly paid for, have you open sourced your code?

A. Yes. One issue with the codebase it’s not in a state where they feel it’s good enough to release on to GitHub. A lot of it is specific to their database model.

Team++ – techniques for turbocharging your team’s performance

Neil Crosby

When he joined the BBC he realised he could improve the team. Here are some of the things he did.

For the last month he’s been a Technical Project Manager for LOVEFiLM. He’s a project manager but he’s not evil. He used to be the lead developer on the BBC homepage.

Today he’s talking about the terror he felt when he first joined the BBC. The BBC moved from a Perl based system. When they took the BBC homepage live for the first time, immediately everything fell over. Bugs, storing data in silly places.

They realised had huge bits of code going into production that only one person had seen. This was a problem when they left.

When they started on a new version of the BBC homepage, they wanted it to be better. He’s going to talk about the things they did to make their lives better.

Here’s the list:

• Continuous Peer Review
• They brought standards
• Tests

This isn’t rocket science, but none of the teams they’d been in had done this very well.

Continuous Peer Review (“Dev Checks”)

It’s not a replacement for a normal code review. They happen when you’ve done a big chunk of code. A Dev Check is a process that happens before something’s tested by UI testers.

“Before any task is moved into test, a developer who didn’t work on it must say that they are happy with how it’s been completed.”

The testing developer will ask questions of the developer who wrote it. Does it adhere to standards of the team? Does it work in different browsers? You share code and if it’s not good enough you tell them. You also ask “Does anything worry you?”. Sometimes I write code that’s not great. It’s good to be challenged on this. Nine times out of ten, you’re happy to fix the code.

If something isn’t good enough, it goes back into development. Whatever the organisational level of the Dev Check developer (or even the original coder), you have to go back and sort out the code. The Dev Check process takes about 10% of the time it takes to write the code in the first place. The BBC did this for everything, including simple links.

“Sometimes people do things wrong”. This just happens, but allowing bad code onto a live server isn’t good.

“People die, get ill”. Dev Checks are good to share knowledge, it means the team gets better.

Ultimately, peer review helps the team, the bug rate plummets, you have more time to write code.

Having standards

These are good right? “Yes” from the audience. Having standards of writing code is important. When Neil was in Yahoo! they tried to put standards for code in place. However, it two months of arguing about tabs vs. space, where the curly bracket should go etc.

On the BBC homepage, they use PHP _CodeSniffer. It looks at the standards and makes sure the code adheres to them. However, just having standards doesn’t mean you actually stick to them. So they worked the standards into the build process. If the build process breaks, the developer responsible would have to go and fix it. This made the BBC have a code base that would be easily viewable or digested by any other developer.

Worthwhile Tests

They wrote tests. They put them in their build system. This became part of the Dev Check process to make sure that Unit Tests were in place.

Functional Tests

They made sure they fit in with every single story that initiated the feature.

Regression Tests

Sometimes things do break. Anytime anything broke, they went back to write some new tests for it, this saved the team from making stupid mistakes. Just like with the standards, if the tests broke, their build broke.

Other Helpful Stuff

Pair Programming

This is good, please do it, it’s good sometimes for the right thing, do it where appropriate.

Enhance Progressively

One thing Neil was really keen on for the BBC homepage was to make sure it works for everybody. They started development working without JavaScript, they called this the “core view”. Explaining this to designers without saying “JavaScript” meant the team worked well. This is good because sometimes JavaScript isn’t available straight away.

Also – Don’t work out of hours. They didn’t want people burning out. Of course, sometimes things explode and people had to stay late, but this was the exception.

Also, Cakes Are Good! …. and Socialise! It’s nice to be able to moan about something in the office when you’re not there.

With all of this they wen’t from a bad environment to good.

Q&A

Q. Why not just fire the bad people?
A. We knew there were things going wrong that were not just about the people. We also wanted to make sure the code base shipped to Salford in the BBC move was on a good quality.

Q. Were the slides from your own collection of Lego?
A. Some of them yes.

Q. You’ve explained the “Core View”, how did you work with browsers?
A. They started with semantic HTML, that would work with everything.

Q. How did you convince the people with the money that it would eventially work?
A. By mentioning the amount of bugs we’d reduce.

Q. How do you enfore the continous code review idea but how do you convince people to do it?
A. Firstly by recognising that the quality of the code originally was bad. But also by selling it as a chat and making people realise the quality of their code would get better.

Q. What didn’t you pair programme on everything?
A. Some things were just too small.

Q. Everything you talked about it post commit, what about precommit?
A. A lot of the systems we use are vastly different.

Q. How big was your team?
A. The team in London was 4 front end, 1 back end. They also had a team in Cardiff. They did the Dev Check process over IRC, but this wasn’t very nice.

Q. Can you give an example of a functional test?
A. E.g. making sure that if the user clicked off the page and can back the information was maintained on the page.

Q. How did you sell to the mangers that working until stupid oclick is a bad idea?
A. Fortunately it wasn’t in the culture already.

Q. Was there anything that you did that didn’t work?
A. I’ll come back to that one!

Q. How can you try and convince people to be less precious about their code?
A. At the beginning of the process people were more precious. However, only over three weeks things fell into place.

Q. Why did you leave the BBC team, surely continuity is really important?
A. The team was moved to Salford. He’d still be working there otherwise. All the way through they made sure the code quality was there. He also tried to make sure he

Q. What was the most challenging part of the process for you personally?
A. Working on the new codebase was hard. When it came to working on the new code base the was much gnashing of teeth. But a change in quality came from the team itself.

Q. How do you tell the difference between the small stuff and the big stuff?
A. Every story they worked on had a Dev Check. Everything that was a bug had a regression test.

Q. Did you have a specific day when you did review?
A. No. When a task was completed you did it then and there.

Q. How many other people at the BBC have you infected?
A. A lot of this was through the force of your own personality.

Q. The Dev Check. These reviews would add up to a backlog, how did you get people to push it and prioritise them?
A. During their day-to-day work they were all on IRC. Whenever they needed a Dev Check they had someone who’d say yes and come and perform it.

Q. At what level did you do accessibility testing?
A. During the process they kept in touch with accessibility people at the BBC.

LWS Team Dev (#lwsteam)

Our next event is on Monday 14 November at The Shooting Star (nearest tube Liverpool St). General release tickets are available from Eventbrite on Friday 4 November at 1pm:

http://lwsteam.eventbrite.com

Team++ – techniques for turbocharging your team’s performance

A talk by Neil Crosby (@neilcrosby) from LOVEFiLM.

A talk about his experiences leading the team that built the current Beta BBC Homepage. He’s now joined LOVEFiLM, where he intends to take a lot of the lessons learnt there and apply them to a brand new team.

Developing and Delivering (surviving as a developer in a National Museum)

A talk by Rich Barrett-Small (@richbs) from the V&A.

A talk about striving for web standards and best practise during a major redevelopment of the V&A’s websites. Individuals working in small in-house teams or those who pitch-to/work with large organisations may find enlightenment here.

Lets be daring and a bit more creative with what we do on the web

This blog post covers a talk at the Open & Creative night on Monday 24 October 2011. By request there’s no video of this talk.

‘Femi (@designjuju), Creative and Tech Strategist/Consultant.

‘Femi used to work at the BBC as a development manager. ‘Femi started out as a “Web Master” and has worn many hats in the web field.

Creativity, Ideas worth Generating, defining it

Sir Ken Robinson’s idea of creativity in a nut shell is:  “The process of having original ideas that have value”. The dictionary definition “originality of thought”, being “facetious”. The point is, why are we trying to define it?

One of the reasons to define creativity, to define something gives it value. When attempting to be creative, if your idea doesn’t give value it can’t be judged. In today’s web world being creative usaully means providing ‘Added value’ for or to something as well as to or for someone.

There are four universally agreed processes for being creative:

1. Clarify – how many times have you had a client ask you to make something sexy? Often they ask: ”Can you make it look like Apple?”; “I want those reflection things”; “Can you just be creative?”; “I want it the same but different”; “traditional but modern”; “Can you make it ‘pop’?”. We need to clarify the brief.
2. Ideate – she hates the word because it sounds pompous but it has a use. It’s about conceiving ideas something most of us do whilst brainstorming.
3. Develop – This is where an idea is grown/expanded
4. Implement – This is the one people usually leave off because it is the natural conclusion of the others, to implement is to put into effect. In our case, build/prototype  e.t.c.

Theories!!

Once you have the agreed methods, then look at how you do it. She won’t go all the theories/systems our there but there quite a few out there which can be adapted: such as De Bono’s ‘thinking hats’, the Standford Research Institute’s NABC system can make things pretty straight forward. But the one she likes at the moment is WhatIf!’s  ‘4Rs’:

Revolution

This is really provocative, people really like to do this but it also scares them. “If the client brief says X, we’re going to tear it down!” If its straight, we make it circular. We begin to question the actualy essence of the thing.

She gets a brief from the back of the room (Glyn Wintle) “How do you clean up Government data?”

EXAMPLE:
Lets say we want to design a site for the future. We know the basics about websites, they’re all on a rectagular screen. But what if the screen didn’t exist or what if it was circular? It’s still the web. When we look at the web, we always think about devices. Our devices at present are iPads, screens, phones, screenreaders (heckle from the back: “SEGA Dreamcast!”), Microsoft Surface. But what if your web was on a visor? Or going further, what if it’s not a flat screen, maybe it’s not on a device? What are we doing that’s projected at the moment? Currently projectors are used to create 3D visuals. The first thing to do is to think big, that’s when we’re revolutionising the web.

Jason Grant puts forward a situation, a conversation he had. ‘Femi thinks he’s doing the right thing. She likes to work by pushing the boundaries with her colleagues. Example, they did this in Star Trek, the PADD was looking to the future, it was born out of ‘revolution’ but has influenced the now.

When ‘Femi was younger she watched the Hanna Barbera cartoons, through that she was promised a future of flying cars, hover boards, silver foil dresses and other futuristic things. Our creative imagination leads to a place where we can iinnovate, we haven’t got the flying cars yet, but we do have small aircrafts which can be driven for short distances, we also have cars are capable of even faster speeds than before.. How different was this creative thinking than that which created the iPad?

Is it revolution or evolution? Jason Grant challenges from the audience. ‘Femi won’t get into that argument because she doesn’t necessarily disagree. She’s interested in tearing things apart in order to build them back up in new and exciting ways. You’re trying to generate volumes of ideas and get your brain working. We all think we’re very creative, but we restrict ourselves. Everything actually exists in the gray not in the black & white. To use a musical expression: ‘The key is to find the groove and ride it’.

Re-expression

Describing the problem in a different way. She want’s to design a website for 2050, what would it be like? From the audience “Rounded corners?”, “Comic Sans?”.

‘Femi laughs, instead of saying “I’m trying to design a website for 2050”, try to re-express the problem. Change the question around “In 2050, we think the world is going to look like X, how can we put that in sync with what everyone else is doing?”

She shows an image of a house that’s shaped like a plane. It’s designed for the owner to feel like they’re travelling, even though they no-longer can. If we’re looking at the web in 2050, we don’t know what it will look like, but there are companies like BMW who are looking at the interfaces of the future, head-up displays, in-built GPS. Sharing ideas helps innovation, for example the idea for roll-on deodorant came from its inventor looking at a ball-point pen.

Rendom Links

She asks people to shout out words: “Wibble”, “Badger” come back. When you think of these words what else do you think of?

Badger
Smelly – What if the web had a sense of smell?
Attack small children – What if the web could attack? But what does this mean? What if the web could reach out and touch you? What if it responded to gestures
Hairy – What if the web had texture?

Someone shouts out a crazy idea, but it leads to new thoughts. How can we put this in a package? How can we relate this to the web? What if the web was sensory? We can come up with new thoughts from crazy ideas.

Resistance

One of the things we find very hard is to let go of our preconceived notions. That’s called resistance. Nobody’s going to quote you on the crazy ideas you came up with. We need to cut down our resistance, it comes down to fear. Fear that others (our managers?) will critique out ideas. As a child we had lots of imagination. You’d get into a box and make it into something else, a car, a boat something else. Heckle from the audience “That’s thinking inside the box isn’t it?” (smile).

The Tool

She says: we always carry our digital devices with us. When people ask for creative tools, many responses are usually : ‘ Always carry your ipad, always have a pen and pad, a camera, use mind mapping e.t.c.’ The most important tool you have is your mind. You need to open this up and start a revolution in web design. So far we’ve had rounded corners(!!). Why don’t we have circular navigation? Seriously why not? Heckle from the audience “it’s the defacto standard” and “It’s usually top and left, but only because of resizing the viewport”.

Please look at a website called HitLantis. It has a beautiful circular navigation.

It’s not just that, it’s convention, agreement. Things won’t stop being a defacto standard, until you make something else. Defacto standard is something that we make it, we can change it. Things are never black or white, they’re shades of gray, there are no right or wrong answers.

However, the biggest thing you can do for yourself as a creative is give yourself a constraint. One could be time “I only have 20 mins to work on this”. Even if you had the most hostile environment for web development, you’d still get your sites online. What if every single browser obeyed the DOM? We wouldn’t need hacks, would we be coming up with sites that look the same? What if we disobeyed every single rule? There’s a beauty in constraints and a beauty in no constraints.

Comment from the audience “The iPhone changed things because it was significantly better”. ‘Femi asks, but significantly better for whom?

She finished on a quote from Einstein  “Imagination is better than knowledge.”

Other Links

• What If – http://whatif.com/
• Steve Pressfield, “Do the Work”
• Edward De Bono’s published works
• Sir Ken Robinson (especially one of Ken’s TED talks)

LWS Open & Creative – Live Blog

Open Data with Hadley Beeman (and Glyn Wintle)

Not many people have heard of LinkedGov. It began as a conversation over coffee. Hadley is talking today about open government data. There wasn’t a lot of data out there, it needed to be cleaned etc. Hadley’s background is in collaborative technologies.

She started LinkedGov to spread the load of work to make the data clean and useful. With Glyn Wintle, the Technology Strategy board and other she found out there are a lot of companies trying to use Government data. The Technology Strategy Board offered to help kick things off.

They’re talking about all Government data, from transport stats to the stats relating to Hospitals, to Council Tax, Benefits etc. It’s all the data collected by and for Government and all non-personably identifiable.

Why we’re not there yet?

It comes down to two basic problems:

1. A lot of the data has codes that make no sense to outsiders. The first challenge was to build a way to ask civil servants what data means only once, then use it over and over. Glyn explains how difficult this problem was before they worked this out, a technical person
2. Typos and other problems with the data. For example, marking something as closed that hasn’t been since 2009. Formatting issues. They have data is RDF, 20% PDF, a lot of CSV, Excel (definitely their favourite option)

Linking and Linked Data

They use Google Refine to go through data. There’s a lot that technology can to do wade through badly formed data. There’s also a lot that a human can do. She show’s an example of two Councils that show data in very different formats, they often get a human to make the connection between data sets that a computer would dismiss as wildly different. Another example is high streets. They combine Royal Mail data with other data to make some that’s very useful.

Underneath everything is a great big web of linked data. Each council has this. We end up with a highly complex graph. How do you wade through it? When cleaning up data you usually want to get a non-technical person to do it. They used Google Refine, but it’s designed for technical users who are used to how to tool works. LinkedGov devised a way to allow non-technical people to clean up data. This greatly increases the number of people who can work on the data.

Most interestingly LinkedGov uses games to get information out of data. Their aim is to use games as tools to get as many people as possible involved in the project. LinkedGov is a volunteer driven website, in order for it to survive, everybody putting something in has to get much more out of it.

For the civil servants putting letting us know what the codes mean, they’re getting data worked on by others. They get access to their own data.

Hadley shows an example of what the queries the site puts together. This site was the motivation for civil servants to input into the site. Otherwise they’d have no reason, exposing this data meant more work, potentially less money and perhaps show where you’re not doing your job properly. But being able to query the data (once worked on by volunteers) meant they’d comply.

This was an overview of what they’re up to. Any questions?

Q&A

Q. What volunteers are you looking for?

A. They need a lot of help designing games. Interfaces, the framework. They want them to be mobile friendly. The alpha of LinkedGov is designed to provoke developers to help make things better. Glyn says “It’s a crap product, please help us improve it”.

Q. Have you looked into Google’s visuals API?

A. There’a lot of potential for this, up until now they’ve been looking at the backend.

Q. Do you have any plans to help Government enter new data that they’re not at the moment?

A. LinkedGov is the “project that shouldn’t need to exist”. There are bits of Government where there are very very smart people and they’re will to help. However, it’s an effort in convincing senior managers that this is a good idea.

Q. Is there any evidence that data geeks respond to scoring?

A. They’ve done a lot of work establishing motivtations of the different people involved. the data geeks, they’re hoping that points will make it more fun, but also putting in a motivation pathway that it’s a better alternative to doing it yourself. There’s usually someone out there who’s interested

Q. How are you linking with Data.gov?

A. Hadley went to speak to they, they were really happy to help but they have no money. They’re focussed on transparency, LinkedGov is helping people to make money from it. Different aims, but it’s the same data so they help each other. One point, most of this data is Crown Copyright, however 99.99% of data coming out of Government is Open Government License (OGL).