• You are currently browsing the archives for the General category.

  • Archive for the ‘General’ Category

    Thank you, TEDx Thessaloniki

    Tuesday, May 13th, 2014

    Last weekend was a milestone for me: I spoke at my first TEDx event. I am a big fan of TED and learned a lot from watching their talks and using them as teaching materials for coaching other speakers. That’s why this was a big thing for me and I want to take this opportunity to thank the organisers and point out just how much out of their way they went to make this a great experience for all involved.

    thanks tedx thessaloniki

    Hey, come and speak at TEDx!

    I got introduced to the TEDx Thessaloniki folk by my friend Amalia Agathou and once contacted and approved, I was amazed just how quickly everything fell into place:

    • There was no confusion as to what was expected of me – a talk of 18 minutes tops, presented from a central computer so I needed to create powerpoint or keynote slides dealing with the overall topic of the event “every end is a beginning”
    • I was asked to deliver my talk as a script and had an editor to review it to make it shorter, snappier or more catered to a “TED” audience
    • My flights and hotel were booked for me and I got my tickets and hotel voucher as email – no issue getting there and no “I am with the conference” when trying to check into the hotel
    • I had a deadline to deliver my slides and then all that was left was waiting for the big day to come.

    A different stage

    TEDx talks are different to other conferences as they are much more focused on the presenter. They are more performance than talk. Therefore the setup was different than stages I am used to:

    • There were a lot of people in a massive theatre expecting me to say something exciting
    • I had a big red dot to stand and move in with a stage set behind me (lots of white suitcases, some of them with video projection on them)
    • There were three camera men; two with hand-held cameras and one with a boom-mounted camera that swung all around me
    • I had two screens with my slides and a counter telling me the time
    • I was introduced before my talk and had 7 seconds to walk on stage whilst a music was playing and my name shown on the big screens on stage
    • In addition to the presentations, there were also short plays and bands performing on stage

    Rehearsals, really?

    Suffice to say, I was mortified. This was too cool to be happening and hearing all the other speakers and seeing their backgrounds (the Chief Surgeon of the Red Cross, famous journalists, very influential designers, political activists, the architect who designed the sea-side of the city, famous writers, early seed stage VCs, car designers, photo journalists and many, many more) made me feel rather inadequate with my hotch-potch career putting bytes in order to let people see kittens online.

    We had a day of rehearsals before the event and I very much realised that they are not for me. Whilst I had to deliver a script, I never stick to one. I put my slides together to remind me what I want to cover and fill the gaps with whatever comes to me. This makes every talk exciting to me, but also a nightmare for translators (so, a huge SORRY and THANK YOU to whoever had to convert my stream of consciousness into Greek this time).

    Talking to an empty room doesn’t work for me – I need audience reactions to perform well. Every speaker had a speaking coach to help them out after the rehearsal. They talked to us what to improve, what to enhance, how to use the stage better and stay in our red dot and so on. My main feedback was to make my jokes more obvious as subtle sarcasm might not get noticed. That’s why I added it thicker during the talk. Suffice to say, my coach was thunderstruck after seeing the difference of my rehearsal and the real thing. I told him I need feedback.

    Event organisation and other show facts

    All in all I was amazed by how well this event was organised:

    • The hotel was in walking distance along a seaside boulevard to the theatre
    • Food was organised in food trucks outside the building and allowing people to eat it on the lawn whilst having a chat. This avoided long queues.
    • Coffee was available by partnering with a coffee company
    • The speaker travel was covered by partnering with an airline – Aegean
    • The day was organised into four sections with speakers on defined topics with long breaks in between
    • There were Q&A sessions with speakers in breaks (15 minutes each, with a defined overall topic and partnering speakers with the same subject matter but differing viewpoints)
    • All the videos were streamed and will end up on YouTube. They were also shown on screens outside the auditorium for attendees who preferred sitting on sofas and cushions
    • There was an outside afterparty with drinks provided by a drinks company
    • Speaker dinners were at restaurants in walking distance and going long into the night

    Attendees

    The best thing for me was that the mix of attendees was incredible. I met a few fellow developers, journalists, doctors, teachers, a professional clown, students and train drivers. Whilst TED has a reputation to be elitist, the ticket price of 40 Euro for this event ensured that there was a healthy cross-section and the afterparty blended in nicely with other people hanging out at the beach.

    I am humbled and amazed that I pulled that off and I was asked to be part of this. I can’t wait to get my video to see how I did, because right now, it all still seems like a dream.

    TEDx Thessaloniki – The web is dead?

    Saturday, May 10th, 2014

    OMG OMG OMG I am speaking at TEDx! Sorry, just had to get this out of the way…

    I am currently in the sunny Thessaloniki in Greece at TEDx and waiting for things to kick off. My own talk is in the afternoon and I wanted to share my notes and slides here for those who can’t wait for the video.

    The, slightly cryptic overall theme of the event is “every end is a beginning” and thus I chose to talk about the perceived end of the web at the hand of native apps and how apps are already collapsing in on themselves. Here are the slides and notes which – as usual – might end up just being a reminder for myself what I want to cover.


    Hello, I am here today to tell you that the web is dead. Which is unfortunate, as I am a web developer. I remember when the web was the cool new revolution and people flocked to it. It was the future. What killed it?

    Typing on a Blackberry Torch

    The main factor in the death of the web is the form factor of the smart phone. This is how people consume the web right now. And as typing web addresses in it isn’t fun, people wanted something different.

    We got rather desperate in our attempt to make things easier. QR codes were the cool thing to do. Instead of typing in an address in a minute it is much easier to scan them with your phone – and most of the time the camera does focus correctly in a few minutes and only drains 30% of your battery.

    This is when the app revolution kicked in. Instead of going to web sites, you can have one app each for all your needs. Apps are great. They perform well, they are beautiful, they are easy to find and easy to install and use.

    Apps are also focused. They do one thing and one thing well, and you really use them. You don’t have a browser open with several windows. You keep your attention to the one thing you wanted to do.
    So, in order to keep my job, I came up with an idea for an app myself.

    In my research, I found that apps are primarily used in moments of leisure. Downtime, so to say.

    This goes so far that one could say that most apps are actually used in moments historically used for reflection and silence. Like being in the bathroom. My research showed that there is a direct correlation between apps released and time spent in facilities.

    chart: time spent in toilet playing games

    And this is where my app idea comes in. Instead of just using a random app in these moments, use WhatsOut!

    whatsout logo

    WhatsOut is a location based checkin app much like Foursquare but focused at public facilities. You can check-in, become the mayor, leave reviews, win badges like “3 stall buddies” when checking in with friends.

    Marking territory

    The app is based on principles of other markets, like the canine one where it’s been very successful for years. There are many opportunities to enhance the app. You can link photos of food on Instagram with the checkin (as an immediate result), and with enough funding and image recognition it could even become a health app.

    hype

    Seriously though: this is my problem with apps. Whilst technically superior on a mobile device they are not an innovation.

    The reason is their economic model: everything is a numbers game. For app markets to succeed, they need millions of apps. For apps to succeed, they need thousands of users. What the app does is not important – how many eyeballs it gets is.

    This is why every app needs to lock you in. It needs for you to stay and do things. Add content, buy upgrades, connect to friends and follow people.

    tamagotchi

    In essence, for apps to succeed they have to be super annoying Tamagotchi. They want you to care for them all the time and be there only for them. And we all know what happened to Tamagotchi – people were super excited about them and now they all collect dust.

    The web was software evolved – you get your content and functionality on demand and independent of hardware. Apps, as they are now, are a step back in that regard. We’re back to waiting for software to be delivered to us as a packaged format dependent on hardware.

    That’s why the web is far from dead. It is not a consumable product. Its very nature is distributed. And you can’t shut down or replace that. Software should enrich and empower our lives, our lives should not be the content that makes software successful.

    Presentation tips: using videos in presentations

    Sunday, May 4th, 2014

    I am currently doing a survey amongst people who speak for Mozilla or want to become speakers. As a result of this, I am recording short videos and write guidelines on how to deal with various parts of presenting.

    movie projector
    Photo Credit: Carbon Arc via Compfight cc

    A lot of the questions in the “Presenting tips for Mozilla Reps” survey this time revolved around videos in presentations. Let’s take a look at that topic.

    Videos are a great format to bring a message across:

    • They are engaging as they speak to all senses (seeing, hearing, reading)
    • They allow for a lot of information in a very short time
    • They are relatively simple to make and with the help of YouTube and others very easy to distribute

    As part of a presentation, videos can be supportive or very destructive. The problem with videos is that they are very engaging. As a presenter, it is up to you to carry the talk: you are the main attraction. That’s why playing a video with sound in the middle of your talk is awkward; you lose the audience and become one of them. You are just another spectator and you need to be very good to get people’s attention back to you after the video played.

    Videos with sound

    The rule of thumb of videos with sound is either to start with it and thus ease people into your talk or to end with it. In Mozilla we got a lot of very cool and inspirational short videos you can start with and then introduce yourself as a Mozillian followed by what you do and what you want to talk about today. You can also end with it: “And that’s what I got. I am part of Mozilla, and here are some other things we do and why it would be fun for you to join us”.

    Screencasts

    Screencasts are a superb format to use in your presentation to narrate over. Using a screencast instead of a live demo has a lot of benefits:

    • They work – you know things work and you are not relying on a working internet connection or being able to use a certain computer setup.
    • You can concentrate on presenting – you will not get into trouble trying to talk and do things at the same time. This is harder than it looks and it is astonishing how many speakers forget their password when talking and logging into a system on stage
    • They have a fixed time – you know the time you will use for the demo and not get stuck at your computer slowing down for random reasons or showing the audience a loading animation for minutes because of the slow WiFi. Silence on stage is awkward and whilst you can crack a joke it seems bad planning
    • You can focus on the important bits – you can zoom in and out in a screencast and only show the relevant bit. This is also possible with a live demo, but needs more skills

    Of course screencasts have a few pitfalls:

    • They could appear as cheating – make sure you explain the setup used in the demo and point people to live examples where they can try out the same demo for themselves. Do not show things working you know not to. This is what sales weasels do.
    • Make sure you have the video on your computer – no, you will not have a connection fast enough to show a YouTube video at every event. Actually that is almost never a good idea.
    • Test the video with the projection system – sometimes presentation software doesn’t show the video and you might need to use a media player to show it instead
    • Keep them short – you want to make a point, not narrate a movie to an audience.

    What about length?

    Videos in presentations should make a point and have a purpose. In the end, a talk is a show and you are the star. You are the centre of attention. That’s why videos are good to make things more engaging but don’t lose the audience to them – after all they will have to look at them instead of you. One minute is to me a good time, less is better. Anything above 5 minutes should be a screenshot of the video, the URL to see it and you telling people why they should watch it. This works, I keep seeing people tweet the URL of a video I covered in my talks and thanking me that I flagged it up as something worth watching.

    Quick one: using download attribute on links to save Canvas as PNG

    Tuesday, April 22nd, 2014

    One of the things I always liked about Firefox is that you can right-click any canvas and select “save image as”. Chrome and others don’t do that (well, Chrome doesn’t). Instead you need to get the image data, create a url and open a new tab or something in that order.

    One very simple way to allow people to save a canvas as an image (and name it differently – which would have to be done by hand in the case of right-clicking on Firefox) is to use the download attribute of a link.

    You can see this in action in this JSFiddle. Simply paint something and click the “download image” link.

    The relevant code is short and sweet (canvas is the reference of the canvas element):

    var link = document.createElement('a');
    link.innerHTML = 'download image';
    link.addEventListener('click', function(ev) {
        link.href = canvas.toDataURL();
        link.download = "mypainting.png";
    }, false);
    document.body.appendChild(link);

    Web Components and you – dangers to avoid

    Friday, April 18th, 2014

    Lego
    Legos by C Slack

    Web Components are a hot topic now. Creating widgets on the web that are part of the browser’s rendering flow is amazing. So is inheriting from and enhancing existing ones. Don’t like how a SELECT looks or works? Get it and override what you don’t like. With the web consumed on mobile devices performance is the main goal. Anything we can do to save on battery consumption and to keep interfaces responsive without being sluggish is a good thing to do.

    Web Components are a natural evolution of HTML. HTML is too basic to allow us to create App interfaces. When we defined HTML5 we missed the opportunity to create semantic widgets existing in other UI libraries. Instead of looking at the class names people used in HTML, it might have been more prudent to look at what other RIA environments did. We limited the scope of new elements to what people already hacked together using JS and the DOM. Instead we should have aimed for parity with richer environments or desktop apps. But hey, hindsight is easy.

    What I am more worried about right now is that there is a high chance that we could mess up Web Components. It is important for every web developer to speak up now and talk to the people who build browsers. We need to make this happen in a way our end users benefit from Web Components the best. We need to ensure that we focus our excitement on the long-term goal of Web Components. Not on how to use them right now when the platforms they run on aren’t quite ready yet.

    What are the chances to mess up? There are a few. From what I gathered at several events and from various talks I see the following dangers:

    • One browser solutions
    • Dependency on filler libraries
    • Creating inaccessible solutions
    • Hiding complex and inadequate solutions behind an element
    • Repeating the “just another plugin doing $x” mistakes

    One browser solutions

    This should be pretty obvious: things that only work in one browser are only good for that browser. They can only be used when this browser is the only one available in that environment. There is nothing wrong with pursuing this as a tech company. Apple shows that when you control the software and the environment you can create superb products people love. It is, however, a loss for the web as a whole as we just can not force people to have a certain browser or environment. This is against the whole concept of the web. Luckily enough, different browsers support Web Components (granted at various levels of support). We should be diligent about asking for this to go on and go further. We need this, and a great concept like Web Components shouldn’t be reliant on one company supporting them. A lot of other web innovation that heralded as a great solution for everything went away quickly when only one browser supported it. Shared technology is safer technology. Whilst it is true that more people having a stake in something makes it harder to deliver, it also means more eyeballs to predict issues. Overall, sharing efforts prevents an open technology to be a vehicle for a certain product.

    Dependency on filler libraries

    A few years ago we had a great and – at the same time – terrible idea: let’s fix the problems in browsers with JavaScript. Let’s fix the weirdness of the DOM by creating libraries like jQuery, prototype, mootools and others. Let’s fix layout quirks with CSS libraries. Let’s extend the functionality of CSS with preprocessors. Let’s simulate functionality of modern browsers in older browsers with polyfills.

    All these aim at a simple goal: gloss over the differences in browsers and allow people to use future technologies right now. This is on the one hand a great concept: it empowers new developers to do things without having to worry about browser issues. It also allows any developer to play with up and coming technology before its release date. This means we can learn from developers what they want and need by monitoring how they implement interfaces.

    But we seem to forget that these solutions were build to be stop-gaps and we become reliant on them. Developers don’t want to go back to a standard interface of DOM interaction once they got used to $(). What people don’t use, browser makers can cross off their already full schedules. That’s why a lot of standard proposals and even basic HTML5 features are missing in them. Why put effort into something developers don’t use? We fall into the trap of “this works now, we have this”, which fails to help us once performance becomes an issue. Many jQuery solutions on the desktop fail to perform well on mobile devices. Not because of jQuery itself, but because of how we used it.

    Which leads me to Web Components solutions like X-Tags, Polymer and Brick. These are great as they make Web Components available right now and across various browsers. Using them gives us a glimpse of how amazing the future for us is. We need to ensure that we don’t become dependent on them. Instead we need to keep our eye on moving on with implementing the core functionality in browsers. Libraries are tools to get things done now. We should allow them to become redundant.

    For now, these frameworks are small, nimble and perform well. That can change as all software tends to grow over time. In an environment strapped for resources like a $25 smartphone or embedded systems in a TV set every byte is a prisoner. Any code that is there to support IE8 is nothing but dead weight.

    Creating inaccessible solutions

    Let’s face facts: the average web developer is more confused about accessibility than excited by it. There are many reasons for this, none of which worth bringing up here. The fact remains that an inaccessible interface doesn’t help anyone. We tout Flash as being evil as it blocks out people. Yet we build widgets that are not keyboard accessible. We fail to provide proper labeling. We make things too hard to use and expect the steady hand of a brain surgeon as we create tight interaction boundaries. Luckily enough, there is a new excitement about accessibility and Web Components. We have the chance to do something new and do it right this time. This means we should communicate with people of different ability and experts in the field. Let’s not just convert our jQuery plugins to Web Components in verbatim. Let’s start fresh.

    Hiding complex and inadequate solutions behind an element

    In essence, Web Components allow you to write custom elements that do a lot more than HTML allows you to do now. This is great, as it makes HTML extensible (and not in the weird XHTML2 way). It can also be dangerous, as it is simple to hide a lot of inefficient code in a component, much like any abstraction does. Just because we can make everything into an element now, doesn’t mean we should. What goes into a component should be exceptional code. It should perform exceptionally well and have the least dependencies. Let’s not create lots of great looking components full of great features that under the hood are slow and hard to maintain. Just because you can’t see it doesn’t mean the rules don’t apply.

    Repeating the “just another plugin doing $x” mistake

    You can create your own carousel using Web Components. That doesn’t mean though that you have to. Chances are that someone already built one and the inheritance model of Web Components allows you to re-use this work. Just take it and tweak it to your personal needs. If you look for jQuery plugins that are image carousels right now you better bring some time. There are a lot out there – in various states of support and maintenance. It is simple to write one, but hard to maintain.

    Writing a good widget is much harder than it looks. Let’s not create a lot of components because we can. Instead let’s pool our research and findings and build a few that do the job and override features as needed. Core components will have to change over time to cater for different environmental needs. That can only happen when we have a set of them, tested, proven and well architected.

    Summary

    I am super excited about this and I can see a bright future for the web ahead. This involves all of us and I would love Flex developers to take a look at what we do here and bring their experience in. We need a rich web, and I don’t see creating DOM based widgets to be the solution for that for much longer with the diversity of devices ahead.