Down

Slimming down the web: Remove code to fix things, don’t add the “clever” thing

Today we saw a new, interesting service called Does it work on Edge? which allows you to enter a URL, and get that URL rendered in Microsoft Edge. It also gives you a report in case there are issues with your HTML or CSS that are troublesome for Edge (much like Microsoft’s own service does). In most cases, this will be browser-specific code like prefixed CSS. All in all this is a great service, one of many that make our lives as developers very easy.

If you release something on the web, you get feedback. When I tweeted enthusiastically about the service, one of the answers was by @jlbruno, who was concerned about the form not being keyboard accessible.

The reason for this is simple: the form on the site itself is none insofar there is no submit button of any kind. The button in the page is a anchor pointing nowhere and the input element itself has a keypress event attached to it (even inline):

screenshot of the page source codeclick for bigger

There’s also another anchor that points nowhere that is a loading message with a display of none. Once you click the first one, this one gets a display of block and replaces the original link visually. This is great UX – telling you something is going on – but it only really works when I can see it. It also gives me a link element that does nothing.

Once the complaint got heard, the developers of the site took action and added an autofocus attribute to the input field, and proudly announcing that now the form is keyboard accessible.

Now, I am not having a go here at the developers of the site. I am more concerned that this is pretty much the state of web development we have right now:

  • The visual outcome of our tools is the most important aspect – make it look good across all platforms, no matter how.
  • As developers, we most likely are abled individuals with great computers and fast connections. Our machines execute JavaScript reliably and we use a trackpad or mouse.
  • When something goes wrong, we don’t analyse what the issue is, but instead we look for a tool that solves the issue for us – the fancier that tool is, the better

How can this be keyboard accessible?

In this case, the whole construct is far too complex for the job at hand. If you want to create something like this and make it accessible to keyboard and mouse users alike, the course of action is simple:

  • Use a form elment with an input element and a submit button

Use the REST URL of your service (which I very much assume this product has) as the action and re-render the page when it is done.

If you want to get fancy and not reload the page, but keep all in place assign a submit handler to the form element, call preventDefault() and do all the JS magic you want to do:

  • You can still have a keypress handler on the input element if you want to interact with the entries while they happen. If you look at the code on the page now, all it does is check for the enter button. Hitting the enter button in a form with a submit button or a button element submits the form – this whole code never has to be written, simply by understanding how forms work.
  • You can change the value of a submit button when the submit handler kicks in (or the innerHTML of the button) and make it inactive. This way you can show a loading message and you prevent duplicate form submissions

What’s wrong with autofocus?

Visually and functionally on a browser that was lucky enough to not encounter a JavaScript error until now, the autofocus solution does look like it does the job. However, what it does is shift the focus of the document to the input field once the page has loaded. A screenreader user thusly would never ever learn what the site is about as you skip the header and all the information. As the input element also lacks a label, there isn’t even any information as to what the user is supposed to enter here. You sent that user into a corner without any means of knowing what’s going on. Furthermore, keyboard users are primed and ready to start navigating around the page as soon as it loads. By hijacking the keyboard navigation and automatically sending it to your field you confuse people. Imagine pressing the TV listings button on a TV and instead it just sends you to the poodle grooming channel every time you do it.

The web is obese enough!

So here’s my plea in this: let’s break that pattern of working on the web. Our products don’t get better when we use fancier code. They get better when they are easier to use for everybody. The fascinating bit here is that by understanding how HTML works and what it does in browsers, we can avoid writing a lot of code that looks great but breaks very easily.

There is no shortage of articles lamenting how the web is too slow, too complex and too big on the wire compared to native apps. We can blame tools for that or we could do something about it. And maybe not looking for a readymade solution or the first result of Stackoverflow is the right way to do that.

Trust me, writing code for the web is much more rewarding when it is your code and you learned something while you implemented it.

Let’s stop adding more when doing the right thing is enough.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

These apples don’t taste like oranges – let’s burn down the orchard

When I see comparisons of HTML5 to native apps I get the feeling that the way we measure failure and success could give statisticians a heart attack. Take Andrea Giammarchi’s The difficult road to vine via web as an example. In this piece Andrea, who really knows his stuff tries to re-create the hot app of the month, Vine using “HTML5 technologies” and comes to the conclusion – once again – that HTML5 is not ready to take on native technologies head-on. I agree. But I also want to point out that a 1:1 comparison is pretty much useless. Vine is only available in iOS. Vine also was purposely built to work for the iPhone. In order to prove if HTML5 is ready all we’d need to do is to find one single browser on one single OS, nay even only on one piece of hardware to match the functionality of Vine.

sobbing mathematically

Instead we set the bar impossibly high for ourselves. Whenever we talk about HTML5 we praise its universality. We talk about build once and run everywhere and we make it impossible for ourselves to deliver on that promise if we don’t also embrace the flexible nature of HTML5 and the web. In other words: HTML5 can and does deliver much more than any native app already. It doesn’t limit you to one environment or hardware and you can deliver your app on an existing delivery platform – the web – that doesn’t lock you in to Terms and Conditions that could change any time from under you. Nowhere is written though that the app needs to work and look the same everywhere. This would actually limit its reach as many platforms just don’t allow HTML5 apps to reach deep into hardware or to even perform properly.

What needs to change is our stupid promise of HTML5 apps working the same everywhere and matching all the features of native apps. That can not happen as we can not deliver the same experience regardless of connectivity, hardware access or how busy the hardware is already. HTML5 apps, unless packaged, will always have to compete with other running processes on the hardware and thus need to be much cleverer in resourcing than native apps.

Instead of trying to copy what’s cool in native and boring and forgotten a month later (remember Path?) if we really want to have HTML5 as our platform of choice we should play it to its strengths. This means that our apps will not look and feel the same on every platform. It means that they use what the platform offers and allow lesser able environments to at least consume and add data. And if we want to show off what HTML5 can do, then maybe showcasing on iOS is the last thing we want to do. You don’t put a runner onto a track full of quicksand, stumbling blocks and a massive wind pushing in the opposite direction either, do you?

HTML5 needs to be allowed to convince people that it is a great opportunity because of its flexibility, not by being a pale carbon copy of native apps. This leads to companies considering native as the simpler choice to control everything and force users to download an app where it really is not needed. Tom Morris’ “No I’m not going to download your bullshit app” and the lesser sweary I’d like to use the web my way thank you very much, Quora by Scott Hanselman show that this is already becoming an anti-pattern.

Personally I think the ball is firmly in the court of Android to kill the outdated and limiting stock browser and get an evergreen Chrome out for all devices. I also look for Blackberry 10 to make a splash and for Windows phone and tablets to allow us HTML5 enthusiasts to kick arse. And then there is of course Firefox OS, but this goes without saying as the OS itself is written in HTML5.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)