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?

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!

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.

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!

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!

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!

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!

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?

On diversity and people being weird

Maybe you have noticed the discussion regarding diversity in the tech industry lately. No? Really? I’m pretty sure you have read something about it. Either the cancellation of The British Ruby Conference or the discussion lately around Edge.

There is one thing about this that concerns me and that is after reading several articles, comments, tweets etc. It seems like the general opinion is that diversity is good and we all (most of us) want it. But, and this is where I have a problem, we do not want to do anything to achieve it. It’s bad trying to get a variation of people cause somehow that equals not getting the best people. Tech events for women are discrimination. I’ve been in involved in some tech events for women and whoa, the negative comments you get. In general most of the things that people suggest doing to improve the diversity are criticized.

Kagami is not getting it

This is the thing I do not get. How can it make sense to want something but at the same time not wanting to do anything to achieve it? It’s just like this story my dad once told me about a lady who really wanted to be good at playing the piano. She was asked if she wanted to take some lessons. No, she said, absolutely not, I just want to wake up one day and be really good at playing. People you know what? The world doesn’t work like that. If we want something we need to work for it.

It’s why this year I will try to do my share of changing things. Cause yep, I actually do believe in diversity as well and as a woman I feel like I need to step up. Especially when harassment like what happened to Iris is still around. For me this means that I will continue to tweet and blog. I’ve also said yes to speak at a local meetup. The last thing is something I’ve always said no to in the past since I felt like I was being asked simply because I’m a girl and not because somebody thought I actually had something to say. This year I will stop saying no. I’m going to try speaking now and I think it’s going to be good.

Avoiding Kodsmuts – The List

During the past weekend my mind was occupied with what to not forget for a site that’s not too far from launching. No, I don’t mean raw functionality. I mean those little things. The things that no client will ask for but most people will be expecting to just be there. Without those things your site would be a big buggy mess so let’s get it clean.
Here is the list!

Working links

Sounds obvious but I noticed that a lot of new sites are failing at this. Of course it’s not enough to just click randomly and have a feeling that you got it covered. Have a real tool (there are free ones) go through your site and report back.

Old content

If the launch of your new site means you are going to dump old content you should make sure you got that covered with some 301. Links can live for a pretty long time in peoples bookmarks and on Google.

Error-pages

Having default server-error pages are simply embarrassing and some people might even think they broke something if they come by one. The default .NET-error-page for one looks like you just got a virus.
A minimum of at least a 404 and a 500-page that fits the look and feel of the site and have some good informative text is a must.

Print-styling

Save the trees. Yep. But as for today your site will seem broken with bad usability if you can’t print it without losing content. Add some print-styling just in case. If you want to go a step further add a print-link on your site and display some tree-saving message when people click it. Or offer to convert the site to a pdf. Yea, dirty. I know. But that is how it is.

Retina

Screens are not what they use to be. Make sure to have it covered. Icons and other images must look crisp. You will be looked down on if they do not. And remember it’s not only min-device-pixel-ratio 2.0. We also have 1.3, 1.5 etc. Read up on it!

Phones and tablets

I don’t care if you are building responsive or an old-fashioned “desktop”-site. People will visit it with whatever device they got. There are no excuses today for not testing on multiple devices.

Browsers

You probably did cover the most common desktop browsers already and hopefully you did match your test with some stats from a current site. But don’t forget the new browsers that are starting to gain popularity. I’m thinking Chrome on iOS and Firefox on an Android-device. Probably these browsers are way outdated when people read this but you get the point. Do your research!

Favicons

Add them all. To rely on the browser default-icon is just unprofessional. An old-fashioned .ico and a .png at least. If you add some for apple-devices and others you are being good.

Meta description

You know that text that shows up on Google beneath the link? That’s hopefully your meta description. If the text makes no sense at all you probably forgot to add one. Because if you didn’t Google pick random (not really) text for you. Worse case the text might look like spam and people will avoid visiting your site.

Page titles

Make sure they are descriptive. The way I prefer it is putting the title of the page first and after that the title of the site.

URLs

Are they logical? The should be readable and not a kilometer long with weird parameters. Try making it as clean as possible.

Facebook

Sharing on Facebook is another thing that many people think just works out of the box. It doesn’t. To make a shared page looking good and not displaying weird stuff you need to uglify the head of your page with some og. Don’t know what og is? Read up on it!

RSS

Another thing that people think comes by default. If you have any kind of blog or even some news-list you need to make sure there are some RSS-feed that people can pick up. Make sure to not just add it but also test it! A site with updates that you can’t subscribe to in some way is broken.

Robot.txt

This always sounds soo much cooler than it is. Texts for robots! (Huge robot wandering the earth picking up pieces from text with instructions from humans…) Anyway. Make sure this one is correct! It’s important! (As @uppderdog can tell you…)

Updated libraries

Maybe you started working on your site a couple of months ago. Maybe the libraries you included back then where really fresh. Do a double-check that they are still up to date. You don’t want to miss out on bug-fixes and new functionality. And when I’m at it make it a habit to always look for updates every time you touch the site in the future.

Screenreader

Do test with a screenreader. No, it’s not something that you can just skip. If you’re on a Mac you have it built in. If you’re on Windows you can download NVDA for free. No excuses! Test!

View source the site

How does it look? Correct headers? Use of markup? Dirty comments gone? The previous test with screenreader will do a lot to improve the result of this test.

Analytics

A feature yesterday. A must today. Without stats how can you tell how people uses your site? More importantly, how can you improve it? Include Google Analytics or the like. In a smart way.

Sitemap

Another thing that’s easy to forget. I’m talking of an xml sitemap. Help them crawl your site.

Optimize images

Make sure your users aren’t downloading unnecessary things. Smush and optimize where you can. Talk to the people putting in content (if it’s not you) and tell them how to save images in a optimized way.

Minified resources

Kind of like the song of Monty Python every request is sacred. It’s not ok to have multiple scripts and stylesheets. Fix your build-process so that it takes care of concatenating and minifying your resources.

Caching

Add it where it’s logical. Make a plan for it.

Total pages size

Go through your pages. Is it possible to cut down on something somewhere? Did you miss anything?

Performance in general

Check Google Page Speed and YSlow. If the site doesn’t get a good score fix it.

External resources

A lot of cool things (like fonts) can now be included via an external library. You just put a link in the head. Well if you do you better be pretty sure that that resources loads and that it loads fast. Otherwise your users will be stuck with a blank page. We all know that the browser takes a break when it comes by a script in the header. I, personally, wouldn’t want to rely on an external resource being loaded. Please do an extra check for this!

Validate your HTML

Sounds old school? The reason that it will impress other people is, well, old. But validating is still a good tool to spot errors.

Lint your JS and your CSS

Same here. Spot the errors and defects. Fix them.

Colors and contrast

Do some tests. If you can get hold of a real person having some sort of colorblindness and/or bad sight: even better! Don’t forget to do a crappy screen test! It’s real dangerous to have a screen that is a little too good when you are making a site for other people.

Proof read your code

Don’t just clean the site on the outside. Do it inside out. Remove old bad comments. Add new where it’s needed. Make sure things make sense, refactor. Remember that clean and logical code will help your site get fast updates in the future.

Accessibility

Yea, I know lumping things together here. But do a general test. Check alt-attributes. Is it easy to navigate with the keyboard? Do some checks and remember that accessibility changes constantly and it’s not just about a checklist and being trippel-A.

Read the content

Last but not least. Read the content. As many times as you got time. Sloppy and misspelled content is just so euuuuw.

Longest list. But I didn’t just write it for you. I actually wrote it to remind myself.
Let’s act like pros people ^.^