Blog: #design

I’ve started work on a picture book, and me being me, I ended up making some storyboarding templates. Currently there are PDFs for 24- and 32-page square books.

(And yes, this is one way I’m avoiding work on the actual book.)

Reply via email

So I got this idea of making an outline map of Britain and Ireland and then compiling a list of fifty populous/famous towns and cities, to see how well I can locate them on the map. Being an Anglophile, I thought I’d do pretty well. Ha. It was sad. (But I did get London.)

Anyway, should you care to test your knowledge, you can now download PDFs of both the map and my semi-arbitrary list of towns and cities. Enjoy.

Notes on how I made these

For the map, I used TileMill to style and generate the map lines. I exported the map to SVG, converted it to Illustrator, and then imported it into InDesign and added the label.

For the list of towns and cities, I took a list of the most populous cities and added in some literary places as well. Basically, it’s a very-not-comprehensive list of places in Britain and Ireland that I’ve heard of.

Reply via email

I threw together a (very) rough mockup to explain a few of the ideas I mentioned last week:

Again, super rough, and lots will change. Salient points:

• Text preview windows. They’re using Markdown converted to HTML and styled with CSS. The idea is to be able to see how your changes affect the typeface when it’s being used on a page (and with the age of ereaders, it’s good to be able to test light on dark as well).
• Revisions. Ideally, it’d be nice to have a preview pane showing a page using an older revision and a preview pane showing your current work, so you can see if your changes are better or worse. And being able to revert to an older revision would reduce the stress of trying things out. (Hmm, I wonder if branching ala Git would be worthwhile…)
• Glyph code. Under the glyph, you can see some rudimentary code describing the glyph. I’m not sure this is the syntax I’d use, but it’d be something fairly similar. (Point type, point coordinates, and then zero to two control points.)
• Regular + italic. As you can see in the preview windows, I want to make it easy to preview italic along with the regular. I don’t know yet what ramifications this has for the font view or glyph editing, but I’ll figure it out.

What I’m not including in this mockup:

• A tool palette. I’m not sure yet if I want to have one at all, actually. With the heavy emphasis on keyboard shortcuts (and with a search that knows about tools), I don’t know if I need one. Or at least not a traditional palette. We’ll see.
• Settings menus for each window. Still not sure how I want this to work, but it would be similar to the side panels in Blender.

And of course there’s a lot more to figure out and work through.

Reply via email

I’ve decided that I’m now done with Pigna — partly because I’ve learned the technical things I set out to learn, but mostly because I’m seriously itching to design a real typeface, one I’ll use for actual text work. But first, a review of what’s happened since my last post:

Diacritics

I learned how to add anchors thanks to a tutorial by Peter Baker. It’s quite easy and mmm, diacritics. (The acute, grave, cedilla, and macron are the only marks I drew, though.)

I also played around with the mkmk feature for stacking marks on other marks and got it working (with an acute on top of a macron).

Italics

For the heck of it, I ran Pigna through FontForge’s convert-to-italic feature, and this is what it came up with:

It didn’t have a crossbar on the ‘f’, and the ‘d’ was somewhat mangled, so I fixed both of those. But other than that it’s straight from the conversion. It’s interesting. I’ll still draw italics by hand when I do them for real, though.

More kerning

I also added the em dash and en dash and curly quotes, but I decided to leave out the oldstyle numerals. (I learned how to do them with a small test font, though.) And I added more kerning, as you can perhaps see in the latest Tom Sawyer test sheet:

Conclusion

That’s all, folks. Pigna has been a good learning exercise, and it’s gotten me to finally make a typeface. Turns out it’s easier than I thought, especially once I got past the initial learning curve. Now on to the real work of making a good typeface.

Reply via email

Ever since seeing the IPython notebook, I’ve been thinking about how its notebook idea would be great for genealogical research. So I put together a (very rough) proof of concept:

Some notes:

1. A text-based query interface (the queries are in purple) to get information from a database. I don’t know that the best query language would be natural language like this — it’s more just to get the idea across — but the important thing is being able to easily do these types of queries against the genealogical information you’ve stored, enabling all sorts of analysis. “Who in my tree is born more than nine months after their father died?” “Who got married when they were younger than 12 years old?” “Who are all the children who died when they were younger than eight years old?” And so on.
2. Interleaving queries, their results, and other text (using Markdown, of course). This is the core notebook idea. Or you can look at it as an annotated transcript of a query session. Rather than just having a list of queries and their results, you sort of embed them in between your writing about the research. (Similar to literate programming.) For me, writing things out helps me to see what I think and wrap my head around the research.
3. There’s a lot of room for data visualization here. I’ve only shown pedigree charts and some basic tables, but it’d be easy enough to have a query return any other type of chart — bar, pie, fan, you name it. Including interactive things like the family analysis tool.
4. I didn’t include this in the mockup (because I, uh, just barely thought of it), but you could extend the query language to support hypotheticals. “Show me what William Crowder’s family would look like if he and Sarah got married in 1820” or “From now on, pretend Samuel Shinn was born in 1860.” And then following queries would act as if that were true. It’s nice to be able to establish a few suppositions and then see what the ramifications would be, whether they’re plausible, etc. Or to compare two different hypotheses.
5. Which brings us to the purpose of all this: to have a good place to do the rough, messy side of genealogical research. Thinking through things, seeing what comes of it, and keeping a record of the journey, basically.
6. Since the information in the database would be subject to change (as you do more research), it would probably be good to cache the results. Or maybe highlight the queries whose results have changed when you reload a notebook. Personally, I lean more towards caching, so that the notebook accurately represents the database at the time it was written (making it a valuable historical record of your research), but you could also look at it as a living document that updates automatically when the background data is updated.

Anyway, the proof of concept is just a static HTML page. I’m not planning to do anything more with it, but I wanted to get the idea out there.

Reply via email

First, a couple premises:

• The web is now the best document delivery platform, and that will become even more true as time goes on.
• Documents need to be flexible so you can view them on any size device — desktop, tablet, mobile, anything.

As I’ve been doing more responsive web design, I’ve been thinking that this principle of reflowable content could apply to sheet music. For example, here’s a normal page of sheet music (from the Mutopia project):

If you were to view this music on a smartphone, you’d either have to zoom all the way out (making it super small), or zoom in on just one section of the page and pan around, which can be a lot of two-dimensional panning — not too great if you’re trying to actually play the music.

Neither is ideal. So I’m thinking maybe sheet music should automatically reflow to fit your viewport — the way both text and responsive websites do:

(This is just a quick copy-and-paste mockup — in reality you’d keep the clefs on each line and probably make things a little smaller and so on — but you get the idea.)

So as the viewport shrinks, you would drop the space between notes until you hit an unacceptable squishiness, then drop the number of measures per line by one and set the space between notes to be wider to fill the space again. Rinse and repeat. By the time you’re down to smartphone size, you’d probably be at two measures per line as in the above mockup.

Implementation

In a perfect world, there’d be a set of tags in HTML for typesetting music, and the browser would do the rendering, and CSS media queries would take care of the rest. That will almost certainly never happen, though, since it’s too domain-specific. I think the best we can hope for is a JavaScript rendering engine that uses SVG — something like Vexflow.

One other thought: jumps (repeats, codas) should be hyperlinks, so the player doesn’t have to think about where to go. (And when it jumps to the location, it could flash a highlight or marker or something on the measure you should start at.) Or, even better, since we aren’t really worried about taking up space, just flatten repeats and codas altogether — take the repeated section and write it out. Space isn’t as much of an issue on the web. The disadvantage is that it’s not as easy to know that the repeated section is in fact identical.

Disadvantages

If you’re only seeing one or two measures per line on, say, a smartphone, and if you’re playing something with more than one staff (piano music, for example), then you’re going to be doing a lot of scrolling. So you probably wouldn’t want to go down quite this much.

There’s also a slight loss of familiarity. When you play a page of music over and over again, you get familiarity grooves etched into your mind; with responsive sheet music, you wouldn’t really get that as much. (If you used the same device every time in the same orientation, then it’d be a little more stable, but you’d be scrolling instead of flipping pages, which anchors things less.)

Ticker-style sheet music

Another idea that came to mind when I was mulling this over was reducing the music to one line and automatically scrolling it like a ticker. (This probably already exists. Responsive sheet music may exist as well, but I couldn’t find it — if someone has already implemented it, let me know. I want to use it.)

Advantages:

• Focus. Since the music is one-dimensional, the player doesn’t have to think about other dimensions (down and up, where the end of the page is, etc.).
• Linearity. With this style it really would be better to flatten out repeats and codas, so it’s just one long line of sheet music. Then you don’t have to spend any mental cycles thinking about jumping around.

The disadvantages are pretty much the same as with responsive:

• You lose some familiarity — with a full page of music, you get used to its layout and it reminds you of things, whereas a scrolling ticker would always feel somewhat new.
• Flattening repeats makes you lose the knowledge that the repeated section you’re starting to play is the exact same as the previous section.

Reply via email

Toby Schachman just blogged about his brilliant new live graph editor that breaks down a function to show you each component visually:

Want.

Reply via email

A while ago I said I was going to post more in-progress stuff, but I haven’t really done that. So, here’s one of my current projects (click for the full image):

It’s a little app (currently just a mockup) that helps you track LDS temple ordinance work. With my own family history work, I’ve found that it’s a bit of a pain trying to remember which sealings I can do and which I’m waiting on the endowments for. I’d rather let the computer do that. So, the idea with this app is that it’s smart enough to keep track of the relationship between people (children and parents, spouses) and know which ordinances you can do and which you’re still waiting on. (I haven’t mocked this up yet, but in the Sealings column, there’ll be a ghosted area for sealings waiting on other ordinances.)

The other use case is that when you’re about to go to the temple, it makes it easy to see at a glance what cards are ready for whatever ordinance you’re planning on doing. “I’m doing initiatories, okay, here are the cards I need to take with me.” That kind of thing.

I’m also planning to include a stats page so you can see how many ordinances you’ve done each month (separated out by type) and get a list of all the people you’ve done the work for.

Progress-wise, I’ve got the design roughly where I want it (with polishing still left), so I’m just figuring out the backend logic and planning out the code.

Reply via email

In genealogy web apps, I kind of like consolidating name fields into a single textbox. Simpler is better. But then you run into the problem of distinguishing the surname from the rest of the name — because of surnames like “Gutierrez Sanchez,” you can’t just assume the surname is the last word in the string.

I’ve been thinking for a while about a clean way to deal with this (as well as giving a nice visual indication of the surname instead of just slashes), and here’s what I’ve got so far, which I’m dubbing (rather unimaginatively) the Javascript name box:

When you click on the name, it becomes editable:

How it works

Basically, you give it an input.namebox element and it creates a corresponding div tag for displaying the highlighted surname. It then flips back and forth between the input and the div, parsing the name field and changing the highlight appropriately.

Live demo

Javascript name box

Reply via email

This is the project that spawned my CSS mini timeline adventure (which I ended up not using, actually). It’s a really simple proof of concept for analyzing family relationships:

You enter basic information for the family and on the fly it draws a timeline and shows you how old each person was when other major family events happened (siblings born, deaths, etc.). Super simple. It’s mostly so you can get a better feel for what all the dates actually mean — you can see that so-and-so was only 16 when her mother died, or that there’s a gap where a child could have been born, etc.

Anyway, I’ve got an online demo up, and you can get the code from the project page.

Also, this is just a proof of concept — I’m not completely satisfied with the design, and the print stylesheet needs more work (but yes, there’s a print stylesheet), and there are plenty of issues left to resolve (some of which are on the GitHub issues page for the project) — but you get the idea.

Something like this would be more useful when hooked up with a data store (like FamilySearch, for example, which wouldn’t be very hard to do). Then you wouldn’t have to type everything in.

Reply via email