Colophon: I made these with JavaScript/Node, generating SVGs that I then converted into PDFs with Inkscape.

Reply via email

This time the chart doesn’t have a specific year baked in, so it’s reusable. (And there’s a variation for leap years.) It’s freely available as PDFs in both portrait and landscape. Currently just letter size, though maybe someday I’ll start including A4 and other sizes.

Colophon: I made these charts with HTML (it’s just a table), CSS, JavaScript (on page rather than via Node), and Firefox. The font is Avenir Next.

Reply via email

Counsel with the Lord in all thy doings (Alma 37:37)

I will go and do (1 Nephi 3:7)

Reply via email

Why would you use this? No idea. I haven’t been able to come up with any good use cases for it, but the itch needed to be scratched so here we are.

Sidenote: I made the original lined/grid paper with PlotDevice but decided to use SVG instead this time, converting the files to PDF with Inkscape.

Reply via email

Ruby test

Implementation notes:

• 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)

Design notes:

• 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

Implementation notes:

• The names are wrapped in span tags with position: relative set, and the SVG gets position: absolute. Fairly simple.
• Even leading!
• 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

Reply via email

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.

Design Engineering Handbook by Natalya Shelburne et al., a free ebook which looks interesting. (I’ve read part of the first chapter so far.) Design Better (which appears to be an InVision thing) has other free books available as well, on various design-related topics.

Max Koehler on continuous typography. Also see his post about the tool and the tool itself. This is great, and I hope these ideas get broader traction. (Also, I’m excited to start using Source Serif 4 and its optical sizing axis.)

Aleksey Kladov on including an ARCHITECTURE.md file. Great idea. Having a high-level overview is so helpful.

Graydon Hoare on always betting on text. I’ve probably linked to this before, but it’s good and worth rereading occasionally.

Reply via email

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.

Reply via email

Reply via email

Reply via email

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!

Problem definition

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.)

Research

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.)

Sketches

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.

Blockframes

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.)

Wireframes

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.

Color palette

Next I chose a (very) simple palette:

Ordinarily, though, I’d need a more complex, organized color scheme.

High-fidelity mockups

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.

What’s next

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.

Reply via email