distributed collective mind
443 stories
·
4 followers

EmacsCast 6 - Back to basics

1 Share

You can now support EmacsCast on Patreon! There are perks and this wonderful feeling of helping the project you like :-)

News

Back to basics





Download audio: https://pinecast.com/listen/b9163c23-00a6-4766-ac23-deb6ea70c565.mp3?source=rss&ext=asset.mp3
Read the whole story
sness
2 days ago
reply
milky way
Share this story
Delete

Writing for Designers

1 Comment

A note from the editors: We’re pleased to share an excerpt from the Introduction of Scott Kubie’s Writing for Designers, from A Book Apart.

Shit. The writing. We forgot about the writing. The thing, the design thing…it needs words! Oh man, so many words. I thought somebody…wasn’t the client going to…shit. We’ve got to get the writing done. We’ve got to get the writing done! How are we going to get the writing done?!

Don’t worry, friend. I’m here. We’ll get the writing done. The first step is to accept a hard truth: someone has to do the writing.

Some teams seem to build their whole process around not writing. They fill wireframes with lorem ipsum (that fake Latin text that confuses stakeholders) and write CTA goes here on their buttons. I’ve been handed my share of comps where anything remotely word-based was represented by a bunch of squiggly lines.

You know that comic about how to draw an owl? Step one: draw some circles. Step two: draw the rest of the fucking owl. That’s you with your squiggly lines. Rude.

Everything left unwritten is a mystery box of incomplete design. These mysteries beget other mysteries, and pretty soon you’ve got dozens of screens of things that kinda-sorta-maybe make sense but none of them can really be final because you never wrote the words.

Choosing words and writing what appears in an interface forces us to name components, articulate choices, and explain things to the user. It’s part of design.

We know this, don’t we? We knew it at the beginning of the design project, and yet here we are. Why did we wait?

Writing is part of design

Words are one of the most powerful design materials available. They convey deeply complex meanings in a compact space. They load fast. They’re easy to manipulate and easy to transmit. And the best part is, you don’t have to invent any of them! You just have to use them.

Sometimes words get written off (see what I did there) as mere “details” in our designs. True details can wait until the end of your design process. Words, however, are deeply integrated throughout the user’s experience of your design. Look at your favorite app, site, or interface. Take all the words away and what do you have? Not much!

Even if the particular thing you’re designing seems light on words, take a broader view and you’ll find words hiding everywhere:

  • error messages and recovery flows
  • confirmation screens
  • user-visible metadata like page titles and search engine descriptions
  • transactional emails
  • in-app user assistance
  • support documentation
  • changelogs
  • feature descriptions and marketing copy

These are as much a part of the design as the layout, graphics, and animations. Designs depend on words.

Even if your design were simple, beautiful, and intuitive, writing can take it one step further. Writing can reinforce how you want users to think about your design. Writing can explain the approach or philosophy that underpins your design. Writing can guide users through complex processes. Writing can even help cover for the quirks and compromises in our designs—hopefully not our first resort, but valuable nonetheless.

Sometimes the writing isn’t done because we’re trying to solve everything with “pure design.” Supposed UX thought leaders throw around baloney like “Good design doesn’t need explanation” and “If you have to use words, you’ve failed.” Come on. I hope my pilot knows what all those switches in the cockpit do, but I also hope they’re labeled, just in case.

To keep things simple in this book, we’ll be talking about three general categories of writing you might have to do to support your design work:

  • Interface copy: Often referred to as UI copy or microcopy, this is the text that’s deeply integrated within the interface, like labels for form fields, text on buttons, navigation labels on a website, error messages, and similar. It’s often made of single words or short phrases. If the interface would “break” or be extremely hard to use if you removed this text, we’ll call it interface copy.
  • Product copy: Writing that’s integral to the function of the site/product/app/experience, but not necessarily a direct part of the interface—the body of an onboarding email, for instance, or a description of updates to an application in a changelog. This is content focused on helping/supporting the reader.
  • Marketing copy: Longer-form writing that is primarily filling a sales or promotional sort of role. This is content focused on persuading the reader.

Depending on your product and organization, you might have many more buckets of content, or you may find the lines especially blurry even between these three. That’s okay! These buckets will just make things easier while we talk about writing in this book. Cool? Cool.

(Oh, and “copy” is just a way to distinguish words written by a designer from the more generic idea of “text,” which could be just about anything in your system, including user-generated input.)

Writing is always hard

If you know someone who makes writing look easy, you’re right. They make it look easy. You can’t plan well for a difficult journey if you assume it’s going to be an easy journey. Accepting that writing is hard is an important step toward making it easier and getting it done.

Writing is hard because it’s personal. Even if you’re writing about something you don’t feel strongly about, or even something you disagree with, it’s still your writing. The words you write carry a little echo of you. To get the writing done, you’re going to have to be a little vulnerable. Maybe a lot.

Writing is even hard for writers—and since most people don’t realize that, they make it even harder on writers. They don’t give writers enough time to write. They don’t provide enough information to work with. They say things that minimize the difficulty of the task and the skill required to complete it. “You’re so creative! This should be easy, right? Shoot me something back before lunch.” Ugh.

Unfortunately, there’s no special potion you can take to help you get the writing done, and even the most beautifully retro hipster typewriter still needs you to operate the keys.

Workflow gets the writing done

So if magic won’t help you get the writing done, what will? In design contexts, a useful way to think about writing is workflow. Workflow is a big-picture idea that accommodates all kinds of different processes, techniques, and tools.

If following a recipe is a process, making dinner is a workflow. A dinner-making workflow has obvious phases—plan the meal, prep the ingredients, mix and cook things, finish and serve the meal. The specific steps and outcomes vary depending on the meal, but the basic workflow remains the same.

This is also a useful way to think about design writing. No matter what you’re cooking up—no matter how custom the request and how many dietary restrictions your stakeholders might have—you’ll follow the same basic workflow each time you do the writing:

  1. Prepare (to write)
  2. Compose (the words)
  3. Edit (what you wrote)
  4. Finish (the damn writing)

Planning your workflow means choosing the tools, techniques, people, and processes that will be part of each of these four phases. Until this framework becomes old hat, I recommend explicitly planning your writing workflow. Planning is how you avoid getting stuck. You might not immediately know every single tool, step, and person you’ll need to get the writing done. But knowing even a few things, and giving yourself a basic map to follow to get the writing done, will help you learn what’s missing.

Planning your workflow doesn’t need to be a long process—or even something you share with other people. You can create a formal, structured worksheet to plan it out (Fig 0.1), you could sketch it out on a whiteboard or in a notebook (Fig 0.2), or simply make some notes at the top of a new document. The important thing is to think about how you’re going to get the writing done before you start writing.

An example of a structured worksheet with the assignment and writer details at the top, and space to add details for preparation, composition, editing, and finishing including tools, steps, processes, and more.
Fig 0.1: A structured worksheet can help you plan your writing workflow before you start, and serve as an anchor in the storm throughout the project. If you go this route, I recommend customizing it to suit the particulars of your organization.
A simpler example of a simpler workflow with four quadrants for preparation, composition, editing, and finishing handwritten on a piece of paper.

Fig 0.2: Planning your workflow on paper doesn’t have to take long, and it’s a nice break from staring at screens. Plus, you can cross things off as you go! (Always satisfying.)

You can write

Mr. Hays, my high school choir teacher, was a great recruiter. When he’d ask people to try out for choir, they’d protest with some version of “Oh, no, I can’t sing.” Nonsense, he’d say: “If you can talk, you can sing. It’s all the same muscles!” And, more often than not, he’d pull that student right over to a piano and demonstrate to them that they could, in fact, sing.

In case you’re skeptical, worried, or unsure about whether or not you can handle this, here’s my pitch for writing: writing is just thinking plus typing. You can think. You can type (or otherwise get text into a computer). So yes, you can write.

We’re going to get into all kinds of methods about how to compose and refine text throughout this book. But at the end of the day, writing is just thinking plus typing. Have some thoughts in your head, then write them down. Do this over and over until the writing is done. Every other tip, trick, method, and process is just an improvement or distillation of this basic approach.

And more good news: writing is more like design than you might think. Common design activities like framing the problem, identifying constraints, and exploring solutions are part of writing, too. Many of the methodologies one might use in UX work can be part of a writing workflow: stakeholder interviews, user research, content auditing, ideation workshops, critiques, and more.

Writing is always hard, yes. But it gets easier.

Good? Good. We’re making progress already. It’s time to Prepare.

Read the whole story
sness
4 days ago
reply
+1
milky way
Share this story
Delete

String Theorists' Heads Bobble Over Potential Dark Energy Wobble

1 Share

Harvard physicist Cumrun Vafa is one of string theory’s strongest proponents. But this summer, other string theorists have been reeling from his latest conjecture, which might invalidate their ideas built on a decade-long assumption that dark energy is constant. Vafa’s work implies that dark energy’s value changes.

Read more...

Read the whole story
sness
12 days ago
reply
milky way
Share this story
Delete

We Need A Red Box

1 Share

“Wanting to combat the cultural taboos against criticizing management, Toyota’s leaders painted a big red square on the assembly line floor. New employees had to stand in it at the end of their first week, and they were not allowed to leave until they had criticized at least three things on the line. The continual improvement this practice spawned was part of Toyota’s success. I asked my team what they thought: did we need a red box?”
– Kim Scott

From the book Radical Candor

Read the whole story
sness
15 days ago
reply
milky way
Share this story
Delete

Getting Started with the Prettier Plugin for ESLint

1 Share

If you’ve ever had to edit a project before (yours or someone else’s), you’ve definitely thought at some point: “What am I even looking at?”

Enter Prettier, the new tool to transform the way we code. Once I got the hang of Prettier, it’s hard to imagine not including it in all future projects.

I wanted to write an article that I wish I had when I was flipping through multiple browser tabs trying to figure it out. In this tutorial, I’ll be using the Prettier plugin for ESLint.

What is Prettier?

Prettier is an opinionated code formatter. It enforces a consistent style by parsing your code and reprinting it with its own rules, like adding semicolons and wrapping code. Prettier doesn’t care what you think your code should look like. All it cares about are the default and declared rules, and makes your code conform to those sets of rules.

There are a couple of ways of integrating Prettier and ESLint into your workflow. I’m going to show you the process that made the most sense to me, which is installing Prettier as an ESLint plugin. At the end of this tutorial, your code will be consistent, clean, and easy to read. Let’s get started.

Installing the Prettier Plugin

Once you’ve installed ESLint, you can install the Prettier plugin called eslint-plugin-prettier, and it works for all code editors. This plugin runs Prettier as an ESLint rule and reports differences as individual ESLint issues.

Start by adding Prettier as an ESLint rule using this first command in the terminal, followed by installing Prettier itself.

npm install --save-dev eslint-plugin-prettier

npm install --save-dev --save-exact prettier

Once those are finished installing, add the following snippet to your .eslintrc.* file. The .eslintrc.* file is a where ESLint can be configured, you can learn about ESLint configuration here. You may need to create this file.

{
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": "error"
 }
}

You probably don’t want to hear the same formatting issue twice from Prettier and ESLint. There is a solution to this! You can disable conflict rules (while keeping rules Prettier doesn’t care about). The easiest way of doing this is to use eslint-config-prettier. This turns off all active rules that might conflict with Prettier or are unnecessary:

npm install --save-dev eslint-config-prettier

Then, add eslint-config-prettier to the “extends” array in your .eslintrc.* file, you can use the “recommended” configuration. When doing this, make sure that it goes last, so it can override other configurations. It should look something like this when you are finished:

{
    "plugins": [
        "prettier"
    ],
    "rules": {
        "prettier/prettier": "error"
    },
    "extends": [
        "plugin:prettier/recommended"
    ]
}

That’s it for installation. Now you can define your own rules and override the default ones if you choose to. Prettier has also been kind enough to include a page of customizable format options. Should you decide to change the rules that Prettier follows, you can do so by creating a .prettierrc.* file and adding them there. You may have to create this as well. Here is an example:

{
    "singleQuote": true,
    "tabWidth": 2
}

Another way you can set parameters for Prettier is in a package.* file. Whether you’re putting your configurations in a .prettierrc.*, or a package.* file, ESLint will look for and read automatically, or you can specify a configuration file on the command line. In the package.* file, it will look something like this:

{
  "name": "cool_stuff",
  "version": "0.0.1",
  "description": "",
  "main": "index.js",
  "scripts": {
    "build": "npm gulp build",
    "serve": "npm gulp",
    "start": "npm install && npm run serve",
    "check-lint": "prettier --list-different '**/*.js' && eslint '**/*.js'",
    "lint": "prettier --write '**/*.js' && eslint --fix '**/*.js'"
  },
  "prettier": {
    "singleQuote": true
  }
}

Please note, Prettier is well known for its “format-on-save” feature. With some code editors, this is on by default, but it is different depending on the editor you are using. Check your code editors settings and toggle it on or off for whatever you’d like.

Prettier combined with ESLint make a powerful duo, I hope I was able to successfully make the process as easy to follow as possible. Happy coding!

Read the whole story
sness
18 days ago
reply
milky way
Share this story
Delete

Dolphins

1 Comment

Dolphins

And more intelligence.

Read the whole story
sness
19 days ago
reply
weeawu
milky way
Share this story
Delete
Next Page of Stories