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

  • Archive for the ‘General’ Category

    Making distributed team meetings work

    Tuesday, February 24th, 2015

    Being in a distributed team can be tough. Here are a few tricks I learned over the years to make distributed meetings easier.
    This is cross-posted on Medium, you can comment there.

    Man on phone with 'shut up' on whiteboard behind himPhoto Credit: Tim Caynes

    Working as distributed teams is a red flag for a lot of companies. Finding a job that allows you to work remote is becoming a rare opportunity. As someone who worked remote for the last few years I can say though that it is a much better way of working. And it results in more effective and above all, happier, teams.

    What it needs is effort by all involved to succeed and often a few simple mistakes can derail the happy train.

    The big issue, of course, is time difference. It is also a massive opportunity. A well organised team can cover a product in half the time. To achieve that, you need well organised and honest communication. Any promise you can’t keep means you lost a whole day instead of being able to deliver quicker.

    There are many parts to this, but today, I want to talk about meetings with distributed teams. In the worst case, these are phone conferences. In the best case, you have a fancy video conferencing system all people in your team can use.

    Quick aside: a lot of people will use this as an opportunity to tell me about their amazing software solutions for this problem. I am sure you can tell me a lot about your multi-media communication system with supercharged servers and affordable rates. Please, don’t. I don’t buy these things and I also have seen far too many fail. Connectivity and travel don’t go too well together. The crystal clear, uninterrupted, distraction-free meetings we see in advertisements are a product of fiction. You might as well add unicorns, at least that would make them fabulous. I’ve seen too many bad connections and terrible surroundings. What they taught me is that planning for failure beats any product you can buy. Hence these tips here.

    Synchronous Asynchronicity?


    World online information
    Meetings are synchronous – you expect all people to be in one place at the same time. Distributed teams work asynchronous. While one part is doing the work, the others are sleeping or having a social life until it is time to switch over.
    Thus, if you have a meeting at 10 in the morning California time and you talk to people in Europe you have two kind of people in the virtual room:

    • Those who already had a whole day of work with all the joys and annoyances it brings
    • Those who just got up, far too early for their own liking and got stuck in transit. Either on a packed motorway or involuntarily nestling in the armpit of a total stranger in an overcrowded train

    In any case, both are kind of weary and annoyed. Without proper planning, this isn’t an opportunity for knowledge sharing. It is a recipe for disaster as both groups have wildly diverging agendas about this meeting.

    • One group wants to give an update what they did today, hand over and call it a day and
    • The other group wants to know what is important today and get on with it to fight off the cobwebs of commuting

    As an expert remote worker you start to diffuse this issue a bit by shifting your daily agenda around. You allow for a few hours of overlap, either by staying longer on the job and starting later in the early afternoon. Or by getting up much earlier and communicating with your colleagues at home before leaving for the office. This works well as long as you don’t have a partner that works normal hours or you live in a country where shops close early.

    In any case, you need to find a way to make both groups more efficient in this meeting, so here is the first trick:

    Separate the meeting into remote updates and social interactions


    sandwichPhoto by Ron Dolette

    This may sound weird, but you can’t have both. Having a meeting together in a room in the office is great for the locals:

    • You can brainstorm some ideas in an animated discussion where everyone talks
    • You can cover local happenings (“did you see the game last night? What a ludicrous display”)
    • You can have a chat about what’s bothering you (“damn, the office is cold today”) and
    • talk about location-specific issues and socialise.

    This doesn’t work when the topic of discussion is current and about the location you are in. Telling someone eight hours ahead and far away from you that you will enjoy company-provided food right after the event is not helping their morale — on the contrary. It alienates people outside the group even more than they already feel. It is great for the team in the room though. Don’t let one’s group perk become the others reason for jealousy.

    By separating your meeting into four parts, you can focus better on giving the right people what they came for and get their updates. Make it a meeting sandwich:

    • Meet in the room, have a quick social chat,
    • Dial in the remote participants, ask them about a quick social update,
    • Have a focused info session with both groups,
    • Let the remote people disconnect and phase out the meeting with another local, social update.

    This way everybody uses their time efficiently, feels listened to and not bothered by updates or benefits that don’t apply to them. I have seen this work well in the past. It also resulted in much shorter meetings and we all love those.

    Have a clear agenda and turn it into live meeting notes


    a clear plan where we are and what's coming
    Sending out an agenda before the meeting makes things crystal clear. People know if it is worth to join and can choose not to. Make sure that all the resources you cover in the meeting are linked in the agenda. Make sure that these resources are publicly available to all people in the meeting and not on someone’s internal IP or file share only a few have access to. Having to ask “what is Margaret talking about, where can I find this?” is distracting and frustrating.

    During the meeting you can add notes and findings to the agenda items. This has a lot of benefits:

    • People who can not attend the meeting or drop off half way through can look up what happened later.
    • You have an archive of your meetings without having the extra work of publishing meeting notes.
    • People who missed the meeting can scan the meeting results. This is much easier than listening to an hour long recording or watching a video of people in a room talking to a microphone. As beneficial as a video call is when you are all live, it gets tedious and hard to navigate to the items you care about when it is a recording.

    Be aware of sound distractions


    tis be the time of hammer
    In essence what you are dealing with here is a many to one conversation. If you have several people talking to you and you can see them, this is not an issue. If you can’t see them and you don’t even have a spatial recognition where the sound comes from, it all blurs together. That’s why it is important to have one person speak at any time and others to be aware of the fact that any noise they make is distracting. This means:

    • As someone remote, mute your microphone. There is nothing more annoying than the clatter of a keyboard magnified by the microphone just above it
    • As someone in the room with others, lean away from the microphone. Don’t cough into it, don’t shift things around on the table the mic is standing on. Coffee mugs, spoons and pens can be incredibly loud on those.
    • As the speaker, lean into the microphone and speak clearly – always assume there is static and sound loss. A mumbled remark in the back of the room followed by laughter by all could come across to a remote listener as an inside joke or even an insult. No need to risk such misunderstandings.
    • If you switch the speaker, tell them to introduce themselves. This may feel silly in the room, but it helps avoiding confusion on the other side.

    Use a chat system as the lifeline of the meeting


    Bad skype quality
    Video and Audio chat will always go wrong in one way or another. The problem is that when you are presenting the system won’t tell you that. You are not aware that the crystal clear image of yourself with perfect sound is a pixelated mess with a robot voice that makes Daft Punk jealous on the other end.

    Having a chat running at the same time covers a few scenarios:

    • People can tell you when something is wrong on their end or when you stopped being comprehensible
    • People can comment without interrupting your audio flow. Many systems switch the presenter as soon as someone speaks – which is unnecessary in this case.
    • People can post resources without having to interrupt you. “In case you missed it, Jessica is talking about http://frolickinghedgehogs.com”

    Have a consumable backup for each live update


    upload and downloadPhoto by
    John Trainor

    If you are presenting things in the meeting, send out screencasts or slide decks of what you present beforehand. Far too many times you can not see it as a remote participant when someone shares their screens. Switching from presenter to presenter always ends up in a lot of time wasted waiting for the computer to do the thing we want it to.

    For the presenter this allows for better explanations of what is happening. It is distracting when you present and press a button and nothing happens. The remote attendees might also have some lag and get a delayed display. This means you talk about something different than they are currently seeing on their screen.

    Plan for travel and meeting as a whole team


    group hugPhoto by Joris Louwes

    Last, but not least, plan to have visits where you meet as a whole team. Do social things together, give people a chance to get to know one another. Once you connected a real human with the flat, blurry face on the screen, things get much easier. Build up a cadence of this. Meet every quarter or twice a year. This might look expensive at first sight, but pays out in team efficiency. My US colleagues had an “a-hah” moment when they were on a laptop late in the evening waiting for others to stop talking about local things they couldn’t care less about. I felt much more empathy for my colleagues once I had to get up much earlier than I wanted to be in the office in time to meet my European colleagues. Let the team walk in each other’s shoes for a while and future meetings will be much smoother.

    Progressive Enhancement is not about JavaScript availability.

    Wednesday, February 18th, 2015

    I have been telling people for years that in order to create great web experiences and keep your sanity as a developer you should embrace Progressive Enhancement.

    escalators are great. when there is an issue, they become stairs and still work

    A lot of people do the same, others question the principle and advocate for graceful degradation and yet others don’t want anything to do with people who don’t have the newest browsers, fast connections and great hardware to run them on.

    People have been constantly questioning the value of progressive enhancement. That’s good. Lately there have been some excellent thought pieces on this, for example Doug Avery’s “Progressive Enhancement Benefits“.

    One thing that keeps cropping up as a knee-jerk reaction to the proposal of progressive enhancement is boiling it down to whether JavaScript is available or not. And that is not progressive enhancement. It is a part of it, but it forgets the basics.

    Progressive enhancement is about building robust products and being paranoid about availability. It is about asking “if” a lot. That starts even before you think about your interface.

    Having your data in a very portable format and having an API to retrieve parts of it instead of the whole set is a great idea. This allows you to build various interfaces for different use cases and form factors. It also allows you to offer this API to other people so they can come up with solutions and ideas you never thought of yourself. Or you might not, as offering an API means a lot of work and you might disappoint people as Michael Mahemoff debated eloquently the other day.

    In any case, this is one level of progressive enhancement. The data is there and it is in a logical structure. That’s a given, that works. Now you can go and enhance the experience and build something on top of it.

    This here is a great example: you might read this post here seeing my HTML, CSS and JavaScript interface. Or you might read it in an RSS reader. Or as a cached version in some content aggregator. Fine – you are welcome. I don’t make assumptions as to what your favourite way of reading this is. I enhanced progressively as I publish full articles in my feed. I could publish only a teaser and make you go to my blog and look at my ads instead. I chose to make it easy for you as I want you to read this.

    Progressive enhancement in its basic form means not making assumptions but start with the most basic thing and check every step on the way if we are still OK to proceed. This means you never leave anything broken behind. Every step on the way results in something usable – not necessarily enjoyable or following a current “must have” format, but usable. It is checking the depth of a lake befor jumping in head-first.

    Markup progressive enhancement

    Web technologies and standards have this concept at their very core. Take for example the img element in HTML:

    <img src="threelayers.png" 
         alt="Three layers of separation 
              - HTML(structure), 
              CSS(presentation) 
              and JavaScript(behaviour)">

    By adding an alt attribute with a sensible description you now know what this image is supposed to tell you. If it can be loaded and displayed, then you get a beautiful experience. If not, browsers display this text. People who can’t see the image at all also get this text explanation. Search engines got something to index. Everybody wins.

    <h1>My experience in camp</h1>

    This is a heading. It is read out as that to assistive technology, and screen readers for example allow users to jump from heading to heading without having to listen to the text in between. By applying CSS, we can turn this into an image, we can rotate it, we can colour it. If the CSS can not be loaded, we still get a heading and the browser renders the text larger and bold as it has a default style sheet associated with it.

    Visual progressive enhancement

    CSS has the same model. If the CSS parser encounters something it doesn’t understand, it skips to the next instruction. It doesn’t get stuck, it just moves on. That way progressive enhancement in CSS itself has been around for ages, too:

    .fancybutton {
      color: #fff;
      background: #333;
      background: linear-gradient(
        to bottom, #ccc 0%,#333 47%,
        #000 100%
      );
    }

    If the browser doesn’t understand linear gradients, then the button is white on dark grey text. Sadly, what you are more likely to see in the wild is this:

    .fancybutton {
      color: #fff;
      background:  -webkit-gradient(
        linear, 
        left top, left bottom, 
        color-stop(0%,#ccc), 
        color-stop(47%,#333), 
        color-stop(100%,#000));
    }

    Which, if the browser doesn’t understand webkit gradient, results in a white button with white text. Only because the developer was too lazy to first define a background colour the browser could fall back on. Instead, this code assumes that the user has a webkit browser. This is not progressive enhancement. This is breaking the web. So much so, that other browsers had to consider supporting webkit specific CSS, thus bloating browsers and making the web less standardised as a browser-prefixed, experimental feature becomes a necessity.

    Progressive enhancement in redirection and interactivity

    <a href="http://here.com/catalog">
    See catalog
    </a>

    This is a link pointing to a data endpoint. It is keyboard accessible, I can click, tap or touch it, I can right-click and choose “save as”, I can bookmark it, I can drag it into an email and send it to a friend. When I touch it with my mouse, the cursor changes indicating that this is an interactive element.

    That’s a lot of great stuff I get for free and I know it works. If there is an issue with the endpoint, the browser tells me. It shows me when the resource takes too long to load, it shows me an error when it can’t be found. I can try again.

    I can even use JavaScript, apply a handler on that link, choose to override the default behaviour with preventDefault() and show the result in the current page without reloading it.

    Should my JavaScript fail to execute for all the reasons that can happen to it (slow connection, blocked resources on a firewall level, adblockers, flaky connection), no biggie: the link stays clickable and the browser redirects to the page. In your backend you probably want to check for a special header you send when you request the content with JS instead of as a redirect from the browser and return different views accordingly.

    <a href="javascript:void()">
    Catalog</a> or 
    <a href="#">Catalog</a> or 
    <a onclick="catalog()">Catalog</a>

    This offers none of that working model. When JS doesn’t work, you got nothing. You still have a link that looks enticing, the cursor changed, you promised the user something. And you failed at delivering it. It is your fault, your mistake. And a simple one to avoid.

    XHTML had to die, HTML5 took its place

    When XHTML was the cool thing, the big outcry was that it breaks the web. XHTML meant we delivered HTML as XML. This meant that any HTML syntax error – an unclosed tag, an unencoded ampersand, a non-closed quote meant the end user got an error message instead of the thing they came for. Even worse, they got some cryptic error message instead.

    HTML5 parsers are forgiving. Errors happen silently and the browser tries to fix them for you. This was considered necessary to stop the web from breaking. It was considered bad form to punish our users for our mistakes.

    If you don’t progressively enhance your solutions, you do the same thing. Any small error will result in an interface that is stuck. It is up to you to include error handling, timeout handling, user interaction like right-click -> open in new tab and many other things.

    This is what progressive enhancement protects us and our users from. Instead of creating a solution and hoping things work out, we create solutions that have a safety-belt. Things can not break horribly, because we planned for them.

    Why don’t we do that? Because it is more work in the first place. However, this is just intelligent design. You measure twice, and cut once. You plan for a door to be wide enough for a wheelchair and a person. You have a set of stairs to reach the next floor when the lift is broken. Or – even better – you have an escalator, that, when broken, just becomes a set of stairs.

    Of course I want us to build beautiful, interactive and exciting experiences. However, a lot of the criticism of progressive enhancement doesn’t take into consideration that nothing stops you from doing that. You just have to think more about the journey to reach the final product. And that means more work for the developer. But it is very important work, and every time I did this, I ended up with a smaller, more robust and more beautiful end product.

    By applying progressive enhancement to our product plan we deliver a lot of different products along the way. Each working for a different environment, and yet each being the same code base. Each working for a certain environment without us having to specifically test for it. All by turning our assumptions into an if statement. In the long run, you save that way, as you do not have to maintain various products for different environments.

    We continuously sacrifice robustness of our products for developer convenience. We’re not the ones using our products. It doesn’t make sense to save time and effort for us when the final product fails to deliver because of a single error.

    Flipboard and the “mobile web” dream…

    Sunday, February 15th, 2015

    According to the luminaries of the web design world, the “mobile web” doesn’t exist. Stephen Hay said it, Smashing Magazine said so and Jeremy Keith amongst many others.

    Except, it does. Not as a technical reality, but as a dream of marketing and overly excited managers who believe in magical powers of their engineers. And it is nothing new. We’ve been there before, and we probably will get there again. Every few years a new form factor or technology comes out that promises a web that is catering perfectly to a very niche need whilst being open and available to all. Or – in other words – water that is almost, but not totally wet.

    Flipboard’s magical journey at 60 fps

    Last week Flipboard engineering released the Kraken with their “60 fps on the mobile web” post, explaining how they managed to give the new “web version” of Flipboard a buttery smooth 60 frames per second on mobile by forfeiting the DOM and rendering the whole thing in Canvas. The general outrage was that it was read as a call to give up on the DOM and use react.js and Canvas instead.

    Kid needs light-up shoes to run faster - we need canvas to have a performing web app

    Not surprisingly, this sparked a lot of discussion and annoyance toward them. But let’s step back a bit: first of all, it is a good thing when engineering teams publish their findings and tell us why they made some decisions. It can be a great learning resource and is a courageous thing to do. In a world where people spend most of their time dismembering technical posts on hacker news putting yourself out there means you also need to deal with a lot of polarised feedback. You need to learn fast how to deal with trolls and people using these systems to grandstand. So, thanks are in order – thank you, Flipboard. The post is detailed, it explains what they tried to do and how they achieved it.

    The usefulness of such a resource starts getting questionable when hype kicks in and people take it as gospel. Flipboard did not claim that what they do is the perfect way to achieve happiness on mobile. Instead they are very open about their intentions:

    In the pursuit of 60fps we sometimes resort to extreme measures. Flipboard for mobile web is a case study in pushing the browser to its limits. While this approach may not be suitable for all applications, for us it’s enabled a level of interaction and performance that rivals native apps.

    Right now, mobile is still hot. HTML5 is still hot. A company pushing the boundaries of both is hot. That’s why it is good value for a tech company to write articles like that. And I am 100% sure the Flipboard engineers have the heart in the right place and rightfully are proud of what they have achieved.

    Solving the right problem with the wrong approach

    That said, the title is terrible as it promises a simple answer to a huge problem. Or, on reflection, not a problem, but a massive misunderstanding.

    What this post told me most of all is that it isn’t solving an issue of the web. It is about simulating a native interface for a mobile touch device at 60 fps using web technologies. It’s aim is to run smoothly on the currently hot device that the most affluent people use – let’s say the iPhone 6. They are not beating around the bush about this at all:

    Now we’re coming full circle and bringing Flipboard to the web. Much of what we do at Flipboard has value independent of what device it’s consumed on: curating the best stories from all the topics, sources, and people that you care about most. Bringing our service to the web was always a logical extension.

    There’s a massive flaw in this: it tries to bring value independent of what device it is consumed on and then it applies assumptions and concepts that are only beneficial to a mobile, touch-enabled device.

    This is a porting exercise. This is bringing something to the web. It is not creating a web product. That would be reaching as many people as possible, and making your content available independent of hardware, ability and environment. You can not “go to web”. The web is not another form factor when your starting point is a very restricted environment. That’s how we got text-only versions of Flash movies and “accessible versions” of DHTML monstrosities. Using web technology means you start with the assumption that you have no control over the way your content is consumed. And that’s as far removed as it can from what Flipboard said:

    Flipboard launched during the dawn of the smartphone and tablet as a mobile-first experience, allowing us to rethink content layout principles from the web for a more elegant user experience on a variety of touchscreen form factors.

    And this is why calling this a web experience is ill-advised from the get-go. As Faruk Ates put it:

    …what Flipboard unleashed onto the world a “Web” version is akin to calling a collection of tires, AA batteries and spare car parts a Tesla.

    This is not about the technical implementation. The flaw is in the idea of turning a native app that was specifially designed for a certain form factor into a “web version”. The journey explained is full of assumptions.

    The first one is the big 60. All our web technology efforts need to match the 60 fps threshold or they are useless, right? Well, looking at my Nexus 5 device with Android Lollipop and anything I could do to be state-of-the-art I can safely say that not a single app works consistently smoothly at 60 fps or doesn’t stutter from time to time. So, I guess, I have no apps.

    Of course, we need goals to aspire to and some things to measure against. But defining something like 60fps as a baseline is pretty naive considering the fragmentation of hardware and the amount of abstraction layers an HTML5 app has to go through. Maybe considering less greedy interaction models might be a way forward?

    Which brings me to the second assumption: endless scrolling is what the web is about. And from there, the article tries to make that work. True, a lot of solutions have endless scrolling. Also true, many a time that is more annoying than a pagination would have been.

    What Flipboard did here is to build a native-feel solution in an environment that has no native paradigms. There are no form-factor standards on the web. They change constantly. The parallax scrolling page today is the multi-level DHTML drop-down of tomorrow.

    Stretching the canvas

    It is a daring and seemingly clever solution to go for canvas to reach good performance in an endless scrolling interface. But that’s all it is – a currently clever solution with a very short shelf-life. As Rachel Nabors put it:

    Re: recreating the DOM in canvas and accessibility: we will look back on this as a hack. Browsers will catch up, will render the DOM faster.

    When working on Firefox OS and low-end devices, the main issue just a few months ago was that canvas was too slow and people used the DOM instead and complained that it is the wrong API for games. The push was towards canvas to become hardware accelerated or – even better – mobile browsers to support WebGL. Now we have this and many a DOM solution using all kind of 3D transform tricks in CSS to force hardware accelerated layers look silly. Much like this might look silly very soon.

    The honest approach to this would be to give the article the title “How we created endless scrolling at 60 fps on high-end mobile devices by replacing the DOM with Canvas”. But that’s not as quotable and it doesn’t make you sound like a trailblazer solving a “real and very common” problem.

    Access denied

    Flipboard already admits that in terms of accessibility, this is a horrible solution. Screenreader availability aside, my warning bells went off when I saw elements with not only fixed positions on the screen but also fixed dimensions. And when you use a tool that supports text but means you need to calculate line breaks, I’d get a queasy feeling in my stomach. There goes resizing the font. There goes copying and pasting. There goes translating a text. All things the web is great at. And it is nothing new.

    Every single time we replaced text with graphics to gain more control we had to re-invent these basic features of a text-based web. Remember image replacement techniques of headlines before we had web fonts? Remember how Flash had to bend over backwards to seed the browser history and to make text highlight-able? Remember how it was impossible on mobile devices to copy and paste at all?

    When reading the section of the post about accessibility I get flashbacks to horrible times:

    This area needs further exploration. Using fallback content (the canvas DOM sub-tree) should allow screen readers such as VoiceOver to interact with the content. We’ve seen mixed results with the devices we’ve tested. Additionally there is a standard for focus management that is not supported by browsers yet.

    One approach that was raised by Bespin in 2009 is to keep a parallel DOM in sync with the elements rendered in canvas. We are continuing to investigate the right approach to accessibility.

    Wait a second. Re-read this, please, and tell me if I am crazy when I think this sounds like a lot of duct-tape around a leaking faucet.

    We have a perfectly accessible way of achieving all of this: we call it HTML and we have the DOM and the accessibility API. That way we’d have a perfectly working web site that gets found, indexed, is accessible to a lot of people. We can then convert into a fast performing canvas solution on mobile devices that are touch-enabled. We can test for that – web technology is good at that. Think about it: a data source that comes with lots of accessibility benefits and already has an API to read it in part? Sign me up.

    Instead we consider adding a lot of HTML content inside the canvas element as a fallback and hope browsers and assistive technology will do something with that.

    Content inside canvas becomes interesting when canvas isn’t supported. Today, that’s an almost non-existent use case. Browsers support canvas. It is a blank, stateless placeholder in the page that we paint on and wipe. It is an etch-a-sketch in the page. It isn’t even vector based – it is a dumb collection of pixels. That’s why canvas is fast – the Flipboard article does a good job explaining that.

    Canvas is to HTML5 what DIV and SPAN are to HTML4 - it has no semantic meaning. It is a placeholder for generated, visual content. Not text, not interactive elements. When canvas came to be, the first comments were that it is the new applet. And that is still quite a sensible way of describing it from a markup/semantic meaning angle. It is as much a black box in the page as Flash was to the rest of the markup.

    Replace the DOM, but not its virtues

    The problem with Flipboard’s solution to the mobile performance issue is that it wants to use canvas because of its stateless and high-performance nature and get all the benefits of HTML and the DOM at the same time. This is asking too much.

    We could, however, get quite a long way by creating our canvas content from HTML that is in the document. And that is what it means to build a web product – you build a sensible HTML solution first, and then use CSS and JavaScript to enhance it. That way you don’t need to worry about covering the basics after you fine-tuned the final product. That approach will always result in disappointing fallbacks that are hardly ever maintained.

    The “mobile web” thing

    The whole goal of this exercise was to match native performance by using web technology and applying ideas of native environments. And this is a thing we should be aware of. The mobile web.

    The issue is that according to this post and many others of the same ilk, the mobile web exists. The mobile web is not a technical thing – it is a misconception and one that is hard to match. Companies nowadays start with a native experience. This is where the short-term gain is. This is where the short-term high user numbers lie. This is the beautiful technology – the shiny devices, the backing from OS vendors and the exciting interaction models that come with the OS. It feels good, it feels that there is something to work with.

    Then these people hear about the benefits of web technologies: cross-platform support, lower cost of engineering as you don’t need to pay experts of red-hot new technologies, re-use across different form factors and so on. A lot of times this happens when the honeymoon period of the native solution is over and there is new growth to be unearthed.

    Then, they want both. Hence, “the mobile web”.

    We have two issues to battle with this: a technical problem and an image problem.

    Let’s talk technical first: matching the performance of a native app with a web app is a game the web can currently not win. At least not if all you count as performance is its fps speed and how well it integrates with the OS. The reason is that the cards are stacked against us. Unless the browser becomes the most important thing in a mobile OS, we will always have a hacky experience.

    To the OS vendor, the browser is a necessary thing to offer – another app much like the calculator or the phone app. From a marketing and monetary point of view, having people build exclusively for your platform with your tools and in your languages is a win-win. You have a captive audience and you can show their numbers in huge figures during your keynotes to your stakeholders. Making the browser amazing means you have to share.

    Add to this the ridiculous browser fragmentation and the amount of zombie browsers on older systems that will never get an update again and you will find that matching the newest and coolest of the native offering is really hard.

    The image problem is that the web seems stale. Our market thrives on hype and short term gains. All our messaging about the web is praising its longevity. What you do now means you will benefit in years to come, even if it means some extra work. Your products will be easy to maintain for years to come. Future technology will already support what you do now and it will be easy to extend if you use progressive enhancement. This is our messaging, and it is great messaging.

    Except when all you care about is the next month’s user and download numbers and how many people posted selfies and sent stickers to each other that you sold them. Then this message is just noise and sounds like arrogant “in my days” speeches.

    If we love the web and want it to work out, we need to pick our battles. And the real battle lies with operating systems not having a browser we can rely on. And with lack of support of very basic features we need to give an app experience across browsers and platforms. And with a lack of standards that really get to fruition and are implemented instead of being replaced by a library that is open source, but never leaves beta.

    The mobile web is real – and it isn’t. It is a dream of people who don’t get the nature of the web trying to harvest its benefits. And right now, these people get all the VC money and get the tech press excited as they promise something new. The hype as it is now is not sustainable. It killed these people once in the dotcom boom and will again – very soon.

    We can stomp our foot about that and get angry and we can repeat tiring old messages. Or we can bide our time and fix what is broken and keeps us from performing the way we want to. Let those who need the quick short-term win pretend they found the solution. Our time can be used differently. The amount of devices, form factors and user needs is not decreasing any time soon. The web can cover all of them. Let’s make that happen once the fever dream of the one true app form factor is over. Much like there is not one mode of transport to cover all needs, there is no such thing as a perfect app or interaction model.

    Jfokus2015 – My keynote, HTML5 talk, screencasts, slides and the resources I mentioned

    Wednesday, February 4th, 2015

    The last two days I spent at the waterfront conference center in Stockholm, Sweden attending Jfokus2015, Sweden’s biggest developer conference with 1,700 participants. To make this even scarier, I gave the opening keynote one day after joining a new company and a technical talk about HTML5 at a conference mostly frequented by Java developers.

    jfokus closing keynote and audience

    Jfokus is a big, seven track event. Many of the other talks covered frameworks, out-of-the-box solutions or big topics like smart homes, self-aware drones and other IOT matters. The organisation was very smooth and as it is the case with all Nordic events, the catering excellent.

    The keynote: you don’t need another hero app, you need one that survives the Thunderdome

    I was very humbled to hear that I’ve been chosen to give the opening keynote and I put a talk together that covers the current state of the app space and what developers can do to stay relevant in a world of declining install numbers and OS functionality takeovers.

    There’s a screencast of the keynote on YouTube.

    You can also read the keynote slides are on Slideshare

    Resources I used and mentioned in the keynote:

    HTML5 beyond the hype

    My second talk was about the current state of HTML5. My goal for this talk was not to dazzle and impress with great new technology and experimental features. Instead, I wanted to remind people how much we have available to us across browsers these days. A lot of very basic, but also very useful functionality of HTML5 and CSS3 is now safe to use. The hype around HTML5 at his inception and the subsequent disappointment when browsers didn’t support it immediately made us forget about these features. In this talk, I wanted to remind people of what can be used and how it could improve existing web solutions – even in the enterprise space.

    There’s a screencast of the HTML5 session to YouTube.

    Many people asked for the slide deck, so here it is on Slideshare

    The resources I covered in the talk are listed here, in case you want to follow up with them:

    All in all, I very much enjoyed my time at Jfokus. The organisation is very efficient, it was fun to talk to people and good to see that me joining a big company didn’t change much the way people approached me. I hope I managed to inspire some people to play with tech they have not before and to tell their bosses about things their companies should be doing.

    On towards my next challenge…

    Thursday, January 29th, 2015

    One of the things I like where I live in London is my doctor. He is this crazy German who lived for 30 years in Australia before coming to England. During my checkup he speaks a mixture of German, Yiddish, Latin and English and has a dark sense of humour.

    He also does one thing that I have massive respect for: he never treats my symptoms and gives me quick acting remedies. Instead he digs and analyses until he found the cause of them and treats that instead. Often this means I suffer longer from ill effects, but it also means that I leave with the knowledge of what caused the problem. I don’t just get products pushed in my face to make things easier and promises of a quick recovery. Instead, I get pulled in to become part of the healing process and to own my own health in the long run. This is a bad business decision for him as giving me more short-acting medication would mean I come back more often. What it means to me though is that I have massive respect for him, as he has principles.

    Professor X to Magneto: If you know you can deflect it, you are not really challenging yourself

    As you know if you read this blog, I left Mozilla and I am looking for a new job. As you can guess, I didn’t have to look long and hard to find one. We are superbly, almost perversely lucky as people in IT right now. We can get jobs easily compared to other experts and markets.

    Hard to replace: Mozilla

    Leaving Mozilla was ridiculously hard for me. I came to Mozilla to stay. I loved meeting people during my interviews who’ve been there for more than eight years – an eternity in our market. I loved the products, I am still madly in love with the manifesto and the work that is going on. A lot changed in the company though and the people I came for left one by one and got replaced by people with other ideals and ideas. This can be a good thing. Maybe this is the change the company needs.
    I didn’t want to give up on these ideals. I didn’t want to take a different job where I have to promote a product by all means. I didn’t want to be in a place that does a lot of research, builds impressive looking tools and solutions but also discards them when they aren’t an immediate success. I wanted to find a place where I can serve the web and make a difference in the lives of those who build things for the web. In day to day products. Not in a monolithic product that tries to be the web.

    Boredom on the bleeding edge

    My presentations in the last year had a re-occuring theme. We can not improve the web if we don’t make it easy and reliable for everybody building things on it to take part in our innovations. Only a tiny amount of the workers of the web can use alpha or beta solutions. Even fewer can rely on setting switches in browsers or use prefixed functionality that might change on a whim. Many of us have to deliver products that are much more strict. Products that have to adhere to non-sensical legal requirements.

    These people have a busy job, and they want to make it work. Often they have to cut corners. In many other cases they rely on massive libraries and frameworks that promise magical solutions. This leads to products that are in a working state, and not in an enjoyable state.

    To make the web a continuous success, we need to clean it up. No innovation and no framework will replace the web, its very nature makes that impossible. What we need to do now is bring our bleeding edge knowledge of what means well performing and maintainable code down the line to those who do not attend every conference or spend days on Hacker News and Stack Overflow.

    And the winner is…

    This is why I answered a job offer I got and I will start working on the 2nd of February for a new company. The company is *drumroll*:

    Microsoft. Yes, the bane of my existence as a standards protagonist during the dark days of the first browser wars. Just like my doctor, I am going to the source of a lot of our annoyances and will do my best to change the causes instead of fighting the symptoms.

    My new title is “Senior Program Manager” in the Developer experience and evangelism org of Microsoft. My focus is developer outreach. I will do the same things I did at Mozilla: JavaScript, Open Web Technologies and cross-browser support.

    Professor X to Magneto: you know, I've always found the real focus to be in between rage and serenity

    Frankly, I am tired of people using “But what about Internet Explorer” as an excuse. An excuse to not embrace or even look into newer, sensible and necessary technology. At the same time I am bored of people praising experimental technology in “modern browsers” as a must. Best practices have to prove themselves in real products with real users. What’s great for building Facebook or GMail doesn’t automatically apply to any product on the web. If we want a standards-based web to survive and be the go-to solution for new developers we need to change. We can not only invent, we also need to clean up and move outdated technology forward. Loving and supporting the web should be unconditional. Warts and all.

    A larger audience who needs change…

    I’ve been asking for more outreach from the web people “in the know” to enterprise users. I talked about a lack of compassion for people who have to build “boring” web solutions. Now I am taking a step and will do my best to try to crack that problem. I want to have a beautiful web in all products I use, not only new ones. I’ve used enough terrible ticketing systems and airline web sites. It is time to help brush up the web people have to use rather than want to use.

    This is one thing many get wrong. People don’t use Chrome over Firefox or other browsers because of technology features. These are more or less on par with another. They chose Chrome as it gives them a better experience with Google’s services. Browsers in 2015 are not only about what they can do for developers. It is more important how smooth they are for end users and how well they interact with the OS.

    I’ve been annoyed for quite a while about the Mac/Chrome centric focus of the web development community. Yes, I use them both and I am as much to blame as the next person. Fact is though, that there are millions of users of Windows out there. There are a lot of developers who use Windows, too. The reason is that that’s what their company provides them with and that is what their clients use. It is arrogant and elitist to say we change the web and make the lives of every developer better when our tools are only available for a certain platform. That’s not the world I see when I travel outside London or the Silicon Valley.

    We’re in a time of change as Alex Wilhelm put it on Twitter:

    Microsoft is kinda cool again, Apple is boring, Google is going after Yahoo on Firefox, and calculator watches are back. Wtf is going on.

    What made me choose

    In addition to me pushing myself to fix one of the adoption problems of new web technologies from within there were a few more factors that made this decision the right one for me:

    • The people – my manager is my good friend and former Ajaxian co-writer Rey Bango. You might remember us from the FoxIE HTML5 training video series. Rey and me on the beach My first colleague in this team is also someone who I worked with on several open projects and got massive respect for.
    • The flexibility – I am a remote worker. I work from London, Stockholm, or wherever I need to be. This is becoming a rare occasion and many offers I got started with “you need to move to the Silicon Valley”. Nope, I work on the web. We all could. I have my own travel budget. I propose where I am going to present. And I will be in charge of defining, delivering and measuring the developer outreach program.
    • The respect – every person who interviewed me was on time, prepared and had real, job related problems for me to solve. There was no “let me impress you with my knowledge and ask you a thing you don’t know”. There was no “Oh, I forgot I needed to interview you right now” and there was no confusion about who I am speaking to and about what. I loved this. and in comparison to other offers it was refreshing. We all are open about our actions and achievements as developers. If you interview someone you have no clue about then you didn’t do your research as an interviewer. I interviewed people as much as they interviewed me and the answers I got were enlightening. There was no exaggerated promises and they scrutinised everything I said and discussed it. When I made a mistake, I got a question about it instead of letting me show off or talk myself into a corner.
    • The organisation – there is no question about how much I earn, what the career prospects are, how my travels and expenses will work and what benefits I get. These things are products in use and not a Wiki page where you could contact people if you want to know more.
    • The challenge – the Windows 10 announcement was interesting. Microsoft is jumping over its own shadow with the recent changes, and I am intrigued about making this work.

    I know there might be a lot of questions, so feel free to contact me if you have any concerns, or if you want to congratulate me.

    FAQ:

    • Does this mean you will not be participating in open communication channels and open source any longer?

      On the contrary. I am hired to help Microsoft understand the open source world and play a bigger part in it. I will have to keep some secrets until a certain time. That will also be a re-occuring happening. But that is much the same for anyone working in Google, Samsung, Apple or any other company. Even Mozilla has secrets now, this is just how some markets work. I will keep writing for other channels, I will write MDN docs, be active on GitHub and applaud in public when other people do great work. I will also be available to promote your work. All I publish will be open source or Creative Commons. This blog will not be a Microsoft blog. This is still me and will always remain me.

    • Will you now move to Windows with all your computing needs?

      No, like every other person who defends open technology and freedom I will keep using my Macintosh. (There might be sarcasm in this sentence, and a bit of guilt). I will also keep my Android and Firefox OS phones. I will of course get Windows based machinery as I am working on making those better for the web.

    • Will you now help me fix all my Internet Explorer problems when I complain loud enough on Twitter?

      No.

    • What does this mean to your speaking engagements and other public work?

      Not much. I keep picking where I think my work is needed the most and my terms and conditions stay the same. I will keep a strict separation of sponsoring events and presenting there (no pay to play). I am not sure how sponsorship requests work, but I will find out soon and forward requests to the right people.

    • What about your evangelism coaching work like the Mozilla Evangelism Reps and various other groups on Facebook and LinkedIn?

      I will keep my work up there. Except that the Evangelism Reps should have a Mozilla owner. I am not sure what should happen to this group given the changes in the company structure. I’ve tried for years to keep this independent of me and running smoothly without my guidance and interference. Let’s hope it works out.

    • Will you tell us now to switch to Internet Explorer / Spartan?

      No. I will keep telling you to support standards and write code that is independent of browser and environment. This is not about peddling a product. This is about helping Microsoft to do the right thing and giving them a voice that has a good track record in that regard.

    • Can we now get endless free Windows hardware from you to test on?

      No. Most likely not. Again, sensible requests I could probably forward to the right people

    So that’s that. Now let’s fix the web from within and move a bulk of developers forward instead of preaching from an ivory tower of “here is how things should be”.