Weeknotes are back, I think, and we’ll start a new season to celebrate the gap.
Today marks one full year since BYU announced that classes were going remote, and tomorrow is the anniversary of my work and the kids’ school following suit. One year. Whew. A bit mind-blowing. It’s certainly taken longer than we thought it would, but hope is finally upon us. My wife and I are looking forward to getting vaccinated next month, and then hopefully the trials with children go well. (We have a child with a high-risk medical condition, so we can’t really breathe easy until the whole family’s vaccinated. Which probably won’t be till the end of the year. Endure to the end!)
Quick update on the new job (which is great, loving it): while I still hit occasional pockets of onboarding slowness (new parts of the codebase, mainly), overall I feel like the impostor syndrome is mostly shutting the heck up. Also, Go turns out to be a great language for team-based work, at least in my view. Extremely easy to read, and it feels transparent, like it’s just you and what you’re trying to do, without the language getting in the way.
A couple weeks ago I messed up my back and have been dealing with the fallout since then. This time it’s taking longer to recover than it did a few years ago, which I suspect has to do at least in part with age. What a joy.
Art has slowed down a bit. I’m still planning to keep at it, but on a less regular basis. (It’s been my main thing for a while now and I think I’d like to focus more on other things.) When I do work on it, I’m planning to continue exploring the new texturing technique I used on Where Can I Turn for Peace? (probably redo a few old pieces with it). Maybe some more Blender, too, though I’m not really sure yet how that fits in.
Most of my writing projects are in the planning/outlining stages, so there’s not much to show yet there, sadly. (A fact which needs to bother me more, enough so that I start actually finishing stories. Good grief. But I guess part of working in public is being incompetent in public. Here you go! And I hope that the beats idea is the answer to my writing woes.)
I’ve finished the initial draft of lowercase letters on the Hinte typeface, and I’m in the middle of refining those and starting on the uppercase. Hoping to do much more type design going forward. (And eventually replace Literata on this site with something homegrown.)
As part of that endeavor, by the way, I’m itching to build that nice new web-based version of Curves. (FontForge is functional, sure, but its UI definitely does not spark joy for me.) Since I’ve already built the font-generating backend, the main remaining challenge here is just figuring out how I want the UI to work.
Another in-progress bit of design, this time from a writing app I’m working on. (Which I’m thinking of as a potential replacement for Storybook.)
Panes
One of the core ideas I want to explore with this app is a pane-based layout system, similar to what you get in Blender and After Effects, and in tiling window managers. Here’s what Blender looks like:
There’s a lot going on there, but fundamentally it’s just panes. You can split a pane, merge it with another, resize panes, and change the type and/or contents of a pane.
There is also usually the idea of a workspace, where you can switch between different pane layouts for different types of work. (In Blender, for example, there are workspaces for modeling, shading, animating, compositing, and more.) Photoshop has echoes of this as well, though it’s not fully pane-based.
A brief analysis
Some of the advantages of panes (at least in my mind):
Flexibility. You can create the workspace you need, with things arranged the way you want.
Simplicity. You can see everything in a workspace, with nothing hidden under another window. (This isn’t completely true, though.)
Responsive. Because the layout needs to adapt to a variety of configurations, each pane needs to work at pretty much any size.
I’m not sure yet what to call this, but you can easily switch between tasks, whether that’s changing a pane briefly or switching workspaces.
And some of the disadvantages of panes:
Fiddly. Because it’s malleable, you end up spending more time tweaking the layout.
Connected. Resizing a pane resizes the adjacent panes on the other side of the divider.
Complexity. There can be (and usually are) panes that you don’t have visible in your workspace, with state about your project. Some things are hidden after all.
Because I’m interested in interface design, and because I’ve long wanted to explore this particular space, I’m going to try applying the pane idea to writing. I’m not sure it’s a good fit, but if it’s not, I want to find out which factors determine that, and which types of activities would be better candidates for a layout system like this.
Panes on mobile
Designing for mobile first, I immediately ran into the hard, cold fact that a phone screen is too small to split into panes.
This got me thinking about what panes do, at a more abstract level. My conclusion: panes let you have multiple things open at a time, in a way that preserves state (where you are in each pane, to use a spatial metaphor).
With that in mind, it seems to me that the closest analogue would be a screen for each pane, with a way to switch between them — similar to the way Safari handles the open tabs in iOS in portrait mode on a phone. This model allows for switching between tasks in a reliable, persistent way on a device with a small screen.
Pane types
I first brainstormed some possible pane types and came up with this tentative list:
Draft. Where you do the writing.
Outline. A foldable outline or note cards or something in that vein.
Feedback. Comments from beta readers and editors.
Notes. Your notes on characters, locations, etc.
Labels. Working off the idea that you can label a chapter/scene/paragraph, this would be a pane for working with labels (navigating and managing the list of labels, seeing what has been tagged with a given label, etc.).
History. A way to see previous drafts. My plan involves a branching model ala Git, though, which would include experimental drafts, so this probably needs to be renamed.
Mobile pane design
I made some quick sketches and considered turning them into a prototype, but going to wireframes instead seemed a better use of my time (it’s much easier to iterate on wireframes).
Here’s the current state of the prototype (made in Figma with variants and auto layout and Smart Animate). It’s not finished, and it’s still a bit rough, but you can at least start to get the idea:
And some of the screens:
Further work
Some of the things I’m thinking about at this point, that I plan to validate and iterate on through testing:
Whether the switcher makes sense as an overlay (what we’ve got here) or its own screen. Leaning towards an overlay so that the other panes are near the bottom of the screen, closer to the user’s hand.
Whether a right-handed overlay is problematic for left-handed users. (Keeping in mind that the button for the switcher is already on the right side of the screen, and so the user’s finger will already be in the vicinity. But that may not make a difference.)
Whether a list like this is the right way to display panes, or if a visual of the actual panes (like the app switcher in iOS) would be better. For visual-based work this makes sense, but for work like writing that’s largely text-based, I’m not sure. This will affect the type of transition used when switching between panes, too.
When you add a new pane, what the pane type should be and where it should be navigated to. The same type/contents as the active pane? The same type but reset to the beginning of the project? Some default pane type?
Whether switching a pane’s type (by tapping on the pane type icon in the switcher list) makes sense in this context. I believe it does when you’re working with actual panes on a larger screen, but it may not fit.
Once I’ve got this sorted out (by testing and iterating), I’ll follow the same process to design the UI for working with panes at larger screen sizes.
Brain dump time. These are some of the things I think about re: art, specifically the type of art I’ve been doing these past few years (which admittedly has some quirks that other types of art wouldn’t necessarily have). These are in no particular order:
Concept. With this kind of minimalist religious art, the question is always: “How can I convey this idea in as few lines/shapes/colors/etc. as possible?” I usually mull over an idea, sketch something out until I feel loosely satisfied with it, then send it to my wife and we do a few rounds of feedback and revision. I also find myself thinking about other ways to represent things minimally, beyond just the circles, triangles, and rectangles I’ve used. (Yesterday’s Peace, Be Still felt like a nice change, for example.)
Process. The main question is usually: “What’s the fastest way to execute this idea without a drop in quality?” And, close on its heels: “What style do I feel like working in right now?” At the moment, the process I tend to use most is this: refine the idea in Illustrator, then export to SVG, open the file in Vim and add in the filters (turbulence, displacement, erosion, etc.), using Quicklook to preview my work, then open it in Inkscape and export to a 6500×6500 PNG (or thereabouts), which I then texture in Photoshop. Writing it out like that makes it seem fairly time-consuming, but it’s usually not too bad. (On average, I think I spend a total of perhaps an hour per piece, though it’s usually broken up over several days.) Lately I’ve been itching to simplify my texturing process, or perhaps to try wildly different textures. (With this type of art, I’ve found that it’s the idea that matters most. As long as it’s adequately conveyed, the rest — which tools I use, what style I do it in, etc. — doesn’t matter nearly as much.)
Releasing. I often think about whether I should care what time of day I post pieces (and usually decide that I don’t care), whether I should only post one piece per day max (I go back and forth here but usually post whatever pieces are finished regardless), and how much explanation I should give in the captions. I also think about how checking Instagram and Facebook for likes and comments feels a little like a soul-sucking death trap. Sometimes I think about ditching both platforms and posting art only to my site, but I’m not quite ready yet.
Storage. Last and probably least, I find myself frequently thinking about how much storage all these original image files are taking up. It’s a bit silly since it’s peanuts compared to video and I have plenty of disk space, but the part of my brain that loves plain text often points out that a novel takes up a mere few hundred KB while these original image files are usually a much larger 50–80 MB each (full-resolution lossless PNG; I’ve thought about JPEG but I don’t think I want to go down that road). And then I tell that part of my brain to hush, since it’s not a real problem.
I’m getting a bit of a nostalgia kick reading through the Standard Ebooks process. I haven’t made anything with them (though they do good work and I’m reading two of their editions right now), but years ago — in a former life, it seems — I used to make ebook editions of old books.
As far as I can tell, the first ebook I made was Chesterton’s The Ball and the Cross, which I typed up by hand and posted to Project Gutenberg. Around that time I worked on a handful of other books for PG, including Henry Sweet’s An Icelandic Primer, which was much more involved (Old Icelandic characters, tables, etc.) and incredibly fun.
Somewhere around five or so years ago I stopped, partly from working on other things, partly from repetitive strain injuries. (Even with Vim macros to help, there’s still a multitude of repetitive keystrokes in cleaning up texts, at least for me.) With reading about Standard Ebooks and writing this post, though, I’m tempted to get back into it. I built Fledge years ago as an attempt to script away more of the repetitive work, and I suspect wiser use of both it and Vim might be enough to minimize the RSI.
On a related note, I’ve been wanting to rewrite md2epub. It’s a decent-enough Python script that takes Markdown files and turns them into an EPUB, and it’s worked well. But it’s an old codebase, and I don’t like the name anymore, and it could be faster, and I have a few ideas on how to make it more ergonomic, so I’m planning to dub it Caxton and rewrite it in Go or Rust. (Primarily so I’ll have an easier way to make EPUB editions of my fiction.) This part is the most likely to actually happen, I think.
I realized (this is the very small breakthrough I mentioned yesterday) that I could use Blender to add 3D texture to my pieces. Verisimilitude has been the goal all along, and using an actual 3D renderer brings so much to the table that it boggles my mind that I didn’t think of this much earlier.
A closeup of the texture:
How I made this piece: I mocked it up in Illustrator, then exported it to SVG where I manually added the turbulence and displacement filters (in Vim) to distress the edges of the white square, which you can see in that closeup. I used Inkscape to export the SVG to a 6500×6500 PNG.
Then, in Blender, I created a plane and went to town on the shading, using a combination of procedural and image textures to mix the colors together and displace the geometry of the plane. There’s a key light and a dim fill light. And in the compositor I added a little chromatic aberration around the edges with the lens distortion filter.
Rendered it at 5200×5200, which took about two hours on my 16″ MacBook Pro. I tend to work a little smaller and then upscale to 6500x6500 (for square pieces), since Photoshop’s upscaling is fairly decent these days. After upscaling, I added my signature thingie, which I’ll add in Blender in the future so it fits in better.
Here’s the node setup on the plane (and in the future I’ll use groups to make things more manageable):
Overall, I’m happy with this technique. It’s more time-consuming than painting textures in Photoshop, but I can do other things while it’s rendering, and the result looks much better to me. Working in 3D is more fun, too. Most importantly, using Blender gives me loads of new options that would have been harder to do well with my old technique — shiny paint, glowing materials, etc.
Achievement unlocked: today I finished the first draft of my (as yet untitled) novel, weighing in at just over 260 pages (65,000 words).
It’s a good feeling, but the work is far from done. As mentioned, I’ll let it sit for a month or so to distance myself from the text, then it’ll be time to dive into editing.
In the meantime I’m still planning to write several short stories and outline my next novel and try to figure out ways to speed up this novel-writing process without sacrificing quality. Fall semester starts soon and will inevitably slow all of this down, but hopefully not to a halt.
An update on the novel: I’m at around 226 pages on this first draft, which translates to roughly 87% done, based on my wholly arbitrary target goal. I also wrote out a brief sentence or paragraph about each of the remaining chapters, so that I have some semblance of a plan (which will almost certainly change).
Barring any serious life events, I should finish by the end of next week. Next week! After so, so many failed novel starts, it’s a wonderfully mind-blowing to finally approach this end of a full draft.
My current plan is to let the book sit for a month before I start editing. During that time, I’ll write short stories and plan my next novel (so that I have a rough outline when I start writing).
Also, once fall semester starts — the final semester of my master’s, here at last! — I’m planning to drop my daily word count goal from 1,000 to 200 or 300, to keep from overburdening myself. My hope, though, is that schoolwork ends up being manageable enough that I can still write more.
Brief backstory: when I’m doing my minimalist religious art, I usually sketch an idea out first by hand or in Paper on my phone, then mock them up in Illustrator to iterate on the concept. Once it’s satisfactory, I move to execution, either painting the piece in Procreate or using some of the brushes in Illustrator to get a more organic look. And finally I texture the image in Photoshop.
A couple months ago I got interested in exploring alternatives to Illustrator and Photoshop for both execution and texturing processes. And me being me, I wanted to try doing it in code, just to see what it was like. (Some things are easier in code, though I don’t know how often that would actually be the case with these.)
Note: this is still very much a WIP, and who knows if I’ll end up using any of it or not. But here’s the current state of things.
SVG
After reading somewhere that SVG has turbulence and displacement filters, I realized I could potentially use those for the execution part of the process, to distress the edges enough to make things more interesting. (And hopefully to be less repetitious than the Illustrator brushes I use.)
I put together an initial test using a few different settings, and it turned out a bit better than I expected. A sample of the code:
The background rectangle, the red figure, and the white figure all have different turbulence and displacement values. The red figure uses two sets of turbulence and displacement filters, which worked out fairly well, I think.
I used Inkscape render it out to a high-res PNG, since Illustrator wasn’t able to handle the filters. Eventually, if I keep going down this path, I’d hopefully be able to find a command-line tool that can do the rendering. (Maybe Inkscape has a headless option.)
Overall, this path seems promising. I don’t know that I’d use it all the time, but for certain things it may be handy. I still need to look into sane ways to round corners, and it seems that the other filters (dilation/erosion, convolution, etc.) may be helpful, too.
Grain
I’ve begun writing a Python script called Grain for texturing the final art image. The goal here is to see if I can streamline the process at all, and to see if this idea even works. Grain takes as input a text-based input file that looks like this:
Each block is a layer. Grain starts with the bottom layer (the executed base image) and goes up from there, adding each layer on top with the specified blending mode and opacity.
The :pattern roughdots command would generate procedural dots (not implemented yet), and the textures# bit in the :image command calls is a shortcut to my folder with texture photos.
So far, the results are disappointing. While the layering does currently work, it isn’t yet producing anything remotely publishable. I think there might be some discrepancies between blending modes in pyvips and in Photoshop. Hard to tell.
And, less importantly, it’s a little slow — partially from using high-res images, partially from Python. If the idea ends up working, I’ll most likely port this to Rust or Go, and probably also have scale things down for the exploration phase of texturing (with a final high-res export at the end).
I’ll keep tinkering with it from time to time and we’ll see how it goes.
Lately I’ve felt a bit stuck with the minimalist religious art. Ideas aren’t coming as easily as they used to. Over the last month or so I’ve iterated on a lot of mockups that haven’t gone anywhere, and while that’s normal, usually there are more ideas that make it through.
I’ll keep plugging away at it, though — I feel reasonably confident that there are still many gospel concepts and stories that would work in this format. (And many more that wouldn’t. Some things seem impossible to abstract away into simple shapes.)
