When I joined my current company last year, we introduced Slack as the tool to communicate with each other. Of course we have the normal communication channels like email, video calls, phones, smoke signs, flag semaphore and clandestinely tapped Morse code stating “please let it end!” during meetings. But Slack seemed cool and amazing much like BaseCamp used to. And Wikis. And CampFire. And many other tools that came and went.

Here’s the thing though: I really like Slack. I have a soft spot for the team behind it and I know the beauty they are capable of. Flickr was the bomb and one of the most rewarding communities to be part of.

Slack is full of little gems that make it a great collaboration tool. The interface learns from your use. The product gently nudges you towards new functionality and it doesn’t overwhelm you with a “here’s 11452 features that will make your more productive” interface. You learn it while you use it, not after watching a few hours of video training or paying for a course how to use it. I went through many other “communication tools” that required those.

Another thing I love about Slack is that it can be extended. You can pull all kind of features and notifications in. It is a great tool, still frolicking in the first rounds of funding and untainted by a takeover by a large corporation and smothered in ads and “promoted content”.

Seeing that I enjoy Slack at work, I set out to consider running a community on my own. Then life and work happened. But when yesterday my friend Tomomi Imura asked if there are any evangelism/developer advocacy Slack groups, I told her I’d started one a few weeks ago and we now have it filling up nicely with interesting people sharing knowledge on a specialist subject matter.

And then my friend and ex-colleague Marco Zehe wanted to be part of this. And, by all means, he should. Except, there is one small niggle: Marco can’t see and uses a screen reader to navigate the web. And Slack’s interface is not accessible to screen readers as – despite the fact that it is HTML - there is no semantic value to speak of in it. It’s all DIVs and SPANs, monkeys and undergrowth – nothing to guide you.

What followed was a quick back and forth on Twitter about the merits of Slack vs. open and accessible systems like IRC. The main point of Marco was that he can not use Slack and it isn’t open, that’s why it is a bad tool to use for team communication. IRC is open, accessible, time-proven and – if used properly – turns X-Factor dropouts into Freddy Mercury and pot noodles into coq au vin.

Marco has a point: there is a danger that Slack will go away, that Slack will have to pivot into something horrible like many other community tools have. It is a commercial product that isn’t open, meaning it can not easily be salvaged or forked should it go pear shaped. And it isn’t as accessible as IRC is.

But: it is an amazing product and it does everything right in terms of interface that you can. Everything IRC is not.

I love IRC. I used IRC before I used email – on a Commodore 64 with a 2400 baud modem and 40 character per line display. I spent a long time on #html getting and publishing HTML documentation via XDCC file transfer. Some of my longest standing friends and colleagues I know from IRC.

If you introduce someone who is used to apps and messaging on mobile devices to IRC though, you don’t see delight but confusion on their faces. Rachel Nabors complained a lot about this in her State of Web Animation talks. IRC is very accessible, but not enjoyable to use. I am sure there are clients that do a good job at that, but most have an interface and features that only developers can appreciate and call usable.

Using IRC can be incredibly effective. If you are organised and use it with strict channel guidelines. Used wrongly, IRC is an utter mess resulting in lots of log files you only can make sense of if you’re good with find and grep.

I have been sitting on this for a long time, and now I want to say it: open and accessible doesn’t beat usable and intelligent. It is something we really have to get past in the open source and web world if we want what we do to stay relevant. I’m tired of crap interfaces being considered better because they are open. I’m tired of people slagging off great tools and functionality because they aren’t open. I don’t like iOS, as I don’t want to locked into an ecosystem. But damn, it is pretty and I see people being very effective with it. If you want to be relevant, you got to innovate and become better. And you have to keep inventing new ways to use old technology, not complain about the problems of the closed ones.

So what about the accessibility issue of Slack? Well, we should talk to them. If Slack wants to be usable in the Enterprise and government, they’ll have to fix this. This is an incentive – something Hipchat tries to cover right now as Jira is already pretty grounded there.

As the people who love open, free, available and accessible we have to ask ourselves one question: why is it much easier to create an inaccessible interface than an accessible one? How come this is the status quo? How come that in 2016 we still have to keep repeating basic things like semantic HTML, alternative text and not having low contrast interfaces? When did this not become a simple delivery step in any project description? It has been 20 years and we still complain more than we guide.

How come that developer convenience has became more important than access for all – a feature baked into the web as one of its main features?

When did we lose that fight? What did we do to not make it obvious that clean, semantic HTML gives you nothing but benefits and accessibility as a side effect? What did we do to become the grouchy people shouting from the balcony that people are doing it wrong instead of the experts people ask for advice to make their products better?

Accessibility can not be added at a later stage. You can patch and fix and add some ARIA magic to make things work to a degree, but the baby is thrown out with the bath water already. Much like an interface built to only work in English is very tough to internationalise, adding more markup to make something accessible is frustrating patchwork.

Slack is hot right now. And it is lovely. We should be talking to them and helping them to make it accessible, helping with testing and working with them. I will keep using Slack. And I will meet people there, it will make me effective and its features will delight the group and help us get better.

Slack is based on web technologies. It very much can be accessible to all.

What we need though is a way to talk to the team and see if we can find some low hanging fruit bugs to fix. Of course, this would be much easier in an open source project. But just consider what a lovely story it would be to tell that by communicating we made Slack accessible to all.

Closed doesn’t have to evil. Mistakes made doesn’t mean you have to disregard a product completely. If we do this and keep banging on about old technology that works but doesn’t delight everybody loses.

So, use Slack. And tell them when you can’t and that you very much would like to. Maybe that is exactly the feature they need to remain what they are now rather than being yet another great tool to die when the money runs dry.

Photo by CogDogBlog

Also on Medium

The other day Cats who code had a blog post about detecting AdBlock, where the main trick is to try to load a JavaScript document with the name adframe.js:

<script type="text/javascript">
var adblock = true;
</script>
<script type="text/javascript" src="adframe.js"></script>
<script type="text/javascript">
if(adblock) {
  //adblock is installed
}
</script>

The adframe.js document only contains one line unsetting the adblock Boolean:

var adblock = false;

This seems to work pretty well (and you can see it used in many web sites), but also seems a bit wasteful having to try another script loading and executing. Of course there are many adblocker detection scripts available (some with colourful names), but I wondered what the easiest way to do that is. The trick described in the abovementioned article using a bsarocks class on an element stopped working.

Detecting AdBlock without another request

What does work, though is the following and you can see it in action and get the code on GitHub:

var test = document.createElement('div');
test.innerHTML = ' ';
test.className = 'adsbox';
document.body.appendChild(test);
window.setTimeout(function() {
  if (test.offsetHeight === 0) {
    document.body.classList.add('adblock');
  }
  test.remove();
}, 100);

The trick is the following:

• You create an element with the class adsbox (as defined as a removable element in the definition file of AdBlock Plus)
• You add it to the document and after a short while you read its offsetHeight
• If AdBlock is installed, the element won’t have any height.

You can see it in action here:

Ethics?

Play nice with this. I’m not going into the ethics of ad blocking or detecting ad blockers. Fact is, we started an arms race with that nobody can win. The more we block, the more aggressive ads will get. As users we should vote with our voice and tell companies that we hate their aggressive advertising. We should also start to understand that nothing is free. As publishers, we should start thinking that showing ads as our only revenue stream is a doomed way of monetisation unless we play dirty.

Alex.js is a service to “Catch insensitive, inconsiderate writing” in text. You can try out Alex online.

photo by Alex Eylar

Whatever your stance on “too PC” is, it is a good idea to think about the words we use and what effect they can have on people. And when it is easy to avoid a word that may cause harm, why not do it? That said, we’re lazy and forgetful creatures, which is a why a tool like Alex.js can help.

With Alex being a JavaScript solution, we didn’t have to wait long for its integration into our favourite toys like Atom, Sublime, Gulp and Slack. However, these are our tools and the message and usefulness of Alex should be spread wider.

Whilst I am writing this in Sublime text, the fact is that most documents are written in office suites. Either the ones by Microsoft or Google’s or other online versions. I was very excited to see that Microsoft Office now has the ability to extend all its apps with JavaScript and I wanted the Alex.js integration to be my first contribution to that team. Then lots of traveling happened and the open sourcing of the JavaScript engine and real life stuff (moving, breaking up, such things).

On my last trip to Redmond I had a sit-down with the apps and extensions team and we talked about JavaScript, packaging and add-ons. One of the bits I brought up is Alex.js and how it would be a killer feature for office as a reminder for people not to be horrible without planning to be.

And lo and behold, the team listened and my ace colleagues Kiril Seksenov, John-David Dalton and Kevin Hill now made it happen: you can now download the Alex-add-in.

The add-in works in: Excel 2013 Service Pack 1 or later, Excel Online, PowerPoint 2013 Service Pack 1 or later, Project 2013 Service Pack 1 or later, Word 2013 Service Pack 1 or later and Word Online.

Spread the word and let’s get rid of inconsiderate writing one document at a time.

Photo by the awesome Mandy Chan

Yesterday I delivered my last planned talk of the year in the Facebook offices in New York as part of the NYCHTML5 Meetup. Here’s the screencast of the presentation.

The “slides” – as they were – are on GitHub using Tinderesque (and looking much better on Mac).

It’s been an amazing year and I feel so happy to have delivered everything I did and encountered so many great events and people.

In a new series of posts, I want to introduce the world to people I work with. People who work on the Microsoft Edge browser and related technologies. The faces and voices behind the product.

Today we have an interview with Gaurav Seth (@gauravseth). Gaurav is a program manager on the Chakra JavaScript engine, which – amongst other things – is in use in Edge to make the web just work. Gaurav also just made a splash at the JSConf Last Call conference in the US announcing that in the new year, ChakraCore will be fully open source and available for use and contribution.

The video is on YouTube.

There’s also an audio version on Archive.org.

In this interview, you’ll hear Gaurav try to answer my questions about the following topics:

• What’s the difference between Edge and Chakra
• Why does it make sense to look further than V8 when it comes to server-side JavaScript?
• How does interoperability work across JavaScript engines?
• Who is involved in making JavaScript engines behave, stay backwards compatible and not break the web?
• How can JavaScript engines solve the problem of ES6 breaking in older browsers? Is it up to developers to make that easier?
• How can ES6 get faster? What can developers do to make it happen?
• How evergreen browsers help the adoption of ES6.
• How to meet the Chakra team and get new things into the engine.
• How writing bad code on the web inspired a faster JavaScript
• How minification caused slow JavaScript execution and how the team fixed that issue
• What’s the future of mulithreaded JavaScript and ASM.js?

Thanks must go to Gaurav for answering my questions and Seth Juarez and Golnaz Alibeigi of Channel 9 for filming and producing the series. There are a few cuts in this one, which was because of noisy people in the background, so sorry about that.