WebDevConf 2014 – full notes

Posted on by magicroundabout

Introduction

Today was my first time at WebDevConf in Bristol. I was taking notes as I went. These are currently un-edited, and will probably make more sense to me than they will to others. But there might be useful tips and links in there.

I may edit/tidy up at some point.

Here’s the silly intro video:

https://twitter.com/sstarr/status/520487227777093632

Frank West – Think inside the box

Kids + imagination. Adults stop playing with boxes.

Webdev is exploring and learning. Always choosing directions, fighting battles, learning new things.

7 steps in building a website

  • Code. – creates the page
  • SEO/marketing – helps people find it
  • performance – people could turn away here
  • Design – could also put people off
  • Interaction – keeps people engaged with the site/page
  • Usability – make things easy
  • Accessibility

Developers can’t be experts in all these things…need to specialise.

As we get experienced we get stale – we use the things we know rather than continuing to explore and learn. We get set in our ways. We lose our childlike imagination!

We should come at problems as both the young, enthusiastic, imaginative child, but also as the older, wiser expert. And we should work with others: designers, performance experts, etc

We don’t often have time on projects to try out lots of new things. But perhaps we can focus on a particular area for each project. Try something out, user-test it. Learn as we go.

“Bus Stops” are the best times to do user testing. People ask with nothing to do who have a fixed amount of time.

We can get ordinary people to do user testing!!

Or we can do A/B testing.

https://twitter.com/mikegbabb/status/520514612354355201

Richard Healy (Basekit) – Designing for the unknown

Basekit is a CMS. Has 1.5million sites. Uses themes. The theme design team often don’t know what purposes the themes will be put to. So they are ‘designing for the unknown’

Twice as many websites are created every minute than babies are born!

“Content first” is a trend but doesn’t really reflect what Basekit does, or the reality of web development. TakeAway: you don’t need the content before designing.

But think about content when designing, . The design will need to fit the content rather than the other way around. E.g. Three column feature boxes: often designed to be the same length, when content is anything but.

Flexbox can come to the rescue here! Flexbox also gives you a cheeky generic vertical centre/middle alignment!

Images

70% of images on Basekit are landscape. 20% portrait. Only 10% square. But most galleries are designed for square and so crop images. The design doesn’t work with the content!

Headers

These are really contentious and VERY unknown. E.g. Logo formats and layouts, number of nav items.

Nav is HARD!

Logos

People upload HUGE logos images. Often including the company name.

The best way to handle this “unknown” is to just centre-align everything.

But need more control. Use “element queries” (this is a poly-fill, not built in)

Other

Lots of businesses running on Facebook. Users much more likely to update social media than a website through the CMS.

https://twitter.com/richardhealy/status/520627667742490624

Juksie – The Numbers Game

Works for Office for National Statistics.

“…the most important, worst website in the UK…”

And so on…

Current website is a litany of bad choices: bad tech, bad CMS, etc.

ONS is a monopoly. There’s nowhere else to get their data.

But the website is fragile: changing code is dangerous and often brings the site down.

Jukesie was given a blank canvas to rework the site. But he’s subject to the “cult” of GDS (see service manual and design principles

American equivalent (playbook.cio.gov)

HiPPO (Highest Paid Persons Opinion) vs proper user testing

ONS design principles

1. Users first

The media aren’t ONSs biggest users, they are just the most vocal.

The biggest user group are personal “foragers”

2. Data driven

3. Google is their homepage

80% of traffic comes from Google

Social hardly makes a dent (and isn’t really expected to) (interesting!)

4. It is about the numbers

Surface the stuff in HTML

The easiest thing for ONS staff to do is to upload Excel. They work TOTALLY in Excel and don’t consider that people might want to USE the data in other ways.

5. Don’t reinvent the wheel

6. Build for sustainability

Not bleeding edge, but technologies that have strong communities.

Interestingly, they’re in Newport and want local people available. This may affect tech choice?

7. Accessibility from day one

And inclusivity – make it simple and relevant to everyone.

8. agile not Agile

Take the bits that work for them without subscribing to any particular Agile ‘religion’.

9. Machines have needs too

APIs and OpenData are needed!

10. If all else fails: WWGDSD

What Would GDS Do?!

Style Guide

http://maban.co.uk/projects/front-end/style-guides

Alpha?

No. New site being opened to public for feedback in Dec/Jan

Old site on verge of breaking.

The process is transparent and open:

https://twitter.com/jukesie/status/520533873198108672

Jon Gold – A New Architecture

“Unicorn”? Makes multidisciplinary skills sound unattainable.

http://instagram.com/p/t-v-OuP-3A/

“Designgineer” – also used in derogatory manner

“Devigner”?!?!

Why do we have to break it down?:

“I MAKE INTERNET”

 

http://instagram.com/p/t-v-nFF0oN/

The division between designer/developer exists because of older technologies.

We can bulldoze these titles and their separation.

Stories from history:

  • Bauhaus
  • AJAX and Total Football
  • Dutch design firm (Experimental Jet Set) who share workload

It’s not that we need new job titles. We need a culture of tearing down silos.

We should do the combination of things that keeps you motivated and creative. This will probably be unique to you!!

Rachel Andrew – Were not a startup

Perch – their business – is “fully bootstrapped” – they aren’t funded by investors…and they won’t be.

Funded startups are different – they need to move fast to get quick ROI.

Rachel’s business is More like a marathon. Long term.

Funded startups also don’t tend to talk about money until they have to. Only when a sale or reinvestment is needed.

Product choice:

  • Something for your community
  • Something you can deliver quickly
  • Something that solves a problem that people will be willing to pay to be solved
  • Launch a product that has competition

Something for the community

Look for problems close to home, that you understand and can test assumptions of.

But be aware: Does the community want the product? Do they want you to come in and fix that problem for them?

Ship quickly

Perch v1.0 was about 4 weekends of work. Plus, another 4 weeks setting up documentation, website, sales, etc.

Ship something that you will use yourself, so it it fails, you’ve still benefitted.

Ship small: come up with a minimum product, but one that is a usable product. Keep it specific and small.

Something that people will pay for

Easier to businesses than consumers.

(Bootstrapped with Kids podcast)

Do people care that their workflow sucks and you think it could be better?

With Perch, agencies could solve the problem themselves, but Perch saves them time so they are willing to pay. Price appropriately: relate to time saved.

Getting people to pay is good!

Feedback from paid users is better. Free, community products take more time to build up a community base.

Launch a product that has competiton

Existing products allow you to research how you are different.

Totally new things need user education about why they need it.

Finding the time

Focus on one thing: one completed thing is worth way more than lots of incomplete things.

People find time for things that are important. Make your product important!

Make use of dead time between projects or when waiting for feedback from clients.

(Personal thought: Hack days?)

Make the product a ‘first class citizen’. Make them as important as your other jobs.

Set aside time. Plan in advance your tasks.

Set goals! Tasks with deadlines.

If not time, either re-plan, or re-scope: remove features to get MVP out of the door. Missing features will be more important to you than to your customers.

Don’t be apologetic about small feature set. Sell what you have!

Start small. Get feedback from customers. Improve based on feedback.

Launch and beyond

Side projects need support. Launch isn’t the end, it’s the beginning!

If it’s not profitable then why? Are you using expensive services? Pricing too low?

Growth of bootstraps is slow. How to manage it and keep it slow.

Don’t promise dates for features.

Don’t publish a roadmap. Allows you to adjust roadmap according to customer needs.

Work to use cases, not feature requests. Make sure you tell people when new features are implemented. Make it personal. Delight your customers in this way.

Sometimes, where appropriate and changes are trivial and non-breaking, release things quickly.

But don’t lose focus on your core use case. Don’t just do anything and everything. Say ‘no’!

Keep releases small. A major release could be done alongside a new website, payments, etc. avoid this!!

Don’t be led by a noisy Minority of customers.

Marketing

Marketing is about stories, not solutions. Tell people about real use cases.

Pre-launch sign-up: collect email address.

Market to a community that might want the product. This will work for a while but then you will flatline. Need to expand.

Content marketing: not just writing blog posts. Write and speak.

Sponsorship: conferences, podcasts, sites that you like.

Paid ads. Google, etc.

If you can’t track ads, don’t pay for it.

Target long-tail keywords. They’re cheaper and better targeted.

Buy sell ads. Research smaller sites that your ideal customer might visit. Advertise on them?

Social media: if someone mentions Perch to ask about it, perch retweet it, customers then reply.

Tractionbook.com

Create your own definition of success. Billion pound acquisitions are rare. But you can still be ‘successful’.

Slides at: http://rachelandrew.co.uk/presentations/not-doing-a-startup

Rob Hawkes – ViziCities

How do cities work? Food distribution, transport, waste.

Lots of BIG numbers when looking at city stats.

London has only 1 air ambulance!!

London has 7 power stations.

Cities are complex. It’s amazing that they work.

Understanding them is important.

Lots of data about cities: data.gov.uk

Vizicities already exists: SimCity’s data views

ViziCities aims to create these kinds of views for real cities.

Tube in 3D with live trains!

Aircraft.

Flooding.

Data journalists are starting to use it.

Open sourcing was the scariest and best decision of the project.

Making the complex simple

Cities aren’t 2D: streets, underground, airspace, buildings

BBC Crossrail documentary might be interesting to see.

ViziCities is potentially HUGE in terms of data. Too much to see.

Need to show people simplest form of things and allow them to dig deeper. But don’t dumb things down. “Progressive Complexity”

http://vizicities.com

Get Involved!

Future:

  • Oculus Rift
  • Myo band – gesture control

Gavin Strange – Graft, Craft, Being Daft

Gavin (see here) kinda just went nuts with some thrown together slides and animation. I didn’t take many notes. My main thought was that I wished I was more visually creative. But must remember this:

“The reason we struggle with insecurity is because we compare our behind-the-scenes with everyone else’s highlight reel”
? Steven Furtick
(See https://www.goodreads.com/author/quotes/4057607.Steven_Furtick

He basically got where he is today by being a polymath – doing loads of different things very enthusiastically.  Throwing stuff at the wall and seeing what sticks (a phrase I’m going to use a lot for a while).

Other takeaways:

  • “Being crap is OK”
  • “Make stuff that matters”

http://instagram.com/p/t-wKhlv-3a/

https://twitter.com/Pete_Gale/status/520620428688384000

And he referenced two books: