[ { "slug": "css-grid-lanes", "title": "CSS Grid Lanes", "date": "2026-02-06", "html": "

I've been trying to get a masonry-ish layout working on this site for the homepage grid. Tried a polyfill, tried hacking dense grid into something passable — all kind of janky. Then I came across Jen Simmons' post on the WebKit blog about display: grid-lanes and it clicked.

\n

This is the thing the CSSWG has been arguing about for five years. You might remember Firefox had grid-template-rows: masonry as an experiment back in 2020 — this isn't that. Grid-lanes is its own display value with its own layout algorithm. Items pack into the shortest column instead of filling rows. You define your columns and they just flow down.

\n

The wild part is it reuses basically everything from grid. grid-template-columns, gap, even grid-column: span 2 — it all just works. There's one new property, flow-tolerance, which controls how aggressively items pack. Default is 1em, meaning columns within 1em of each other get treated as equal height. Prevents stuff from shuffling around over tiny pixel differences which is nice.

\n

Here's what I'm using on this site right now:

\n
.mosaic {\n  display: grid;\n  display: grid-lanes;\n  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));\n  grid-auto-rows: 180px;\n  grid-auto-flow: dense;\n  gap: 8px;\n}
\n

The trick is stacking the display declarations — browsers that don't understand grid-lanes just ignore it and fall back to regular grid. The grid-auto-rows and dense flow keep things looking decent on everything else.

\n

Browser support as of writing: Safari Technology Preview 234. Chrome and Firefox are working on it. So right now it's basically a progressive enhancement — when it lands in stable browsers the layout just gets better without changing anything.

" }, { "slug": "spool", "title": "Spool", "date": "2026-01-26", "html": "

Spool

\n

Spool is a git-native, event-sourced task tracker. Tasks live in the repo as append-only event logs — no server, no SaaS, no separate system to keep in sync. It came out of exploring agentic orchestration workflows. Tools like Beads exist in this space, but the goal here was something more opinionated and personal — build the thing, use it daily, see what works.

\n
cargo install spool-cli\nspool init\nspool add \"Fix the thing\" -p p0 -t bug
\n

Why files on disk

\n

Your tasks should live where your code lives. When project tracking is a SaaS product, you're one acquisition or pricing change away from losing your history. Worse, the tracking is decoupled from the work — tasks exist in some web app while the actual context is in your repo, your branches, your commits.

\n

Spool puts everything in .spool/events/ as daily JSONL files. You commit them with your code. When you branch, your tasks branch. When you merge, your tasks merge. The tracking is the repo.

\n

Append-only JSONL

\n

Every change — create, assign, complete, comment — is an immutable event appended to a log file:

\n
{\"v\":1,\"op\":\"create\",\"id\":\"k8b2x-a1c3\",\"ts\":\"2026-01-13T12:00:00Z\",\"by\":\"@alice\",\"d\":{\"title\":\"Fix bug\"}}\n{\"v\":1,\"op\":\"assign\",\"id\":\"k8b2x-a1c3\",\"ts\":\"2026-01-13T12:01:00Z\",\"by\":\"@bob\",\"d\":{\"to\":\"@bob\"}}\n{\"v\":1,\"op\":\"complete\",\"id\":\"k8b2x-a1c3\",\"ts\":\"2026-01-13T14:00:00Z\",\"by\":\"@bob\",\"d\":{\"resolution\":\"done\"}}
\n

State gets materialized by replaying events. Caches are gitignored and rebuilt on demand with spool rebuild.

\n

This matters most at scale. Imagine tens or hundreds of people working across branches. With mutable task files, every merge is a potential conflict. With append-only logs, conflicts are rare — two people appending events to the same daily log just means keeping both sets of lines. Even when conflicts do occur, resolution is trivial: keep everything, rebuild.

\n

The TUI

\n

spool-ui gives you a terminal interface. Priority-sorted task list, detail pane with full event history, search, stream filtering.

\n

\"spool

\n

\"task

\n

The history view shows every event across the project — creates, completes, assigns, all with timestamps and branch info:

\n

\"full

\n

Agents and open questions

\n

Spool started as an experiment in agentic workflows, and so far it's working — agents can create tasks, update status, and track their own work through the CLI. But there are real challenges.

\n

Getting agents to use it consistently is the main one. An agent will happily track tasks for a while, then forget to update status, or create duplicates, or ignore the existing backlog entirely. Discipline is hard enough for humans — turns out it's hard for agents too.

\n

The team question is trickier. The obvious answer for keeping caches fresh is git hooks — post-merge, post-checkout, run spool rebuild. But git hooks are local, unenforced, and fragile. They don't travel with the repo in a way you can rely on. For a solo project or small team that's fine. For a real team, there needs to be something better. Still figuring that part out.

\n

This site uses spool for its own task tracking — the .spool/ directory in the repo is the real thing, not a demo.

" }, { "slug": "ferrotype", "title": "Ferrotype", "date": "2026-01-12", "html": "

Ferrotype

\n

Ferrotype is a Rust-to-TypeScript type generator. The existing options in this space mostly produce basic, flat types — Record<string, any> everywhere, no discriminated unions, no generics, none of the type-level features that make TypeScript actually good. The generated types compile, technically, but they're not types you'd want to write by hand. Ferrotype tries to close that gap.

\n
cargo add ferro-type
\n

The basics

\n

Derive TS on a struct, get a TypeScript type:

\n
#[derive(TS)]\n#[ts(rename_all = \"camelCase\")]\nstruct UserProfile {\n    display_name: String,\n    avatar_url: Option<String>,\n    post_count: u32,\n    is_verified: bool,\n}
\n
type UserProfile = {\n  displayName: string;\n  avatarUrl: string | null;\n  postCount: number;\n  isVerified: boolean;\n};
\n

rename_all respects casing conventions — your Rust stays snake_case, your TypeScript gets camelCase. Option<T> becomes T | null, not T | undefined or some wrapper type. The basics should just feel right.

\n

Discriminated unions

\n

This is where most typegens fall apart. Rust enums are sum types — they should generate proper discriminated unions, not string | object or some untyped mess.

\n
#[derive(TS)]\n#[ts(tag = \"kind\")]\nenum ApiResponse {\n    Loading,\n    Success { data: Vec<Post>, total: u32 },\n    Error { code: i32, message: String },\n}
\n
type ApiResponse =\n  | { kind: \"Loading\" }\n  | { kind: \"Success\"; data: Post[]; total: number }\n  | { kind: \"Error\"; code: number; message: string };
\n

TypeScript narrows these automatically in switch statements and if checks. The tag attribute controls the discriminant field name — default is type, but kind, variant, whatever you want.

\n

For adjacently tagged enums (serde's tag + content style):

\n
#[derive(TS)]\n#[ts(tag = \"type\", content = \"data\")]\nenum Event {\n    Click { x: f64, y: f64 },\n    Keypress(String),\n    Blur,\n}
\n
type Event =\n  | { type: \"Click\"; data: { x: number; y: number } }\n  | { type: \"Keypress\"; data: string }\n  | { type: \"Blur\" };
\n

Untagged unions work too — #[ts(untagged)] gives you a plain A | B | C union.

\n

Generics

\n

Generic structs produce generic types:

\n
#[derive(TS)]\n#[ts(rename_all = \"camelCase\")]\nstruct Paginated<T> {\n    items: Vec<T>,\n    total_count: u32,\n    has_next_page: bool,\n}
\n
type Paginated<T> = {\n  items: T[];\n  totalCount: number;\n  hasNextPage: boolean;\n};
\n

So Paginated<User> in Rust gives you Paginated<User> in TypeScript. The generic constraint carries through — you don't lose the relationship between the two sides.

\n

Composition and extension

\n

flatten inlines fields from a nested struct, the same way serde does:

\n
#[derive(TS)]\nstruct Timestamps {\n    created_at: String,\n    updated_at: String,\n}\n\n#[derive(TS)]\nstruct Post {\n    title: String,\n    #[ts(flatten)]\n    timestamps: Timestamps,\n}
\n
type Post = {\n  title: string;\n  createdAt: string;\n  updatedAt: string;\n};
\n

For extending external types you don't control, extends generates intersection types:

\n
#[derive(TS)]\n#[ts(extends = \"BaseEntity\")]\nstruct User {\n    name: String,\n    email: String,\n}
\n
type User = BaseEntity & { name: string; email: string };
\n

Template literals and branded types

\n

This is the kind of thing no other typegen even attempts. TypeScript has template literal types — ferrotype can generate them:

\n
#[derive(TS)]\nstruct Order {\n    #[ts(pattern = \"order-${string}\")]\n    id: String,\n    #[ts(pattern = \"${number}px\")]\n    width: String,\n}
\n
type Order = {\n  id: `order-${string}`;\n  width: `${number}px`;\n};
\n

Now your TypeScript compiler rejects \"abc123\" as an order ID but accepts \"order-abc123\". The type system does the validation.

\n

Indexed access types

\n

Reference a field's type from another type, keeping them in sync:

\n
#[derive(TS)]\nstruct Comment {\n    #[ts(index = \"User\", key = \"id\")]\n    author_id: String,\n    body: String,\n}
\n
type Comment = {\n  authorId: User[\"id\"];\n  body: string;\n};
\n

If User[\"id\"] changes from string to number, every type referencing it updates automatically. No manual syncing.

\n

The registry

\n

Types aren't generated in isolation. TypeRegistry collects everything, deduplicates, and renders in dependency order:

\n
let mut registry = TypeRegistry::new();\nregistry.register::<ApiResponse>();  // pulls in Post, User, etc.\nlet output = registry.render();
\n

If ApiResponse references Post which references User, all three get emitted in the right order. No forward reference issues, no duplicates.

\n

Everything else

\n

A few more things that matter for real-world usage: #[ts(skip)] omits fields, #[ts(default)] marks fields optional (?), #[ts(type = \"Date\")] overrides the generated type when you need an escape hatch, #[ts(inline)] inlines a type definition instead of emitting a reference, and #[ts(transparent)] on a newtype wrapper dissolves it into its inner type.

\n

Named it after the tintype photography process — ferro for iron/Rust, type for types.

" }, { "slug": "building-ui-in-gpui", "title": "Building UI in GPUI", "date": "2025-04-27", "html": "

A reasonably unstructured collection of tips and tricks for building UI in gpui.

\n

This post will give a bit more flavor as we go to the examples in the gpui-examples repo.

\n

Application & Context

\n

Remove the default titlebar

\n

Example – Hide titlebar

\n

This one is pretty straight forward. but immediately useful.

\n

If you are building a reasonably custom looking UI, hiding the titlebar is one of the first things you will be looking to do.

\n

Since this one is so short, I'll just share the whole main fn:

\n
fn main() {\n    let window_options = WindowOptions {\n        titlebar: None,\n        ..Default::default()\n    };\n\n    Application::new().run(|cx: &mut App| {\n        cx.open_window(window_options, |_, cx| {\n            // your app\n        })\n        .unwrap();\n\n        cx.activate(true);\n    });\n}
\n

Basically, just pass None to titlebar in WindowOptions. This will give you an app with no titlebar at all.

\n

Extending cx

\n

Example – Context Extension

\n

Add globally accessible data and methods with a central way to access them by extending App.

\n

I have a full post on this one, but here is a quick example:

\n
// Define a basic theme struct\n#[derive(Clone, Debug)]\npub struct Theme {\n    fg: Hsla,\n    bg: Hsla,\n    accent: Hsla,\n}\n\nimpl Default for Theme {\n    fn default() -> Self {\n        Theme {\n            fg: hsla(220.0 / 360.0, 9.0 / 100.0, 72.0 / 100.0, 1.0),\n            bg: hsla(220.0 / 360.0, 14.0 / 100.0, 18.0 / 100.0, 1.0),\n            accent: hsla(207.0 / 360.0, 82.0 / 100.0, 66.0 / 100.0, 1.0),\n        }\n    }\n}\n\n// Make it accessible globally\n#[derive(Clone, Debug)]\npub struct GlobalTheme(pub Arc<Theme>);\n\nimpl Deref for GlobalTheme {\n    type Target = Arc<Theme>;\n    fn deref(&self) -> &Self::Target { &self.0 }\n}\n\nimpl Global for GlobalTheme {}\n\n// Define the extension trait\npub trait ActiveTheme {\n    fn theme(&self) -> &Arc<Theme>;\n}\n\n// Implement the extension for App\nimpl ActiveTheme for App {\n    fn theme(&self) -> &Arc<Theme> {\n        &self.global::<GlobalTheme>().0\n    }\n}\n\n// Set your global theme\nfn main() {\n    Application::new().run(|cx: &mut App| {\n        // Initialize the global theme\n        cx.set_global(GlobalTheme(Arc::new(Theme::default())));\n\n        cx.open_window(window_options, |_window, cx| {\n            // Now you can access the theme anywhere\n            cx.new_view(|cx| MyView::new(cx))\n        }).unwrap();\n    });\n}\n\n// Then use your context extension anywhere\nimpl Render for MyView {\n    fn render(&mut self, _: &mut Window, cx: &mut Context<Self>) -> impl IntoElement {\n        div()\n            .text_color(cx.theme().fg)\n            .bg(cx.theme().bg)\n            // ... other properties\n    }\n}
\n

UI Components

\n

Conditional Rendering

\n

When building UI, one of the most common tasks is conditional rendering.

\n

You can do this with if/match obviously:

\n
#[derive(RenderOnce)]\npub struct Checkbox {\n    pub checked: bool,\n}\n\nimpl RenderOnce for Checkbox {\n    fn render(self, _: &mut Window, cx: &mut App) -> impl IntoElement {\n        div()\n            .child(\n                if self.checked {\n                    // might return some svg\n                    Icon::check().into_any_element()\n                } else {\n                    // else return an empty element\n                    div().into_any_element()\n                }\n            )\n    }\n}
\n

but there are a number of other useful conditional rendering patterns as well:

\n\n

more coming soon

" }, { "slug": "the-black-magic-of-canvas-and-text-editing", "title": "The Black Magic of Canvas and Text Editing", "date": "2025-03-29", "html": "

As I dive into building my own canvas editor I'm starting to wonder about the folks and tech that has come before. Here is a collection of things I've found so far (with hopefully more to come!)

\n

Canvas

\n

Figma - Evan Wallace

\n

A collection of writings on technical work on Figma.

\n

Figma - Rasmus Andersson

\n

An overall overview of the Figma by Rasmus, including design, engineering, and culture.

\n

Inside Sketch: A deep dive into our Canvas tech - Pieter Omvlee

\n

Figma 1 & Figma 2 - Andrew Chan

\n

Scene Graph

\n

Wikipedia: Scene Graph

\n

Some advantages of the scene graph:

\n\n

Text

\n

Text Rendering Hates You - faultlore

\n

A bible on text rendering.

\n
\n

Thannks to all the folks in this thread for contributing links!

" }, { "slug": "fig-gen-making-generative-art-in-figma", "title": "fig-gen: Making Generative Art in Figma", "date": "2021-11-06", "html": "

Generative Art with Figma & Automator

\n

I spent the evening exploring the new Automator plugin for Figma from Jordan Singer. I thought a minimal generative series using pixels and mapping equations would be a fun way to try it out.

\n

\"Some

\n

Process

\n

I started by pushing on nesting shapes – How does it look when you nest and rotate shapes continuously? I got some cool outcomes like below, but I realized that most of the gens would end up looking pretty similar, relying so heavily on rotation.

\n

\"\"

\n

Exploring a different direction, I remembered playing with graphing calculators back in high school – Using trig functions like sin, cos, and tan, I got some exciting results right off the bat.

\n

Once I found a few directions I liked, I realized that these gens would probably show best in some sort of frame, especially if I wanted to show a few together. I went with the simplest outline possible to keep everything monochrome and on theme.

\n

In the end, I didn't use any nesting to create each gen. Frames 1px tall and 1~6px wide (randomized) are charted in 2D along the x-axis using the repeat's {{index}}.

\n

The generative functions are mostly created using sin, cos, tan, a randomizer variable, and {{index}} combined in different ways.

\n

My favorite thing so far about Automator is how quickly I was able to explore a ton of variations. I was able to create over 60 gens with some really wide variation in under 2 hours.

\n

\"\"

\n

Here are some of my favorite gens:

\n

\"\"\n\"\"\n\"\"\n\"\"\n\"\"\n\"\"

\n

I'm looking forward to exploring another generative series soon, following everything I learned with this one!

\n

You can find some of the JSON import files I saved as I was exploring in the fig-gen repo.

\n
\n

Jordan Singer's Automator plugin is currently in closed beta. I can't wait to see what everyone is able to create once they get their hands on this!

" }, { "slug": "writing-with-adhd", "title": "Writing with ADHD", "date": "2021-06-13", "html": "

This post is a reflection on Geraint Evans' \"This is how an ADHD\nperson actually writes.\"\nI'd start there first!

\n

I'm a terrible writer.

\n

Or, at least, I've convinced myself of that my whole life. The things that I write flow awkwardly, and I never understand all the rules of writing and the way to make things sound immersive and natural. My writing ends up awkwardly verbose and tends to wander a lot. I tend to mix tenses constantly.

\n

I never understood why I write the way I do, until I discovered at the beginning of the year that I have rather severe inattentive ADHD.

\n
\n

Coming across this tweet was pretty mind blowing for me. It was like someone speaking to the way I write for the first time in my life. Then seeing tons of replies under it validating the way ADHD people write I realized I wasn't alone in this. Honestly, you should probably just go read Geraint's article \"This is how an ADHD person actually writes.\" instead of reading this, but I'll do my best to share my thoughts on top of it.

\n

In his article Geraint calls out four main points in his concussion, so I'll use that as a starting point. (And sorry if this structure doesn't make sense... You know. ADHD ¯\\_(ツ)_/¯)

\n

Here are the four points:

\n\n

We'll dive into each separately.

\n

Impulsivity

\n

Gotta go fast. Having my special flavor of ADHD means a mind constantly full of ideas at all times. You know that expression \"drinking from the fire hose\"? It's like that, but 8+ hours of the day, every day (before completely running out of energy and crashing, but that is a topic for another time.)

\n

A lot of ideas

\n

Even trying to sit down and write this out, it's hard to move to the next because there are 18 different ways I could continue this sentence, and 14 of them probably involve a complete topic change.

\n

Each idea feels like it is so incredibly pressing, and the entire world should hear about this – only to be frustrated after tweeting it out to the world, bugging a coworker or talking to my partner, and finding no interest at all in it.

\n

Writing with ADHD means TONS of edit passes on even a few paragraphs because often I've shoved so many ideas into a small space that it feels overwhelming and disjointed to read. It ends up being hard to follow because I've left out a bunch of the in-between framing context that is in my head that I forget others can't follow.

\n

Overly passionate

\n

Often having this volume of ideas, and an immense, fast burning passion for a topic means things are often oversold, or phrased incorrectly.

\n

I remember once writing an email to a director at my then-work flagging that a product decision was \"unethical\" because I believed strongly we were making the wrong decision. In reality, while it was a bad decision, unethical was both the incorrect framing AND severity. Would both craft and inclusivity suffer from this decision?

\n

Yes. However, was this a decision that was any more or less severe from the thousands made at the company every day? No, not really. In the moment though, it seemed like the most important thing in the universe, and my passion was dialed to 11.

\n

Luckily, this person was highly empathetic, and explained to the email chain what I likely meant (and why I was over-reacting) without condescending. It was really eye opening to me, and I always remember that. (Aside: Stick with the people who will call out out in a loving way! These people will help you grow immensely.)

\n

Because I feel like I've explained absolutely nothing here, that seems like a great time to move on to point two!

\n

Attention to detail

\n

This one's short description nails it on the head: \"Yeah, probably fine, ill just post it.\"

\n

This pretty much captures my whole sentiment here, and really conflicts with the last point, Feeling Misunderstood, yet some how coexist.

\n

How this often manifests is either 1) writing for hours, attempting to get things right or concise or understandable and eventually getting frustrated and hitting post, or 2) blasting some writing out in 30 seconds and pressing send without even reading it back.

\n

I was never able to write papers in school because if I tried to edit a long piece of writing, rather than editing it I would just end up rewriting the whole thing on each edit pass. In the end I defaulted to writing a few hours before the deadline so I wouldn't have time to fret over the contents or writing style. I call this \"Deadline Adrenaline.\" I found I got better grades and responses often with just throwing something out there on the first pass than trying to write in a way others would understand easily (because, of course I couldn't do that. My brain doesn't work that way.)

\n

Deadline Adrenaline

\n

An aside – deadline adrenaline is something that I've come to lean on as an ADHD person throughout all parts of my life. I'm not sure if this is strictly and ADHD thing, or a me thing.

\n

Deadline adrenaline is roughly leaving something so late to the last minute that I'm basically fucked if I don't finish it in X hours. School papers, project deadlines, even packing a house or submitting some documents, many of these things in my life get done this way.

\n

Often tasks that seem impossible I'm able to pull off with ease leaning on this, but it means it can be difficult to worth with others effectively. My managers are always terrified and then shocked when in a day I turn around an entire project, or complete what seems like an impossible amount of work in a short time.

\n

This process I go through is part of the ADHD cycles I experience, which I'd love to write about more later.

\n

The super TL;DR is when not on medication I experience pretty severe cycles on both roughly a daily and monthly basis. These cover energy, creative output, focus and more.

\n

It makes it extremely difficult to work with others if a creative or energy high doesn't align with where others are at the time, but also when my cycle highs align with a project or collaboration people are often amazed at both the volume and quality of my output (and then probably confused why a week later I can't seem to create two screens.)

\n

Err, we went on a bit of a tangent here though, so lets get to point 3!

\n

Being socially inappropriate

\n

This one is pretty straight forward for me. Let me say this first, I recognize I'm VERY, SUPER privileged to be able to work this way.

\n

I don't work with people, companies, etc that require me to do anything in a certain way. Need to dress a certain way? That is a nope. Talk or write formally? That is a nope. Maybe seems messed up, but it's how my brain works ¯\\_(ツ)_/¯

\n

I am fortunate that I've been able to find a career path that I've been able to design a way to create that works for me, and brings people value, but I think many ADHD people's potential is never even given a chance to shine because they can't engage with the world the way the world wants them to.

\n

I was blessed with some incredible teachers and mentors that saw the value in me despite my \"weirdness\" that I was never able to define until recently.

\n

I think we leave a lot of great people behind because they can't or don't work the way the world wants them to. I'd be still in my parents basement if my only options were suit & tie or on my feet at 8am in retail. (Y'all are the unsung heroes, doing some of the hardest work with completely unjust levels of compensation. Thank you, and I hope we can improve the way you all have to work in my lifetime.)

\n

To wrap up this section: I've always done the worst when I tried to fit myself into the mould of the \"Normal.\" I end up coming off just as a slightly ok-ish designer. I've found resounding success in the past few years when I've leaned into the me unapologetically, even though I recognize it can be hard to work with and around.

\n

I have the utmost respect for managers and leaders that can utilize the odd-shaped puzzle pieces like myself and figure out where they fit.

\n

Feeling Misunderstood

\n

Moving on to the biggest one – Feeling misunderstood. This is the root of almost all social issues that ADHD brings for me personally.

\n

Feel like someone didn't understand what you said – here comes 10 minutes of exposition to try to explain that one statement I said, meanwhile the whole group is slowly edging away to get away from this odd guy.

\n

Post a piece of writing online? \"People will pick apart every statement.\", \"Don't post that, people won't understand what you mean.\" The amount of self-censorship you do from fear of being misunderstood is both socially crippling, and highly career negative.

\n

When I worked at Facebook, one thing I always struggled with is there is this idea of as you become a more senior designer you build more of a public following, and begin to have an impact on our industry. This was always crippling for me to even think about, because of the fear of doing or saying something wrong and then being outcast.

\n

The feeling of being misunderstood to and ADHD person is TERRIFYING. I still have a thousand minor slights or social awkwardness I've committed that I think about weekly, and am just begging in my head to be able to go back and explain or correct.

\n

Wrapping Up

\n

Even as I start this wrap up, I basically feel like I just wrote a bunch of stuff that people won't really get anything out of because of it being highly disjointed.

\n

But I'll throw it out there since I'm trying to get better at challenging my assumptions and learning more about myself and my ADHD through sharing with others and getting feedback.

\n

This meandered a bit from just focusing on writing, but writing is HARD for ADHD people. I'm trying to do it more to get better, and identify how the above things affect me and my writing and how I can improve it.

\n

I one-shot this writing, so apologies for any issues, spelling, flow or otherwise. I'm always open to talk about design, ADHD and more. You can reach me at iamnbutler@gmail.com.

\n

Hope this is interesting or useful to someone!

\n

Nate 🌱

" }, { "slug": "design-workshop", "title": "Design Workshop", "date": "2015-03-12", "html": "

This is a project about discovery, identifying weakness, and finding strength. A two part project: one part illustration, one part narrative. It was born out of a desire to make without a problem, to make for the sake of making.

\n

Learning to Make

\n

The illustrations began by exploring the ideas of lost worlds and alternate realities but as the project continued it began to gradually in change form.

\n

\"\"

\n

The idea of making without a goal or problem in mind was both terrifying and liberating. Designers are used to the idea of making from a brief or a set of instructions, or finding a solution to a problem. Here I sought to explore the scope of possibilities outside the prototypical design process. The project is a rejection all that is design: creating using a problem and solution formula. It is a dive into the concept of design as making, creating to discover about the world and one's self.

\n

Perhaps saying that the project doesn't deal with a problem is misleading. It would be more correct to say that the problem is the process in which making powers discoveries through research. It is easy to become complacent when designing from project briefs, and it is easy to lose some of the imagination and pure creation that one starts out with in design when following this process. Exploring showed how to research and design bymaking--creating work that by itself was not solving a problem, but when put together in series showed development and expansion of of voice.

\n

Visual Research

\n

Sketching came first in the form of simple geometric illustrations. There was an idea of geometric shapes and forms right from the beginning. The direction pursued was one of exploring an unknown world, of teleportation and telepresence.

\n

\"\"

\n

This idea manifested itself in the work through form, layering and artistic direction. Rather than focus on designing to these ideas, they simply existed as a springboard into a deep process of making.

\n

Creating a Process

\n

I began exploring various 3D softwares. I stumbled upon a delightful voxel design program called MagicaVoxel (a voxel is the 3D equivalent of a 2D pixel.) It was a simple, very lightweight program that allowed quick prototyping of ideas, with rather straightforward rendering tools.

\n

\"\"

\n

The process of designing work was a form of visual research for me. By first creating, then observing work out in the world and then reflecting and creating again I could see a shift in the voice of the work I created. This was a strange but exciting feeling to me as I had not worked in this fashion intensely before, discovering new ideas by creating rather than doing formal research.

\n

\"\"

\n

I quickly desired more depth in my 3D software so I explored Blender and Maya. I spent a large amount of time working on learning the new workflows of these platforms, but noticed that the quality of the work I produced week to week was less. I was spending less time on finding exciting compositions and interactions and more on developing new techniques and learning how to do more complex rendering. While this in itself is not a bad thing, because of the short nature of the project I decided to go back to the simpler software I worked with to continue to develop my ideas.

\n

\"\"

\n

To summate the results of my making and research so far I created a series of five posters. The posters address the topics of intention, message, complexity and fluidity. They include narrative that discuss results and act as visual process, exposing a landmark in my research.

\n

One of the themes that came up during this process of summation and evaluation of work completed was the cyclical nature of the making process. Exploration and research lead to making, which lead to new inspiration, which in turn lead to more exploration and research to find how to make the next desired piece, and so forth. While this is true of many processes it seemed to occur very rapidly while making in this manner.

\n

Taking a Step Back

\n

Beginning from the second half of the project, while making continued as in the first half, I began to explore writing as another way to challenge weakness. Writing is an important aspect of design that is often overlooked and one that I personally struggle with. By diving into writing different aspects of making could be addressed. Language, personal versus impersonal writing, pacing and sentence structure are similar to the tools used in production design, akin to the pen tool, the type tool, rulers, guides and shapes. By seeing writing beyond just words it reveals itself as another form ofcreating--one which can be explored, manipulated, molded and crafted.

\n

I decided to make a mini-site with a collection of four stories reflecting on things I had learned during my time in and out of school over the past four years. By drawing from my own experience I'm able to write about topics that I care about, but attempt to universalize them so that they are applicable to many other designers that may read the stories. The stories included:

\n

1 -- The Impostor Inside

\n

Identifying impostor syndrome and understanding your value

\n

2 -- Break the Cycle

\n

Living with depression and dealing with it's effects on your creative process

\n

3 -- Make! Make! Make!

\n

Why finding a balance between collecting knowledge and making is important

\n

4 -- Kill Your Idols

\n

There is no such thing as a design superstar, just those with more experience, and those that put the work in

\n

\"\"

\n

Making By Reflecting

\n

The writing began as a mostly self-reflective process, but I learned through the process that simply reading someone else's reflections does not drive a desire for change, or help the reader to feel the impact of the writing.

\n

As I wrote and rewrote my stories I attempted to lead into less personal rhetoric as the story progressed to help universalize the problem being discussed. The goal was not to tell others how I dealt with impostor syndrome or worked through my depression, but rather to inspire others who may be dealing with or know others dealing with the same situations, and maybe learn some steps to take to help climb out of these situations.

" } ]