Categories
Uncategorized

The hidden cost of one bad design

I once worked on a project where users wanted to pay using PayPal. We designed this:

Payment options page

The business blocked the design because it was too easy to select PayPal. This is because we received a 50p transaction fee when users paid by card.

We we’re asked to put the PayPal option behind a click-to-reveal pattern encouraging users to choose card.

But, the hidden costs of doing this add up to way more than 50p per order.

Unhappy users use the service less or use competing services instead. They also stop recommending the

See original post

Categories
Uncategorized

Designing honestly for the web

I admit: I’ve bent the web many times in the past. For example, I’ve:

used tables for layout given submit buttons a pointer cursor used a select box as a makeshift navigation bar

In A Dao of Web Design, John Allsopp says:

“If you’ve never watched early television programs, it’s instructive viewing. Television was at that time often referred to as “radio with pictures,” and that’s a pretty accurate description. Much of television followed the format of popular radio at that time.”

Like the relationship between television and radio, there’s a relationship between print and web.

See original post

Categories
Uncategorized

Designing a responsive menu without a hamburger

James Archer has explained why the hamburger menu can cause usability problems. I thought I’d jot down a few alternative designs here.

# 1. Medium

Medium’s success is down to it’s simplicity which can be seen in its navigation which simply drops underneath the header.

Medium’s navigation stacks underneath the header on small screens # 2. Product Hunt

Product Hunt follows the same approach as Medium, but does regardless of screen size. But, as Product Hunt has more links, they wrap onto two lines.

This menu could be designed a little better, it’s hard to

See original post

Categories
Uncategorized

Progressively enhanced Javascript

Using Javascript to design progressively enhanced interfaces is probably the most important yet, misunderstood subject in web development.

In this article we’ll discuss these misunderstandings. Then, we’ll explore long-forgotten techniques that have stood the test of time.

“The problems we have with websites are ones we create ourselves”

— Motherfuckingwebsite.com

By default, the web is accessible to everyone. That’s the web’s super power. It’s us lot that take this natural super power and lace it with kryptonite, hurting users in the process.

Most of us care about users, but we also fail in the execution of that intent.

See original post

Categories
Uncategorized

Addendum to the boring front-end developer

Thanks to everyone who read The Boring Front-end
Developer
. There were some outrageous and funny comments which I found entertaining and there were also some points worth addressing.

# 1. CSS preprocessors

I know I’m in the minority here. I know a lot of developers who like them, and a lot who don’t. I can see their many advantages too.

It’s just that I’ve worked on enough projects to know some of the problems they induce. Such as performance, maintainability and more.

It’s relatively easy (cheap) to add a CSS preprocessor to a tech stack,
but it’s relatively hard (costly)

See original post

Categories
Uncategorized

The disadvantages of Javascript polyfills

A polyfill, also known as a shim, is a user-defined implementation of an API that some browsers provide natively, normalising browser differences.

As a proponent of outside-in development, I see the lure of trying to develop as if all browsers are the same. The problem is that browsers are not the same. Polyfills are problematic because:

# 1. They augment host objects

Polyfills augment host and native objects. Experts such as Richard Cornford, David Mark, Thomas Lahn and Kangax have told us this is a bad idea. The latter of which published two articles on the subject:

What’s wrong

See original post

Categories
Uncategorized

The disadvantages of CSS preprocessors

CSS preprocessors have many advantages. But like most tools, they also have a number of drawbacks which I’ll describe here.

# 1. Debugging is harder

Preprocessors have a compilation step, meaning that CSS line numbers are irrelevant when trying to debug our code. But debugging is twice as hard as programming, so this alone is a huge drawback.

“Debugging is twice as hard as programming”

— Brian Kernighan

Source maps provide a solution, but they need to be setup and they don’t work in all browsers, particularly those where bugs often come up.

Without source maps, we’re left

See original post

Categories
Uncategorized

The role of the Front-end Developer

The role of the front-end developer extends far beyond translating designs into code. They should be involved in many other aspects of the design and development process too.

# User experience and interaction design

Everyone is responsible for UX and front-end developers play an essential role due to their intimate relationship with a huge range browsers, across devices and operating systems. How can you design for the web if you don’t understand the platforms’ constraints and powers?

# Front-end architecture

An experienced front-end developer should be able to design a suitable front-end architecture which includes the consideration of the following:

See original post

Categories
Uncategorized

Technical wanking

Technical wanking is the practice of using cool and new technology because — well — it’s cool and new. But it’s better to choose technology on merit.

I first heard the term in 2010 when I was building my first Single Page Application (SPA). We were using “cutting-edge” libraries for client-side templating and other bits; we also wrote our own client-side router.

The administration system we were building didn’t need to consider SEO, and only needed to work in Chrome. The application contained various CRUD interfaces with a few rich interactions around it sich as drag and drop and sorting

See original post

Categories
Uncategorized

The boring front-end developer

Cool front-end developers are always pushing the envelope, jumping out of their seat to use the latest and greatest and shiniest of UI frameworks and libraries.

They’re often found bridging the gap between native apps and web and so will strive to make the UI look and behave like an app. Which app? you may ask. iPhone? Android? What version? All good questions, alas another topic altogether.

However, there’s another kind of front-end developer, the boring front-end developer. Here’s an ode to the boring front-end developer, BFED if you will.

# Browser support

The BFED realises that while not all

See original post