Tags: clients

11

sparkline

Tuesday, November 19th, 2019

Mental models

I’ve found that the older I get, the less I care about looking stupid. This is remarkably freeing. I no longer have any hesitancy about raising my hand in a meeting to ask “What’s that acronym you just mentioned?” This sometimes has the added benefit of clarifying something for others in the room who might have been to shy to ask.

I remember a few years back being really confused about npm. Fortunately, someone who was working at npm at the time came to Brighton for FFConf, so I asked them to explain it to me.

As I understood it, npm was intended to be used for managing packages of code for Node. Wasn’t it actually called “Node Package Manager” at one point, or did I imagine that?

Anyway, the mental model I had of npm was: npm is to Node as PEAR is to PHP. A central repository of open source code projects that you could easily add to your codebase …for your server-side code.

But then I saw people talking about using npm to manage client-side JavaScript. That really confused me. That’s why I was asking for clarification.

It turns out that my confusion was somewhat warranted. The npm project had indeed started life as a repo for server-side code but had since expanded to encompass client-side code too.

I understand how it happened, but it confirmed a worrying trend I had noticed. Developers were writing front-end code as though it were back-end code.

On the one hand, that makes total sense when you consider that the code is literally in the same programming language: JavaScript.

On the other hand, it makes no sense at all! If your code’s run-time is on the server, then the size of the codebase doesn’t matter that much. Whether it’s hundreds or thousands of lines of code, the execution happens more or less independentally of the network. But that’s not how front-end development works. Every byte matters. The more code you write that needs to be executed on the user’s device, the worse the experience is for that user. You need to limit how much you’re using the network. That means leaning on what the browser gives you by default (that’s your run-time environment) and keeping your code as lean as possible.

Dave echoes my concerns in his end-of-the-year piece called The Kind of Development I Like:

I now think about npm and wonder if it’s somewhat responsible for some of the pain points of modern web development today. Fact is, npm is a server-side technology that we’ve co-opted on the client and I think we’re feeling those repercussions in the browser.

Writing back-end and writing front-end code require very different approaches, in my opinion. But those differences have been erased in “modern” JavaScript.

The Unix Philosophy encourages us to write small micro libraries that do one thing and do it well. The Node.js Ecosystem did this in spades. This works great on the server where importing a small file has a very small cost. On the client, however, this has enormous costs.

In a funny way, this situation reminds me of something I saw happening over twenty years ago. Print designers were starting to do web design. They had a wealth of experience and knowledge around colour theory, typography, hierarchy and contrast. That was all very valuable to bring to the world of the web. But the web also has fundamental differences to print design. In print, you can use as many typefaces as you want, whereas on the web, to this day, you need to be judicious in the range of fonts you use. But in print, you might have to limit your colour palette for cost reasons (depending on the printing process), whereas on the web, colours are basically free. And then there’s the biggest difference of all: working within known dimensions of a fixed page in print compared to working within the unknowable dimensions of flexible viewports on the web.

Fast forward to today and we’ve got a lot of Computer Science graduates moving into front-end development. They’re bringing with them a treasure trove of experience in writing robust scalable code. But web browsers aren’t like web servers. If your back-end code is getting so big that it’s starting to run noticably slowly, you can throw more computing power at it by scaling up your server. That’s not an option on the front-end where you don’t really have one run-time environment—your end users have their own run-time environment with its own constraints around computing power and network connectivity.

That’s a very, very challenging world to get your head around. The safer option is to stick to the mental model you’re familiar with, whether you’re a print designer or a Computer Science graduate. But that does a disservice to end users who are relying on you to deliver a good experience on the World Wide Web.

Thursday, October 3rd, 2019

Blog service workers and the chicken and the egg

This is a great little technique from Remy: when a service worker is being installed, you make sure that the page(s) the user is first visiting get added to a cache.

Wednesday, July 5th, 2017

Is it really safe to start using CSS Grid Layout?

Rachel uncovers a great phrase for dealing with older browsers:

It isn’t your fault, but it is your problem.

She points to multiple ways of using CSS Grid today while still providing a decent experience for older browsers.

Crucially, there’s one message that hasn’t changed in fifteen years:

Websites do not need to look the same in every browser.

It’s crazy that there are still designers and developers who haven’t internalised this. And before anyone starts claiming that the problem is with the clients and the bosses, Rachel has plenty of advice for talking with them too.

Your job is to learn about new things, and advise your client or your boss in the best way to achieve their business goals through your use of the available technology. You can only do that if you have learned about the new things. You can then advise them which compromises are worth making.

Friday, February 1st, 2013

“The Post-PSD Era: A problem of expectations,” an article by Dan Mall

I really like Dan’s take on using Photoshop (or Fireworks) as part of today’s web design process. The problem is not with the tool; the problem is with the expectations set by showing comps to clients.

By default, presenting a full comp says to your client, “This is how everyone will see your site.” In our multi-device world, we’re quickly moving towards, “This is how some people will see your site,” but we’re not doing a great job of communicating that.

Friday, September 28th, 2012

Friday, July 13th, 2012

Client/Agency Engagement is F*cked, Waterfall UX Design is a Symptom | disambiguity

Leisa nails it. The real stumbling block with trying to change the waterfall-esque nature of agency work (of which Clearleft has certainly been guilty) can be summed up in two words: sign off.

And from a client’s perspective, this emphasis on sign-off is completely understandable.

It takes a special kind of client to take the risk and develop the level of trust and integration required to work the way that Mr Popoff-Walker any many, many other inhabitants of agency world would like to work.

Friday, April 16th, 2010

Good Kickoff Meetings

The companion website to Kevin Hoffman's IA Summit talk, this is a hugely valuable resource for an often-overlooked part of the design process: the kick-off meeting.

Wednesday, November 25th, 2009

"It's like twitter. Except we charge people to use it."

This is just wonderful. "Please design a logo for me. With pie charts. For free."

Tuesday, October 30th, 2007

Make My Logo Bigger Cream

Just rub it on and watch it grow. Gauranteed to satisfy your client.

Friday, November 24th, 2006

National flags with client comments

It's funny because it's true.

Wednesday, December 14th, 2005