Posts Tagged ‘jeremy keith’

The Savage Beatings Anti-Pattern

Monday, October 1st, 2012
CSSquirrel #102: The Savage Beatings Anti-Pattern

Just so we’re clear, in no way do I think that Jeremy Keith (one of today’s guest stars) would actually do any violence to Michael Sippey (the other guest star) or any other person in real life. I do, however, share Jeremy’s well documented rancor about the email notification anti-pattern. Which, among many other shameful companies, Twitter is notorious for its participation.

For those precious few of you who haven’t been victims of it, the anti-pattern in question is as follows:

  1. A site creates a new notification/email/spam.
  2. An option is created for their existing users to sign up for this further bloat to their in-boxes.
  3. As a “convenience”, it is set to “yes” by default.
  4. If for some reason (Heaven forfend!) you don’t like spam, you must then follow a link to their site, log INTO said site, and then un-click the offending “Yes” that’s on an item labeled something patently false like “Emails You’ll Really Want”.

This isn’t a customer service. They know it. And we know it. It’s force-feeding end users in the desperate hopes of squeezing extra profits out of our bloated corpses.

So what do we do about it?

I’m going to suggest we follow Jeremy’s advice.

Document (aka, blog) the situations when they occur, so there’s a greater awareness for new startups entering the space that this type of interaction and marketing is unwanted and hostile to users.

We probably shouldn’t threaten them with bats, but I suggest communicating directly with offenders. They may not change from one voice, or ten, or a hundred. But if enough people complain, maybe they’ll get the picture.

Also, participate in efforts to proactively communicate what web patterns suck, such as pointing people to Harry Brignull’s Dark Pattern Wiki (which doesn’t currently have this anti-pattern listed on it, but certainly should.)

Those are the best ideas I’ve got. Documentation, mockery, notification and education.

Got your own? Let me know via one of the response methods below. Or, heck, if you actually like being signed up for spam without your prior consent, please let me know. You’re likely the last of your kind and belong in a museum.

Game Break

Wednesday, September 19th, 2012
CSSquirrel #100: Game Break

It’s true. I pre-ordered Borderlands 2, but thanks to the wonders of shipping delays the game is somewhere between the warehouse and my home. It will be days yet before it makes it into my hands. Part of me wonders at the purpose of pre-ordering something if it’s not shipped in time to be received on launch day, but somehow I’ll survive. Like the Squirrel, I might choose distract myself through the powers of make-believe. Whatever it takes, right?

Don’t let my current game-related obsession fool you, however. I’m not suddenly competing with Penny Arcade for the title of “best gamer comic ever”. Today’s comic actually touches on the field of web design while discussing games for a very specific reason. Today’s guest star is Anna Debenham, a freelance front end developer from Brighton, UK. Anna is one of those brilliant web people that continues to add to that city’s reputation of being stuffed full of an unfair amount of awesome talent.

If somehow you haven’t heard of her yet, you will have a hard time continuing that trend going forward. Among other things she has contributed to 24 ways, shared her wisdom at conferences (she will be speaking at the upcoming Full Frontal 2012), and has just had a very interesting article about testing websites in game console browsers published over at A List Apart.

The article is a good read, and I recommend you check it out because it probably contains wisdom you need but currently lack.

I know I did.

Yes, I already knew that people were browsing websites via consoles. Yes, I knew that in some cases those consoles’ browsers aren’t nearly as capable as a typical desktop experience. But in my head that wasn’t something I needed to worry about. After all, how often are people browsing the web via their PS3?

A lot, it turns out. According to Anna’s article, a full one in eight people overall (in the UK, US and France) and one in four teens use their game console to browse the web on a regular basis. That, my friends, is a lot of people.

It’s an amount we probably can’t afford to ignore.

Among other things, this means that I now need to start thinking about how client sites might look in console browsers. I wonder if I can use this data to get Mindfly to set up an Xbox 360, PS3 and Wii in the studio.

You know, for work purposes.

This also reminds me of the need for community device labs that Jeremy Keith (another Brighton design wizard) has been thumping for. There’s so many bloody web-connected devices these days that it’s outside of the budget of most studios or teams to build a thorough collection themselves. Which is why he advocates the need for designer communities to support each other in putting together an open lab for one another to contribute towards and make use of. In his posts Jeremy spoke mainly about having mobile and tablet devices, but after reading Anna’s article I think there’s good reason to include consoles and even browser-capable toasters in such collections.

Let’s be honest, if a toaster can’t connect to the Internet yet, one soon will.

Should we be designing for every device, including consoles, with our websites? No. That way lies madness. There’s simply too many to account for, and by targeting all the ones you know you’ll be explicitly excluding the ones you don’t.

Nor should we get caught up in the mentality of targeting sites to specific devices. Every time you build a site to render specifically on an iPhone you’re failing to take into account how many other smartphones are out there with different capabilities and screen dimensions. Despite how abundantly clear this is, I see the same mistake made over and over again.

Don’t make your sites for specific devices. Please.

Anna rightly points that out herself in her ALA piece:

We can’t tailor experiences for every possible use case on every device, but we can use what we know about console web browsing to build a better overall experience. Like we’ve done by designing with mobile in mind, considering how a site could be used on a console can have a knock-on effect of making it easier to use overall.

Jeremy Keith speaks to that same point in the article of his that I linked above:

In fact I’ve found that one of the greatest benefits of testing on as many different platforms as possible is that it stops me from straying down the path of device-specific development. When I come across a problem in my testing, my reaction isn’t to think “how can I fix this problem on this particular device?”, which would probably involve throwing more code at it. Instead I think “how can I avoid this problem?” The particular device may have highlighted the issue, but there’s almost always a more fundamental problem to be tackled …and it’s very rarely tackled by throwing more code at it.

So do yourself a favor. Go check out Anna’s article about consoles. If you haven’t already done so, start thinking about what it means to be a web designer in a world where virtually every device we can think of can visit your website, and what it takes to make a design robust enough to survive on them all. And the next time you start thinking about tailoring for specific devices, stop and remember that’s a trap you can’t afford to fall for in our modern device-happy world.

More On HTML5 Semantics

Monday, November 14th, 2011

It’s been a few days since I wrote my post (and comic) entitled The Value of Meaning, wherein I registered my objection to Divya Manian’s article about HTML5 semantics called Our Pointless Pursuit of Semantic Value. In that time there’s been a great deal of continuing discussion on the topic from a lot of intelligent people that’s worth pointing out in case you missed it.

If you have time, you should read all of these. They’re all written by intelligent people getting into the heart of the HTML5 semantics debate with more clarity and detail than I could ever manage.

Can Hixie’s <Data>leks Exterminate <Time>?

Thursday, November 3rd, 2011
CSSquirrel #88: Can Hixie's <Data>leks Exterminate Time?

Edit: Roughly twenty minutes after I posted this, the W3C took action on the issue, insisting that the <time> element be placed back into the specification. You can read about it here. But please read on. It’s a good primer for the next time something like this happens.

Contrary to what you may have already heard, the <time> element hasn’t disappeared from HTML.

Yes, officially <time> is currently not part of the HTML spec. (Thanks to the muddle that is “HTML Living Specification” I’ll be honest and admit I’m not sure if is no longer part of HTML5 or it’s in some sort of Schrodinger’s Cat quantum-zombie state of existing in HTML5 but missing in the “ongoing HTML” that the WHATWG is proud to keep rolling down the conveyor belt.)

That doesn’t mean it’s not being used by authors (how’s Drupal builds, 2.6 million WordPress installs and the Boston Globe for you?) nor does it mean that is it not being used by user agents (ever-plucky Opera supports it).

What it means is that a single human being has decided that he doesn’t care for time one wit, and that a rather vague element called <data> can replace it instead.

This human is none other than Ian “The Benign Leviathan Dictator For Life” Hixie, editor for the HTML specification.

I could give you an explanation on how this scenario came to exist, but two Brits who are far more informed than I am (and likely slightly smarter) have made their own summaries. If you like knowing what’s going on (and I do) then go read them. These pair of fine gentlemen, Jeremy Keith and Bruce Lawson, both guest star in today’s comic as the good Doctor thanks to a little spot of regeneration, where they’re fighting the good fight against Hixie’s <data>leks.

Virtually every problem I have with a single person wielding so much power over such a fundamentally important pillar of the web as HTML can be summed up in this incident. <Time> is officially out, despite the lack of merit or consensus in that decision. And it took just one man to make that happen. Either through a lack of awareness or a genuine disregard for what authors are already doing, Ian has claimed incorrectly that <time> isn’t seeing adoption, isn’t useful, and should be canned. And because the only balance to his power is a rather tedious process to oust him, there’s no official remedy to bringing <time> back into the HTML fold than trying to convince him that its existence is a good thing.

From what I understand, it’s easier to keep red shirts alive on away missions than it is to change Ian’s opinion on something.

Fortunately, there’s a big difference between having no official remedy and having no remedy whatsoever.

As “authors”, we are the 99% of HTML5. We can follow Jeremy Keith’s sage advice:

We can make a stand and simply carry on using the time element in our web pages. If we do, then we’ll see more parsers and browsers implementing support for the time element. The fact that our documentation has been ripped away makes this trickier but it’s such a demonstrably useful addition to HTML that we cannot afford to throw it away based on the faulty logic of one person.

So as I said, <time> hasn’t disappeared from HTML. It’s still there on millions of sites already. And nothing is stopping us from putting it on millions more. It’s our chance to send those <data>leks packing. As soon as this post is finished I’m going to edit my site’s theme to make use of <time>. Hixie can go stuff it.

Occupy HTML5.

Comic: A Nacho Moment

Monday, February 14th, 2011
CSSquirrel #80: A Nacho Moment

Featuring Jeffrey Zeldman, Jeremy Keith and Dave Shea, today’s comic highlights what makes good people on the Internet into great people.

Humanity, it seems, is destined to fight with itself over every little detail. That’s probably not new information to you.

Thanks to the Internet, we don’t even need stamps or to be in someone’s physical presence to have these arguments. As anyone with a net connection knows, this means we will get into heated, acrimonious fights over topics as unimportant as who the hell was Papa Smurf’s partner in creating his dozens of smurf offspring. And we’ll stew over it. And we’ll 386 someone because of it. And we’ll lose sleep and remove friends from Facebook over it.

As as developer/designer who follows the same category of people on Twitter, many of the Internet fights I witness involve web standards, the tools we use as developers, the erotic-sounding but thoroughly disappointing topic of hashbangs and anything in between. Heck, I participate in these brawls, throwing acorns at the whole mess.

There’s a lot of reasons for these fights, but most often we argue because we care. The products we make as professionals mean a lot to us. We want the best for our medium and our industry, and so we get trenchant about Flash, HTML5, naming conventions, design techniques or the proper shade of blue. Because to us it matters. It matters a lot. And there is nothing wrong with that level of passion about your work. Quite the opposite. If you can’t imagine yourself fiercely defending what you do as an occupation, maybe you need a different career.

However, in the process we frequently seem to forget that we’re dealing with other people. Passionate people, some of which are just as informed as we are. Or even more so. And believe it or not, they’re entitled to have arrived at different conclusions than us. Yet, so often something about the Internet seems to boil away the concept of the right to respectfully disagree.

Last week, Zeldman and Keith got into a debate over a blog post by Andy Rutledge on the subject of Kickstarter. At times it seemed heated, and due to the nature of the medium they were debating in it was both very public and very abrupt. Then the next day Zeldman posted a series of tweets carefully reiterating his view, made it clear that Keith was his friend and simply saying “sorry” for the whole confusion. In front of an audience of 144,000 followers. Jeremy replied in the same vein.

It shouldn’t seem amazing that two people apologize over a fight in public. But somehow, on today’s Internet, it’s all but unheard of.

There’s a strange comfort in knowing that our Internet heroes are just as capable of the same fallacies we are.

It’s inspiring to see them follow it up by providing good examples by rising to a level of good behavior we rarely get to witness in social media today.

I’ve termed this sudden cessation of hostilities (without ceding the value of each party’s opinions) as a “nacho moment“, so named thanks to a moment of intentional, deliberate hilarity by Dave Shea best summarized by this pair of tweets. It’s a testament to his actions that I don’t even recall what large debate was going on before his tweets, but do know that afterward the Internet got a little less contentious and the Seattle area’s nacho sales rose just a bit.

Don’t stop caring about the things you care about, whether it’s the Smurfs or funding crowdsourcing. But when you’re in a debate, have a nacho moment and remember you’re talking to other people. People who also care.