Since the phone is now the window to the soul, here’s my current home screen:
Things of possible interest (or more likely imminent boredom):
30 Seconds is a system shortcut I made that starts a thirty-second timer, which I use for my physical therapy exercises morning and night (I used to use a third-party app until I realized I didn’t need one)
Projectile (an app version of my project tracker), Bookshelf (reading tracker), Slash (blog engine), Storybook (writing app), Momentum (time tracker), and Liszt (to-do list) are all PWAs I’ve built
While it’s kind of weird (they’re the same exact app), I love that Marvin SxS is on the App Store alongside Marvin; I use the dark-background Marvin for fiction and the white-background Marvin for nonfiction
From left, the three bottom apps in the dock are Codex (notes app), Saturn (launcher), and Gate (Drafts clone), which are also PWAs I’ve built, and clearly I have a problem
I currently have 136 tabs open in mobile Safari, and clearly I have two problems
Brief and no doubt boring update on internal tooling:
As of a few days ago, I’m planning to take Vinci (logs), Arc (notes), Storybook (fiction writing), and possibly Slash (blog) and smush them all together into a new, streamlined Django app called Writ. (Fundamentally, they’re all tools for writing, and there’s enough overlap among them that keeping them split out isn’t worth it to me.) Still in the initial design/planning stage. Looking forward to simplifying things a bit.
I’m no longer intent on using plain text as the data store for my apps. The main reasons I wanted to do this in the first place: a) archival durability and b) rampant minimalism. For the first, I’ll instead have all my apps export everything to plain text whenever there’s a change. It won’t be canonical, but it will be a redundant copy of the data so it’s even more archivally durable. As for the minimalism, well, sometimes one can go too far.
Lastly, I’m looking into hosting my site statically via Linode Object Storage (ala S3). Still exploring ramifications — redirects, etc. Main goal with this is to make my site more resilient, and even if the object storage part doesn’t work out, I’ll still move the site over to a new static engine (which I’m naming Cast, and I plan to write it in Go).
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.
Not very long ago I felt like Storybook was a bit cumbersome, and in a fit of consolidation glee I decided to trash it and instead use Arc for my writing. I got as far as adding wiki-style links and backlinks (still helpful additions), then realized Arc wasn’t actually a good fit after all — my brain apparently doesn’t like having the story drafts in among all the other notes. It seems to like things in separate bins.
So Storybook lives after all. There are, however, gobs of cruft that have built up over the years — several features I tried out and then ended up not sticking with — so I’m going to rewrite it from scratch using FastAPI and plain text storage (as mentioned before). Leaner and more focused. Looking forward to it. (On this I’ve done some preliminary planning and have written a script to export the old data in the new plain text format, but that’s it.)
I’ve been using Arc to plan the editing of the novel. It works, but I’ve also found myself wondering if an infinite canvas tool like Figma or Milanote might be even better, with the power to break out of the cold confines of a linear column of text. You can probably tell where this is going, can’t you. And you’re right: because it foolishly doesn’t seem like that hard of a problem, and because I want full control (ha, what an illusion) over both the experience and my data, yes, I’m making my own infinite canvas web app. It’s called Space. It’s in the early amorphous stages of planning and will likely stay that way for a while because I’m in the middle of the semester. But I’m excited about it. (And have been for a while; this project’s been on the docket for over a year.) I initially planned to use canvas, but before I settle on that I’m going to try WebGL; if it works, it would allow for much more interesting possibilities, along the lines of the spatial interface ideas I alluded to a while ago.
Some quick thoughts about the project space I see myself working in (meaning personal coding projects that aren’t the productivity tools I mentioned before), both now and for the foreseeable future. To be honest, it’s mostly a roadmap for myself, posted here as part of working in public.
Bookmaking tools
One of the areas in the project space is bookmaking tools: tools that help with making either print books or ebooks. What I’ve worked on in that area (and some of these are still in progress or in the future):
Storybook — writing tool (covered under the productivity tools, yes, but I feel it fits in here)
Creativity tools
The next area, somewhat related, is creativity tools: tools for making art, music, etc. I do realize that there’s a bit of overlap between the two areas — art can be used in books, for example. This is not a rigorous taxonomy.
While I haven’t done much in this area so far, the intersection of software and art has been calling to me more lately. I expect creativity tools to become much more of a focus for me, probably even more so than the bookmaking tools.
Human-Computer Interaction
Last but not least, HCI. My master’s thesis is in this area, and much of my other work also touches on it in limited ways. (What I mean by that, I think, is that with projects like Trill, Curves, and Press, the parts that have most interested me are the interfaces. Also, those interfaces have been textual in these particular cases, but I’m also interested in other kinds of UIs.) So I plan to start building more proofs of concept and interface experiments — like the spatial interface ideas I mentioned several weeks ago.
Still another entry in the will-it-ever-end series talking about my personal productivity tools.
Storybook is my fiction writing app. It’s a Python app running Django. The name comes from, uh, books with stories in them.
Overview
First, the dashboard, which lists weekly writing stats and active stories at top and backburnered stories at bottom:
The writing view has a stats bar at top (showing how close I am to meeting my daily 1,000-word goal) and then the textbox for the actual writing:
The menu has some overall story stats and an outline (with somewhat vague and hopefully unspoilery scene titles), and some admin links:
Syntax
As you can see from the screenshots, it expects Markdown. I’ve put in a convention hack where h2 tags (##) delineate scenes. Also, scene titles that begin with “Chapter X” create chapter divisions. (Clarification: a story has a flat list of scenes. The chapter divisions are display-only.)
How I use Storybook
On my laptop, I have it open in Firefox as a pinned tab. On my phone, I have it saved to my homescreen as a PWA.
I mostly avoid using Storybook (cough) but somehow still manage to put in a thousand words a day, one word after another.
There’s a payload syntax so I can send writing from Gate or Quill to Storybook, but I never use it.
The future
Same old story: I’m planning to move it to FastAPI and start using plain text files for storage instead of a database.
At some point I want to refactor the outline UI and add search functionality.
I’m currently working on a short story (working title is “A Glass Darkly”), outlining the whole thing before I write it. For a while I thought I might be a discovery writer, but I’ve learned that I do better if I have a solid plan. Figuring out the structure of the story beforehand — the overall arc, the individual scene arcs, the character arcs, etc. — seems to help me write better stories, and not to panic when I get to the middle and usually have no idea what should come next. Structure is my friend.
Anyway, I’m wrapping up the outline (figuring out the middle, as it happens), and should have a first draft banged out a week or so after that. This time, rather than releasing it on my site immediately after I finish it, I’m going to start submitting it to magazines, something I haven’t done before. Racking up a few rejection slips will be a good thing for me as a writer, I think. (Sidenote: I’m very much on the fence re: trying to get my fiction traditionally published vs. self-publishing it. But that’s a topic for another post.)
Tool-wise, I put together a Google spreadsheet for tracking daily word counts, but I realized that when I’m not drafting — when I’m outlining — it doesn’t make sense. Time spent (plus deadlines) is a better metric. So I’ve revised my spreadsheet to track minutes instead.
I’ve also been itching to have a better place to do the actual outlining and writing. This may just be my neverending toolmaking itch, but I think it’ll help me be more productive. I want to write an outline, then flesh it out in place into a list of scenes, then flesh that out into an actual draft. A simplified version of the snowflake method, basically. Forest, trees, branches, leaves.
While you could do this fairly easily in Word or any other writing app, some of the other bits I want (easily moving between levels of abstraction, drag and drop reordering of scenes, etc.) might not be as easy, so to work through the ideas and figure out what I really need, I’m working on a new web app called Storybook. I built an initial prototype a few months ago, but it isn’t very good, for a number of reasons (it isn’t mobile-friendly, it’s too cluttered, etc.). I’m in the middle of rethinking how it should work, and I think I’ve got a better handle now on how the UI should work.
A final word: back in my younger days, I would build tools and then stop using them after a short time. I’m not entirely sure what changed, but now the tools I build stick with me a lot longer, and I can easily see the productivity gains from using them. Toolmaking does take time away from whatever it is the tool is supposed to help me with (writing, in this case), but I’ve found it to be well worth the investment.
