This is just a quick post to give you all the content and links I talked about.
Here’s the slidedeck on Slideshare
Links I mentioned:
You are currently browsing the archives for the General category.
This is just a quick post to give you all the content and links I talked about.
Here’s the slidedeck on Slideshare
Links I mentioned:
This morning Ars Technica had a wonderful article on CSS colour names titled ““Tomato” versus “#FF6347”—the tragicomic history of CSS color names“. It made me look again into the wonderful world of CSS colour names and create an interactive demo showing them when you roll over the colour swatches.
Building up on this, I created a small game, that allows you to train your knowledge of colours and their names.
(The colours in the game don’t change, this is a GIF issue…)
The source code is on GitHub, and it is pretty simple to create these things, once you have the dataset.
There were some fun exercises in there, like how to sort the colours by lightness (split the values each 2 characters, convert to decimal, push into array, sort it) and creating an array_shuffle in JS (hey, PHP has it).
The game keeps your score in local storage and should work fine on mobile – it does on my Huawei Honor.
When it comes to giving a talk at a conference the thing people freak out the most about is the delivery. Being in front of a large audience on stage is scary and for many people unthinkable.
I don’t want to discourage anyone to do this – it is amazing and it feels great to inspire people. The good news is that by covering the things here you will go on stage with the utmost confidence and you will dazzle.
I wanted to note down the things people don’t consider about presenting at conferences. There is no shortage of posts claiming that evangelism is “only presenting at conferences”. Furthermore it is deemed only worth-while when done by “real developers who work on the products”. This is the perfect scenario, of course. Before you judge “just presenting” as a simple task consider the following questions. If you are a professional presenter and evangelist you need to have them covered. More importantly, consider the time needed to do that work and how you would fit it into your daily job of delivering code.
If you talk about your own product, this is easy. It is also easy to be useless. Writing a demo for a talk that can’t fail is cheating. It is also hard to repeat for the audience. It is a theoretical exercise, and not a feat of delivery. Writing a product in a real work environment means dealing with other people’s demands and issues. It also means you have to re-think what you do a lot, and that makes for better products. How you built your product does not make it a best practice. It worked for you. OK, but is that repeatable by your audience or can they learn from you approach?
To give a great talk, you need to do a lot of homework:
It is easy to make grandiose statements and wrap them in the right rhetoric to be exciting. It is also easy to cause a lot of trouble with those. If you make a promise on stage, make sure it is yours to fulfill. You don’t want to get your colleagues into trouble or delivery stress by over-promising.
You are likely to present to an audience who know their stuff and are happy to find holes in your argumentation. Therefore you need to do your homework. Check your facts, keep them up-to-date and don’t repeat truisms of the past.
Get the newest information, and verify that it is fact before adding it to your talk. This also means checking various sources and cross-referencing them. Legwork, research.
Work with your colleagues who will need to deliver what you talk about and maintain it in the future. Ensure they are up to the task. Remember: you are not likely to be the maintainer, so delegate. And delegation means you need to give others a heads-up what is coming their way.
Your job is to educate and entertain the audience of the conference. To achieve this, you need to cater your talk to the audience. Therefore you need to understand them before you go forward. For this, you need to follow some steps:
Get information about the audience from the conference organisers:
Then think about what you’d like to get out of your talk:
A presentation is nothing without a story. Much like a movie you need to have to have an introduction, a climax and a conclusion. Intersperse this with some anectodes and real life comparisons and you have something people can enjoy and learn from. Add some humour and some open questions to engage and encourage. How do you do that? What fits this talk and this audience?
If you want the audience to repeat what you talk about you need to make sure your materials are available.
It is simple to pretend that we are a cool crowd and everyone gets a good geek joke. It is also easy to offend people and cause a Twitter storm and an ugly aftermath in the tech press.
It is also easy to get into legal trouble for bad-mouthing the competition or using media nilly-willy. Remember one thing: fair use is a myth and not applicable internationally. Any copyrighted material you use in your talk can become a problem. The simplest way to work around that is to only use creative commons licensed materials.
That might mean you don’t use the cool animated GIF of the latest TV show. And that might be a good thing. Do you know if the audience knows about this show and gets your reference? Thinking internationally and questioning your cultural bias can be the difference between inspiring and confusing. Or frustrating. If you talk about great products that aren’t available in the country you present. Don’t write your talk from your perspective. Think what the audience can do with your material and if they can understand it.
There are quite a few things that affect the time you have to prepare your presentation:
Depending on what the conference does for you, they also want you to help them. That can include:
This needs time allocated to it. In general you can say a one day conference will mean you’re out for three.
Traveling is the biggest unknown in your journey to the stage. All kind of things can go wrong. You want to make sure you book the right flights, hotels and have a base close to the event. All this costs money, and you will find conference organisers and your company try to cut down on cost whenever they can. So be prepared for some inconvenience.
Booking and validating your travel adds and extra two days to your conference planning. Getting to and from your home to the event can be a packed and stressful journey. Try to avoid getting to the event stressed, you need to concentrate on what you are there for. Add two buffer days before and after the event at least.
Booking your own travel is great. You are not at the mercy of people spelling your name wrong or asking you for all kind of information like your passport and date of birth. But it also means you need to pay for it in some way or another and you want that money back. Finding a relaxed and affordable schedule is a big task, and something you shouldn’t take too lightly.
You are going to be out for a while. Both from work and your home. Make sure that in your absence you have people in place that can do the job you normally do. Make sure you covered all the needs like passport and visa issues and you know everything about the place you go to.
Prepare to get sick and have medication with you. It can happen and it should not be the end of the trip. Stay healthy, bring some safe food and plan for time to work out in between sitting cramped on planes and in cars.
Do you know how to get to the hotel and around the city you present in? Do you speak the language? Is it safe? Is there someone to look after your home when you’re gone? Prepare for things going wrong and you having to stay longer. Planes and trains and automobiles fail all the time.
Conference participation costs money. You need to pay for travel, accomodation, food, wireless, mobile roaming costs and many more unknowns. Make sure you get as much paid for you as possible. Many conference organisers will tell you that you can pay for things and keep receipts. That means you will have to spend quite some time with paperwork and chasing your money. The same applies to company expense procedures. You need to deal with this as early as possible. The longer you wait, the harder it gets.
A local event is pretty easy to sell to your company. Flying somewhere else and having the both the cost of money and time involved is harder. Even when the conference organiser pays – it means you are out of the office and not available for your normal duty. One way to add value for your company is to add meetings with local clients and press. These need to be organised and planned. So ensure you cater for that.
It is great to use online editors to write your talk. It means people can access your slides and materials. It also means you are independent of your computer – which can and will behave oddly as soon as you are on stage. Online materials are much less useful once you are offline on stage. Conference wireless is anything but reliable. Make sure you are not dependent on a good connection. Ask about the available resolution of the conference projection equipment. Don’t expect sound to be available. And above all – bring your own connectors and power cables and converters.
Your company gave you time and money to go to a conference and give a talk. How do you make this worth their while? You have to show something on your return. Make sure you measure the feedback your talk got. See if you can talk to people at the event your company considers important. Collect all this during the event and analyse and compact it as soon as you can. This sounds simple, but it is tough work to analyse sentiment. A Twitter feed of a conference is pretty noisy.
If you work for a larger company, they expect of you as an evangelist to make your materials available for others. A lot of companies believe in reusable slide decks – for better or worse. Prepare a deck covering your topic that is highly annotated with delivery notes. Prepare to present this to your company. Whilst hardly anything is reusable, you are expected to make that happen.
After the conference you have to answer emails, contact requests and collect and note down your leads. Most companies expect a conference report of some sort. Many expect you to do some internal presentation to debrief you. What you did costs a lot of time and money and you should be prepared to prove your worth.
You’ll get more requests about your talk, the products you covered and people will ask you to speak at other events. And thus the cycle starts over.
That’s just a few of the things you have to consider as a presenter at conferences. I didn’t deal with stress, jet lag, demands, loneliness and other mental influences here. Next time you claim that people “talk instead of being a real coder” consider if what you’re saying is valid criticism or sounds a bit like “bro, do you even lift?”. Of course there are flim-flam artists and thinly veiled sales people calling themselves evangelists out there. But that doesn’t mean you should consider them the norm.
These are the notes of my talk at SmartWebConf in Romania. Part 1 covered how Impostor Syndrome cripples us in using what we hear about at conferences. It covered how our training and onboarding focuses on coding instead of human traits. In Part 2 I showed how many great things browsers do for us we don’t seem to appreciate. In this final part I’ll explain why this is and why it is a bad idea. This here is a call to action to make yourself feel better. And to get more involved without feeling inferior to others.
This is part 3 of 3.
It is an inspiring feeling to be the person who solved a web-wide issue. It boosts our ego to see that people rely on our brains to solve issues for them. It is great to see them become more effective and faster and free to build the next Facebook.
It gets less amazing when you want to move on and do something else. And when people have outrageous demands or abuse your system. Remy Sharp lately released a series of honest and important blog posts on that matter. “The toxic side of free” is a great and terrifying read.
Releasing software or solutions as open source is not the same as making it available for free. It is the start of a long conversation with users and contributors. And that comes with all the drama and confusion that is human interaction. Open Source is free as in puppy. It comes with responsibilities. Doing it wrong results in a badly behaving product and community around it.
If you embrace the idea that open source and publishing on the web is a team effort, you realise that there is no need to be on the bleeding edge. On the opposite – any “out there” idea needs a group of peers to review and use it to get data on how sensible the idea really is. We tend to skip that part all too often. Instead of giving feedback or contributing to a solution we discard it and build our own. This means all we have to do is to deal with code and not people. It also means we pile on to the already unloved and unused “amazing solutions” for problems of the past that litter the web.
The average web page is 2MB with over 100 http requests. The bulk of this is images, but there is also a lot of JS and CSS magical solutions in the mix.
If we consider that the next growth of the internet is not in the countries we are in, but in emerging places with shaky connectivity, our course of action should be clear: clean up the web.
Of course we need to innovate and enhance our web technology stack. At the same time it is important to understand that the web is an unprecedented software environment. It is not only about what we put in, it is also about what we can’t afford to lose. And the biggest part of this is universal access. That also means it needs to remain easy to turn from consumer into creator on the web.
If you watch talks about internet usage in emerging countries, you’ll learn about amazing numbers and growth predictions.
You also learn about us not being able to control what end users see. Many of our JS solutions will get stripped out. Many of our beautiful, crafted pictures optimised into a blurry mess. And that’s great. It means the users of the web of tomorrow are as empowered as we were when we stood up and fought against browser monopolies.
So there you have it: you don’t have to be the inventor of the next NPM module to solve all our issues. You can be, but it shouldn’t make you feel bad that you’re not quite interested in doing so. As Bill Watterson of Calvin and Hobbes fame put it:
We all have different desires and needs, but if we don’t discover what we want from ourselves and what we stand for, we will live passively and unfulfilled.
So, be active. Don’t feel intimidated by how clever other people appear to be. Don’t be discouraged if you don’t get thousands of followers and GitHub stars. Find what you can do, how you can help the merging of bleeding edge technologies and what goes into our products. Above all – help the web get leaner and simpler again. This used to be a playground for us all – not only for the kids with the fancy toys.
You do that by talking to the messy kids. Those who build too complex and big solutions for simple problems. Those doing that because clever people told them they have to use all these tools to build them. The people on the bleeding edge are too busy to do that. You can. And I promise, by taking up teaching you end up learning.
These are the notes of my talk at SmartWebConf in Romania. Part 1 covered how Impostor Syndrome cripples us in using what we hear about at conferences. It also covered how our training and onboarding focuses on coding. And how it lacks in social skills and individuality. This post talks about the current state of affairs. We have a lot of great stuff to play with but instead of using it we always chase the next.
This is part 2 of 3.
When reading about the state of the web there is no lack of doom and gloom posts. Native development is often quoted as “eating our lunch”. Native-only interaction models are sold to us as things “people use these days”. Many of them are dependent on hardware or protected by patents. But they look amazing and in comparison the web seems to fall behind.
This is true, but it also not surprising. Flash showed many things that are possible that HTML/CSS/JS couldn’t do. Most of these were interesting experiments. They looked like a grand idea at the time. And they went away without an outcry of users. What a native environment have and what we do on the web is a comparison the web can’t win. And it shouldn’t try to.
The web per definition is independent of hardware and interaction model. Native environments aren’t – on the contrary. Success on native is about strict control. You control the interaction, the distribution and what the user can and can’t see. You can lock out users and not let them get to the next level. Unless they pay for it or buy the next version of your app or OS. The web is a medium that puts the user in control. Native apps and environments do not. They give users an easy to digest experience. An experience controlled by commercial ideas and company goals. Yes, the experience is beautiful in a lot of cases. But all you get is a perishable good. The maintainer of the app controls what stays in older versions and when you have to pay the next version. The maintainers of the OS dictate what an app can and can not do. Any app can close down and take your data with it. This is much harder on the web as data gets archived and distributed.
Evolution happens and we are seeing this right now. Browsers on desktop machines are not the end-all of human-computer interaction. That is one way of consuming and contributing to the web. The web is ubiquitous now. That means it is not as exciting for people as it was for us when we discovered and formed it. It is plumbing. How much do you know about the electricity and water grid that feeds your house? You never cared to learn about this – and this is exactly how people feel about the web now.
This doesn’t mean the web is dead – it just means it is something people use. So our job should be to make that experience as easy as possible. We need to provide a good service people can trust and rely on. Our aim should be reliability, not flights of fancy.
It is interesting to go back to the promises HTML5 gave us. Back when it was the big hype and replacement for Flash/Flex. When you do this, you’ll find a lot of great things that we have now without realising them. We complained when they didn’t work and now that we have them – nobody seems to use them.
Take forms for example. You can see the demos I’m about to show here on GitHub.
When it comes down to it, most “apps” in their basic form are just this: forms. You enter data, you get data back. Games are the exception to this, but they are only a small part of what we use the web for.
When I started as a web developer forms meant you entered some data. Then you submitted the form and you got an error message telling you what fields you forgot and what you did wrong.
<form action="/cgi-bin/formmail.pl"> <ul class="error"> <li>There were some errors: <ul> <li><a href="#name">Name is required</a></li> <li><a href="#birthday">Birthday needs to be in the format of DD/MM/YYYY</a></li> <li><a href="#phone">Phone can't have any characters but 0-9</a></li> <li><a href="#age">Age needs to be a number</a></li> </ul> </li> </ul> <p><label for="name">Contact Name *</label> <input type="text" id="name" name="name"></p> <p><label for="bday">Birthday</label> <input type="text" id="bday" name="bday"></p> <p><label for="lcolour">Label Colour</label> <input type="text" id="lcolour" name="lcolour"></p> <p><label for="phone">Phone</label> <input type="text" id="phone" name="phone"></p> <p><label for="age">Age</label> <input type="text" id="age" name="age"></p> <p class="sendoff"> <input type="submit" value="add to contacts"> </p> </form>
This doesn’t look much, but let’s just remember a few things here:
HTML5 supercharged forms. One amazing thing is the required attribute we can put on any form field to make it mandatory and stop the form from submitting. We can define patterns for validation and we have higher fidelity form types that render as use-case specific widgets. If a browser doesn’t support those, all the end user gets is an input field. No harm done, as they can just type the content.
In addition to this, browsers added conveniences for users. Browsers remember content for aptly named and typed input elements so you don’t have to type in your telephone number repeatedly. This gives us quite an incredible user experience. A feature we fail to value as it appears so obvious.
Take this example.
<form action="/cgi-bin/formmail.pl"> <p><label for="name">Contact Name *</label> <input type="text" required id="name" name="name"></p> <p><label for="bday">Birthday</label> <input type="date" id="bday" name="bday" placeholder="DD/MM/YYYY"></p> <p><label for="lcolour">Label Colour</label> <input type="color" id="lcolour" name="lcolour"></p> <p><label for="phone">Phone</label> <input type="tel" id="phone" name="phone"></p> <p><label for="age">Age</label> <input type="number" id="age" name="age"></p> <p class="sendoff"> <input type="submit" value="add to contacts"> </p> </form>
There’s a lot of cool stuff happening here:
datefield has a placeholder telling the user what format is expected. You can type a date in or use the arrows up and down to enter it. The form automatically realises that there is no 13th month and that some months have less than 31 days. Other browsers even give you a full calendar popup.
numbertypes do not only limit the allowed characters to use, but also switch to the appropriate on-screen keyboards on mobile devices.
That’s a lot of great interaction we get for free. What about cutting down on the display of data to make the best of limited space we have?
Originally, this is what we had select boxes for, which render well, but are not fun to use. As someone living in England and having to wonder if it is “England”, “Great Britain” or “United Kingdom” in a massive list of countries, I know exactly how that feels. Especially on small devices on touch/stylus devices they can be very annoying.
<form action="/cgi-bin/formmail.pl"> <p> <label for="lang">Language</label> <select id="lang" name="lang"> <option>arabic</option> <option>bulgarian</option> <option>catalan</option> […] <option>kinyarwanda</option> <option>wolof</option> <option>dari</option> <option>scottish_gaelic</option> </select> </p> <p class="sendoff"> <input type="submit" value="add to contacts"> </p> </form>
However, as someone who uses the keyboard to navigate through forms, I learned early enough that these days select boxes have become more intelligent. Instead of having to scroll through them by clicking the tiny arrows or using the arrow keys you can start typing the first letter of the option you want to choose. That way you can select much faster.
This only works with words beginning with the letter sequence you type. A proper autocomplete should also match character sequences in the middle of an option. For this, HTML5 has a new element called
<form action="/cgi-bin/formmail.pl"> <p> <label for="lang">Language</label> <input type="text" name="lang" id="lang" list="languages"> <datalist id="languages"> <option>arabic</option> <option>bulgarian</option> <option>catalan</option> […] <option>kinyarwanda</option> <option>wolof</option> <option>dari</option> <option>scottish_gaelic</option> </datalist> </p> <p class="sendoff"> <input type="submit" value="add to contacts"> </p> </form>
This one extends an
input element with a
list attribute and works like you expect it to:
There is an interesting concept here. Instead of making the select box have the same feature and roll it up into a combo box that exists in other UI libraries, the working group of HTML5 chose to enhance an input element. This is consistent with the other new input types.
However, it feels odd that for browsers that don’t support the
datalist element all this content in the page would be useless. Jeremy Keith thought the same and came up with a pattern that allows for a select element in older browsers and a datalist in newer ones:
<form action="/cgi-bin/formmail.pl"> <p> <label for="lang">Language</label> <datalist id="languages"> <select name="lang"> <option>arabic</option> <option>bulgarian</option> <option>catalan</option> […] <option>kinyarwanda</option> <option>wolof</option> <option>dari</option> <option>scottish_gaelic</option> </select> </datalist> <div>or specify: </div> <input type="text" name="lang" id="lang" list="languages"> </p> <p class="sendoff"> <input type="submit" value="add to contacts"> </p> </form>
This works as a datalist in HTML5 compliant browsers.
In older browsers, you get a sensible fallback, re-using all the option elements that are in the document.
This is not witchcraft, but is based on a firm understanding of how HTML and CSS work. Both these are fault tolerant. This means if a mistake happens, it gets skipped and the rest of the document or style sheet keeps getting applied.
In this case, older browsers don’t know what a
datalist is. All they see is a select box and an input element as browsers render content of unknown elements. The unknown
list attribute on the input element isn’t understood, so the browser skips that, too.
HTML5 browsers see a
datalist element. Per standard, all this can include are
option elements. That’s why neither the
select, nor the
input and the text above it get rendered. They are not valid, so the browser removes them. Everybody wins.
Browsers and the standards they implement are full of clever and beautiful things like that these days. And we’ve loudly and angrily demanded to have them when they got defined. We tested, we complained, we showed what needed to be done to make the tomorrow work today and then we forgot about it. And we moved on to chase the next innovation.
How come that repeatedly happens? Why don’t we at some point stop and see how much great toys we have to play with? It is pretty simple: control.
But more on that in part 3 of this post.