Posts in the Projects Category

Hamonshu

Published 1 month, 3 weeks past

I ended my observance of CSS Naked Day 2020 by launching an entirely new design for meyerweb.  I’m calling it Hamonshū after the source from which I adapted most of the graphic elements.  I’ve been working on it sporadically in my free time since mid-January, finally coming to a place I thought was ready to launch in late March.

Naked Day was a convenient way to change over the structure of pages while there was no design, which probably makes it sound like that’s the only reason I even observed it.  To the contrary, I hadn’t planned to launch the new design until June 8th of this year—but once I decided on going style-naked, I realized it was the perfect opportunity to make the switch.

I might still have delayed, if not for everything happening in the world right now.  But Cameron Moll said it best as he recently launched a new design: “Deploying in the middle of a pandemic seems so unimportant at the moment. Or maybe there’s no better time for it.”  That last sentence resonated with me unexpectedly deeply, and came to mind again as I took the CSS away for Naked Day.

I’ll have quite a few things to say about the design in the future: things I learned, techniques I used, bits I really like, that sort of thing.  In this post, I want to say a bit about its genesis.

It all started when someone—I’ve since lost track of who, or even where it happened—brought my attention to Hamonshū, Vols. 1-3, available on the Internet Archive thanks to the Smithsonian Institution.  Hamonshū, a word which I understand roughly translates into English as “wave forms” or “wave design”, is a three-volume set of art studies of water.  Created by Yūzan Mori and published in 1903, I had never heard of it before, but the sketches immediately appealed to me.  You can get an preview of some of Yūzan’s art in this article from Public Domain Review, or just go to the source (linked previously, as well as in the footer of the site) and immerse yourself in it.

As I absorbed Yūzan’s ink studies of ocean waves, rivers, fountains, and more, the elements of a design began to form in my head.  I won’t say I saw it—being aphantasic, I couldn’t—but certain sketches suggested themselves as components of a layout, and stuck with me.

Tall Bamboo and Distant Mountains, after Wang Meng, Wang Hui 王翬, 1694

Early on, I had thought to combine elements from Hamonshū with other artwork, primarily ink landscape paintings from the Qing Dynasty and Edo periods: two such examples being Tall Bamboo and Distant Mountains, after Wang Meng (Wang Hui 王翬, 1694) and View of West Lake (Ike Taiga, 1700s).  I made attempts, but the elements never really combined properly.  I eventually realized I was trying to combine close-up studies of water with adaptations of much larger works, and the scale of the brush strokes was clashing.  At that point, I abandoned the paintings and concentrated exclusively on Hamonshū.

As the various design elements came together, I went looking for fonts to use.  I originally thought to use variable fonts, but I kept coming back to IM Fell, a typeface I’d seen Simon St. Laurent use and had put to my own purposes in an experimental typeset of Neal Stephenson’s Mother Earth Mother Board.  IM Fell has a sort of nautical feel to it, at least to me, which fit nicely with the water elements I was adapting from Hamonshū, so I ended up using it as a “site elements” typeface.  It’s what’s used for the site name in the header, the main navigation links, metadata for posts, sidebar heading text, the h1 on most pages, and so on.

Originally I used IM Fell for the titles of blog posts like this one, but it didn’t feel quite right.  I think it caused the titles to blend into the rest of the design a little too much unless I kept it relatively huge.  I needed something that felt consistent, but distinguished itself at the smaller sizes I needed for post titles.  I went back to Google Fonts and scrolled through the choices until I narrowed down to a few faces, of which Eczar was the eventual winner.  In addition to using Eczar for post titles, I also employ it in the site’s footer, at least wherever IM Fell isn’t used.  The general body copy of the site is Georgia Pro, falling back to Georgia or a generic serif as needed.

One of the limitations I set for myself was to be reasonably lightweight, and that was a major part of the process.  The details merit a post or two of their own, but my overall goal was to get even the post archive pages under a megabyte in total.  I’m pleased to say I was able to get there, for the most part.  As an example, the main post archive page is, as I write this (but before I posted it) 910.98KB, and that includes the various photographs and other images embedded in posts.  The time to DOMContentLoaded over WiFi is consistently below 200ms, 400-500ms on “Regular 3G”, and 500-600ms on “Regular 2G”, all with the local cache disabled, at least when the server is responding well.  I still have work to do in this area, but I was comfortable enough with the current state to launch the design publicly.

Since I was redesigning anyway, I did some sprucing up of various subpages.  Most notable are the Toolbox and Writing pages, which use a number of techniques to improve organization and appearance.  I still think the top part of the Writing page could use some work, but it’s leagues better than it used to be.  The one major page I’d like to further upgrade is CSS Work, but I’m still looking for an approach that is distinct from the other pages, yet thematically consistent.  If I can’t find one, I’ll probably take the same general approach I did for Toolbox.  I also rewrote some of the microcopy, such as the metadata (publication date, categories, etc.) at the bottom of blog posts, to be more evocative of the feel I was going for.

Late in the process, I got a welcome assist from Jesse Gardner, who had seen a preview of article design.  He had the idea to make a traced SVG version of the “Hand Made With Love” necklace charm from the masthead of the previous design, and then he just up and did it and sent me the file.  You’ll find it in the footer of the site.  It isn’t interactive, although it may in the future.  I haven’t decided yet.

I really hope you enjoy the new look.  It’s the first design I’ve done that wasn’t cribbed off someone else’s site in, oh, 15-20 years, give or take, and I’m rather proud of it.  It won’t win any awards, but it makes the statement I want it to make, and visiting my own site gives me a little glow of satisfaction.  I don’t know if I could ask for more than that.


Woodshop SVG: Studs and Shelves

Published 4 months, 1 week past

As I’ve worked on my indoor workspace, I’ve continued to find SVG useful for planning purposes, and putting it to use in my planning has pushed me to learn more about the language.  (That last sentence is actually a play on words, for reasons that I hope will become clear by the end of the post.)

For example, the basement room I’m partially turning into a workspace has a set of exposed framing studs (exposed once I removed a couple of cabinets, anyway) that I wanted to turn into a set of rough shelving, so that I could organize the various bits ‘n’ bobs I accumulate: leftover bolts, extra pullchain, and so on.  These studs are perched on foundation cinderblock, about 48 inches off the floor, and run up to the ceiling from there.

Each stud is 28 inches tall, running from a 2×6 base up to a stacked pair of 2×6 crossbeams.  They also have strips of 2×10 mounted vertically at their bottoms, running between each stud.  (I’m not entirely sure why the 2×10s are there, but I’m not about to start ripping them out now.)

The distances between subsequent studs is also not consistent: they’re mostly close to 16 inches on-center, but not perfectly so, and the last set is only 12 inches apart because the framing ends where a set of stairs begins.  So I created a schematic, including a red box to mark where a 1-gang electrical box. protrudes from the other side of the wall.

The middle stud is taller as a reminder to me that, if not for the crossbeams, it could keep going up past the ceiling joist.  The others are essentially centered on the joists above them (centered within half an inch or so, anyway).

Why does that matter?  Because to make the shelves, I decided to mount 2×6s in front of the framing studs, to allow for shelves 11 inches deep.  So in cases where the studs are centered below ceiling joists, I can run the front-mounted 2×6es up to them.  In that middle case, I’ll actually need a longer 2×6 to run up next to the joist.

This all might sound like a lot of work to deal with odd circumstances, but that was part of the point of this part of the project.  We don’t always get to work in ideal circumstances.  Learning how best to work around the existing limitations is a valuable lesson in itself.

I tried out a lot of different shelf configurations.  At first, I was just using <rect> elements like this.

<rect x="1.5" y="9"    width="14.5" height="0.5" />
<rect x="1.5" y="19.5" width="14.5" height="0.5" />

That’s two shelves, ten inches apart, in the leftmost stud bay.  (The shelves are a half-inch thick.)  That worked okay for a while, but then I decided to show the support rails that would both tie the 2×6s to the studs behind them, and also hold up the shelves.  So that meant more <rect>s, like so.

<rect x="1.5" y="9"    width="14.5" height="0.5" />
<rect x="1.5" y="19.5" width="14.5" height="0.5" />
<rect x="1.5" y="9.5"  width="0.75" height="1.125" />
<rect x="15.25" y="9.5"  width="0.75" height="1.125" />
<rect x="1.5" y="20"  width="0.75" height="1.125" />
<rect x="15.25" y="20"  width="0.75" height="1.125" />

Again, that’s just for the first stud bay: two shelves, and then four supports, two for each shelf.  And I have five bays to do.

Still, it it took deciding to show the storage bins I wanted on the shelves to push to look for a better way.  Basically, what I wanted was a way to define a primitive of a shelf and two support rails, and then just place that.  And then a way to do the same for collections of storage bins, which could be stacked atop each other.

SVG provides for exactly this, through the combination of <defs> and <use>.  I set up a basic shelf set like this:

<defs>
    <g id="shelf">
        <rect x="0" y="0" width="14.5" height="0.5" />
        <rect x="0" y="0.5"  width="0.75" height="1.125" />
        <rect x="13.75" y="0.5"  width="0.75" height="1.125" />
    </g>
</defs>

If you think of that as its own little SVG, it defines a horizontal shelf 14.5 coordinate units wide, and half a unit tall, starting at 0,0.  It then places the two support rails just below, starting half a unit down from the top.

With that in hand, the two shelves I was drawing before collapsed from six lines to two:

<use xlink:href="#shelf" x="1.5" y="9" />
<use xlink:href="#shelf" x="1.5" y="20" />

Suddenly, rather than fiddling with the X,Y coordinates of several pieces just to move a shelf, I could adjust the X,Y of one <use> element.  To say this sped up my workflow would be a monumental understament.  Trying out different shelf spacing and shelf counts went from being a chore to being almost too easy.

This was only magnified when I wrote the definitions for storage-bin primitives.  At first, I drew them the same way I had the shelves, down and right from 0,0, but that was difficult in a number of ways.  Different bin sizes meant I had to do different math to get the bins to sit on the shelves.  And then I remembered that SVG is unbounded on both axes—which meant I could draw the bins up from 0,0, meaning I could give them the same y coordinate as the shelves.

Wait, what?  Let me show you.  Inside <defs>, I wrote:

<g id="bins4">
    <rect x="0" y="-4" width=".15" height="4" />
    <rect x="4" y="-4" width=".15" height="4" />
    <rect x="0" y="-1.5" width="4.15" height="1.5" />
    <rect x="4.2" y="-4" width=".15" height="4" />
    <rect x="8.2" y="-4" width=".15" height="4" />
    <rect x="4.2" y="-1.5" width="4.15" height="1.5" />
    <rect x="8.4"  y="-4" width=".15" height="4" />
    <rect x="12.4" y="-4" width=".15" height="4" />
    <rect x="8.4"  y="-1.5" width="4.15" height="1.5" />
</g>

Everything is drawn starting from above the y=0 line, and reaches down to y=0.  So that first <rect> with height="4" starts at a Y coordinate of -4.  -4 plus 4 equals zero.

That allowed the following:

<use xlink:href="#shelf" x="1.5" y="9" />
<use xlink:href="#bins4" x="2.5" y="9" />
<use xlink:href="#shelf" x="1.5" y="20" />
<use xlink:href="#bins4" x="3.0" y="20" />

See how the y coordinate is the same for both shelf and associated bins?  If I decide to move a shelf up an inch and a half, I just take 1.5 off the y value for the shelf’s <use>, and then use that same value for the y attribute on the bins’ <use>.

Could I have made this even better by combining shelves and bins into a single primitive definition, and only having one <use>?  Yes, if there would only be one set of bins per shelf.  That’s how I dd it in this particular arrangement.  (In this case, the brown vertical studs are actually the 2×6s mounted in front of the wall studs, so they’re taller and based lower.)

However, I also considered stacking bins on each other between shelves, as in this configuration.

That wound up being pretty close to what I did, in the end.

There were a couple of things I wished I could do (or wish I had figured out how to do) in SVG.  The first was a way of varying the width on the <use> elements.  The rightmost stud bay is 12 inches wide, not the 14½ inch bays the others have.  I ended up defining a separate primitive definition for those shelves.

<g id="shelf-sm">
    <rect x="0" y="0" width="12.5" height="0.5" />
    <rect x="0" y="0.5"  width="0.75" height="1.125" />
    <rect x="11.75" y="0.5"  width="0.75" height="1.125" />
</g>

I guess I could have done X-axis scaling transforms on the regular #shelf primitive.  Actually, looking back on it, that probably makes a lot more sense than what I did.  It would have squished the support rails a tiny bit, but not enough to throw off precision cuts or anything.  (There really were no precision cuts in this project—this is carpentry at its roughest.)

The other thing I wanted was the ability to draw “backwards” by giving negative height and width values.  So as an example, I’d have liked to write the rightmost support rail like this:

<rect x="14.5" y="0.5" width="-0.75" height="1.125" />

I know, I know, a negative distance doesn’t really make sense when talking about physical units.  I still wanted to do it.  I mean, it made sense to me in my head.

Just like the idea of hand-authoring SVG to plan out workshop projects made sense to me.  I’m sure I could have done it a little faster and a little more intuitively in a vector editor, but I’d have had to buy one (my copy of Illustrator no longer runs on my Mac, more’s the pity) and if I’d gone that route, I wouldn’t have learned a lot more about SVG and its capabilities.  Either way, the end result is pleasing to me… at least for the time being.


Woodshop SVG

Published 4 months, 2 weeks past

For the holiday break this year, I decided to finally tackle creating an indoor work space.  I’d had my eye on a corner of our basement storage room for a while, and sketched out various rough plans on graph paper over the past couple of years.  But this time?  This time, I was doing it.

The core goal is to have a workbench where I can do small toy and appliance repair when needed, as well as things like wood assembly after using the garage power tools to produce the parts—somewhere warm in the depths of winter and cool at the height of summer, where glue and finish will always be in its supported temperature range.  But that spawns a whole lot of other things in support of that goal: places to store components like screws, clamps, drills, bits, hammers, saws, wires, and on and on.

Not to mention, many tools are powered, and the corner in question didn’t come with any outlets.  Not even vaguely nearby, unless you count the other side of the room behind a standing freezer.  Which, for the record, I don’t count.  I had to do something about that.

So anyway, a lot of stuff got cleared out of the corner and stored elsewhere, if it wasn’t just tossed outright.  Then I took a couple of cabinets off the wall and remounted one of them elsewhere in the room, which was quite the experience, let me tell you.  When I discovered I’d mis-measured the available space and the cabinet ever so slightly, I had the following conversation with myself:

“This cabinet is an eighth-inch too tall to fit. You’ll never get it in there!”

“Yeah?  Well, me and Mister Block Plane here say different.”

Reader, I got it in there.

Moving the cabinets exposed a short wall of framing studs mounted atop a cinderblock foundation wall.  I’ll get to how I used those in a future piece, but here I want to talk about something I’ve been using to help me visualize parts of this project and get cut lists out of it at the end: hand-written SVG.

You heard me.  I’ve been hand-coding SVG schematics to figure out how thing should go together, and as a by-product, guide me in both material buying and wood cutting.

This might sound hugely bespoke and artisanally overdone, but they’re not that complicated, and as a major benefit, the process has helped me understand SVG a little bit better.  Here’s one example, a top-down diagram of the (supposedly) temporary workbench I recently built out of plywood and kiln-dried framing studs.

That shows a 2’×4′ benchtop with a supporting frame (the overlapping grayish boxes) and the placement of the four legs (the brown rectangles).  Here’s how I wrote the elements to represent the supporting frame.

<g class="structure">
    <path d="M 3.75 3.75  l 40.5 0" /> <!-- back -->
    <path d="M 3.75 12.00 l 40.5 0" class="optional" />
    <path d="M 3.75 20.25 l 40.5 0" /> <!-- front -->

    <path d="M 3.75 3  l 0 18" /> <!-- left -->
    <path d="M 24.00 3.75 l 0 16.5" class="optional" />
    <path d="M 44.25 3 l 0 18" /> <!-- right -->
</g>

And here’s how I styled them.

.structure {
    stroke: #000;
    stroke-width: 0;
    fill: #000;
}
.structure path {
    opacity: 0.1;
    stroke-width: 1.5;
}
.structure .optional {
    opacity: 0.05;
}

I like using paths in this situation because they let me pick a starting coordinate, then draw a line with relative X-Y values.  So that first path starts at X=3.75 and Y=3.75, and then draws a line whose endpoint is 40.5 X-units and 0 Y-units from the starting point.  In other words, it’s 40.5 units long and purely horizontal.  Compare that to the path marked left, which starts nearby (X=3.75, Y=3) and runs 18 units straight down.

This helps with cut planning because I set things up such that each unit equals an inch.  Just by looking at the values in the SVG, I know I need two pieces that are 40.5 inches long, and two that are 18 inches long.  (Three pieces of each length, if I’d decided to use the pieces classed as optional, but I didn’t.)

And how did I get that to work?  I set the viewbox to be only a few coordinate units larger than the overall piece, which I knew would be 24 by 48 units (inches), and then made the image itself large.

<svg xmlns:svg="http://www.w3.org/2000/svg"
    xmlns="http://www.w3.org/2000/svg"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    width="1000"
    height="500"
    viewBox="0 0 54 30"
    >

Basically, I added 6 to each of 24 and 48 to get my viewBox values, allowing me three units of “padding” (not CSS padding) on each side.  I filled the whole thing with a rectangle with a soft gray fill, like so.

<rect height="100%" width="100%" fill="#EEE" />

Which was great, but now I had to figure out how to get the 24×48 workplan into the center of the viewbox without having to add three to every coordinate.  I managed that with a simple translation.

<g transform="translate(3,3)">
    <rect width="48" height="24" fill="hsla(42deg,50%,50%,0.5)" />
    …
</g>

And with that, everything inside that g (which is basically the entire diagram) can use coordinates relative to 0,0 without ending up jammed into the top left corner of the image.  For example, that rect, which has no x or y attributes and so defaults both to 0.  It thus runs from 0,0 to 48,24 (as is proper, X comes before Y), but is actually drawn from 3,3 to 51,27 thanks to the transform of the g container.

The drawback to this approach, in my eyes, is that if text is added, it needs a really small font size.  In this particular case, I decided to add a measurement grid to the diagram which is revealed when the SVG is printed.  You can also see it on a mouse-and-keyboard computer if you click through to the SVG and then hover the tabletop.  To all the paths I used to make the grid (and yes, there’s a better way), I added a set of labels like these:

<text x="12" y="0" dx="0.5" dy="-0.5">12</text>
<text x="24" y="0" dx="0.5" dy="-0.5">24</text>
<text x="36" y="0" dx="0.5" dy="-0.5">36</text>
<text x="48" y="0" dx="0.5" dy="-0.5">48</text>

<text x="0" y="0" dx="-0.33" dy="-0.33">0</text>
<text x="0" y="12" dx="-0.5" dy="0.5">12</text>
<text x="0" y="24" dx="-0.5" dy="0.5">24</text>

At my browser’s default of 16px, the text is HUGE, because it gets made 16 units tall.  That’s almost three-quarters the height of the viewbox!  So I ended up styling it to be teensy by any normal measure, just so it would come out contextually appropriate.

.lines text {
    font-size: 1px;
    font-family: Arvo, sans-serif;
    text-anchor: end;
}

Yes.  1px.  I know.  And yet, they’re the right size for their context.  It still grates on me, but it was the answer that worked for this particular context.  You can see the result if you load up the SVG on its own and mouse-hover the benchtop.

The legs I decided to do as rect elements, for no reason I can adequately explain other than I’d started to get a little sick of the way path forced me to figure out where the center of each line had to be in order to make the edges land where I wanted.  path is great if you want a line exactly centered on a unit, like 12.00, but if you want the edge of a board to be three inches from the left edge of the tabletop, it has to start at x="3.75" if the board is 1.5 inches wide.  If the width ever changes, you have to change the x value as well.

For the support frame, which is going to be made entirely out of boards an inch and a half wide, this wasn’t a super big deal, but the math had started to grate a bit.  So, the legs are rects, because I could use the grid I’d drawn to figure out their top left corners, and the height and width were constants.  (I probably could have set those via the CSS, but eh, sometimes it’s better to have your code self-document.)

<g class="legs">
    <rect x="4.5" y="4.5" height="1.5" width="3.5" />
    <rect x="4.5" y="18" height="1.5" width="3.5" />
    <rect x="40" y="4.5" height="1.5" width="3.5" />
    <rect x="40" y="18" height="1.5" width="3.5" />
</g>

Honestly, I probably didn’t even need to include these, but they served as a useful reminder not to forget them when I went to buy the wood.

As I said, simply by glancing at the SVG source, I can see how long the support frame’s pieces need to be—but more to the point, as I adjusted numbers to move them around, I worked their sizes into my head.  What I mean is, I had to visualize them to draw the right lines, and that means I’ve already done some visualization of the assembly.  I just need to remember that each of the four legs will be 34″ long at the most.  Taken all together, I’ll need three 8-foot 2×4 boards (which actually have a cross-section of 1.5″×3.5″—don’t ask), chopped up and joined appropriately, to go under my 2’×4′ benchtop.

So that’s how I utterly geeked up my workbench project—and if that seems like a bit much, just wait until you see the next thing I did, and what I learned along the way.


CSS4 Color Keyword Distribution Visualization

Published 1 year, 2 months past

Long, long ago—not quite seven years ago, in fact—I built a canvas-based visualization of the distribution of CSS3/SVG color keywords and released it.  And there it’s sat, static and inert (despite being drawn with a whooooole lotta JS) ever since.

I’ve always meant to get back to it and make it more interactive.  So over the past several evenings, I’ve rebuilt it as an SVG-based visualization.  The main point of doing this was so that when you hover the mouse pointer over one of the little color boxes, it will fill the center of the color wheel with the hovered color and tell you its name and HSL values.  Which it does, now.  It even tries to guess whether the text should be white or black, in order to contrast with the underlying color.  Current success rate on that is about 90%, I think.  Calculating perceived visual brightness turns out to be pretty hard!

Other things I either discovered, or want to do better in the future:

  • Very nearly half the CSS4 (and also CSS3/SVG) color keywords are in the first 90 degrees of hue.  More than half are in the first 120 degrees.
  • There are a lot of light/medium/dark variant names in the green and blue areas of the color space.
  • I wish I could make the color swatches bigger, but when I do that the adjacent swatches overlap each other and one of them gets obscured.
  • Therefore, being able to zoom in on parts of the visualization is high on my priority list.  All I need is a bit of event monitoring and some viewbox manipulation.  Well, that and a bit more time. Done, at least for mouse scroll wheels.
  • I’d like to add a feature at some point where you type text, and a list is dynamically filtered to show keywords containing what you typed.  And each such keyword has a line connecting it to the actual color swatch in the visualization.  I have some ideas for how to make that work.
  • I’d love to create a visualization that placed the color swatches in a 3D cylindrical space summarizing hue, lightness. and saturation.  Not this week, though.
  • I’m almost certain it needs accessibility work, which is also high on my priority list.
  • SVG needs conic gradients.  Or the ability to wrap a linear gradient along/inside/around a shape like a circle, that would work too.  Having to build a conic gradient out of 360 individual <path>s is faintly ridiculous, even if you can automate it with JS.
  • And also z-index awareness.  C’mon, SVG, get it together.

Anyway, here it is: CSS4 Color Keyword Distribution.  I hope you  like it!


My Contribution to “Modern Loss”

Published 2 years, 4 months past

 

My wife Kat and I tell ourselves we’d love another child for who they are, not for who they replace. We even believe it. But we can’t be sure of it—and that keeps us from shutting our eyes, jumping back into the adoption process, and hoping it will turn out okay. We know all too horribly well that sometimes, it doesn’t.

That’s the opening of my essay “The Second Third Child”, included in the new book from Modern Loss titled Modern Loss: Candid Conversation About Grief. Beginners Welcome, published this week.

I’m deeply honored to be one of the 40+ contributors to the book, some of whom you may know—Dresden Dolls co-founder Amanda Palmer, CNN’s Brian Stelter, author Lucy Kalanithi, Dear Evan Hansen director Michael Greif, Stacy London of What Not To Wear—and many of whom you may not, as I will be unknown to the vast majority of the book’s readers. I’ve written articles for Modern Loss in the past, but to be entrusted with a part of their first book was humbling.

Several of the essays in the book are intentionally funny, but mine is not one of them. It’s quiet, reflective, and elegiac in more than one way, but never anything but honest. It appears in the first section of the book, titled “Collateral Damage”.

As Stephen Colbert put it: “Talking about loss can feel scary. This book isn’t. It’s about grieving deeply over the long term, and the reassurance that you’re far from broken because of it.” I hope my essay, and the book as a whole, helps readers to come to terms with their own grief, by seeing that they are not alone, and that they did the best they could even if it doesn’t feel that way at all.

All my thanks to Rebecca Soffer and Gabrielle Birkner for making me a part of their incredible, inspiring work.


The Newwwyear Design

Published 2 years, 5 months past

Well, here it is—the first new design for meyerweb since February 2005 (yes, almost 13 years).  It isn’t 100% complete, since I still want to tweak the navigation and pieces of the footer, but it’s well past the minimum-viable threshold.

My core goal was to make the site, particularly blog posts, more readable and inviting.  I think I achieved that, and I hope you agree.  The design should be more responsive-friendly than before, and I think all my flex and grid uses are progressively enhanced.  I do still need to better optimize my use of images, something I hope to start working on this week.

Things I particularly like about the design, in no particular order:

  • The viewport-height-scaled masthead, using a minimum height of 20vh.  Makes it beautifully responsive, always allowing at least 80% of the viewport’s height to be given over to content, without requiring media queries.
  • The “CSS” and “HTML” side labels I added to properly classed pre elements.  (For an example, see this recent post.)
  • The fading horizontal separators I created with sized linear gradients, to stand in for horizontal rules.  See, for example, between post content and metadata, or underneath the navlinks up top of the page.  I first did this over at An Event Apart last year, and liked them a lot.  I may start decorating them further, which multiple backgrounds make easy, but for now I’m sticking with the simple separators.
  • Using string-based grid-template-areas values to rearrange the footer at mobile sizes, and also to make the rare sidebar-bearing pages (such as those relating to S5) more robust.

There are (many) other touches throughout, but those are some high points.

As promised, I did livestream most of the process, and archived copies of those streams are available as a YouTube playlist for those who might be interested.  I absolutely acknowledge that for most people, nine hours of screencasting overlaid with rambling monologue would be very much like watching paint dry in a hothouse, but as Abraham Lincoln once said: for those who like this sort of thing, this is the sort of thing they like.

I was surprised to discover how darned easy it is to livestream.  I know we live in an age of digital wonders, but I had somehow gotten it into my head that streaming required dedicated hardware and gigabit upstream connections.  Nope: my five megabit upstream was sufficient to stream my desktop in HD (or close to it) and all I needed to broadcast was encoding software (I used OBS) and a private key from YouTube, which was trivial to obtain.  The only hardware I needed was the laptop itself.  Having a Røde Podcaster for a microphone was certainly helpful, but I could’ve managed without it.

(I did have a bit of weirdness where OBS stopped recognizing my laptop’s camera after my initial tests, but before I went live, so I wasn’t able to put up a window showing me while I typed.  Not exactly a big loss there.  Otherwise, everything seemed to go just fine.)

My thanks to everyone who hung out in the chat room as I livestreamed.  I loved all the questions and suggestions—some of which made their way into the final design.  And extra thanks to Jen Simmons, who lit the fire that got me moving on this.  I enjoyed the whole process, and it felt like a great way to close the books on 2017.


A Meyerweb Makeover

Published 2 years, 5 months past

This coming week, I’m going to redesign meyerweb.com—which will be its first redesign in twelve and a half years.

I’m doing this as part of Jen Simmons’ #newwwyear initiative.  As Jen put it:

Ok, here’s the deal. Tweet your personal website plan with the hashtag #newwwyear (thanks @jamiemchale!): 1) When will you start? 2) What will you try to accomplish? 3) When is your deadline? Improve an existing site. Start a new one. Burn one down & start over. It’s up to you.

Many of us feel bad about our personal websites. Me included. We keep meaning to make one, improve what’s there, or burn it down and start over. We are busy. Afraid. Overwhelmed. Well, let’s do it. Maybe over the holidays. Maybe after, in the New Year. #newwwyear

On Friday, I announced my plan:

  1. I’ll start Wednesday, December 27th.
  2. I’ll redesign http://meyerweb.com  for the first time in a dozen years, and I’ll do it live on the production site.
  3. My deadline is Wednesday, January 3rd, so I’ll have a week.

I won’t be redesigning all day every day—I still have paying work to do, after all—but I’ll do my best to put in a couple of hours each weekday.

When say I’ll do it live, I mean I’ll be making all my changes here on the production site, with minimal or no testing beforehand—literally opening the style sheet(s) into BBEdit via Transmit, and saving changes up to the server to see what happens.  Stuff will break, and then I’ll fix it, live in the public eye.  It’s possible I’ll try out new ideas and then junk them before moving on to others.  I’m hoping that accidents spark inspiration, as they often do.

(There will be a local copy of the site in case things go so badly that I need to reset to the starting point.  I’m not completely insane, after all.)

I have a vague plan with all this, which is: realign the site’s appearance to be more inviting, more readable, and more visually engaging.  I do have a few past experiments that I’ll fold in, like using relative times (e.g., “Two months ago”) on posts, but a lot of this will be me doing free-association design.  And hopefully a little markup cleanup and enhancement as well.

I’m sticking with WordPress to drive the blog, given that it contains close to two decades of posts and makes it easy to allow comments, a feature I still value; and my hand-built old-school-standards-punk mostly-static templating system for the rest of the site, which let the site be static(ish) way before static was cool.  (No, I will not consider migrating to other CMSes or template systems: with a week set aside for this, I won’t have the time.)

So, that’s the plan: a week for a meyerweb makeover.  I don’t know if I’ll keep up a running commentary on Twitter while I do, or if I’ll take breaks and blog short entries chronicling my progress, or what.  If someone sets up a #newwwyear Slack team, I’ll probably join in.  If the #newwwyear idea excites you, I hope you’ll join in too!


Preview Video: What Would a Human Do?

Published 3 years, 3 months past

We’re about halfway through February, he said with some deliberate vagueness, and that means the launch-month special on my Udemy course “Design for Humanity” is also half-done.  If you haven’t taken advantage yet, use the code MW_BLOG to get a nice little discount off the list price.

You may be wondering if this course is really for you.  There are some videos available as free previews on Udemy.  I’m including one here, which is a single “lecture” (as they’re called by the Udemy) from early in the course.  It explores a single concept and also establishes some of the landscape for the course, which is one of the reasons I chose it.

Youtube: “What Would a Human Do?”

Again, the discount code above ends at the end of February, so if you’re interested bu haven’t signed up yet, don’t delay too much longer.  And if you have already taken the course, could you do me a favor and leave an honest review at Udemy?  It will help other people. whether they find the course from me or through Udemy, decide whether the course is right for them or not.  Thank you!


Browse the Archive

Earlier Entries