Tags: collaboration



How To Become A Centaur

We hoped for a bicycle for the mind; we got a Lazy Boy recliner for the mind.

Nicky Case on how Douglas Engelbart’s vision for human-computer augmentation has taken a turn from creation to consumption.

When you create a Human+AI team, the hard part isn’t the “AI”. It isn’t even the “Human”.

It’s the “+”.

Australian Government Open Language for Design

The design system for the Australian government is a work in progress but it looks very impressive. The components are nicely organised and documented.

(I’ve contributed a suggestion for the documentation in line with what I wrote about recently.)

The People Part of Design Systems – Related Works – Medium

I like the idea of “design bugs”:

Every two weeks or so, a group of designers would get together for a couple of hours to fix what we called “design bugs.” These were things that didn’t hinder functionality and wouldn’t have been filed as an engineering bug, but were places where we were using an old component, an existing one incorrectly, or a one-off alteration.

People and tooling | susan jean robertson

I can’t help but also wonder if we’re using tools to solve problems they weren’t meant to solve, like how to communicate with or manage a team.

Hypertext and Our Collective Destiny

The text of a fascinating talk given by Tim Berners-Lee back in 1995, at a gathering to mark the 50th anniversary of Vannevar Bush’s amazing article As We May Think. The event also drew together Ted Nelson, Alan Kay, Douglas Engelbart, and Bob Kahn!

Thanks to Teodara Petkova for pointing to this via the marvellous Web History Community Group.

Teletype for Atom

A plug-in that lets multiple people collaborate on the same document in Atom. Could be useful for hackdays and workshops.

Relative Requirements – CSS Wizardry

I really like this exercise by Harry. I’ve done similar kinds of grading using dot-voting in the past. It feels like an early step to establishing design principles: “this over that.”

By deciding what we value up-front, we have an agreement that we can look back on in order to help us settle these conflicts and get us back on track again.

Relative Requirements remove the personal aspect of these disagreements and instead focuses on more objective agreements that we made as a team.

Design Systems | susan jean robertson

Susan reviews Alla’s superb book on design systems:

If you’re interested in or wanting to create a design system or improve the one you have or get buy in to take your side project at work and make it part of the normal work flow, read this book. And even better, get your colleagues to do the same, so you’ll have a shared understanding before you begin the hard work to build your own system.

Susan also published her highlights from the book. I really like that!

Is there any value in people who cannot write JavaScript?

When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.

I couldn’t agree more.

Teaching and Brainstorming Inclusive Technical Metaphors - Features - Source: An OpenNews project

Some great ideas here about using metaphors when explaining technical topics.

I really like these four guidelines for good metaphors:

  • Complete
  • Memorable
  • Inclusive
  • Accessible

Evaluating Technology | Calum Ryan

Calum’s write-up of the workshop I ran in Nuremberg last week.

Back to the Cave – Frank Chimero

Frank has published the (beautifully designed) text of his closing XOXO keynote.

Kiss My Classname - Zeldman on Web & Interaction Design

I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.

Rogue One: an ‘Engineering Ethics’ Story — SciFi Policy

This article examines what I thought was the most interesting aspect of Rogue One—the ethical implications for technologists.

Don’t dismiss this essay just because it’s about a Hollywood blockbuster. Given the current political situation, this is deeply relevant.

On Style Maintenance | CSS-Tricks

This is a very thoughtful analysis of different approaches to writing maintainable CSS, which—let’s face it—is the hard bit.

I often joke that I don’t want to hire a code ninja. Ninjas come in the middle of the night and leave a bloody mess.

I want a code janitor. Someone who walks the hallways of code, cleaning up pieces, dusting up neglected parts, shinning up others, tossing unnecessary bits. I prefer this gentler, more accurate analogy. This is the person you want on your team. This is a person you want in your code reviews.

Also, can I just say how refreshing it is to read an article that doesn’t treat the cascade like a disease to be wiped out? This article even goes so far as to suggest that the cascade might actually be a feature—shock! horror!

The cascade can help, if you understand and organize it. This is the same as any sophisticated software design. You can look at what you’re building and make responsible decisions on your build and design. You decide what can be at a top-level and needs to be inherited by other, smaller, pieces.

There’s a lot of really good stuff in here to mull over.

My hope for this article is to encourage developers to think ahead. We’re all in this together, and the best we can do is learn from one another.

Science and Culture: The value of a good science hack

The story of Science Hack Day …as told in the Proceedings of the National Academy of Sciences of the United States of America!

(a PDF version is also available)

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.

The Foundation of Technical Leadership · An A List Apart Article

Story of my life:

I have to confess I had no idea what a technical leader really does. I figured it out, eventually.

Seriously, this resonates a lot with what I find myself doing at Clearleft these days.

It’s ok to say what’s ok | Government Digital Service

I really like this list. I might make a similar one for the Clearleft office so what’s implicit is made explicit.

It’s ok to:

  • say “I don’t know”
  • ask for more clarity
  • stay at home when you feel ill
  • say you don’t understand
  • ask what acronyms stand for
  • ask why, and why not
  • forget things

Tim Brown: Making time to read

I know exactly how Tim feels. It’s hard not to feel guilty when you’re reading something instead of spending the time doing “real work”, but it always ends up being time well spent:

Reading time can be hard to justify, even to oneself. There is no deadline. It’s not going to move any immediate projects forward (most likely). And it often feels like a waste of time, especially if your interests are diverse. But it’s important. Most great work is the product of collaborative thinking.