Posts Tagged ‘idea’

Book idea: The Vanilla Web Diet

Tuesday, October 30th, 2012

I right now feel the itch to write a book again. I see a lot of people buying books and making a living selling them and I feel that there is a space for what I have in mind. I also don’t see how I could cover all the things I want to cover right now in talks or blog posts. It is presumptuous to think you’d follow a series of them so using a book form with code and possibly a series of screencasts seems to be the right format.

vanilla cupcakes

I have a few outstanding offers by publishers but having my first publisher just hand over a second edition of my first book to someone else without waiting for my yay or nay makes it less interesting to me to go through the traditional publishing route. Whilst I am pondering other distribution offers (and if you have some, talk to me) here is what I am planning to write about:

The web needs a diet

Web development as we know it has gone leaps and bounds lately. With HTML5 we have a massive opportunity based on a predictable rendering algorithm across browsers. CSS has evolved from removing the underline of links and re-adding it on hover to a language to define layout, animation and transformations. The JavaScript parts of HTML5 give us a much simpler way to access the DOM and manipulate content than traditional DHTML and DOMScripting allows us to.

Regardless of that, we still clog the web with lots and lots of unnecessary code. The average web site is well beyond a megabyte of data with lots of HTTP requests as our desktop machines and connections allow us to add more and more – in case we need it later.

On mobile the whole thing looks different though and connectivity is more flaky and each byte counts. In any case we should be thinking about slimming down our output as we put more and more code that is not needed out, adding to a landfill or quickly dating solutions that will not get updated and fixed for future environments and browsers. We litter the web right now, and the reasons are:

  • A wrong sense of duty to support outdated technology (yes, OLDIE) without really testing if our support really helps users of it
  • A wrong sense of thinking that everything needs to be extensible and architected on a enterprise level instead of embracing the fleeting nature of web products and using a YAGNI approach.
  • An unwarranted excitement about technology that looks shiny but is not to be trusted to be around for long

Shed those kilobytes with the fat-free vanilla approach

In the book I’d like to outline a pragmatic and backwards compatible way of thinking and developing for the web:

  • We start with standards-compliant code that works without relying on hacks and temporary solutions
  • We improve when and if the environment our code is consumed in supports what we want to do
  • Instead of shoe-horning functionality into outdated environments, we don’t leave promises of functionality when it can not be applied
  • We write the right amount of code to be understandable and maintainable instead of abstracting code to write the least amount without knowing what the final outcome is

The book will be opinionated and challenge a few ideas that we started to love because of their perceived usefulness for developers. In the end though I want to make people aware of our duty to produce the best products for our end users and to write code for the person who will take over from us when we want to move on to other things.

The book will teach you a few things:

  • How to build with instead of just for the web
  • How to use what browsers can do to build without writing much code
  • How to avoid writing code that will fail in the near future
  • How to not make yourself dependent on code you don’t control
  • How to learn to let go of “best practices” that made a lot of sense in the past but are not applicable any longer
  • How to have fun with what we have as web developers these days without repeating mistakes of the past
  • How to embrace the nature of the web – where everybody is invited, regardless of ability, location or technology

What do you think? Tell me on Facebook or Google+.

The skill swap Twitter game

Friday, June 10th, 2011

At the Inspire conference this week Simone Brummelhuis of The Next Women used one of the breaks to play “The Skill Swap” game.

Simone handed out sheets of paper where you could say what skill you need and what skill you have and your contact details. She then picked a few and asked the people to stand up and matched them with people in the audience who were happy to provide the skills needed. All in all it was good fun and quite useful. However, I considered it a bit “eighties” – especially at a conference dealing with inspiration in new technology:

  • It kills trees
  • Simone had to decipher handwriting (and failed at time)
  • What happens to the papers with people’s contact details afterwards? This could be confidential information
  • It doesn’t scale as you have only a short time to make a few matches

Instead I want to move the idea of that game to a place where it makes more sense: Twitter. For this, I’d need some test data I’d love you to provide me with.

How the skill swap game can work with Twitter

Instead of providing papers to fill out we could do simple tweets and write a small app that harvests them. The syntax could be pretty simple:

#{conference} - #sks-{have|want}-{skill}

So say you are at FOWA London 2011 and you are looking for a UX person the Tweet would be

#fowaldn2011 - #sks-want-ux

If you are an mobile startup looking for funding, you can do

#fowaldn2011 - #sks-want-funding(mobile startup)

If you are a kick-ass developer:

#fowaldn2011 - #sks-have-html5,javascript,css3

And so on. The app could then show a pool of wants and haves and the people who offer them. It could suggest pairings and show trends which are the hottest wants and needs and so on.

Let’s have a go

What do you think? In order to start with this I’d like to have some data. So let’s come up with a fake conference and send out some Tweets please.

For the conference, let’s take the name #awesomeconf – bring the data :)

@codepo8 #awesomeconf - #sks-have-html5

Would opt-in or opt-out for Google Streetview be a better solution?

Saturday, August 14th, 2010

Seems like the whole of Europe is currently up in arms against Google streetview showing their houses (let’s not even start with the sniffed wireless points and their data) and as friends in Google tell me there are queues in the Google Germany office where people request their houses to be removed.

Should Google Streetview be opt-in? by photo

The reason is privacy and people are worried about security. As my mom put it “Thieves only need to use that Streetview thing and see where there are nice houses to steal things” to which I replied that they could also use a technology like a bicycle or a car to do the same thing and they wouldn’t have to go far to steal things.

Now, today a friend of mine Christian Bräunlich had a damn good idea and put it on a mailing list:

Bestimmte Leute wollen ja ihre Haeuser nicht im Streetview haben. Mein
Vorschlag zur Loesung: es wird ein spezieller 2D-Barcode definiert. Jeder kann
sich den ausdrucken und über die Tür kleben. Dieses Haus wird dann verpixelt.
Vorteil: geringer Aufwand, erprobte Technik: das hat schon vor 6000 Jahren
funktioniert. Häuser können automatisiert verpixelt werden. Den Barcode sieht
man kaum, man könnte ja verschiedene je nach Hausfarbe, definieren.
Ich denke ja nicht, dass alle fristgerecht ihre Anträge einreichen koennen zur
Entfernung, und ausserdem bindet das doch viel Manpower bei Google.

In English:

Some people aren’t happy about seeing their houses in Streetview. Here’s my proposal for a solution: you define a 2D barcode that people can print out and display on their house. Houses with a bar code don’t added to Streetview. The benefits are: this is simple to achieve, the technique is old and already proven (6000 years ago, really). You can hardly see the barcode and you could offer several different ones according to the colour of the house. I don’t think that people will be able to send in their requests to be removed from Streetview in time and the overhead in manpower at Google to respond to removal requests is another problem.

This is the opt-out idea. You could also turn that around and make it an opt-in. If you want to have your house in – display a barcode.

The only problem I can see with this is when you have houses with several tenants. The other benefit of this is that Google could offer these barcodes and send them by mail. They could also create a generator that would allow for example shops to also add their names and product offers in the barcode data and thus enhance the Streetview information even further. What do you think?