Posts in the Tech Category

Originally published at Medium on July 30th, 2015.

Yesterday, I decided to try importing a story to Medium. I’d hunted around for a way to auto-post to Medium from WordPress, which runs the blog portion of meyerweb (the rest is mostly HTML, with a little PHP here and there), and hadn’t found one. Then I found the “Import story” feature on Medium and thought, Sure, why not?

So I tried it out on my most recent post, which also happened to have some code in it, as my posts sometimes do. The process was, as anyone who’s used it can tell you, very simple. Paste in a URL and the content gets sucked in.

Well, except for code blocks.

I’d structured the block with a pre element, as I always do, and yet the line-breaking was stripped away. It looks like my indentation tabs were preserved, but without the linefeeds, they didn’t have nearly the same utility.

The real problem is that the importation of the code block stopped cold at the first <, dropping the rest of the code on the floor. Now, I admit, I didn’t escape or entity-ize the character in my source, and maybe that was the problem. Still, I feel like an import tool should be a little smarter about things like less-than symbols on import. Otherwise, how many less-than-threes will end up as just plain threes?

Fortunately, the fix was simple: I went back to the original post, drag-selected the whole code block, copied, went back to Medium, drag-selected the mangled code, and hit ⌘V. Done. It was properly formatted and no less-than terminations occurred.

Today, I’m experimenting with writing my post on Medium first, after which I’ll repost it at meyerweb. This is likely the only time I’ll do it in that order, given my experience over here. Captions are deucedly hard to edit (at least in my browser of choice, Firefox Nightly), the apparent inability to add simple decorations like border to images, and the apparently intentional, active enforcement of single-space-after-sentence even when editing annoy me deeply. (Yes, that’s how I roll. Let’s not have the spacing argument here, please.)

I can see why Medium appeals to so many. It’s pretty frictionless, a lot more so than almost any other tool of its kind I’ve used. I mean, my WordPress install is pretty frictionless to me, but that’s because I invested a lot of time customizing it to be that way. Much like my browser, mail client, and other essential tools.

So anyway, that’s what I found during import and authoring on Medium. Here’s hoping this posts properly, and without the stray “in” that’s somehow shown up in my post, and which I can’t select, mouse to delete or otherwise remove through non-Inspector means. If only I could prepend an “f”!

• Medium Trials was published on Thursday, July 30th, 2015.
• It was assigned to the Commentary, Tech, and Writing categories.
• There have been three replies.

Inspired by Ryan Joy’s excellent and deservedly popular tweet, I wrote a small, not-terribly-smart Javascript function to undo cut/copy/paste blocking in HTML.

function fixCCP() {
   var elems = document.getElementsByTagName('*');
   var attrs = ['onpaste','oncopy','oncut'];
   for (i = 0; i < elems.length; i++) {
      for (j = 0; j < attrs.length; j++) {
         if (elems[i].getAttribute(attrs[j])) {
            elems[i].setAttribute(attrs[j],elems[i]
            .getAttribute(attrs[j])
            .replace("return false","return true"));
         }
      }
   }
}

Here it is as a bookmarklet, if you still roll that way (as I do): fixCCP.  Thanks to the Bookmarklet Maker at bookmarklets.org for helping me out with that!

If there are obvious improvements to be made to its functionality, let me know and I’ll throw it up on Github.

• Undoing oncut/oncopy/onpaste Falsities was published on Tuesday, July 7th, 2015.
• It was assigned to the Browsers, DOM, and Web categories.
• There have been four replies.

I have recently, perhaps inevitably, taken up woodworking as a hobby.  It’s just clichéd enough to be credible, isn’t it?  Web, wood, maybe it’s in the leading “w”.

A programmer friend and I get together Wednesday evenings to try our hand at what is currently best described as rough carpentry.  The usual reason to take up a “physical-world” hobby like woodworking is to “get away from the computer for a while, man!”  But of course we pull out our iPhones to use as calculators, look up techniques, or find online tools that can help us.  The laptops stay indoors, but computers and the internet still smooth our way.

In web terms, we’re past “hello world” and at about the point where we understand the basics of HTML and have set a few colors and faces with beginner CSS.  We could put up a single-column fan site if that were the goal, but not much more than that.  We’re still at the stage of making a lot of mistakes and not knowing if our problems spring entirely from not knowing how to use our tools, or also from not knowing enough to realize the tools themselves are deficient.  We’re figuring things out as we go, hitting up YouTube for how-to guides on just about everything.  Wikipedia may aspire to be the site of record for Things of Import, but YouTube holds the sum total of humanity’s practical knowledge, hidden amongst all the pop-star and cat videos.

A lot of the best practices map back and forth, too.  Planning ahead is a core competency, and the more you practice, the better you get at it.  Measurement is vital, and cleverness is as useful as it is dangerous.  The importance of quality tools can’t be overstated.  There are a lot of (very) specialized tools available, but you can get really far with the core set of flexible, time-honored basics.  As long as you have a boatload of clamps, that is.

The one major difference is that there is no versioning in woodworking.  It’s like building a project with only the “Save” command — no milestones, no repositories, no undo.  When you do something, you’re committing to altering the project with no take-backs.  If you get it wrong, you have to find a way to patch over the problem.  If you get it really wrong, you have to scrap what you just did and replace the botched part.  And if you get it really, really wrong, all you can do is scrap the whole thing and start over.

So far we haven’t had to scrap anything.  Our first couple of projects were the classic starters: a simple bookshelf, a firewood box, a more complex bookshelf.  For each, we’ve intentionally stepped up the complexity, a bit at a time.  The first bookshelf was just screwed together, but the pieces were all pretty much the right size and properly aligned.  The firewood box was also screwed together, but it involved angled cuts and hinges and sealant.  The second bookshelf involved a wood router in a variety of ways, both structural and decorative.

As in networking, we swore a lot at the router, but it got us where we needed to be.  Eventually, that is, once we figured out how to properly configure it and deal with its quirks.

I can’t deny that there’s a visceral satisfaction in picking up a hammer and whacking on a thing until it’s properly assembled, or disassembled, as the case may be.  There’s definitely a triumph in finding out you did all the measuring and cutting and aligning just right, much like the rush you get when your first major coding project does what you meant it to do, except more so because you’ve wrestled atoms into doing your bidding.  That’s literal orders of magnitude beyond wrangling electrons.

Our next steps are what I assume is the usual second phase: building a wood shop in order to learn how to use a wood shop.  We’re moving up to building fold-down work surfaces with tool storage, custom-fitted wood storage, and braced shelves.  That experience will enable us to move into other, more complicated projects.  Some we already have in mind.  Others will suggest themselves to us.  At every step, we’ll look for new skills to try and practice.

And that, I think, is the real ultimate goal here: to teach ourselves new things, to enrich our skill sets and create useful objects thereby.

So it’s pretty much like working on the web.

Well, except for all the staining.

This article was originally published at The Pastry Box Project on 2 July 2015.

• Everything Looks Like a Nail was published on Thursday, July 2nd, 2015.
• It was assigned to the Personal, Web, and Writing categories.
• There have been no replies.

With the news today of the Supreme Court’s decision in Obergefell v. Hodges, and my recent completion of the part of CSS:The Definitive Guide that deals with gradients, I thought I’d create a couple of flags using linear gradients.

First, I’ll define the basic box of the flags.  The dimensions are the same as those specified for the U.S. flag, 1:1.9.  I added a couple of box shadows for visual constrast with the background.

div {height: 10em; width: 19em; margin: 3em;
    box-shadow: 0 0 0.5em rgba(0,0,0,0.25),
        0.4em 0.6em 0.5em rgba(0,0,0,0.25);}

Okay, with that set, first up is what’s often called the pride flag, which is to say the “rainbow flag”.  There’s an interesting history to the design of the flag, but I’m going to stick with “the six-color version popular since 1973”, as Wikipedia puts it.

For such a flag, we just need color stripes with hard stops between them.  That means putting the color stops right up against each other, like so:

div#rainbow {
    background: linear-gradient(180deg,
        red 0%, red 16.7%, 
        orange 16.7%, orange 33.3%,
        yellow 33.3%, yellow 50%, 
        green 50%, green 66.7%, 
        blue 66.7%, blue 83.3%, 
        purple 83.3%, purple 100%);
}

The first red 0% isn’t really necessary, nor is the last purple 100%, but I left them in for the sake of consistency.  You could remove them both in order to make the CSS a little smaller, and still get the same result.  I decided to go from red to purple, as the spectrum is usually described, which meant having the gradient ray point from top to bottom.  Thus 180deg, although to bottom would be completely equal in this case.

Now for the US flag.  In this case, things get a little more interesting.  I’ll note right up front that I’m not going to put in any stars, in order to keep this simple and gradient-focused, and yet it’s still interesting.  We could use a repeating linear gradient, like so:

repeating-linear-gradient(180deg,
    #B22234, #B22234 0.77em, white 0.77em, white 1.54em)

That would then cause each red-white pair of stripes to repeat vertically forever.  Because the specified stripes are manually calculated to be 1/13th of the height of the overall flag (10em), they’ll just fit like they should.

The problem there is that if the overall flag size ever changes, like if the height and weight are converted to pixels, the stripes will get out of sync with the dimensions of the flag.  Fortunately, we don’t have to rely on ems here; we can use percentages.  Thus:

repeating-linear-gradient(180deg,
    #B22234, #B22234 7.7%, white 7.7%, white 15.4%)

Ta-da!  The stripes are the right sizes, and scale with any changes to the height and width of the flag, and repeat as required.

That’s all well and good, but we still need the blue canton (as it’s called).  Since the canton will be on top of the stripes, it actually needs to come first in the comma-separated value list for background-image.  That gives us:

background-image:
    linear-gradient(0deg, #3C3B6E, #3C3B6E),
    repeating-linear-gradient(180deg,
        #B22234, #B22234 7.7%, white 7.7%, white 15.4%);

Wait.  A blue-to-blue gradient?  Well, yes.  I want a consistent blue field, and one way to create that is a gradient that doesn’t actually grade.  It’s a quick way to create a solid-color image that can be sized and positioned however we like.

So, now we size and position the canton.  According to the official design specifications for the flag, the canton is the height of seven stripes, or 53.85% the height of the overall flag, and 40% the width of the flag.  That means a background-size of 40% 53.85%.  The stripes we then have to size at 100% 100%, in order to make sure they cover the entire background area of the flag.  Finally, we position the canton in the top left; the stripes we can position anywhere along the top. so we’ll leave them top left as well.

The final result:

div#usa {
    background-image:
        linear-gradient(0deg, #3C3B6E, #3C3B6E),
        repeating-linear-gradient(180deg,
            #B22234, #B22234 7.7%, white 7.7%, white 15.4%);
    background-size: 40% 53.85%, 100% 100%;
    background-repeat: no-repeat;
    background-position: top left;
}

And if you, like Bryan Fischer, believe that morally speaking “6/26 is our 9/11”, you can move the canton from top left to bottom left in order to invert the flag, which is permitted “as a signal of dire distress in instances of extreme danger to life or property”.

(Of course, it’s a lot easier to do that with background positioning since I didn’t include the stars.  If the stars were there, then we’d have left the canton’s position alone and done a rotateX() transform instead.)

So, there you go: two gradient flags.  You can see both (along with the “distress” variant) on this test page.  If you’ve any desire to use any or all of them, go ahead.  No copyright, trademark, patent, etc., etc. is asserted, implied, etc., etc.  I just wanted to have a little fun with gradients, and thought I’d share.

• Gradient Flags was published on Friday, June 26th, 2015.
• It was assigned to the CSS and Guide categories.
• There have been five replies.

Over the weekend, I published “Time and Emotion” on The Pastry Box, in which I pondered the way we’re creating the data that the data-miners of the future will use to (literally) thoughtlessly construct emotional minefields — if we don’t work to turn away from that outcome.

The way I introduced the topic was by noting the calendar coincidence of the Star Wars-themed tradition of “May the Fourth be with you” and the anniversary of the Kent State shootings in 1970, and how I observe the latter while most of the internet celebrates the former: by tweeting some song lyrics with a relevant hashtag, #maythe4th.  I did as I said I would…and Twitter blindly added a layer of commentary with a very simple little content filter.  On twitter.com and in the official Twitter app, a little Stormtrooper helmet was inserted after the hashtag #maythe4th.

So let’s review: I tweeted in remembrance of a group of National Guardsmen firing into a crowd of college students, wounding nine and killing four.  After the date hashtag, there appeared a Stormtrooper icon.  To someone who came into it cold, that could easily read as a particularly tasteless joke-slash-attack, equating the Guardsmen with a Nazi paramilitary group by way of Star Wars reference.  While some might agree with that characterization, it was not my intent.  The meaning of what I wrote was altered by an unthinking algorithm.  It imposed on me a rhetorical position that I do not hold.

In a like vein, Thijs Reijgersberg pointed out that May 4th is Remembrance of the Dead Day in the Netherlands, an occasion to honor those who died in conflict since the outbreak of World War II.  He did so on Twitter, using the same hashtag I had, and again got a Stormtrooper helmet inserted into his tweet.  A Stormtrooper as part of a tweet about the Dutch remembrance of their war dead from World War II on.  That’s…troublesome.

Michael Wiik, following on our observations, took it all one step further by tweeting a number of historical events collected from Wikipedia.  I know several of my British chums would heartily agree with the 1979 tweet’s added layer of commentary, but there are others who might well feel enraged and disgusted.  That could include someone who tweets about the election in celebration, the way people sometimes do about their heroes.

But what about appending a Stormtrooper helment to an observance of the liberation of the Neuengamme concentration camp in 1945?  For that matter, suppose someone tweets May-4th birthday congratulations to a Holocaust survivor, or the child of a Holocaust survivor?  The descendant of a Holocaust victim?

You might think that this is all a bit much, because all you have to do is avoid using the hashtag, or Twitter altogether.  Those are solutions, but they’re not very useful solutions.  They require humans to alter their behavior to accommodate code, rather than expecting code to accommodate humans; and furthermore, they require that humans have foreknowledge.  I didn’t know the hashtag would get an emoji before I did it.  And, because it only shows up in some methods of accessing Twitter, there’s every chance I wouldn’t have known it was there, had I not used twitter.com to post.  Can you imagine if someone sent a tweet out, found themselves attacked for tweeting in poor taste, and couldn’t even see what was upsetting people?

And, as it happens, even #may4th wasn’t safe from being hashflagged, as Twitter calls it, though that was different: it got a yellow droid’s top dome (I assume BB-8) rather than a Stormtrooper helmet.  The droid doesn’t have nearly the same historical baggage (yet), but it still risks making a user look like they’re being mocking or silly in a situation where the opposite was intended.  If they tagged a remembrance of the 2007 destruction of Greensburg, Kansas with #may4th, for example.

For me, it was a deeply surreal way to make the one of the points I’d been talking about in my Pastry Box article.  We’re designing processes that alter people’s intended meaning by altering content and thus adding unwanted context, code that throws pieces of data together without awareness of meaning and intent, code that will synthesize emotional environments effectively at random.  Emergent patterns are happening entirely outside our control, and we’re not even thinking about the ways we thoughtlessly cede that control.  We’re like toddlers throwing tinted drinking glasses on the floor to see the pretty sparkles, not thinking about how the resulting beauty might slice someone’s foot open.

We don’t need to stop writing code.  We do need to start thinking.

• Warning Hashflags was published on Tuesday, May 5th, 2015.
• It was assigned to the Culture, Observations, Politics, Tech, and Web categories.
• There have been eight replies.

This coming Monday, as has become tradition, a significant fraction of the Twitter user base will send out Star-Wars-themed tweets tagged #maythe4th or #maythefourthbewithyou, because saying the day in that way makes for a handy bit of wordplay.  There will be cosplay pictures, Yoda-esque inversions of sentence structure, and probably (this year) a fair bit of squeeing about the upcoming sequel and its brilliantly fan-service trailer.

Also this coming Monday, as has become tradition for me, I will send out a tweet containing the opening lines of “Ohio” by Crosby, Stills, Nash & Young, tagged #maythe4th, because it was on May 4th, 1970 that National Guardsmen fired a volley into a crowd of Kent State college students, wounding nine and killing four.

Anniversaries are potent psychological markers.  We reflect on historical events, both global and personal, that have particular meaning to us.  We celebrate the days of our birth, of first meeting our loved ones, of all manner of wonderful life-changing moments.  We mourn the days of our losses, of our betrayals, of all manner of terrible life-changing moments.  In every heart, a secret calendar.

There are only so many days in the year; pile enough things together on a calendar, and some of them will coincide.  Some of those alignments will coalesce into rays of remembered joy, warming us from the past.  Others will form spears of relived pain, lodging afresh in our hearts.  A few may do both, comforting and piercing all at once.

The longer we spend online, the more traces of those secret calendars will take public shape.  The dates of my first marriage and divorce are not, to the best of my recollection, recorded anywhere online, but the date of my second (and current) marriage is there, thanks to some early blog posts.  The date of my first professional award is there.  The dates of our children’s placements and adoptions are there.  The dates of my daughter’s illness and death are there.

The more we build online networks, not physical networks but social and emotional networks, the more pieces we leave lying around for algorithms to gather together and present to us with no real thought for what those pieces actually mean, or for how they should or shouldn’t fit together.  A human can glance through a pile of photos and tell which are emotionally or even narratively out of place.  Code cannot.  A human can quickly determine which scraps of text and pixels were happy at the moment of their creation, only to be transformed into talismans of sorrow by later events.  Code cannot.

We’re collectively creating strata of data, adorned with easy bits of metadata like time and date and sometimes place, but lacking all the truly important metadata like feeling and meaning.  As we share with each other, we share with the future.  We share with the companies that help us share with each other, because it’s easy to store it all.  Content in the old network was ephemeral, and in the older networks was tangible but private.  In the new networks, everything we create is easy to retrieve — if not for us, as users of the network, then at least for the code that runs on the same machines which accept all that we share.

And so, more and more with every passing day, code is written to reach back into everything we’ve created, assembling it along easily-identified axes like Likes or Faves or geographic coordinates or the day of the year, in order to show it to us again.  Sometimes it’s code we invite into our lives, but not always.  Sometimes we find the code that drives the networks we use resurrecting our past without warning.

This will not always be welcome.

There are things we can do to make our remorselessly remembering routines more humane, and most of those things are rooted in experience design.  We can design compassionate consent requests ahead of introducing new functionality, and easy ways to mark which dates and memories and bits of data should be avoided, and even design thoughtful expressions of remorse and apology.  We can and should add this very human layer of thoughtfulness to cushion us from literally unthinking code that yields results which may harm as easily as they may heal.

It won’t be easy, and we’ll make mistakes no matter how hard we try.  Our very attempts to be thoughtful may backfire and make things worse, but we’ll learn from those mistakes and do better the next time.

Nothing could be more human than that.

This article was originally published at The Pastry Box Project on 2 May 2015.

• Time and Emotion was published on Saturday, May 2nd, 2015.
• It was assigned to the Commentary, Culture, Tech, and Writing categories.
• There have been no replies.

A week ago today, I stood on a stage in San Francisco and told a couple thousand developers they were doing it wrong.  I mean, I got up there at O’Reilly’s Fluent, The Web Platfom conference, and gave a talk with a slide that literally said, “The Web is NOT a Platform”.  You can see it here, all fifteen minutes of it, in which I borrowed liberally from Jeremy Keith, added a splash of Mike Monteiro, and mixed it all together with things I’ve been saying and thinking for the past, oh, decade or more.

As it turned out, and a little bit to my surprise, a fair number of people completely agreed with what I had to say, judging by the reactions I got both online and in person.  Only a few people disagreed with me in person, which was fine; I actually hoped that there would be some pushback, since I’m not the smartest person in the world by any stretch.  The best part was, our disagreements were friendly, well-sourced, and collegial.  I love having conversations like that.  I don’t know that any of us changed our minds, but we were able to test our assumptions and viewpoints against each other.  In one case, I shook hands on a friendly, no-stakes bet over which of us would prove to be right, five or ten years down the line.

What made it really fun is that not twenty minutes after I stepped off the stage at the end of that talk, I stepped back on to accept a 2015 Web Platform Award alongside Sara Soueidan, Mark Nottingham, and Mikeal Rogers.  Those are some amazing people to stand with, and that it came from O’Reilly made it even more humbling.  In fact, Sara said it best: “This is my first time ever winning a web award, and I feel privileged to have won it from such a prestigious company.”  To which I would only add, and in such prestigious company.

I do want to note that what I said at the very end of my acceptance remarks was woefully insufficient.  What I should have said, and would have said if I hadn’t suddenly felt completely overwhelmed, is that the web has meant more to me, done more for me, and given more to me in the past two years than any one person could ever have any right to expect.  The web and what it makes possible, the ability to reach out and share and hear from you and stay in touch — that kept me sane, and may very well have kept me alive.

Thank you all.

• Heard and Received was published on Wednesday, April 29th, 2015.
• It was assigned to the Speaking and Web categories.
• There have been two replies.

If you prefer hearing voice to reading text, I was on a couple of podcasts recently and would like to share; also, I have some live appearances coming up soon.

The first podcast is a 16-minute segment on the eHealth Radio Network, talking about designing for crisis.  This was recorded shortly before AEA Seattle and HxRefactored, which is why I talk about HxRefactored in the future tense.  Much as was the case with my talk at HxRefactored, this concentrates on the topic of designing for crisis in a medical/health care context, and as it turns out, it’s only slightly shorter than was my HxR talk.

The second is both longer and a bit more recent: I talked for an hour with Chris and Dave at Shop Talk Show about flexbox, inline layout, the difficulties of the past two years, and how I’ve changed professionally.  It doesn’t shy away from the emotional side, and some listeners have described it as “heart-rending” and “sobering”.  So, you know, fair warning.  On the other hand, I call Chris Coyier a “newb” about a minute in, so there’s that.

In the Shop Talk episode, we talk briefly about Facebook’s On This Day feature, which had just launched but I hadn’t seen at that point.  Yesterday, it finally popped up in my Facebook timeline.  I had observations, and will probably write about them soon.  First, though, I need to finish up my slides for Fluent, where I’ll be giving my talk “This Web App Best Viewed By Someone Else”.  I get 13 minutes to tell the audience that they… well, I don’t want to spoil it for anyone.  (Plus there’s another slide deck I need to finish up for next week, but that’s for a private engagement, so never mind that now.)

In May, I’ll once again be presenting the hour-long version of “Designing for Crisis” at An Event Apart Boston.  There are still some seats left if you’d care to join us; it’s a pretty great lineup, and as usual I’m feeling a wee bit intimidated by the brilliance.  Attendees have been telling us that this year’s lineup is one of the best they’ve seen, making AEA worth every penny and then some, so you’d get way more out of the show than just hearing me.

In case you’re wondering (and I also mentioned this on ShopTalk), I won’t be at AEA San Diego in June.  Part of me very much wants to be, but an accident of scheduling made it inadvisable: the show starts June 8th, the day after the first anniversary of Rebecca’s death and what would have been her seventh birthday.  I don’t know that I’ll be in any shape to hold brief conversation, let alone stand on stage in front of a few hundred people and give an hour-long talk, in the days immediately following.  Rather than risk it, we (the AEA team and I) decided to have someone else take my place at the San Diego show, and that show only.  I intend to be at all our other shows this year.

Hopefully, I’ll get a chance to write about attending not-web-design conferences in the near future.  I find such experiences entertainingly, and in some ways refreshingly, different.  I recommend it.

• Talk Talk was published on Wednesday, April 15th, 2015.
• It was assigned to the An Event Apart, Interviews, and Speaking categories.
• There have been no replies.