Posted on

If you are a modern developer and not stupid

And then they said that I had to support IE8! Yes, I know! So of course I didn’t want to work there. I mean I’m not stupid.

That conversation happened at a JavaScript meetup in Stockholm a couple of years ago. Back then the project I was working on had to support IE7. I did not feel stupid.

Fast forward some years and I’m at another meetup. The person on stage talks about how many npm modules they use in their project. They use a lot of things all at the same time. Webpack, Babel, React, Gulp etc.

If you are a modern web developer of course you need to use all of this!

The person states this with confidence while scrolling through the very long package.json-file to show off all the modules. At the time I hardly used anything he mentioned. Was I not a modern web developer?

At a conference. The person on stage talks about the dark years of PHP-development and how they realised that:

PHP is just really stupid programming and everyone who is not stupid should move on to better things

People are laughing. I look around the room. I recognize some of my friends there. Some of them are PHP developers. Really smart people that I look up to. They are not laughing.

Ok, so why do we do this? I’m going to say we because I’m absolutely sure that I’m guilty of this behaviour myself. You find something that you think is a lot better than the thing you worked with before. You want to tell people about it. Fine. But do you need to pass judgement over others? Why not just focus on yourself and your experience? Instead of saying that people using X are stupid you could say something like:

I decided to stop working with X because of reasons and instead I now work with Y because of these things and I feel that it works much better for me.

No judgement. Much better.

Oh and while I’m at it. Don’t use religious references as jokes. As well as it’s not ok to say that people using a certain tech-stack are stupid it’s also not ok to make fun and ridicule people because of their religion.

Have an awesome day everyone!

Posted on

Some Thoughts on Jfokus

A couple of days ago I was talking to a friend of mine, Elisabeth. She mentioned that the norwegian conference JavaZone had very few women in the lineup. We talked about it a bit and I decided to go and check the Swedish conference Jfokus to see how things were looking there. So I went to their website and had a look.

According to themselves Jfokus are Sweden’s largest developer conference. The next edition of Jfokus will take place in Stockholm next year and they actually have a Call for Papers out right now. That’s cool!

I took a quick peak at the speakers they have had this year and if I understood things correctly there were 75 speakers and 5 out of those who seemed to be women. I judged this mainly by looking at the pronoun she, that was used in the speaker-bio. This means that below 7% of the speakers were women. In terms of gender diversity that is not a happy number.

Now I’ve been organising a conference myself this year and also been thinking a bit about speaking more so I decided to take a look at the CFP for next year. Is diversity something they are thinking about? And if so how are they encouraging it?

The CFP-page consisted of a short description of the conference, when the CFP will close and the expected length of a presentation. It also included a commercial policy. All good info but I would have wanted a bit more. In order to continue I had to give them my email-address. It said they would send an email with further instructions. So I submitted my email and then I checked my inbox. Nothing. I checked it again a bit later. Still nothing. Were they checking emails manually? Some hours later I did get the email. It turned out that “further instructions” was a link to an online form were I was supposed to fill in personal details like company, phone number, blog, twitter, experience, bio etc. There was no mention of topic or title for a talk. I tried to fill out some and hit the save button but the form complained that I had to fill in all required fields. I was not sure which fields were required since there were no visual cues. Were all of them required? Some of them? I also noted that the form itself was really hard to fill in from a phone due to weird zooming issues.

At this time I decided to go and check if there was any mention anywhere as to what they might look for in a speaker proposal. I went back to their website but didn’t find anything regarding the purpose of the conference. I even watched their promo video on YouTube but unfortunately it was only showing people attending the conference with a music overlay. Not really any relevant info for people thinking about sending in a proposal.

I took a look at all the previous years to see what kind of speakers and topics there have been. Clearly it’s been quite focused on Java over the years. Even though they don’t state it on their current site Jfokus has always been the conference for Java developers here in Sweden. So no surprise there. But I also noticed that here and there were talks about other things like Scrum, HTML5, Go, Docker and even some talks that seemed less technical. I noticed that some speakers been talking several times over the years. But should I really have to go through the archives to try to guess what they are looking for in the CFP?

I went to their Twitter-page and read the one sentence-bio there. It said: “Developer conference in Stockholm with focus on JVM languages, Rock-star speakers and great inspiration.” Ok. But Rock-star speakers? Do you have to consider yourself to be a rockstar to apply? I was again confused.

In the end I decided that instead of submitting a “proposal” (or sending them some personal info) I would write this article and give Jfokus some tips on how to do this better and in a more inclusive way. At this time my focus will be on making a better CFP and there are quite a lot of things that can be fixed here. Quite easily too I believe.

  1. Be clear about the purpose of the conference. It’s not terrible to have a couple of sentences on why you are doing this and why people should attend.
  2. In the CFP be specific on what kind of speakers you are looking for. Putting together a proposal might take some time and it’s better for all if people are not wasting their time when they don’t have a chance of being accepted.
  3. What kind of topics are you looking for? Again be respectful of peoples time. I’m thinking the commercial policy might be an attempt at this but you could do better. Java-related topics vs non-Java? Is a non-technical talk acceptable? Is it ok to have a talk directed to beginners or should all talks be expert level?
  4. Make sure the forms for submitting works across devices. Also make sure it’s accessible for ATs. An inclusive form should consist of semantic markup with clear labels and inputs.
  5. Explain why you need certain information and what you will use it for. I’m not sure if that email I submitted will only be used to send me an email with a link to another form or if you will also use it to send out info or even spam about other things? As for the personal info it’s the same thing. Why do you need it and how will you use it?
  6. Let people submit a talk (or several). Now I never made it through the form for personal info but I find it really weird that my personal info seemed to be more important than the topic I would like to talk about.
  7. Let people know about the process of choosing speakers. This will again tell people if they might stand a chance and also that the process seems fairly fair. How many people are deciding? Do all proposals stand the same chance regardless of when they are submitted?
  8. If you want to be inclusive don’t call speakers Rock-stars (or ninjas, gurus, super-heroes or the like). A lot of people do not identify themselves with these kind of words and it’s also cool if you as a “regular” person are free to speak as well. If on the other hand you are looking for only Rock Stars (or only “famous” and well-known people) you need to state that clearly. But then again if that is really the case I’m not sure having a CFP is the right way to go.
  9. Tell people what they can expect from you. Are you paying for their trip to Stockholm? Hotel? Food? Do you get payed for speaking? These are all good things to know before proposing.
  10. When are people going to be notified about the selection? Will everyone who submitted get notified regardless of being selected or not? This is something that will help both you and the speakers. A lot of people live busy lives and a late or unclear notification might end up in both of you missing out.

So what all of these things comes down to is trying to be inclusive by respecting people and their time.

In a blog post Karoline Klever writes about diversity at NDC Oslo 2016. I found the following sentence:

In Sweden, most conferences are able to reach 20%, they have a black belt in attracting women and we’d all like to learn a thing or two from them.

It would be so cool if Sweden actually was really good at this, right? Sadly I’m pretty sure we are not. But we can do better and I think Jfokus can do better.

 

 

Posted on

The painful gap

Over the years I’ve been involved in many web sites. A lot of them have been built on top of a CMS. It’s this type of web site I will discuss today.

TL;DR

There is a gap between the editors and the people building. We are often building shells and are later surprised by the errors. We need to work together and we need a plan to change this.

In this article I will talk about the gap. Because over the years, and especially today with the rise of responsive design, it’s painfully obvious that there is a gap. I’m talking about the gap between us and the editors. The editors are the people responsible for putting in content on a web site but for some reason they rarely work together with the people that are building the site or maybe I should say the shell? Because that is actually what a site without content is. The sad fact is that it’s “just” a shell that we often deliver to our customers.

There is a lot of talk today that when building a responsive site every skill has to work together as a team. We need to sit together, talk to each other and we need to cooperate. This includes backend developers, frontend developers, ux people, designers, project managers and what else but in reality it rarely includes editors. In a best case scenario you get to meet the editors once a week or so but you do not work together. This is what I mean with the gap. There is a gap between all of us as a team and them. After the big release of a new web site things slows down for the team that built the shell but the editors keep working. Now the gap is even bigger.

This gap is a problem. What often happens is that content is being put up on the site without feedback. The group of editors might not have a big library of test devices. They might not know the difference between bad and good HTML (even though they should). They might not understand why certain images is not working. Because of this the quality of the site is often slowly going downhill.

So how would I like it to be? Well, during development of a new web site I would like all of the editors to be part of the team as much as possible. We should all work together, sit together and give good feedback to each other. Instead of buidling and deliver a shell we would actually build a full site. There also needs to be a plan for the content that lives on a website. What type of content should be put up? Tone of voice for text and images? Who is putting up content and when? How do we report content-errors? When and how do we evaluate what is being put up? This list could go on. I guess this is somehow included in the concept for a web site but I often find that it needs to be more down to earth. I need dates and names.

I think we can do much better when it comes to building and maintaining web sites. Are you with me on this?

Posted on

Tools for finding kodsmuts

In total I’ve been speaking about Kodsmuts three times this spring. Last time was in Gothenburg at Drupal Camp. I got a question on Twitter after my session from @vincic who wanted to know if I used any special tools to find Kodsmuts. I realized the answer was too long for a tweet and promised to blog about it. This is me fulfilling that promise. Sorry it took a while.

Now I don’t really think I use any fancy tools to check web sites so don’t be disappointed. I’m just going to tell you the way it is. Here it goes.

TL;DR

For you lazy people with no time. Here is a TL;DR. Everyone else move on. Some of the so-called tools I use to review web sites includes view source on a desktop browser and using a js-bookmarklet on my phone. Dev tools in Chrome is great for minified resources and for debugging. My keyboard, VoiceOver, Contrast Ratio and Color Oracle for basic a11y-testing. And of course Google to check some SEO.

Viewing Source

The most common way for me to review a web site. I view source. On a desktop it’s pretty easy. I hit Cmd+Alt+U in Chrome on my Mac and I got the Dev Tools, Cmd+Alt+I, to see the generated source. On my phone a got a nifty little bookmarklet with the following JavaScript:

javascript:(function()%7Bi=document.createElement('iframe');
i.setAttribute('viewsource');
i.setAttribute('width',%20'100%25');
i.src=location.href;
document.body.insertBefore(i,%20document.body.childNodes%5B0%5D);%7D)();

I did add line breaks to make it more readable but if you’d like to use it you better remove the line breaks.

Viewing Minified Resources

Nowadays a lot of resources like CSS and JavaScript are minified. This makes them really hard to read. To get around this I usually check if the file has a “min” in the filename, like scripts.min.js. If it has there are a good chance you can get to the original file by removing the “min”. Otherwise I often visit Dirty Markup (Maybe because I find the name somewhat appealing). You also got the pretty print-button in Dev Tools in Chrome which are pretty useful.  Dev Tools is of course also great for debugging.

Screenreaders

I often use VoiceOver if I suspect something is off. It’s a real good tool to see if the page is logic and not full of hidden things that might destroy the user experience. Cmd+F5 to open up VO and Ctrl+Alt+A to go through it all and Tab for jumping between links. Easy. Now of course VO is for Mac only. If you are on Windows use NVDA.

Colors

To check contrast nowadays I use Lea Verous Contrast Ratio site. I used Jonathan Snooks  tool before. As for color blindness I got a nifty tool called Color Oracle which is very simple but I think it’s good enough for quick checks.

Keyboard

I check the most common things with my keyboard like if the tabbing feels logical and if it’s obvious where on the page I got my focus.

Google

I often use Google to search for things related to a web site to see how they do when it comes to SEO. Do I get good hits? Is the description good enough? If not what might be he reason? I know a lot of web developers think SEO is kind of shady business. But many sites get most of their visitors from Google so you need to check this.

That’s it folks. Keep it clean and healthy out there!

Posted on

Why I will continue to run WordPress

During the last weeks I’ve been digging into Jekyll a bit. It’s a simple static site generator. Perfect for simple blogs driven by techy people. It’s super-easy to make a clean site that is free of kodsmuts. Or well kind of. Until you start noticing that you need to add a lot of third-party things and… oops.

Anyway I’ve got the question a couple of times if it isn’t a good idea for me to move my Kodsmuts-blog over to Jekyll. I must say it’s rather tempting. But in the end I’ve decided to keep up with WordPress. Why? Cause WordPress is the kind of CMS you work with to make web sites for clients. Web sites for those who do not know how to push things to Github and who might not even know HTML. I feel a need to try to make a clean site out of a CMS that do work for those people. I am working on a new theme to make this happen. It might not be ready for this blog very soon (because of other side projects) but it will be ready. It will never be done. Cause as in everything web there are and will always be room for improvement.

I think by not switching this blog to Jekyll I will be able to keep it down to earth. I will not feel like everything I write here is something that is ‘easy for me running my little beautiful static thing’. Now I do know that WordPress isn’t the most heavy stuff. I’ve been working with other so-called CMS-systems that are worse. But still WordPress is real enough for me, at the moment.

Posted on

Don’t forget focus

Ok, this is really simple. Whenever you apply styling or JavaScript on hover do the same for focus. Keyboard users all over the world will thank you. Easy right? And you thought I was going to write this super complicated post on accessibility and stuff. Nope. I just wanted to tell you this.

Ok, so I do understand that this might not be super-obvious for some people so I’ll give a little explanation. When it comes to styling every browser has built-in styling for focus called the outline. It looks like a dotted line in some browsers and like a blue or yellow border in others. It is possible to remove this outline with CSS. Do not do that! You might argue that this is enough styling for focus but sometimes the outline is really hard to see (I’m looking at you Firefox!) so a good rule of thumb is to apply that styling you put on hover on focus as well.

Next thing. JavaScript. It’s not as nice as CSS. There is no built-in fallback in the browser. If you only script for things to happen on hover, touch or (the horror) mouseover it will not be accessible on focus. In real life this means that it will be inaccessible to keyboard users. So do not forget to throw in a little focus in your script.

People often argue that they do not have the time or budget to care about things like accessibility. When it comes to thinking about focus those arguments are simply not valid. It takes you a couple of seconds to fix this. Just do it!

Posted on

Arranging t12t

I’m really excited right now. Tomorrow evening me and a couple of colleagues will host the very first meetup on web accessibility in Stockholm.

It all started after discussing web accessibility together with the other frontend devs in the office. Some people suggested that we should have an evening were we really dug into a11y-things. I got the thought that why just us digging into things why not have an open evening where anyone could come? Like a meetup?

This was about a month ago and now it’s here. Our meetup! It’s called t12t (tillgänglighet) as a swedish equivalence to a11y (accessibility). We got a page up at meetup.com and a fair amount of people seems to be interested and have signed up. When I’m writing this we still have a couple of spots left so if you happen to be in Stockholm tomorrow evening and don’t have anything in particular to do please come by!

I don’t think web accessibility is a boring thing that involves checklists and threats about lawsuits. Personally I think web accessibility is an awesome thing. Just how many other mediums are as accessible as the web by default? I mean just compare it to a printed magazine. Right! The web is awesome and If we have some knowledge about the capabilities of the web and its accessibility we can keep it that way.

I’m hoping the meetup tomorrow will be the first one of many. Excited!

Posted on

Talking Kodsmuts at DrupalCamp

As I’ve been writing in an earlier blog-post I’ve decided to start doing some talking. This Friday I held my first session. I was invited to talk about Kodsmuts by the people organizing DrupalCamp in Stockholm. I did inform them that I was no longer working actively with Drupal but they were all like; we don’t care. So I agreed.

Last year I visited DrupalCamp together with a couple of colleagues. The tech sessions were all held in a pretty small room were you could squeeze in about 30 people or so. It looked kind of like a classroom. At least that’s how I remember it. I thought it was going to be something similar this year so guess my surprise when I walked into the Awave room, where I was going to hold my session, and it turns out that it’s a room capable of holding around 300 people. I was super-excited!

Me with slide of Kodsmuts at DrupalCamp
Me in the very beginning of my talk fiddling with the mic
(Photo by @wibron)

As for the conference it was a good one. I even got a little bit excited about the promises of Drupal 8. Especially after listening to Tobias talking about Symfony and Morten Dk talk about Twig templates. But these things are all in version 8 so I guess I need to wait with being too excited till the end of this year or so.

My session was the last one of the day. I was hoping for everyone not to be asleep and that they would grasp some of the message. Being on stage was an awful lot of fun. I mean just the thought of being able to stand in front of all these people and you know that they will listen to you, more or less, for at least half an hour. So cool!

The main focus of my talk was what kodsmuts is, common problems and how and why it’s important to keep your website as clean as possible. If you’ve been reading this blog before you know that it’s all about being nice to the Internet. Talk went well and I even got a lot of positive feedback from people I’d never met before. I wish I could link to a video or something but unfortunately there were no live streaming or audio recording that I know of. But hey, if you want me to talk about kodsmuts again I’m all up for it. Just let me know!

Posted on

Please View Source

I’m hitting these keys out of habit. They are Cmd + Alt + U in Chrome on a Mac. Ctrl + U in Firefox on a Windows-machine. This is kind of a hobby to me. I’m talking about viewing the source.

It’s probably why I got obsessed with #kodsmuts to begin with. I’m seeing a lot when I view the source. A lot of mistakes and bugs. The thing that often hits me is that it seems like many of them are just simple mistakes. Somebody forgot to remove something or add something or didn’t know that weird thing was duplicated. Common things are missing headers, dead links to JavaScripts, duplicated links to css and a very common one: meta content=”width=device-width” even though your site clearly isn’t responsive. A lot of things is not visible to the eye. But as we all know the beauty of a web site isn’t only what’s on the outside.

It seems to me that we are not viewing the source of the web sites we are working on enough. So I now urge everyone to at least start checking the most common page types before you put things into production. Check each element and make sure you know what it’s doing and why it’s there. If you are not sure ask your colleagues.

Let us stop making these stupid mistakes!

Posted on

Giving feedback, getting feedback

A couple of days ago my sister visited and we talked about going to a play later in the spring. While she was there I picked up my laptop to get tickets. Turned out that there was only one way to get tickets and that was by buying them with a card on a web site. I had a card so no problem so far.
I started filling out the form. I was a little bit annoyed since the site wasn’t using https and the only sign of some kind of security was the sentence: “You will pay over a secure connection”. I hit the pay-button and a lightbox turned up asking me for my card details. Without looking closer at the form I closed the browser. My sister looked at me.

– Why did you do that?
– It wasn’t secure, I replied.
– How could you tell?
– Did you see any padlock?
– ???

I later emailed the support for the web site. The answer I got sounded pretty much like my sister. They didn’t get it. How could I say it wasn’t secure? It was! They even told me so on the site! In addition they emailed me links to their provider who also said that everything was very very secure. I emailed them back with screenshots of their site compared to another site that I actually do find secure. I explained everything in detail and gave them some suggestions on how to improve things. Today I got an email again. A positive one. They said that they were happy about my suggestions and would as soon as possible make sure that the whole checkout was secure. I was happy.

Ok, so now here is three questions.

  1. Why don’t people in general know about secure connections?
  2. Why don’t people who run a web shop know about secure connections?
  3. How do we fix this?