Posts in the Redesign Category

Hamonshu

Published 4 years, 7 months 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.

Headings and Labels

Published 6 years, 10 months past

Following on my last two posts about accessibility improvements to meyerweb, I’ve made two more adjustments: better heading levels and added ARIA labels.

For the heading levels, the problem I face is one familiar to many authors: what makes sense as an <h1> in some situations needs to be an <h2> in others.  The most common example is the titles of blog posts like this one.  On its permalink page, the title of the page is the title of the post.  There, it should be an <h1>.  On archive pages, including the home page of meyerweb, there are a number of posts shown one after the other.  In those situations, each post title should be an <h2>.

Part of the redesign’s changes were to write a single PHP routine that generated posts and their markup, which I could then simply call from wherever.  So I added an optional function parameter that allowed me to indicate the context in which a post was being placed.  It goes something like this:

<?php blogpostMarkup("archive"); ?>

function blogpostMarkup($type = "standalone") {
    if ($type == "archive") $titletag = "h2"; else $titletag = "h1";
    // …markup is all generated here…
    echo $output;
}

Or code to that effect.  (I did not go copy-paste from my actual code base.)

So now, heading levels are what they should be, at least on most pages (I may have missed updating some of my old static HTML pages; feel free to point them out in the comments if you find one).  As a part of that effort, I removed the <h1> from the masthead except on the home page, being the one place it makes sense to be an <h1>.

As for ARIA labels, that came about due to a comment from Phil Kragnes on my last post, where he observed that pages often have multiple elements with a role of navigation.  In order to make things more clear to ARIA users, I took Phil’s suggestion to add aria-label attributes with clarifying values.  So for the page-top skiplinks, I have:

<nav role="navigation" aria-label="page" id="skiplinks">

Similarly, for the site-navigation bar, I have:

<nav role="navigation" aria-label="site" id="navigate">

The idea is that screen readers will say “Page navigation region” and “Site navigation region” rather than just repeating “Navigation region” over and over.

Other than cleaning up individual pages’ heading levels and the occasional custom layout fix (e.g., the Color Equivalents Table needed a local widening of the content column’s maximum size), I think the redesign has settled into the “occasional tinkering” phase.  I may do something to spruce up my old Web Review articles (like the very first, written when HTML tags were still uppercase!) and I’m thinking about adding subnavigation in certain sections, but otherwise I think this is about it.  Unless I decide to go really over the top and model my Tools page after Simon St. Laurent’s lovely new Grid design, that is…

Of course, if you see something I overlooked, don’t hesitate to let me know!  I can’t guarantee fast response, but I can always guarantee careful consideration.

Increasing Accessibility

Published 6 years, 10 months past

Thanks to the fantastic comments on my previous post, I’ve made some accessibility improvements.  Chief among them: adding WAI-ARIA role values to various parts of the structure.  These include:

  • role="banner" for the site’s masthead
  • role="navigation" added to the navigation links, including subnavigation links like previous/next posts
  • role="main" for the main portion of a page
  • role="complementary" for sidebars in the blog archives
  • role="article" for any blog post, whether there are several on a page or just one

In addition, I restored skip links to the masthead of most pages (the rest will get them soon).  The links are revealed on keyboard focus, which I’m not sure I like.  I feel like these aren’t quite where they need to be.  A big limitation is the lack of :matches() (or similar) support in browsers, since I’d love to have any keyboard focus in the masthead or navigation links bring up the skip links, which requires some sort of parent selection.  I may end up using a tiny bit of enhancing Javascript to make the links’ UX more robust in JS situations, but still obviously available if JS fails.  And I may replicate them in the footer, as a way to quickly jump back up the page, especially to the navigation.

Speaking of the navigation links, they’ve been moved in the source order to match their place in the visual layout.  My instincts with regard to source order and layout placement were confirmed to be woefully out of date: the best advice now is to put the markup where the layout calls for the content to be.  If you’re putting navigation links just under the masthead, then put their markup right after the masthead’s markup.  So I did that.

The one thing I didn’t change is heading levels, which suffer all the usual problems.  Right now, the masthead’s “meyerweb.com” is always an <h1> and the page title (or blog post titles) are all <h2>.  If I demoted the masthead content to, say, a plain old <div>, and promoted the post headings, then on pages like the home page, there’d be a whole bunch of <h1>s.  I’ve been told that’s a no-no.  If I’m wrong about that, let me know!

There’s still more to do, but I was able to put these into place with no more than a few minutes’ work, and going by what commenters told me, these will help quite a bit.  My thanks to everyone who contributed their insights and expertise!

A Newwwyear Livestream

Published 6 years, 10 months past

After I announced my newwwyear plans, a couple of people pinged me to ask if I’d do a Google Hangout or some such so that people could follow along as I live-redesign meyerweb in production.  And I thought, that sounds like the nerdiest Twitch stream ever, but what the heck, why not?

So!  I’m going to livestream at least part of my process over on YouTube Live, spread over a few days.  I picked YTL over Twitch because YouTube will archive the streams to my channel, whereas Twitch only holds onto them for 14 days, and one of my weaknesses is that I’m a data hoarder — I hate to throw away anything digital.  So I’ll keep copies on someone else’s computer.

During the stream, I’ll keep up a running commentary on what I’m doing and why.  This sounds artificial, but honestly, I talk to myself a lot as I work anyway.  I’ll also have the YouTube Live chat window open so people can ask questions about why I do what I do, and I’ll do my best to answer.  Or, you know, we can talk about the latest Star Wars movie or whatever.  I’m not going to put too many limits on it other than A) keep the language professional, since kids starting out in web design might join in; and B) treat everyone in the chat with respect.

My guess is any given stream session will be two hours, tops.  My tentative schedule is:

  1. December 26th (today!) starting around 2000 UTC (3:00pm EST, 12:00n PST)
  2. December 27th, 1830 UTC (1:30pm EST, 10:30am PST)
  3. December 28th, 1900 UTC (2:00pm EST, 11:00am PST)1500 UTC (10:00am EST, 7:00am PST)
  4. December 29th, 1500 UTC (10:00am EST, 7:00am PST)

I don’t have a specific structure for how I’m going to approach this, other than: first I turn off all site-wide styling and put up a note about it, maybe add a few very minimal styles, rework the page structures to be sane without CSS, then start building up a new design.  I have no idea how long each part of that sequence will take (except the “remove site-wide styles” part, that’ll take a few seconds).  But there isn’t a scheduled “Typography Day” or what-have-you: I’ll probably go wandering off on tangents, riffing on happy accidents, fiddling with stuff as I notice it and it bugs me, etc., etc.  In other words, how I normally work.

If any of this sounds interesting to you, please join in!  I’ll do my best to announce start times with an hour or so lead over on Twitter, and as comments on this post.

A Meyerweb Makeover

Published 6 years, 10 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!

Out of Order

Published 17 years, 3 weeks past

Apologies to anyone who tried visiting meyerweb in the very near past and found it broken.  I’d noticed that suddenly all kinds of comment spam were getting past Akismet and landing in the moderation queue, and was just preparing to ask the spam-fighters about it when I discovered that the blog portions of the site were throwing a PHP error about not being able to find a function I’d written into a plugin.

At which point I discovered that all my WordPress plugins had been deactivated.  I know I didn’t do that, so how they all got turned off remains a bit of a mystery to me.  I’ve turned all the ones I need back on, and things appear to be back to normal.

So Akismet wasn’t being evaded by the spam: it was simply switched off.  Good thing my non-plugin defenses caught everything that poured in during the outage.  Which, come to think of it, must all have been direct-submit spam, since there wouldn’t have been a comment form available on the entire site.  So what they were really avoiding was my direct-submission defensive plugin, not Akismet.

Well, either way, other defensive measures protected the site, so all’s well there.  I’m certainly not thrilled about the site having been largely offlined for a short period, and again, my apologies to anyone who got blocked from information they wanted.

This episode has actually given me cause to reconsider my usual preference to put site navigation at the end of the document source.  When the PHP failed, the navigation was never served up.  Had I put it at the top of the page, it would’ve been present even though the blog posts were failing.  Getting to the static areas of the site would have been possible.  Due to my structural choices, a script failure dramatically affected the usability of the site as a whole.

Something worth thinking about as I slowly work on improving the organization of meyerweb.

Slashdot’s Validity

Published 19 years, 1 month past

With the Redesign Watch back up and running, the most recent entry is Slashdot, the venerable geek portal so infamous for its ability to kill web servers with a single link that the site’s name is a verb meaning “to bring a server grinding to a halt”.

I was asked in a comment:

What’s your feeling on slashdot being HTML 4.01 (and slightly failing validation) VS XHTML 1.0?

My feeling is good.  Why?  Let’s take the second part first.

When it comes to HTML versus XHTML, I just do not care.  Sure, sure, people will tell you that XHTML is XML so it’s more transformable or something.  That’s a very good argument when the XHTML is well-formed and valid.  It’s also a very good argument for using HTML when it’s well-formed and valid.  Conversely, neither HTML nor XHTML is easily transformed when ill-formed and invalid.  This is an experiential point of view, too: I’ve written XSLT (which is itself so tortuous and ugly that it almost by definition cannot be called well-formed) to transform both HTML and XHTML, and the effort is pretty much the same each way—assuming well-formed, valid markup.

So as far as I’m concerned, there’s really no major practical difference between HTML and XHTML.  There are plenty of minor practical differences, like having to throw trailing slashes on all your empty elements in XHTML and needing some namespace information.  Some people will tell you the whole MIME-type thing is a major practical concern, but I’m just not that much of a purist.  Take that for whatever it’s worth.

I mean, imagine a world where Slashdot had used XHTML instead of HTML, and was failing validation.  How would that be any better or worse than things are now?

Okay, so that’s the second part.  The first part, the failure to validate, is not something I can get too terribly upset about.  Slashdot, as a site that accepts ads, is going to get horrible markup shoved into its pages.  That’s just the way it is.  If you want major sites to be perfectly valid, then in all honesty advertisers are the place to start.  So they’re already operating with a major handicap there.

Even if we were to ride our high horses along a very hard line and say that ads are just no excuse, I’d be hard-pressed to fault the job they’ve done.  For example, I ran a check on the Slashdot home page.  Out of 1,262 lines of code, there were exactly four validation errors, and that’s using HTML 4.01 Strict—you’ll note they bypassed Transitional, which only increases my respect.  Three of the errors revolved around an image in a noscript element, and the last was due to the presence of a language attribute on a script element—something they can fix in fifteen seconds, once it gets to the top of the to-do list.

You know what?  I’d be ecstatic to have that low a failure rate when launching the markover of an incredibly complex site like Slashdot.  Think about all the content they have to manage, stitch together, and offer up.  Four errors out of all that dynamically assembled markup?  I say somebody should organize them a parade for doing such a good job, and showing that any site can make use of and benefit from standards.

I’m also really looking forward to the restyling of Slashdot through user-created style sheets, and the Greasemonkey enhancements built on top of this new structure.  If there’s a site whose readers are inherently primed to script the holy bejeezus out of it, that would be the one.

Would I be happier if they’d managed to achieve total validation?  Of course.  In the meantime, though, I’m going to be very nearly as happy for what they’ve accomplished, and also for the simple fact of it being another major site that’s taken a big step forward.  Progress is always a cause for celebration in my world.

MMBUG Talk

Published 19 years, 1 month past

Those of you in the Boston area might be interested in a talk I’m giving at the Macromedia Boston User Group meeting on Wednesday, 12 October 2005:

From Comp To Code: Pulling A List Apart Together

You’re handed a graphic comp file and told to make it into a living, breathing web page.  Now what?  How do you figure out what approach to take, which techniques to use, and what kinds of markup will go into the final page?  Eric gives us a fast-paced tour of his decision-making process as he tackled the new design for A List Apart– how he analyzed the requirements, the questions he had to ask, the trade-offs he made, and the reasons behind his decisions.

If you’re interested, then please join us from 7:00pm – 9:00pm in E51-151 (Tang Center) on the MIT campus.  According to the meeting organizer, arriving early is recommended.

If you do decide to drop by, I’m sorry to say that you won’t be the first to hear this presentation: that honor, if we can call it that, will go to the attendees of Web Essentials 05.  On the other hand, you’ll be getting a more detailed version of the talk, since at WE05 I only have 45 minutes.

On the third hand, could it be that both groups will be getting a sneak preview of just one of the topics to be discussed as part of An Event Apart Philadelphia?

Maybe.

Browse the Archive

Earlier Entries