Tags: principles

63

sparkline

Wednesday, September 6th, 2017

The Law of Least Power and Defunct StackOverflow Answers - Web Directions

I love John’s long-zoom look at web development. Step back far enough and you can start to see the cycles repeating.

Underneath all of these patterns and practices and frameworks and libraries are core technologies. And underlying principles.

These are foundations – technological, and of practice – that we ignore, overlook, or flaunt at our peril.

Sunday, August 20th, 2017

The Nine Principles Of Design Implementation – Smashing Magazine

I like this list:

This is not a checklist. Instead, it is a set of broad guidelines meant to preserve an underlying value. It can be used as a guide for someone working on implementation or as a tool to evaluate an existing project.

I’ve added them to my collection of design principles.

Sunday, August 6th, 2017

Another Lens - News Deeply x Airbnb.Design

A series of questions to ask on any design project:

  • What are my lenses?
  • Am I just confirming my assumptions, or am I challenging them?
  • What details here are unfair? Unverified? Unused?
  • Am I holding onto something that I need to let go of?
  • What’s here that I designed for me? What’s here that I designed for other people?
  • What would the world look like if my assumptions were wrong?
  • Who might disagree with what I’m designing?
  • Who might be impacted by what I’m designing?
  • What do I believe?
  • Who’s someone I’m nervous to talk to about this?
  • Is my audience open to change?
  • What am I challenging as I create this?
  • How can I reframe a mistake in a way that helps me learn?
  • How does my approach to this problem today compare to how I might have approached this one year ago?
  • If I could learn one thing to help me on this project, what would that one thing be?
  • Do I need to slow down?

Thursday, June 22nd, 2017

And now, a brief definition of the web - The Verge

Analysing what the web is. It’s not the technology stack.

To count as being part of the web, your app or page must:

  1. Be linkable, and
  2. Allow any client to access it.

I think that’s a pretty good definition.

Mind you, I think this is a bit rich in an article published on The Verge:

The HTML web may be slow and annoying and processor intensive, but before we rush too fast into replacing it, let’s not lose what’s good about it.

Excuse me? Slow, annoying, processor-intensive web pages have nothing to do with the technology, and everything to do with publishers like The Verge shoving bucketloads of intrusive JavaScript trackers into every page view.

Still, we can agree on this:

Preserving the web, or more specifically the open principles behind it, means protecting one of the few paths for innovation left in the modern tech world that doesn’t have a giant company acting as a gatekeeper.

Friday, June 9th, 2017

Inclusive Design Principles

I’ve added these to my collection of design principles:

  • Provide comparable experience
  • Consider situation
  • Be consistent
  • Give control
  • Offer choice
  • Prioritise content
  • Add value

Monday, June 5th, 2017

eLife goes live

The World Wide Web was forged in the crucible of science. Tim Berners-Lee was working at CERN, the European Centre for Nuclear Research, a remarkable place where the pursuit of knowledge—rather than the pursuit of profit—is the driving force.

I often wonder whether the web as we know it—an open, decentralised system—could’ve been born anywhere else. These days it’s easy to focus on the success stories of the web in the worlds of commerce and social networking, but I still find there’s something that really “clicks” with the web and the science (Zooniverse being a classic example).

At Clearleft we’ve been lucky enough to work on science-driven projects like the Wellcome Library and the Wellcome Trust. It’s incredibly rewarding to work on projects where the bottom line is measured in knowledge-sharing rather than moolah. So when we were approached by eLife to help them with an upcoming redesign, we jumped at the chance.

We usually help organisations through our expertise in user-centred design, but in this case the design and UX were already in hand. The challenge was in the implementation. The team at eLife knew that they wanted a modular pattern library to keep their front-end components documented and easily reusable. Given Clearleft’s extensive experience with building pattern libraries, this was a match made in heaven (or whatever the scientific non-theistic equivalent of heaven is).

A group of us travelled up from Brighton to Cambridge to kick things off with a workshop. Before diving into code, it was important to set out the aims for the redesign, and figure out how a pattern library could best support those aims.

Right away, I was struck by the great working relationship between design and front-end development within eLife—there was a great collaborative spirit to the endeavour.

Some goals for the redesign soon emerged:

  • Promote the HTML reading experience as a 1st choice for readers.
  • Align the online experience with the eLife visual identity.

That led to some design principles:

  • Focus on content not site furniture.
  • Remove visual clutter and provide no more than the user needs at any stage of the experience.
  • Aid discovery of value added content beyond the manuscript.

Those design principles then informed the front-end development process. Together we came up with a priority of concerns:

  1. Access
  2. Maintainability
  3. Performance
  4. Taking advantage of browser capabilities
  5. Visual appeal

It’s interesting that maintainability was such a high priority that it superseded even performance, but we also proposed a hypothesis at the same time:

Maintainability doesn’t negatively impact performance.

The combination of the design principles and priorities led us to formulate approaches that could be used throughout the project:

  • Progressive enhancement.
  • Small-screen first responsive images.
  • Only add libraries as needed.

Then we dived into the tech stack: build tools, version control approaches, and naming methodologies. BEM was the winner there.

None of those decisions were set in stone, but they really helped to build a solid foundation for the work ahead. Graham camped out in Cambridge for a while, embedding himself in the team there as they began the process of identifying, naming, and building the components.

The work continued after Clearleft’s involvement wrapped up, and I’m happy to say that it all paid off. The new eLife site has just gone live. It’s looking—and performing—beautifully.

What a great combination: the best of the web and the best of science!

eLife is a non-profit organisation inspired by research funders and led by scientists. Our mission is to help scientists accelerate discovery by operating a platform for research communication that encourages and recognises the most responsible behaviours in science.

Tuesday, March 14th, 2017

Take a closer look at the patterns in our language. | Clearleft

Ellen goes through the principles behind the tone of voice on the new Clearleft site:

  1. Our clients are the heroes and heroines, we facilitate their journey.
  2. Speak as an individual doing whatever it is you love. Expose lovable details.
  3. Use the imperative, kill the “-ing”.
  4. Be evocative and paint the picture. Show don’t tell.
  5. Be a practical friend.
  6. Be inquisitive. Ask smart questions that need solving.

Thursday, February 16th, 2017

Principles of Web Development · Jens Oliver Meiert

Some proposed design principles for web developers:

  1. Focus on the User
  2. Focus on Quality
  3. Keep It Simple
  4. Think Long-Term (and Beware of Fads)
  5. Don’t Repeat Yourself (aka One Cannot Not Maintain)
  6. Code Responsibly
  7. Know Your Field

Monday, December 19th, 2016

BAgel

The styleguide, design principles, and pattern library for British Airways. It’s the “global experience language” for BA …so it’s called BAgel.

Thursday, December 15th, 2016

Design principles

Andrew Travers wrote about designing design principles at Co-op Digital. I’m somewhat obsessed with design principles—hence my collection—so I’m also obsessed with figuring out what makes for “good” design principles.

One of my favourite design principles (yes, I have favourites) is from the HTML Design Principles. It’s the priority of constituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

The emphasis my own. It demonstrates how the design principle can be put to use (“in case of conflict”). Andrew also describes uses for the design principles they’re putting together:

What we’re building towards is a set of principles, few enough to be memorable, short enough to be repeatable, relevant enough to be usable. When we’re running a design crit, it’s these principles that we want to lean on. When a sole designer in an agile delivery team is talking about a design approach, it’s these principles that back her up.

Those sound like good use cases to me. Those are situations when design principles can help people reach agreement on priorities, without it having to be about ego or who shouts loudest.

I think it was from Cennydd that I heard about a really good test of a design principle: is it reversible? In other words, could you imagine the exact opposite of the design principle being perfectly valid in a different organisation or on a different project? If not, then the principle may be too weak to be effective. (Cennydd points out that he heard this from Jared who has written a lot about evaluating design principles.)

“Make it easy to use” would be an example of a weak design principle. It’s hard to imagine a situation where “make it hard to use” would be a reasonable guiding principle.

Frankly, there are plenty of “bad” examples in my collection of design principles. Many of them wouldn’t pass the reversibility test. Just recently though, I spotted some that would pass the test with flying colours. They weren’t even labelled as design principles—they’re the tips that Heydon includes at the end of his excellent 24 Ways article on inclusive design:

  • Involve code early
  • Respect conventions
  • Don’t be exact
  • Enforce simplicity

I could easily imagine endeavours where the complete opposite of those tips would be valued. Personally, I think they’re really great design princples.

I should add them to the list.

Thursday, December 8th, 2016

What the Heck Is Inclusive Design? ◆ 24 ways

I really, really like Heydon’s framing of inclusive design: yes, it covers accessibility, but it’s more than that, and it’s subtly different to universal design.

He also includes some tips which read like design principles to me:

  • Involve code early
  • Respect conventions
  • Don’t be exact
  • Enforce simplicity

Come to think of it, they’re really good design principles in that they are all reversible i.e. you could imagine the polar opposites being design principles elsewhere.

Monday, July 25th, 2016

AMP Design Principles

These design principles are meant to guide the ongoing design and development of AMP. They should help us make internally consistent decisions.

I’ve added these to my collection of design principles.

Thursday, July 21st, 2016

Qualities of Successful Pattern Libraries: Pick Any Two - Cloud Four

I think Tyler’s onto something here:

I noticed three qualities that recurred in different combinations. Without at least two, the projects seemed doomed to failure.

  1. User-Friendly
  2. Collaborative
  3. Integrated

I certainly think there’s a difference in how you approach a pattern library intended as a deliverable (something we do a lot of at Clearleft) compared to building a pattern library for an ongoing ever-evolving product.

Tuesday, May 31st, 2016

DRY: Do Repeat Yourself - QuirksBlog

Y’know, I think PPK might be on to something here. It’s certainly true that developers have such an eversion to solving a problem twice that some users end up paying the cost (like in the examples of progressive enhancement here).

I will be pondering upon this.

Tuesday, May 17th, 2016

Design systems and Postel’s law | Journal | The Personal Disquiet of Mark Boulton

Marvellous insights from Mark on how the robustness principle can and should be applied to styeguides and pattern libraries (‘sfunny—I was talking about Postel’s Law just this morning at An Event Apart in Boston).

Being liberal in accepting things into the system, and being liberal about how you go about that, ensures you don’t police the system. You collaborate on it.

So, what about the output? Remember: be ’conservative in what you do’. For a design system, this means your output of the system – guidelines, principles, design patterns, code, etc etc. – needs to be clear, unambiguous, and understandable.

Monday, February 29th, 2016

The New Web Typography › Robin Rendle

A wonderfully thoughtful piece on typography, Jan Tschichold and the web. This really resonated with me:

It’s only been over the past year or so in which I’ve recognised myself as a ‘Web designer’ with a capital W, as I now believe that something happens to information and technology, and even typography itself, when people pass through these interconnected networks and interact with hypertext.

It’s for these reasons that I don’t believe in “digital design” or “designing for screens” and it’s why I’m often attracted to one particular side of this spectrum.

Robin proposes three “principles, suggestions, outlines, or rather things-that-I-ought-to-be nervous-about when setting text on the web”:

  1. We must prioritise the text over the font, or semantics over style.
  2. We ought to use and/or make tools that reveal the consequences of typographic decisions.
  3. We should acknowledge that web typography is only as strong as its weakest point.

There’s an in-depth look at applying progressive enhancement to web type, and every single link in the resources section at the end is worth investigating.

Oh, and of course it’s beautifully typeset.

Friday, February 12th, 2016

Ethical Web Development

I really, really like these principles. Time to add them to the list.

Tuesday, October 13th, 2015

BBC iWonder - Who made the web so hard to control?

A great little primer on the origins of the internet and the web, by Aleks.

Wednesday, August 26th, 2015

Saturday, June 20th, 2015

Paul Robert Lloyd | Responsive Principles | CSS Day on Vimeo

I really like the way that Paul’s talk builds on top of ideas laid down by Ethan and Frank. Good stuff.