Tags: ratio

250

sparkline

Saturday, August 11th, 2018

Weft. — Ethan Marcotte

I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.

Friday, August 10th, 2018

Creating the “Perfect” CSS System – Gusto Design – Medium

This is great advice from Lindsay Grizzard—getting agreement is so much more important than personal preference when it comes to collaborating on a design system.

When starting a project, get developers onboard with your CSS, JS and even HTML conventions from the start. Meet early and often to discuss every library, framework, mental model, and gem you are interested in using and take feedback seriously. Simply put, if they absolutely hate BEM and refuse to write it, don’t use BEM.

It’s all about the people, people!

“Designer + Developer Workflow,” an article by Dan Mall

Dan compares the relationship between a designer and developer in the web world to the relationship between an art director and a copywriter in the ad world. He and Brad made a video to demonstrate how they collaborate.

Accessible Comics - Axess Lab

Nice! It sounds like Lucy and Andy went above and beyond the call of duty when it came to the alt text for 100 Demon Dialogues.

Monday, July 23rd, 2018

Astronomical Typography

Typography meets astronomy in 16th century books like the Astronomicum Caesareum.

It is arguably the most typographically impressive scientific manual of the sixteenth century. Owen Gingerich claimed it, “the most spectacular contribution of the book-maker’s art to sixteenth-century science.”

Friday, July 20th, 2018

What walls are for – disambiguity

Digital things look ‘finished’ too soon. When something is a work in progress on a wall, it looks unfinished, so you keep working on it. moving things around, reshaping things, connecting things, erasing things, and making them again. Walls make it easier to iterate. Iteration, in my opinion, is massively correlated with quality.

Tuesday, July 10th, 2018

Components and concerns

We tend to like false dichotomies in the world of web design and web development. I’ve noticed one recently that keeps coming up in the realm of design systems and components.

It’s about separation of concerns. The web has a long history of separating structure, presentation, and behaviour through HTML, CSS, and JavaScript. It has served us very well. If you build in that order, ensuring that something works (to some extent) before adding the next layer, the result will be robust and resilient.

But in this age of components, many people are pointing out that it makes sense to separate things according to their function. Here’s the Diana Mounter in her excellent article about design systems at Github:

Rather than separating concerns by languages (such as HTML, CSS, and JavaScript), we’re are working towards a model of separating concerns at the component level.

This echoes a point made previously in a slidedeck by Cristiano Rastelli.

Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?

There’s nothing in the “traditonal” separation of concerns on the web (HTML/CSS/JavaScript) that restricts it only to pages. In fact, I would say it works best when it’s applied on smaller scales.

In her article, Pattern Library First: An Approach For Managing CSS, Rachel advises starting every component with good markup:

Your starting point should always be well-structured markup.

This ensures that your content is accessible at a very basic level, but it also means you can take advantage of normal flow.

That’s basically an application of starting with the rule of least power.

In chapter 6 of Resilient Web Design, I outline the three-step process I use to build on the web:

  1. Identify core functionality.
  2. Make that functionality available using the simplest possible technology.
  3. Enhance!

That chapter is filled with examples of applying those steps at the level of an entire site or product, but it doesn’t need to end there:

We can apply the three‐step process at the scale of individual components within a page. “What is the core functionality of this component? How can I make that functionality available using the simplest possible technology? Now how can I enhance it?”

There’s another shared benefit to separating concerns when building pages and building components. In the case of pages, asking “what is the core functionality?” will help you come up with a good URL. With components, asking “what is the core functionality?” will help you come up with a good name …something that’s at the heart of a good design system. In her brilliant Design Systems book, Alla advocates asking “what is its purpose?” in order to get a good shared language for components.

My point is this:

  • Separating structure, presentation, and behaviour is a good idea.
  • Separating an interface into components is a good idea.

Those two good ideas are not in conflict. Presenting them as though they were binary choices is like saying “I used to eat Italian food, but now I drink Italian wine.” They work best when they’re done in combination.

Sunday, July 8th, 2018

BBC News on HTTPS – BBC Design + Engineering – Medium

BBC News has switched to HTTPS—hurrah!

Here, one of the engineers writes on Ev’s blog about the challenges involved. Personally, I think this is far more valuable and inspiring to read than the unempathetic posts claiming that switching to HTTPS is easy.

Update: Paul found the original URL for this …weird that they don’t link to it from the syndicated version.

Saturday, June 23rd, 2018

Manual Aspire

If only all documentation was as great as this old manual for the ZX Spectrum that Remy uncovered:

The manual is an instruction book on how to program the Spectrum. It’s a full book, with detailed directions and information on how the machine works, how the programming language works, includes human readable sentences explaining logic and even goes so far as touching on what hex values perform which assembly functions.

When we talk about things being “inspiring”, it’s rarely in regards to computer manuals. But, damn, if this isn’t inspiring!

This book stirs a passion inside of me that tells me that I can make something new from an existing thing. It reminds me of the 80s Lego boxes: unlike today’s Lego, the back of a Lego box would include pictures of creations that you could make with your Lego set. It didn’t include any instructions to do so, but it always made me think to myself: “I can make something more with these bricks”.

Sunday, June 17th, 2018

DesignOps Handbook - DesignBetter.Co

This looks like a really good (and free!) online book all about design ops.

(Alas, it is, once again, driven by janky JavaScript that makes it a bit of a chore to scroll and read.)

Friday, June 8th, 2018

Registering service workers

In chapter two of Going Offline, I talk about registering your service worker wrapped up in some feature detection:

<script>
if (navigator.serviceworker) {
  navigator.serviceworker.register('/serviceworker.js');
}
</script>

But I also make reference to a declarative way of doing this that isn’t very widely supported:

<link rel="serviceworker" href="/serviceworker.js">

No need for feature detection there. Thanks to the liberal error-handling model of HTML (and CSS), browsers will just ignore what they don’t understand, which isn’t the case with JavaScript.

Alas, it looks like that nice declarative alternative isn’t going to be making its way into browsers anytime soon. It has been removed from the HTML spec. That’s a shame. I have a preference for declarative solutions where possible—they’re certainly easier to teach. But in this case, the JavaScript alternative isn’t too onerous.

So if you’re reading Going Offline, when you get to the bit about someday using the rel value, you can cast a wistful gaze into the distance, or shed a tiny tear for what might have been …and then put it out of your mind and carry on reading.

Wednesday, May 30th, 2018

Solving Life’s Problems with CSS | CSS-Tricks

It turns out that Diana Smith isn’t just a genius with CSS—she’s a fantastic writer too. This post is somehow heartfelt and lighthearted at the same time. It’s also very humorous, but beneath the humour there’s an excellent point here about the rule of least power …and doing things the long, hard, stupid way.

Because something about those limitations just calls to me. I know I’m not alone when I say that a rigid set of restrictions is the best catalyst for creativity. Total artistic freedom can be a paralyzing concept.

That can sometimes be the case with programming. If you have the most powerful programming languages in the world at your disposal, it starts to seem natural that you should then have no difficulty solving any programming problem. With all these amazing tools offering countless solutions to solve the same problem, it’s no wonder that we sometimes freeze up with information overload.

Tuesday, May 29th, 2018

Superfan! — Sacha Judd

The transcript of a talk that is fantastic in every sense.

Fans are organised, motivated, creative, technical, and frankly flat-out awe-inspiring.

Consently - Privacy-friendly and GDPR compliant tracking

This looks very useful: a script that will allow visitors to tailor which tracking scripts they want to allow. Seems like a win-win to me: useful for developers, and useful for end users. A safe and sensible approach to GDPR.

Monday, May 21st, 2018

Architecting the uncertain - Getting started with Agile Software Architecture

Some ideas on the best of use of time in sprint zero of an agile project.

  • Understand your context
  • Identify risks
  • Understand the business process
  • Get testing infrastructure
  • Understand quality attributes
  • Get to know the people
  • Prepare an initial product backlog
  • Build a walking skeleton/spike
  • Build a learning backlog

Saturday, May 19th, 2018

Building and maintaining a design system | susan jean robertson

Susan writes about the challenges when trying to get widespread adoption of a design system. Spoiler: the challenges aren’t technical.

Change is hard. Communication and collaboration are absolutely necessary to make a system work. And the more people you can get involved from various disciplines the better chance you have of maintaining your system.

Friday, May 18th, 2018

Frustration

I had some problems with my bouzouki recently. Now, I know my bouzouki pretty well. I can navigate the strings and frets to make music. But this was a problem with the pickup under the saddle of the bouzouki’s bridge. So it wasn’t so much a musical problem as it was an electronics problem. I know nothing about electronics.

I found it incredibly frustrating. Not only did I have no idea how to fix the problem, but I also had no idea of the scope of the problem. Would it take five minutes or five days? Who knows? Not me.

My solution to a problem like this is to pay someone else to fix it. Even then I have to go through the process of having the problem explained to me by someone who understands and cares about electronics much more than me. I nod my head and try my best to look like I’m taking it all in, even though the truth is I have no particular desire to get to grips with the inner workings of pickups—I just want to make some music.

That feeling of frustration I get from having wiring issues with a musical instrument is the same feeling I get whenever something goes awry with my web server. I know just enough about servers to be dangerous. When something goes wrong, I feel very out of my depth, and again, I have no idea how long it will take the fix the problem: minutes, hours, days, or weeks.

I had a very bad day yesterday. I wanted to make a small change to the Clearleft website—one extra line of CSS. But the build process for the website is quite convoluted (and clever), automatically pulling in components from the site’s pattern library. Something somewhere in the pipeline went wrong—I still haven’t figured out what—and for a while there, the Clearleft website was down, thanks to me. (Luckily for me, Danielle saved the day …again. I’d be lost without her.)

I was feeling pretty down after that stressful day. I felt like an idiot for not knowing or understanding the wiring beneath the site.

But, on the other hand, considering I was only trying to edit a little bit of CSS, maybe the problem didn’t lie entirely with me.

There’s a principle underlying the architecture of the World Wide Web called The Rule of Least Power. It somewhat counterintuitively states that you should:

choose the least powerful language suitable for a given purpose.

Perhaps, given the relative simplicity of the task I was trying to accomplish, the plumbing was over-engineered. That complexity wouldn’t matter if I could circumvent it, but without the build process, there’s no way to change the markup, CSS, or JavaScript for the site.

Still, most of the time, the build process isn’t a hindrance, it’s a help: concatenation, minification, linting and all that good stuff. Most of my frustration when something in the wiring goes wrong is because of how it makes me feel …just like with the pickup in my bouzouki, or the server powering my website. It’s not just that I find this stuff hard, but that I also feel like it’s stuff I’m supposed to know, rather than stuff I want to know.

On that note…

Last week, Paul wrote about getting to grips with JavaScript. On the very same day, Brad wrote about his struggle to learn React.

I think it’s really, really, really great when people share their frustrations and struggles like this. It’s very reassuring for anyone else out there who’s feeling similarly frustrated who’s worried that the problem lies with them. Also, this kind of confessional feedback is absolute gold dust for anyone looking to write explanations or documentation for JavaScript or React while battling the curse of knowledge. As Paul says:

The challenge now is to remember the pain and anguish I endured, and bare that in mind when helping others find their own path through the knotted weeds of JavaScript.

Thursday, May 17th, 2018

I Played Fortnite and Figured Out the Universe - The Atlantic

Robin Sloan smushes the video game Fortnite Battle Royale together with Liu Cixin’s Three Body Problem trilogy and produces a perfect example of game theory, cooperation, and the prisoner’s dilemma.

Based on my experiments in the laboratory of Fortnite, I think Liu Cixin is wrong. Or at least, he’s not entirely right. Fortnite is more Dark Forest theory than not, and maybe that’s true of the universe, too. But sometimes, we have a lever against the vise of game theory, and in this case, it is a single bit of communication. I mean “bit” in the programmer’s sense: a flag with a designated meaning. Nothing more. My heart emote didn’t make Fortnite cuddly and collaborative, but it did allow me to communicate: “Hold up. Let’s do this a different way.”

Monday, May 7th, 2018

Pair Programming

Amber gave a lightning talk about pair programming at the Beyond Tellerrand Düsseldorf side event. Here is the transcript of that presentation.

The fact that everyone has different personalities, means pairing with others shouldn’t be forced upon anyone, and even if people do pair, there is no set time limit or a set way to do so.

So, there’s no roadmap. There’s no step-by-step guide in a readme file to successfully install pair programming

Monday, April 30th, 2018

Apart From Code

A good developer…

  • debugs
  • follows the KISS principle (and respects YAGNI)
  • knows how to research
  • works well with others
  • finds good developer tools
  • tests code