Archive: August, 2014

It’s exactly two weeks until dConstruct. I AM EXCITE!!!11ELEVEN!! If you’ve already got your ticket: excellent! If not, you can still get one. It’s not too late.

There is a change to the advertised line-up…

Alas, Jen can no longer make it to Brighton. Circumstances have conspired to make trans-atlantic travel an impossibility. It’s a real shame because I was really looking forward to her talk, but these things happen (and she’s gutted too: she was really looking forward to being in Brighton for this year’s dConstruct).

But never fear. We’ve swapped out one fantastic talk for another fantastic talk. Brighton’s own Georgina Voss has very kindly stepped into the breach. She’s going to knock your socks off with her talk, Tethering the Hovercraft:

A careen through grassroots innovation, speculative design, supply chains and sexual healthcare provision, lashing down over-caffeinated flailing into the grit of socio-technical systems.

Awwww yeah!

I had the chance to see Georgina speak a few months back at Lighthouse Arts and it was terrific. She is the perfect fit for this year’s dConstruct—she really is living with the network.

It’s a shame that Jen can’t join us for this year’s dConstruct but, my goodness, what a great day it’s going to be—now with added Vossomeness!

Throughout the Brighton Digital Festival, Lighthouse Arts will be exhibiting a project from Julian Oliver and Danja Vasiliev called Newstweek. If you’re in town for dConstruct—and you should be—you ought to stop by and check it out.

It’s a mischievous little hardware hack intended for use in places with public WiFi. If you’ve got a Newstweek device, you can alter the content of web pages like, say, BBC News. Cheeky!

There’s one catch though. Newstweek works on http:// domains, not https://. This is exactly the scenario that Jake has been talking about:

SSL is also useful to ensure the data you’re receiving hasn’t been tampered with. It’s not just for user->server stuff

eg, when you visit http://www.theguardian.com/uk , you don’t really know it hasn’t been modified to tell a different story

There’s another good reason for switching to TLS. It would make life harder for GCHQ and the NSA—not impossible, but harder. It’s not a panacea, but it would help make our collectively-held network more secure, as per RFC 7258 from the Internet Engineering Task Force:

Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.

I’m all for using https:// instead of http:// but there’s a problem. It’s bloody difficult!

If you’re a sysadmin type that lives in the command line, then it’s probably not difficult at all. But for the rest of us mere mortals who just want to publish something on the web, it’s intimidatingly daunting.

Tim Bray says:

It’ll cost you <$100/yr plus a half-hour of server reconfiguration. I don’t see any excuse not to.

…but then, he also thought that anyone who can’t make a syndication feed that’s well-formed XML is an incompetent fool (whereas I ended up creating an entire service to save people from having to make RSS feeds by hand).

Google are now making SSL a ranking factor in their search results, which is their prerogative. If it results in worse search results, other search engines are available. But I don’t think it will have significant impact. Jake again:

if two pages have equal ranking except one is served securely, which do you think should appear first in results?

Ashe Dryden disagrees:

Google will be promoting SSL sites above those without, effectively doing the exact same thing we’re upset about the lack of net neutrality.

I don’t think that’s quite fair: if Google were an ISP slowing down http:// requests, that would be extremely worrying, but tweaking its already-opaque search algorithm isn’t quite the same.

Mind you, I do like this suggestion:

I think if Google is going to penalize you for not having SSL they should become a CA and issue free certs.

I’m more concerned by the discussions at Chrome and Mozilla about flagging up http:// connections as unsafe. While the approach is technically correct, I fear it could have the opposite of its intended effect. With so many sites still served over http://, users would be bombarded with constant messages of unsafe connections. Before long they would develop security blindness in much the same way that we’ve all developed banner-ad blindness.

My main issue—apart from the fact that I personally don’t have the necessary smarts to enable TLS—is related to what Ashe is concerned about:

Businesses and individuals who both know about and can afford to have SSL in place will be ranked above those who don’t/can’t.

I strongly believe that anyone should be able to publish on the web. That’s one of the reasons why I don’t share my fellow developers’ zeal for moving everything to JavaScript; I want anybody—not just programmers—to be able to share what they know. Hence my preference for simpler declarative languages like HTML and CSS (and my belief that they should remain simple and learnable).

It’s already too damn complex to register a domain and host a website. Adding one more roadblock isn’t going to help that situation. Just ask Drew and Rachel what it’s like trying to just make sure that their customers have a version of PHP from this decade.

I want a secure web. I’d really like the web to be https:// only. But until we get there, I really don’t like the thought of the web being divided into the haves and have-nots.

Still…

There is an enormous opportunity here, as John pointed out on a recent episode of The Web Ahead. Getting TLS set up is a pain point for a lot of people, not just me. Where there’s pain, there’s an opportunity to provide a service that removes the pain. Services like Squarespace are already taking the pain out of setting up a website. I’d like to see somebody provide a TLS valet service.

(And before you rush to tell me about the super-easy SSL-setup tutorial you know about, please stop and think about whether it’s actually more like this.)

I’m looking forward to switching my website over to https:// but I’m not going to do it until the potential pain level drops.

For all of you budding entrepreneurs looking for the next big thing to “disrupt”, please consider making your money not from the gold rush itself, but from providing the shovels.

The countdown to dConstruct 2014 has well and truly begun. It’s just three and a half weeks away, and I am very excited.

I have some good news and bad news.

The bad news is that Leila Johnston can no longer make it—she has decided to cancel all her public speaking engagements to focus on the next Hack Circus event.

But the (very) good news is that Anab Jain will be speaking! Yay!

I had actually approached Anab earlier when I was still putting together the line-up for this year’s dConstruct, but it didn’t look like she could fit it into her schedule. Then as the line-up of speakers coalesced, it became clearer and clearer that she would be the perfect person to talk about Living With The Network and I was filled with regret.

Now that she has so graciously agreed to step in at such short notice, I couldn’t be happier. Seriously, I am so excited about the line-up that I’m like a kid counting down the days until Christmas.

There are still tickets available for dConstruct 2014. If you haven’t got yours yet, well, you should fix that. (Have I mentioned how excited I am about this year’s line-up? I’m quite, quite excited about this year’s line-up.)

So you’re coming to @dconstruct right? No? Well that’s where you’re going wrong in life. 2014.dconstruct.org

— Drew McLellan (@drewm) July 8, 2014

If you’re the gambling kind, you can try your luck at winning a ticket to the conference, thanks to our lovely sponsors SiteGround. Fill in their short survey and you’re in with a chance.

Regardless of how you get hold of ticket, get hold of a ticket. And I’ll see you at the magnificent Brighton Dome on Friday, September 5th for a day of superb brain-bending entertainment from Warren Ellis, Mandy Brown, Cory Doctorow, Clare Reddington, Tom Scott, Aaron Straup Cope, Jen Lowe, Brian Suda …and Anab Jain!

Here at Clearleft, we’ve been doing some extra work with Code for America following on from our initial deliverables. This makes me happy for a number of reasons:

1. They’re a great client—really easy-going and fun to work with.
2. We’ve got Anna back in the office and it’s always nice to have her around.
3. We get to revisit the styleguide we provided, and test our assumptions.

That last one is important. When we provide a pattern library to a client, we hope that they’ve got everything they need. If we’ve done our job right, then they’ll be able to combine patterns in ways we haven’t foreseen to create entirely new page types.

For the most part, that’s been the case with Code for America. They have a solid set of patterns that are serving them well. But what’s been fascinating is to hear about what it’s like for the people using those patterns…

There’s been a welcome trend in recent years towards extremely robust, maintainable CSS. SMACSS, BEM, OOCSS and other methodologies might differ in their details, but their fundamental approach is pretty similar. The idea is that you apply a very specific class to every element you want to style:

<div class="thingy">
    <ul class="thingy-bit">
        <li class="thingy-bit-item"></li>
        <li class="thingy-bit-item"></li>
    </ul>
    <img class="thingy-wotsit" src="" alt="" />
</div>

That allows you to keep your CSS selectors very short, but very specific:

.thingy {}
.thingy-bit {}
.thingy-bit-item {}
.thingy-wotsit {}

There’s little or no nesting, and you only ever use class selectors. That keeps your CSS nice and clear, and you avoid specificity hell. The catch is that your HTML is necessarily more verbose: you need to explicitly add a class to whatever you want to style.

For most projects—particularly product work (think Twitter, Facebook, etc.)—that’s a completely acceptable trade-off. It’s usually the same developers editing the CSS and the HTML so there’s no problem moving complexity out of CSS and into the markup templates. Even if other people will be entering the actual content into the system, they’ll probably be doing that mediated through a Content Management System, rather than editing HTML directly.

So nine times out of ten, making the HTML more verbose is absolutely the right choice in order to make the CSS more manageable and maintainable. That’s the way we initially built the pattern library for Code for America.

Well, it turns out that the people using the markup patterns aren’t necessarily the same people who would be dealing with the CSS. Also, there isn’t necessarily a CMS involved. Instead, people (volunteers, employees, anyone really) create new pages by copying and pasting the patterns we’ve provided and then editing them.

By optimising on the CSS side of things, we’ve offloaded a lot of complexity onto their shoulders. While it’s fair enough to expect them to understand basic HTML, it’s hardly fair to expect them to learn a whole new vocabulary of thingy and thingy-wotsit class names just to get things to look they way they expect.

Here’s a markup pattern that makes more sense for the people actually dealing with the HTML:

<div class="thingy">
    <ul>
        <li></li>
        <li></li>
    </ul>
    <img src="" alt="" />
</div>

Much clearer. But now the CSS looks like this:

.thingy {}
.thingy ul {}
.thingy li {}
.thingy img {}

Actually it’s probably going to look more complicated than that: more nesting, more element selectors, more “defensive” rules trying to anticipate the kind of markup that might be used in a particular pattern.

It feels really strange for Anna and myself to work with these kind of patterns. All of our experience screams “Don’t do that! Why would you that?” …but in this case, it’s the right thing to do for the people building the actual website.

So please don’t interpret this as me saying “Hey, everyone, this is how you should write your CSS.” I’m not saying this is better or worse than adding lots of classes to your HTML. If anything, this illustrates that there is no one right way to do this.

It’s worth remembering why we’re aiming for maintainability in what we write. It’s not for any technical reason. It’s for people. If those people find it better to deal with simplified CSS with more complex HTML, than the complexity should be in the HTML. But if the priority for those people is to have simple HTML, then more complex CSS may be an acceptable price to pay.

In other words, it depends.

Last week I had responsive-themed tour of London.

On Tuesday I went up to Chelsea to spend the day workshopping with some people at Education First. It all went rather splendidly, I’m happy to report.

It was an interesting place. First of all, there’s the office building itself. Once owned by News International, it has a nice balance between open-plan and grouped areas. Then there’s the people. Just 20% of them are native English speakers. It was really nice to be in such a diverse group.

The workshop attendees represented a good mix of skills too: UX, front-end development, and visual design were at the forefront, but project management and content writing were also represented. That made the exercises we did together very rewarding.

I was particularly happy that the workshop wasn’t just attended by developers or designers, seeing as one of the messages I was hammering home all day was that responsive web design affects everyone at every stage of a project:

Y’see, it’s my experience that the biggest challenges of responsive design (which, let’s face it, now means web design) are not technology problems. Sure, we’ve got some wicked problems when dealing with non-flexible media like bitmap images, which fight against the flexible nature of the web, but thanks to the work of some very smart and talented people, even those kinds of issues are manageable.

No, the biggest challenges, in my experience, are to do with people. Specifically, the way that people work together.

On Thursday evening, I reiterated that point at The Digital Pond event in Islington …leading at least one person in the audience to declare that they were having an existential crisis (not my intention, honest).

I also had the pleasure of hearing Sally give her take on responsive design. She was terrific at Responsive Day Out 2 and she was, of course, terrific here again. If you get the chance to see her speak, take it.

There should be videos from Digital Pond available at some point, so you’ll be able to catch up with our talks then.

I’ve published the schedule for this year’s dConstruct. Curating an event like this doesn’t stop when the speakers have been finalised. Figuring out the flow of the day is another aspect that I really wanted to get right. It’s like making a mixtape.

Anyway, here’s what I’ve got planned …but maybe I’ll add the “subject to change” caveat just in case I change my mind:

9:00	Registration
10:15	Warren Ellis
11:00	Jen Lowe
11:30	Break
12:00	Clare Reddington
12:30	Aaron Straup Cope
13:00	Lunch
14:30	Brian Suda
15:00	Mandy Brown
15:30	Leila Johnston
16:00	Break
16:30	Tom Scott
17:00	Cory Doctorow
17:45	After-party

Regardless of what order the talks end up in, I’m really excited about seeing every single one of them.

Warren’s talk is simply called “A Cunning Plan”:

Inventing the next twenty years, strategic foresight, fictional futurism and English rural magic: Warren Ellis attempts to convince you that they are all pretty much the same thing, and why it was very important that some people used to stalk around village hedgerows at night wearing iron goggles.

Jen’s is “Enigmas, not Explanations: a Speculative Nonfiction”:

A wander through indescribable projects, magical realisms, and the fantastical present. A speculation on resonances within the network and the good that can come from making questions without answers.

Clare will talk about “Memes for Cities”:

A giant water slide. A talking lamppost. A zombie chase game. These recent city interventions were enabled by networks of people, technology and infrastructure, making the world more playful and creating change. In this Playable City talk, Clare will take on the functional image of a future city, sharing how to design playful experiences that change our relationships with the places we live and work.

Aaron’s talk is intriguely titled “Still Life with Emotional Contagion”.

I love where Brian is going with “Humans Are Only a Self-driving Car’s Way of Making Another Self-driving Car”:

Over 10,000 years ago we lived in balance with the network. Since then we’ve tried to control, rule and bend it to our whims. In all that time, we’ve never asked ourselves if we’re building something that controls us?

Mandy will be talking about “Hypertext as an Agent of Change”:

Mandy Brown contemplates how hypertext has changed us, and what change is yet to come.

Leila’s talk will be the autobiographical “Running Away with the Circus”:

Lessons of launching your own magazine and event series, how to make it work, what not to do, and how to keep the right attitude and get interesting stuff done against the odds.

Tom will take us on a journey to 2030:

Privacy’s dead. What happens next?

And finally, Cory will declare “Information Doesn’t Want to be Free”:

There are three iron laws of information age creativity, freedom and business, woven deep into the fabric of the Internet’s design, the functioning of markets, and the global system of regulation and trade agreements.

You can’t attain any kind of sustained commercial, creative success without understanding these laws — but more importantly, the future of freedom itself depends on getting them right.

They all sound bloody brilliant!

There are still plenty of tickets left so if you haven’t got your ticket to dConstruct yet (what’s wrong with you?), you can grab one now.