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

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

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

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 ^.^

Posted on

The Best Thing a Frontend Developer Can Think of

Yesterday I stumbled across this post by Joakim. Yea, I know it’s in swedish. It talks about the bank Resurs Bank who are in the process of building a new site. They are going responsive and they are building it on WordPress. They are not the first bank to use WordPress (Handelsbanken is also doing it) but I believe that in Sweden they are pretty unique for using it for their main site. I’ve been looking through some swedish bank sites lately and it’s not pretty. (SEB frames, seriously? It’s 2012. Did you know?) So to this project as a whole I’d say: way to go and bravo!

But Joakim also wrote another thing: “Sure you don’t build backend in WordPress but as a frontend developer it’s hard to think of anything better”. Ok, now, here I do disagree. I don’t think WordPress is the best thing I can imagine. Sure I would pick it a thousand times over Sharepoint but there are problems. One of them is quite clearly visible in the beta of Resurs Bank: 

<script type='text/javascript' src='http://new.resursbank.se/wp-content/plugins/twentyfour-chat/js/widget.js?ver=3.3.1'></script>
<script type='text/javascript' src='http://new.resursbank.se/wp-content/themes/resurs/js/lib/jquery.center.js?ver=3.3.1'></script>
<script type='text/javascript' src='http://new.resursbank.se/wp-content/plugins/acf-spot/spot.js?ver=1'></script>
<script type='text/javascript' src='http://new.resursbank.se/wp-content/plugins/knowledge-bank/js/knowledge-bank.js?ver=3.3.1'></script>
<script type='text/javascript'>
/* <![CDATA[ */
var knowledgebankAjax = {"ajaxurl":"http:\/\/new.resursbank.se\/wp-admin\/admin-ajax.php","knowledgebankNonce":"429ccf278e"};
/* ]]> */
</script>
<script type='text/javascript' src='http://new.resursbank.se/wp-content/plugins/knowledge-bank/js/knowledge-bank-ajax.js?ver=3.3.1'></script>
<script type='text/javascript' src='http://new.resursbank.se/wp-content/plugins/knowledge-bank/js/feedback.js?ver=3.3.1'></script>
<script type='text/javascript'>
/* <![CDATA[ */
var feedbackAjax = {"ajaxurl":"http:\/\/new.resursbank.se\/wp-admin\/admin-ajax.php","feedbackNonce":"af70f522c1"};
/* ]]> */
</script>
<script type='text/javascript' src='http://new.resursbank.se/wp-content/plugins/knowledge-bank/js/ajax.js?ver=3.3.1'></script>
<script type='text/javascript'>
/* <![CDATA[ */
var __pluginAjaxRoot = {"url":"http:\/\/new.resursbank.se\/wp-content\/plugins\/rb.bank.connector\/ajax\/"};
/* ]]> */
</script>
<script type='text/javascript' src='http://new.resursbank.se/wp-content/plugins/rb.bank.connector/ajax/js/rb.bank.connector.ajax.js?ver=3.3.1'></script>
<script type='text/javascript' src='http://new.resursbank.se/wp-content/plugins/rb.bank.connector/ajax/js/rb.shop.connector.ajax.js?ver=3.3.1'></script>
<script type='text/javascript' src='http://new.resursbank.se/wp-content/plugins/twentyfour-chat/js/lib/jquery.outerhtml.js?ver=3.3.1'></script>
<script type='text/javascript' src='http://new.resursbank.se/wp-content/plugins/twentyfour-chat/js/lib/jquery.scrollTo-1.4.2-min.js?ver=3.3.1'></script>
<script type='text/javascript' src='http://new.resursbank.se/wp-content/plugins/twentyfour-chat/js/lib/nunt.js?ver=3.3.1'></script>
<script type='text/javascript' src='http://new.resursbank.se/wp-content/plugins/resurs-panels/js/scripts.js?ver=1'></script>

This is not all the js. But still. Pretty hefty. WordPress often rely on plugins and a lot of them add js or links to js in the header or (if a bit better configured) in the footer. Yea, sure there are ways around it like WP Minify But uhm, it’s still not the best thing I can think of. I rather have a good concatination/minification process setup that caches my resources and are NOT run on page load.

Ok, so I could go on and point out more problems like having to try to figure out how to override the default-classes set by WordPress and so on. But well, I won’t do that. After all this blog is live because of WordPress.

Now I know you’d want me to point out my own favorite among technologies for building a web site. And as a frontend dev I say static files with some good build-scripts and server-side configuration. Yes, I’m serious. But I also know it’s an impossible setup for any site that needs server-side integration or some kind of CMS. So what then? As for me I’d say any framework that is clean. That doesn’t include random js on demand or add classes, extra markup or CSS. Right now I’m hoping for Django. The future will tell if that’s the best thing I as a frontend developer can think of.

Posted on

When a tweet changes a meta-tag

Sometimes you get real happy.
This happened to me about a week ago. One of the big tv-channels in Sweden TV4 released their new redesigned and responsive site. I was on my phone and noticed that they had disabled zooming by using the popular attributes initial-scale=1 together with maximum-scale=1. Sigh. So why is this bad? Well, it disables zooming. I happen to really appreciate zooming on the phone. Maybe cause of my bad eyes.

So I sent off a little tweet. In english something like: Would you please remove maximum-scale? And I got answers! And people started agreeing with me! Some a bit more than others…
@upperdog_se posted a link to the excellent blog-post by Roger Johansson. (I kind of agree with everything that’s in there). And then I got the reply that they, the tech-people at TV4, would look into it. Nice! Couple of days later I got a tweet from @peter_lind, one of the developers, saying that the meta-attribut was gone from the site and soon would be removed from the blogs. Wohoo!

So there I have it. It feels like doing this is paying off. Might be a tiny little thing but to me it’s kind of real nice.

Posted on

Never want to be a troll

Well, I mean I like trolls. Especially pen trolls. Super omega-cute. I also like that norwegian movie Trolljegeren. But with that said my intention has never been to be a troll on the internet. Being all negative and grumpy. That is exactly not why I started this blog.

This weekend was midsummer. I was in my hometown spending some time with my parents. Learned my 58-year old mum how to ride a longboard among other important things. I also told my mum about this blog. About how I started it to try to point out the bad things in order to get some improvement (hopefully). My mums response to this was simply: “What about the good things? Why don’t you write about good examples?”. It got me thinking a bit. There are tons (in my opinion) blogs out there that talks about how to do good things, best practices etc. But I actually don’t no a single one that are giving out good examples. Writing things like “Look at this great site. Look how they got it right!”
So with that said I decided to include a new category of posts here. A category of posts about sites that are being nice to the internet in swedish words “är snälla mot internet”.

And oh, here is a video that I saw recently of a talk that Nicole Sullivan gave at Fluent. Watch it! It’s just 12 minutes. It’s not wasted time. Promise!