Lately I’ve been playing around with implementing genealogy sparklines on the web. Still very much a work in progress, but I’m trying to do more working in public, so here’s the messy current status (and at some point I’ll post the actual HTML/CSS):
The sparklines use inline SVG
This test uses the <ruby> and <rt> tags, with ruby-position set to under and ruby-align set to start (though only Firefox supports it so it’s not sadly viable for actual use yet)
I don’t really like that it makes the leading uneven (lines that have ruby vs. lines that don’t)
Rather than having solid squares at the births and deaths, I’ve gone for vertical lines so they’re less obtrusive (and have also considered just getting rid of the vertical lines, though I haven’t tried it out yet)
Circles are simple so I went with them for marriages and children
Absolute positioning test
The names are wrapped in span tags with position: relative set, and the SVG gets position: absolute. Fairly simple.
There’s some wonkiness right now when the span is at the beginning of a line (the sparkline shows up at the end of the previous line), haven’t tried very hard to fix it yet
Trying out a new format with these link bundles, in the hope that dropping the bulleted list format is a) more flexible and b) more conducive to writing a bit more about the links, rather than limiting myself to a single line with an awkward semicolon shoved in if I need more room.
Andy Bell on recent/upcoming CSS changes. Good stuff here. I’m probably most looking forward to using :is and clamp() and ch (all of which I’d read about before but had mostly forgotten). Oh, and scroll-margin-top.
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.)
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.
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:
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.
The initial version of my design portfolio is now live. Whew. Time for a breather over the weekend and then I’ll be diving back in to work on the next case study, a web-based revamp of Curves. It’ll be a new, graphical tool for designing type, and yes, I’m totally re-using the name because a) I never released the old project with the same name (the Python library), and b) there was actually a graphical version that came first (though I don’t know how much of that initial mockup will make it into the new design).
As I’ve been toiling away on my design portfolio, I realized that a) I haven’t been working in public on this project and b) that ought to change. Which it will. Starting now.
My plan at this point (subject to change) is to design the portfolio site itself first, then post each case study project as I finish it.
The portfolio site
Note: the following is effectively an initial draft of a case study documenting the design of the portfolio itself. It’s a little meta, sure, and I expect to replace it in the portfolio as soon as I have enough other projects, but it’ll do for now. And if reading case studies isn’t your thing, stop here!
The goal: to design a site showing what I do as a designer, both in the case studies showcased as well as the design of the portfolio itself.
The main users of the portfolio will be hiring managers and recruiters, who will be evaluating my work to determine whether they should interview me. From what I’ve read, they’re primarily interested in seeing my design process—how I tackle a project, how I solve problems—and secondarily interested in the quality of the final designs. (There’s more to it than that, but you get the idea.)
I began by doing some lightweight competitor analysis, looking at thirty or so portfolios for UX/product designers, and watching a handful of critique videos. By that point I had a good idea of what ought to be involved—initial text describing what I do and what my experience is, case studies documenting my process, a link to my resume, my contact info—and I felt that the site was small enough that I didn’t need to do more formal research at this point. (On other projects, though, this is where I’d do surveys, interviews, card sorting, tree tests, empathy maps, personas, usability tests, etc., depending on what makes the most sense for the project.)
I sketched out some ideas for the nav, starting with mobile first since it’s easier to begin there and scale up to desktop:
I also sketched out some rough layout ideas, with the main focus on the list of case studies on the home page and the case study detail pages.
Last week I was reading about blockframing and have been itching to try it out, so I did:
It’s great. Easier to work with than wireframes, which helps in the earlier stages. Definitely planning to continue using it. (I should also mention here—for curiosity’s sake if nothing else—that I used Figma for everything past the point of sketching.)
I continued with wireframes, to flesh out the ideas with actual text (placeholder text, anyway):
Crimson Text is the primary font (indeed the only font), which I chose because a humanist (old style) serif seemed like the best fit for my personality and the type of design I do.
Next I chose a (very) simple palette:
Ordinarily, though, I’d need a more complex, organized color scheme.
And then we come to the high-fidelity mockups (in which the photos are all from Unsplash or Pexels, and the case study text is made up):
As I applied color, it became clear that the design would benefit from a secondary font, so I added Chivo as a compatible sans-serif. I also added clearer call-to-action links to the individual case study sections on the home page.
Doing some small usability tests to make sure the design works, then straight to implementation. I’m planning to skip prototyping for this project because a) it’s so, so small and there’s not much to prototype beyond dead simple link behavior, and b) with this being a personal project, I’ll be doing the frontend development, and the initial implementation there will be a fairly effective prototype.
Just posted some note paper PDFs which I made in PlotDevice. There’s lined paper — 30 lines/page up to 130 lines/page (for those who write really, really small) — and graph paper — 10×10 up to 140×140.
The only time I’ve had success writing each day has been when I’ve made a physical chart, taped it up on my wall, and then filled in a box each day I hit my goal. It’s Jerry Seinfeld’s don’t break the chain idea, and it works remarkably well for me. My current streak (I don’t write on Sundays):
Since this seemed like it might be useful for others, I’ve made daily goal charts, available for free PDF download:
There’s also what I’m calling a “blank” chart, where you can write in the number of words you wrote (or anything else like that):
Charts for 2018 through 2023 are up. (I figure five years is enough for now.)