Edging Out of IE Support

Having to support a minority of users on IE11 is painful. It’s a browser that is still officially supported by Microsoft, until 2025, but active development has stopped, or at least slowed right down, so the gap between it and other browsers is growing wider with every update.

The growing feature gap means either not using newer features if we’re working to the lowest common denominator or else having to provide polyfills or fallbacks so IE11 can still be used.

But there could be a light at the end of the tunnel, and before 2025. Microsoft Edge is moving from using the EdgeHTML engine to open source Chromium, which will bring it in line with Chrome, Opera and Safari. That’s nice for compatibility but the big deal is that it will be available on older Windows operating systems. Up until now Edge was only available on Windows 10 but it will soon be available on 7, 8 and 8.1 too so more users can drop IE and use Edge as their official Microsoft browser.

The Edge team are going one better than that though. One of the big reasons for clinging on to IE is the use of legacy software which only works on that browser. Edge is introducing an IE11 mode, so users can seamlessly (hmm – I can already hear the massive crash) switch over to IE for specific sites. Very clever.

It looks like we might have a way out of IE11 support in the next 12 months or so. Just need to convince the large corporations to make the switch now but I’m sure Microsoft will be pushing hard on this too. Good news.

Performance Perception Trick: Processing Lists Faster

I’ve got a little trick to make the processing of lists appear to go faster than it actually does.

Let’s suppose we have a list of 10 items and there’s some kind of processing to be done on them, maybe sending them off to a service which returns a Boolean true/false response for each. In reality we post a single request with the data of the 10 items and we get a single response back after 3 seconds.

In the UI we can use animation to make it look as if each item is being sent one at a time by adding a 100 millisecond delay between each state change. This means that the user thinks the last item of the 10 is sent after 1 second but in reality it’s already gone a second ago buying us extra time.

When we get the response, rather than show all the results immediately, we can use a similar animation to make them appear one by one with a 100 millisecond delay again. Although this is slower than just showing them all it maintains the illusion of the items being processed one by one.

So, the reality, without the trickery, is like this:

0Request sent,
perceived waiting time begins
3Response returned,
UI updated,
perceived waiting time ends

This would mean a perceived waiting time of 3 seconds.

And with the trickery:

0Request sent,
animation started
1Animation ends,
perceived waiting time begins
3Response returned,
animation started,
perceived waiting time ends
4Animation ends

Even though the time to getting the final bit of data on screen is actually extended to 4 seconds, the perceived waiting time is reduced to 2 seconds.

Should Designers Be Able to Code?

This seems to be a bit of a hot topic on Twitter right now so here’s my take.

The definitions of designer and developer and where you draw the line between the roles is a bit of a nonsense. In reality you can’t box things like this. It’s about the individuals and what skills they have and what fits your team. Overlaps in skills are not a problem, gaps are. So, the handover points will naturally surface out of what works for the team. That said, I do have some more specific thoughts about what might kinds of coding might empower a designer.

I’m assuming we’re talking about designers who already write HTML and CSS and what level of JavaScript they should know or learn. A designer who works in a graphics editor or prototyping environment clearly has a different skill set.

Knowing some basic DOM manipulation techniques can really help to add some life and interaction to designs – “Interaction Design”.

  1. Being able to select a DOM element with document.querySelector() is a good starting point.
  2. Basic event handling with .addEventListener('click', handler) is useful as it allows you to add actions.
  3. Handling events means learning how to write a very basic named function.
  4. Finally being able to toggle properties like hidden and disabled or add/remove/toggle items fromĀ classList enables you to design for lots of different states within the same document.

I think just these few basic steps will enable a designer to achieve a lot more in their designs.

Most beginner’s JavaScript courses I’ve seen seem to start with constructing objects but this is far less useful for UI work. Designers probably don’t need to worry about objects, arrays, classes and the whole data side. Static data is generally sufficient for communicating the design and interactions.

What Techies Tweet

I was curious as to what value I was getting out of following people in the tech industry on Twitter. Are they sharing useful information or just sharing pictures of their pets? Is it jokes and memes, self-promotion, sharing useful resources, praise, criticism, politics? I studied 100 consecutive tweets to get an idea.

This is by knows means scientific but still quite interesting. There are a few important parameters for how I use Twitter, which may explain differences from what you see. Firstly, I don’t exclusively follow people in tech. I follow real world friends, football journalists, comedians, celebrities – a pretty broad spectrum of people. Here I’ve limited the tweets analysed to just those from people in tech. I’ve got to admit there were one or two where I wasn’t sure so had to check their bios. Secondly, I try to follow real people, not faceless organisations. My rationale is that organisations’ tweets are 99% self-promotion. If their content is good enough I’ll get to hear about it via others retweeting. I’m trusting the people I follow to filter the organisational information I receive. Final point is I have a couple of words muted – “Trump” and “Brexit”. This will obviously impact on the amount of political tweets I see.

So, here’s a breakdown from 100 tweets on Friday 26th April, roughly 5.00 – 5.30pm UK time.

68% were tech-related
29% were not tech-related
3% I couldn’t be sure about

6% I could not understand, tech or otherwise

Of the 68 tech related tweets,
48 (71%) were aiming to share something useful
(retweets, links to resources, media)

Of the 29 tweets not related to tech, subjects/themes were:
4 Gender Inequality *
2 Humorous (jokes/memes)
2 Politics **
2 Cats
1 Dog
1 Goats
1 Game of Thrones
1 Mental Health ***

* It could be argued that these are tech related if the people tweeting are in the tech industry but it wasn’t mentioned explicitly. Either way 4% or 1/25 tweets is very prominent.

** This is despite my “Trump” and “Brexit” muted words.

*** Big thumbs up!

If anyone else would like to do the same exercise it would be interesting to compare and contrast results.

When to Reach for a Framework (and When Not To)

First off, when I say “framework” in this post’s title I just mean any big chunk of stuff that you load up and it does stuff for you. So, could be React, jQuery, Bootstrap, etc.

Let’s say that a “framework” is made up of 10 bits of functionality. If we use all 10 of them then we’re getting great value from it. Conversely, if we’re only using one or two we’re probably loading up a lot of stuff that is never used – bloat.

DIY?

If you’re only using one or two bits then you’d probably be better off writing these parts yourself, if you can, or finding smaller libraries which do just the parts you need.

If you go too far with trying to roll your own system you end up with a kind of framework but one that’s made up of lots of disparate parts which may have other dependencies. It’s a Frankenstein’s Monster of a framework. Hard to maintain and extend.

Tipping Point?

So, the real question is at what point do you move from assembling your own parts to adopting a full framework which organises these parts in a coherent and systemic way? Where’s the tipping point?

Going back to our example of a framework that offers 10 bits of functionality, how many would you want to be using to make adopting the framework worthwhile? I think it’s important not to look at the now but at the future. Where is your project headed? Will it keep growing? What other functionality might you use further down the line? Does the framework given you other things for free that you can do now?

Framework Benefits

The other major benefit that a framework brings is the knowledge and familiarity. You can recruit someone who has worked with a framework before and they will be up to speed quite quickly compared with someone coming in and having to pick their way through a large custom system.

If a framework offers 10 bits of functionality I’d be inclined to adopt it as soon as you’re using 3 of them. I feel the benefits of a framework outweigh the saving.

You also have to consider the quality. Is a framework that has been worked on by top engineers and tested by thousands of developers going to be better than something you roll yourself? And will it integrate better with other third party tools?

Modules FTW

The real answer is for frameworks to become modular with a very small core and lots of optional modules. Not NPM which is going back to the “Franken-framework” but a properly connected set of features which can be included or dropped as needed. A bit of an old-school example now but jQuery UI does this very well – you can build a custom version of the library to suit your needs.