It's been a few weeks of using and configuring Linux for my work computer and I want to document some of what I've been doing and how it has been affecting how I think about things.
I was initially inspired by @neauoire's posts about their switch to elementaryOS. That made it feel within reach. I tried it on an office Thinkpad and was surprised how easy the usb-stick based installation was. Elementary seemed well put together, but I realized using it that I have a lot of complaints about how macOS handles shortcuts. I didn't just want those shortcuts replicated. I figured maybe I'd get there over time, customizing and tinkering with it once and a while. (I also didn't totally know what I wanted in terms of shortcuts/set-up, just... something else.)
Adam suggested I look into i3wm, a tiling window manager. I found a fantastic tutorial on getting started. I think watching this was the point where I realized this was really viable.
I went back and installed ubuntu so I could follow the tutorial exactly. I'd like to switch off ubuntu (maybe to Arch or nixOS) but I'm holding back for now. The nice thing about ubuntu is that when I get stuck doing things on the command line there's usually a totally functional GUI option I can use to. I'd like to move to the command line as much as possible, but it's nice to have an escape hatch in case I don't want to get deep on, say, connecting bluetooth headphones right now.
If there's one thing I've done a lot in my career, it's jumping into technologies I don't understand well and figuring out how to wrestle out what I want from it. It's interesting to try and reflect on what the strategies I use are. One thing I think I've definitely learned is one-thing-at-a-time: that's the idea behind using ubuntu for now. It's enough to get my head around i3wm, I can switch the distro later (it's still a temptation I have to actively resist, though). At the same time, I know I'm motivated by seeing tangible results. So if I want to get the current song displayed on my status bar, I don't feel I need to understand how to do that from scratch. I'll get what looks like the most popular bar (polybar) and find a package and paste a config to get it going. Balancing that mix of getting things I'm excited about running and also going step-by-step is the main meta-task in managing my learning. I think I've definitely developed an intuitive feel for how much I can paste in to feel excited and how much I need to actually understand in order to feel like I still have a handle on the system (compartmentalizing things is also a big part of this, I can have something I don't understand running if I can chunk it as a conceptual unit -- I can always investigate how it works later).
I've been surprised how relatively smoothly this has gone. I think part of it is Linux config is less complicated than I thought, mostly due to people's willingness to share knowledge. But also I've been prepared in various ways. There's using vim, which has gotten me used to a mode of navigation, which i3wm shares. I think that is actually the main draw for me, having this composable system of movement that carries over from vim to the window manager. I also think getting used to npm prepared me better for installing packages (I know the influence goes the other way, but for me it was npm first). I still definitely want to understand more about the mechanics behind packages, and how that system has evolved.
At the same time I've been surprised how radical it feels to extend the customization options I'm used to being able to apply to the web out to other applications. To have nothing on the screen that I "just have to live with". It feels empowering, and it makes more sense to me why some people are as adamant about Linux as they are. It's exciting! But that excitement is tampered by the knowledge that it's definitely a luxury of time and tech that I'm able to get these deep into config. So I don't want to declare it the answer to all things. But I am surprised how exciting of an experience it has turned out to be.
Related to that, an idea I've been thinking about a lot lately as a model of being in the world/influencing others is: paths. Sometimes I think I'm too caught up trying to think of something completely unique to put forward, rather than engaging with others. Maybe a better way to think about it is that I'm helping to tread a path that others have already made. Here I'm following a path of all the work that's gone into Linux and the tools I'm configuring, and also what seems like a new willingness among designer-devs to move off of mac. Sharing my process of moving, and the excitement I'm currently feeling, can help other people decide to make the jump. Then rather than feeling like I should be coming up with something completely new, I just need to make sure the things I'm doing and sharing are treading a path that I think more people should travel on (or even have the option to travel on). I feel good about that with this project so far.
English text is read from left to right.
Text is 1-dimensional. The simplest representation is an unbroken horizontal line. Horizontal reading is uncomfortable though, so we wrap text. The wrapping is presentational only, it has no semantic meaning.
A paragraph is the first spacing-based presentational layer that goes on top of writing. (In CSS a paragraph is when you can start making some real spacing choices.) It is often an indent or an empty line.
Headings are the main tool for establishing hierarchy in an HTML or markdown document. There are six levels. You're only supposed to go down one level at a time. The sections that come after a heading are usually assumed to belong to that heading, though rarely is the code set up this way (the paragraphs are siblings to the heading, not nested within them).
Headings should stand out from paragraph text and they should show their position in the hierarchy. Sometimes I try really hard to think of a bulletproof style hierarchy for the six heading levels.
One of the toughest things about showing hierarchy with headings is that rarely are all your headings on the screen at the same time, so you need to be able to see an H4 in isolation and be able to tell it from an H2 and an H5. It's pretty hard to do this just with sizing. But more explicit methods are often distracting.
Some of the text styling methods you could use for headings are: bold, italic, all-caps, and underline. Underline is not a great option on the internet because of its association with links.
My last attempt at using text styles (no sizing adjustments) to cover all six headings was:
That went OK, but I ended up just switching over to sizing because it was too noisy. It's frustrating that it doesn't really follow a logical progression (why is 'bold' higher than 'bold, italic'? because if you actually try it out going the other way it feels weird). I think part of it is that bold is much more jarring visually than italic or caps, so it's difficult to harmonize them all across six steps.
You do have some other spacing options you could use. Like space before or after a header. I think this can get you a little ways (more space around h2 then h3) but, again, it's difficult to set up a progression that isn't extreme on either the H1 or the H6 end.
One thing I always want to go to is indentation. This probably comes from being used to indentation in code, where it is the main hierarchy signal. The main obstacle I see is just that screen size is limited (especially on a phone). It's going to be annoying if you're only getting to see a few words a line because you're in the middle of an H4 section. Indentation could also be challenging to code up, since paragraphs aren't actually nested under headings. You'd have to run some code to do the structured nesting. Definitely possible, but you're adding in more complexity. I'd still like to try something with indentation sometime. Maybe the indentation can be signaled by a line, so you're not losing as much reading space in the deeper subheadings. Indentation seems like the cleanest symbolically.
I'm working on a new build system for our Fast Forward reports. Previously, we have been writing in Asciidoc. That gets converted to HTML via Pandoc and inserted into a Django template. It works partly through an Asciidoc configuration file with a bunch of trial-and-error-based hacks that I never felt comfortable with. I have long wanted to revamp this but it's taken me a while to figure out exactly what I wanted to do.
So far, in the new system we write in markdown. The report gets built using node and a markdown renderer called markdown-it. Markdown-it had enough plugins/rendering flexibility to get almost all the features we regularly used in Asciidoc (table of contents, figure captions, an info box). The output is much cleaner and I understand the system much better (it's still on my list to understand the markdown-it configuration options better, though).
The markdown render gets put together with HTML and and CSS via a node build file. The process of manipulating (reading, writing, moving) files through a build script is new to me, and it feels great to have that control. I discovered the techniques looking at build processes for Next.js static blogs. The file has gotten messy as I've added more CSS and some javscript. But it still feels great to know exactly the relationship between the code going in and the code generated. I also get to carry over some of the style stuff I've built up from React, where I set a unit for line-height and then can use that for spacing math in both the CSS and the element style options.
My end goal for this is for us to be able to publish research and feel very confident in the presentation. Another big part of this is communicating the available content styles to the rest of the team. A constrained and understood style space is going to ensure there are no rendering surprises. It will also make it easier for everyone to write. I often think back to the title of the article "When I sit down at my text editor I feel calm". That is a big part of the goal. That everyone can sit down and do the work of thinking and writing and feel confident in their tools. Having the tools be understandable (so the user can maintain a mental model of what's going to happen in their head, and feel confindent about it) is, I think, a key part of reaching that feeling.
This is an area I've returned to again and again in my work. I'm thinking about whether and how it could be turned into a career. What is it exactly? Is it just building a CMS? I think what I want to make are content systems. So content strategy is in there. And I also want to build the (simple) tools. And then part of the tool constraints should be tied to the branding, which I'd also like to develop. So that's a lot! Or would I like to make the system that lets other people make these systems?
I have an idea for a writing system where I just describe the things around me (basically like doing a sketch from life everyday but for writing: "My computer is sitting on a brown, wooden table. The table is covered in tan scratches, mostly in the middle and around the edges. I have a small coffee in a cup on a saucer. The coffee is a shade of tan in-between the colors of the scratches and the table."). I wonder what that interface and presentation should look like? Should I also actually draw the scene, and present the sketch along with the words? That seems like an interesting project but the drawing would make the writing somewhat irrelevant.
The ambitious idea of for the observation-write presentation is to use some of the ASCII art experiments I've done, and take a picture of the scene, that then gets rendered using only the letters from the description. I think this is a cool idea, but it might have too many fiddly aspects to start with.
More presentation ideas:
Of those, I think something that represents the different scale of the writing sounds the most promising. It has the feel of a presentation conceit with a meaningful connection to the content, where I'd actually be interested in getting a feel for how much I describe small stuff versus large stuff (compared to time of day or location, which for me would be pretty same-y day-to-day). But what is the way to present that that is noticeable but not overwhelming? Something with bigger and smaller font-size is what I first think of. Hard to that do without being really distracting, though. It would be cool to have a 3d interface where the text is positioned in space. And then maybe the closer stuff could actually be writing positioned closer to the viewer. But I also want the entries to be arranged reversed-chronologically, how do I merge those two overlapping organization systems?
For awhile, instead of constraint systems, I thought I'd do writing systems, and it would be a series of different writing interfaces + sites. The interfaces and the presentation would reflect different writing intentions. One for stream-of-consciousness notes, one a level of polish on top of that (or maybe a level of structure), and one fully polished. The idea is to experiment with how interfaces and presentation can make expression easier.
Scrawl is a version of the unpolished app and so far I would say the experiment is going OK? It is easier for me to write here knowing the expectations I have set for myself is that it will be unpolished. It will be interesting to see when/if I structure this stuff up into something more polished. I might need to make some sort of external commitment (maybe a talk?) to make sure I get that done at some point.
One piece that is not in place yet is a system for creating sketches or graphics along with this content. I would like to make an app where you could switch into drawing mode at a similar fidelity to the level you're writing at. That's partly what some of the constraint system drawing apps could become -- you could write a paragraph, switch to drawing mode, and a keyboard-editable canvas would be dropped in. There too, I would try to productively limit options so that you have what you need to get a concept across visually, but not to fiddle beyond that. Draw quickly, and switch back over to writing. The idea is to keep you in flow. (It might be a keyboard-based diagram-ish thing or it might be that you can switch to free-hand drawing and it's just the stroke is big enough to convey that this is a rough sketch.)
I'm going to keep experimenting. I'll keep running scrawl and see how that feels. I'll think about what it could look like to take some of these scrawl notes and structure them up. And I'll keep experimenting with the drawing tools at constraint systems. And maybe at some point they'll merge.
I think I know what branding is now. Mostly I've been thinking about interfaces lately, but as we rethink the Fast Forward branding to better fit within Cloudera, I've been thinking again about just what branding is and does. Part of my recent thoughts are based off Ben Pieratt's Pre-Brand concept and discussing the idea with some co-workers.
I'm especially thinking about this slide, which diagrams how a start-up may disregard several early identities before settling on a stable identity. The diagram is missing some things that I think are implicit in the rest of idea, but not drawn out. I think the diagram should be more zig-zaggy, and the branding is a marker for where the group wants to go. And it travels along the path towards the idea in that brand for a while, before reorienting towards a different idea, discovered during the work on the previous. Maybe sometimes the course is reversed, but mostly it's probably a zig-zag, where you keep moving in one general direction even as you zig-zag to get there.
Writing that, it's fun to see how much the idea of a 'problem space' has influenced my thinking. How much I tend to see things according to that lens now.
But the thing I want to emphasize, when I look at the proposed pre-brand process, is that the three developed concepts are not just things that might or might not fit. They're looks at what a start-up could be. They're all illuminating different positions within a problem space, and because the start-up being made is moving and developing, they're going to influence that development just by being known and seen.
Of course the brand here is just one aspect in the multi-dimensional stew of how the start-up is going to develop and what it is going to be. That course of development is being pulled along by a lot of other forces, but the brand influences some of those directions.
An early brand is a cultural marker for where you want to meet your users and audience. It stakes out a place for the company in relation to other markers.
I think the new thing that I am starting to believe is how important the brand can be to the start-up itself, to the people working there. In early days, it's probably more important for them than the audience. It can be a reminder as you're doing the mundane, everyday stuff, that this is all working towards something bigger. The brand can be a visual slot for the workers to put all their associations and aspirations for what the work could be. I think this makes me feel better about the usefulness of branding, although of course in that function it could be put to good/mixed/evil use depending on the work.
Scrawl is a new project where I try and write my notes quickly, without much editing. Eventually I hope a lot of this will feed into more polished writing elsewhere. I've been thinking about doing this for a while. Lately, I've been excited about some of the work I've been doing with Constraint Systems and some of the connections I'm making between ideas in my head, but I want to do a better job of exploring some of those ideas with other people. And I'm pretty sure that means writing.
I have some other places for writing, but for a while I've been playing with the idea of a site where the stated purpose is unpolished notes. It's an opportunity to try out some of the constraint design concepts I've been thinking about. The basic idea is that by providing a constrained tool, you free people to express themselves more because you can't distract yourself with formatting decisions. This is closely connected with an idea of staying in flow.
So for this site the posts are run off text files. There's no headings, and there's basically just paragraphs (it actually uses the 'pre-wrap' whitespace setting to preserve the formatting from the text file, which leaves open some opportunities for stuff like formatting a basic text list). There are no images. I can put in links using markdown syntax. I want to write basically stream-of-consciousness and see how things develop. Files are titled according to the date and "hour quarter", where the day is split up into 96 (24 * 4) hour quarters: as shown here.
Hopefully, this serves as a sort of companion to my feed. I think my feed has weirdly been one of my most successful product designs, and that is almost all down to constraints. Specifically, how the constraints make it easier and clear for me to post. One screenshot (or GIF) plus text. A few times I added the ability to do video or quote, but those options are mostly unused now. The goal above all was just to do something where I post. The syndication to Twitter and Mastodon have also been helpful for getting feedback from others. I should probably set up a similar system here. Anyway, I think one of the main things lacking in feed has been context. It's fun to post little cryptic messages, and not needing to explain the background of everything has certainly made it easier to post, but I do want to do more writing and thinking through of my ideas. So now there is scrawl, which is a kind of variation on feed.
All of this stuff is exploratory and provisional. One thing I am pretty sure of, though, is that making different parts as new, separate projects, that live in their own repo and then get a fun subdomain is a great way to do side projects. It hits the right spot for me of forcing me to get it into a releasable state but not a perfectly polished, final state. This is one thing, it's here, I might do a different version but it will be something else, not an update to this one. There is a definite influence there from the idea of immutability in programming and stuff like immutable deploys in Zeit's Now. One of the things I definitely want to write about here is how programming concepts are influencing how I think about design and just process in general.