That's kind of a provocative title, so let me just get this out of the way: No, no they are not. And I am not crazy enough to attempt to convince you otherwise. That said, they aren't nearly as bad as they're given credit for.

Let's do this by way of example. Suppose you have a list, and users need to be able to sort it, alter the items in the list, and delete items. All your front-end developers are busy, and so are the UX people, so it's up to that backend developer to bang something out. What are they going to give you? Something, I suspect, an awful lot like this:

Sort Item Delete?

In other words, a <table> that closely mimics the underlying database structure. Yeah, I can hear the internal screams of the UX people from here. But let's consider this for a moment. Is this going to be fun to use? No. Definitely not. But in its straightforward simplicity, it gives us something that's kind of amazing: anybody can use this form. No matter how spotty your network connectivity, if you managed to load this form, you can submit it. If all you have is a text-only browser, you can use this form. No mouse? That's okay, this form is keyboard-accessible. Do you interact with your computer via voice command? This form will be serviceable.

For the vast majority of your users, this is not great UX. But it is Universal UX. Anybody―everybody―can use it! The web is universally accessible by default, and by staying away from the fancy stuff, by building something that would be at home in 1994, our backend developer managed to preserve that.

We definitely don't want to stop here, but it's a pretty great jumping-off point. So let's put our UX hat on and start making some improvements.

Sort Item Delete?

Some quick wins are simply to adjust the sort values to make rearranging easier, and adjusting the text of the button. Not terribly complicated, even the backend developer can manage it.

Sort Item Delete?

But of course, manually entering the sort weight is awful, so maybe we add some buttons to adjust the list sorting, so users can click a button, rather than type in sort values, and hide the numeric input with a little CSS. We'll leave it in the DOM both for text-only browsers, and to give a place for our buttons to store the sort order (assuming they function via JavaScript).

Sort Item Delete?

And as we get fancier, maybe we dim or strike-through the to-be-deleted rows, to make it obvious they're going to go away. We add a little JavaScript to enable drag-and-drop of the rows, for really simple sorting. Maybe we even add some keypress handlers so people can move things in the list by pressing C-x C-t or whatever seems appropriate. And if those scripts load successfully and work in the user's browser, maybe we even hide the explicit sort buttons from visual users, to avoid clutter. You do run the risk of excluding a small contingent of users that way―if you can only interact with a computer through eye-movements, visible buttons might be kind of handy―but for all I know they may have other ways of handling that, so if you've got the budget, maybe test that sort of thing and report back to the rest of us. I'd certainly love to know.

But in the end, what we end up with is a lot closer to what you might have designed as a visually-oriented UX person, but because we built it in stages, because we started with the basics and layered things on top, it's usable in far more scenarios than it might otherwise be had we started with a Photoshop mockup of the end result.

NB: As you may have noticed, there is no JS attached, and there isn't much in the way of styling. That's partly due to platform limitations, but mostly because this isn't really meant to be about how-to-build it, but more about what-to-consider in the design. It just so happens that if you build it in a certain order, those considerations naturally reveal themselves.

While I am ostensibly a "full-stack" web developer, it's no secret that I'm not particulary fond of the front-end. In large part, this may be because the world seems to be full of bad front-end developers, who by and large are fantastic at building crappy versions of desktop apps inside a browser, but are incredibly bad at building things which are truly of the web.

What makes a good front-end developer? I asked @janiukjf this after her presentation at the ExperiencingUX meetup last night, and she says part of it is a willingness to stay up to date with the constantly-popping-up front end frameworks. And certainly, the front-end changes quickly and it's hard to keep up.

But do we need to keep up? I'm not convinced we do.

After all: a regular form post has worked since the 90s. It's not going to stop working! We built websites without CSS for years―CSS is a wonderful addition, but if your website is nonsensical without CSS, it'll be nonsensical in a text-only browser. It will potentially be less useful to a screen-reader (an h1 and a div with an enlarged font are likely to be expressed differently) or other assistive technology. But even with CSS, you don't have to be on the cutting edge to do useful, beautiful things. In fact it probably helps to avoid being on the forefront: older CSS tends to work better and in more browsers.

And then there's JavaScript: the easiest way to turn a browser into a fragile, distributed computing environment. We built websites without JS for over a decade, and eschewing megabytes of JavaScript to display basic text would greatly improve the speed of the web. Properly applied, JavaScript can be used to do amazing things, but there's no shame in making a simple line-of-business CRUD app out of plain ol' 90s-era forms if that's all it really needs.

So what makes a good front-end developer? I think it's embracing the limitations of the web. It's understanding that the web isn't a pixel-perfect medium; that sometimes your images or fonts or styles or scripts won't load and you have to handle that; it's understanding that the web is populated not just by developers with the latest Macbook and ten-year-olds with iPhones, but also little old ladies with dusty old Gateway computers and cheap faded monitors, and the web should work for all of them. It's understanding that the browser is a hostile computing environment in which anything we tell it to do is a mere suggestion and if we break when it doesn't that is our fault and we need to handle it.

And quite frankly, that's really hard.

May 2017

S M T W T F S
 123456
78910111213
14 151617181920
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags