Christian Heilmann

Posts Tagged ‘pragmatism’

Using HTML5 sensibly and Multimedia on the web – speaking at the London Ajax Meetup

Wednesday, February 9th, 2011

Yesterday night I spoke at the London Ajax Meetup about Multimedia on the web (a repeat of my MIT talk as I wanted a video of it) and “Using HTML5” sensibly.

Especially the second talk was close to my heart as I think it is high time us developers take back HTML5 from the marketing people. HTML5 is the evolution of our web technologies, not another flashy add-on to already badly used outdated practices.

You can find the Slides of the talk on Slideshare:

The audio recording of the talk is also available on archive.org.

The organisers promised that the video of the talks is available soon.

I am also going to write a detailed post on Mozilla once the video is available.

Enjoying the full stack – my talk at Frontend2010 in Oslo, Norway

Friday, September 3rd, 2010

I just got back from Frontend 2010 in Oslo, Norway. Two days of excessive drinkinggreat information about designing and building the web of tomorrow.. I was invited as a speaker alongside a lot of great people and my task was to give the last presentation of the conference to sum up a bit what we had heard about and what to do with it when we get back home. And this is what I did. Here are the slides. More to come later when the video is out and I am not using my almost empty Nexus as a hotspot as the British Airways wireless is FAIL again.

Chris Heilmann the mild mannered speakerChris Heilmann the revengeful norse god

FOWA Dublin – Powerful Tools that You Need (and Probably Don’t Know About)

Sunday, May 16th, 2010

Last Friday I was up in Dublin at the Future of Web apps and gave my talk “Powerful Tools that You Need (and Probably Don’t Know About)”. I took FOWA as an opportunity to (re-)introduce the audience to some of the tools Yahoo offers and to brand the drive of developers to do everything by themselves instead of using already built solutions as ineffective.

The slides of my talk are available on SlideShare:

The audio of the talk is on Archive.org:

The video of the talk is available on Ustream:

Here are the resources I talked about as links:

Also check the YDN blog in the next few days for a full FOWA report.

Chasing the shiny – HTML5, CSS3, transitions – oh my!

Friday, May 14th, 2010

Yesterday I had a back and forth on Twitter with Paul Irish and Divya Manian on Twitter about a thing that is full of win but also drives me crazy.

Those two lads built http://html5readiness.com/ – a beautiful demo of what you can do with CSS transformations, JavaScript and markup these days. Here’s what it looks like:

HTML5 Readiness

In essence this is the designer’s eye for http://caniuse.com/ which listed the same information in a lesser visual but very useful manner.

When I looked at the visualisation I went “WOW” and so did a lot of other people. But actually when using the site my fascination and interest quickly disolved.

I consider myself quite an observant person and I can read really, really fast. Looking at this visualization though I found myself constantly having to check from the coloured ray to the legend to understand just which browser we are currently talking about. Clicking the fixed browser position checkbox made this a bit more obvious but I am still very confused – especially as the colours are close to each other (on my laptop) and the rollover colour change doesn’t match the legend any more. This gets even more confusing when the colour of the main ray and the rollover changes:

HTML5 Readiness dark rollover.

I have no clue why the ray is coloured differently. I might think it is the connector between HTML5 and CSS3, but Geo Location is not part of HTML5.

The next thing I normally do to any interface is to turn off CSS to see how it degrades for non-visual users or on old mobile devices (yes, I do have to use an old Blackberry from time to time).

If you do this on HTML5 readiness you get a terrible experience:

HTML5 without CSS

  • There is no connection between the year names and the browser support (other than links – a nested list would make the connection much more obvious).
  • None of the links (like “Multiple backgrounds”) does anything.

What really made me very confused was looking at the source code though. The authors use B and I tags all over the shop and one of the rays for example is:
















Multiple Backgrounds

OK, I get it – I and B are text stylistically offset from the normal prose without conveying any extra importance> which technically gives us a carte blanche to do whatever we please with these elements.

Back in the real world, however, WYSIWYG editors have B and I buttons which include these elements as BOLD and ITALIC. Now, as accessibility and semantics fans we’ve been bickering for years that this is a bad idea as this is painting with HTML rather than telling a user agent that the text needs to be emphasized or strong. We made quite some headway with this – and people started listening to us. Now we go back and say “oh well then, actually this is all fine – use whatever you want”.

All in all this example reminds me of something I built 8 years ago:

Logo painted with a layout table

This was friggin cool back then. It was done for the Commodore 64 scene and it had to work in every browser that knows HTML - including Amiga ones. I managed to make it a “how is that done” moment by not using an image but instead a layout table with spacer gifs:




















































































































.: the very best of :.


                                                             
                                                   
                                                           
                                                   
                                                   


Wow, terrible, right? Who would use tables for layout? This is madness – these are technologies we shouldn’t need to use any longer.

Or is it? By using the plethora of HTML elements in the visualisation above we do exactly the same thing! HTML is there to logically structure content and give it semantic meaning – not to paint lovely pictures.

The page uses Can I use as its source of data – but instead of using a scraper and converting it to the necessary HTML (and by that making it possible to update automatically) the data is duplicated – and once displayed with no semantic value or logical structure whatsoever. We have the technology to convert sensible, good and clean HTML and turn it into something different. I’ve proven that in the past with the data table to charts conversion script:

Generating charts from accessible data tables using the Google Chart API by  you.

I really don’t understand why we forget the simple promise we share with our users over and over again:

  • Build on stuff that works and then make it more interactive and pretty

In the case of this visualisation – use data tables and generate all the fluff and classes you need to make the CSS work out with JavaScript. Or – how about using SVG for the whole thing?

I am not saying that Paul and Divya did something bad – I am big fans of their work – I am just saying that we keep doing the same mistakes. If you would not write some HTML by hand and only need it for an effect – you are doing things wrong.

On being cleverly lazy – my talk at the WebExpo in Prague

Monday, October 19th, 2009

I am currently in Prague, Czech Republic and gave a talk on re-use, professionalism and ease of development at the WebExpo.

Webexpo Prague by  you.Webexpo Prague by  you.

Today I am going to have a longer chat with the people at the University about accessibility and creating a WAI-ARIA enabled framework for web applications.

For now, here are the slides of the WebExpo presentation and the audio recording of the talk. There was a video streaming, too, and it is up to Microsoft now to get this out as a recording.

Slides

Audio recording

You can download on being cleverly lazy as an MP3 - 36MB or see other audio options on archive.org

Notes / Transcript

Today I will talk about the fact that being cleverly lazy will make you a better developer.

First of all, I am Chris, a developer evangelist. This means I am a developer who evolved into a role where I can tell other developers how to have an easier life and tell my company what other things developers would want to make it even easier for them. I’ve written a developer evangelism handbook if you are interested in learning more about this role and why your company would benefit from having someone like me.

Cleverly lazy

Let me quickly define cleverly lazy here. Lazy is “I don’t want to do it” wheres cleverly lazy is “I don’t want to do that ever again so I do it right this time”. In development the difference between lazy and cleverly lazy is that lazy products do the job but are impossible to maintain whereas cleverly lazy products do the job, are easy to understand, extend and are built on a solid base.

Evolving the web

Our job as developers, designers, planners and organisers of web products is to evolve the web. We should have the chance to concentrate on building solutions that make people happy to use them rather than having to work out how one browser or another fails or how we convert data into a format the web technologies can display and understand.

In order to achieve this, we need to be free to do new things rather than worrying about the past.

The feature loop trap.

One problem is that as developers, we stand in our own way. The biggest trap that there is for developers is the feature loop:

  • As developers we love to take a complex problem and tackle it. We love solving problems, that is why we become developers.
  • We then normally and quite quickly find a simple solution to the complex problem.
  • We then release the solution to the world and get feedback.
  • This is where it goes pear-shaped. We get stuck in a feature adding and feedback loop until the elegant, easy and simple solution becomes a complex one again.
  • Other developers will find our former simple solution and will think “hey, this is a complex problem, let’s make that easy!”

This keeps us from evolving as web developers. We don’t develop the web, we fill it up with solutions to the same problem.

My solution

The next issue is that as developers we love to find solutions ourselves and not use other people’s information. We appreciate other people’s work but in the end we only trust ourselves to come up with the best solution ever.

Short attention span

The problem with finding and building own solutions is that we tend to lose interest in them really fast and then leave them behind as we already another complex problem to simplify. This leads to lots of half-finished solutions on the web that don’t get any love any longer.

Unmaintained code is a security problem

All the code that is not getting any love stays unmaintained on the web and becomes a wonderful attack vector for new security threats or vulnerability exploits. Nothing beats being up-to-date when you want to build secure systems.

Things web developers must know to do their job.

Looking at our job as web developers, here are the things you have to be aware of to build things that people can use.

  • The technologies involved
  • How browsers deal with these technologies and how they fail to support them
  • Security concerns and attack vectors
  • Usability and accessibility of the product
  • Internationalisation of our products
  • Performance concerns
  • Multiple platform support
  • Flexibility of the interface

Browsers suck

Browsers are the bane of our existence as they are unpredictable, unreliable, there are hundreds of them (in various configurations) and they are not being updated by people out there.

That is a lot to know and deal with. The good news is that you don’t need to know all of it.

Good developers are like librarians

Librarians are great people. Instead of knowing everything that is in the library they know exactly where to find the information to solve a problem. As a cleverly lazy developer you should do the same.

Build on a solid foundation

Web development libraries came around for one simple purpose: Make our life as developers easier and our work as web developers predictable. They make browsers suck less and work around differences in browsers. They allow us to use web standards and get results instead of bugs to fix.

Build with components

If you build web applications and interfaces take a look around for what has already been created for you. Almost every library comes with widgets that are tested, work for everybody regardless of ability and can be changed to your needs. If you build your own component you are very likely indeed to forget some very necessary functionality that a collaborative product already had put in.

Use a good debugging environment

You can’t write great products without being able to know what is going on. Luckily enough nowadays we have great debugging tools like Firebug, Yahoo Profiler, JSLint and validators of all kind.

Plan for extensions

If you build a solution, plan a way so that people can extend it without having to change the central code. The central code should only have to change when there is a new browser or platform to be supported or there’s a security fix. Other than that people should be allowed to extend by listening for events or using other API hooks into your product.

Read, use and write documentation

If you build something, document it. There is no such thing as code that explains itself, that is a myth and an arrogant one at that.

Use the web

One of the really cleverly lazy things to do these days is to use the web to build your product rather than building your product and putting it on the web. Distribute your content on specialised systems like Flickr, YouTube, Delicious and LinkedIn and then put it together in a centralised CMS. That way your site will be easy to maintain and not vulnerable to a single point of failure.

Use APIs

To achieve this you need to use APIs. APIs can take a lot of your time to read up on and understand which is why it is a good plan to use YQL as an in-between to avoid going crazy on authentication and understanding what parameters go in and what data comes out.

An example

As an example, let’s take a look at a web site built solely from data on the web, using YQL and PHP.

Thanks!

Thank you, remember if you use what is out there you have time to be creative. I want us to write code most of our time, not to fix bugs.