Tags: 3d

31

sparkline

Wednesday, April 19th, 2017

Designing the Patterns Day site

Patterns Day is not one of Clearleft’s slick’n’smooth conferences like dConstruct or UX London. It’s more of a spit’n’sawdust affair, like Responsive Day Out.

You can probably tell from looking at the Patterns Day website that it wasn’t made by a crack team of designers and developers—it’s something I threw together over the course of a few days. I had a lot of fun doing it.

I like designing in the browser. That’s how I ended up designing Resilient Web Design, The Session, and Huffduffer back in the day. But there’s always the initial problem of the blank page. I mean, I had content to work with (the information about the event), but I had no design direction.

My designery colleagues at Clearleft were all busy on client projects so I couldn’t ask any of them to design a website, but I thought perhaps they’d enjoy a little time-limited side exercise in producing ideas for a design direction. Initially I was thinking they could all get together for a couple of hours, lock themselves in a room, and bash out some ideas as though it were a mini hack farm. Coordinating calendars proved too tricky for that. So Jon came up with an alternative: a baton relay.

Remember Layer Tennis? I once did the commentary for a Layer Tennis match and it was a riot—simultaneously terrifying and rewarding.

Anyway, Jon suggested something kind of like that, but instead of a file being batted back and forth between two designers, the file would passed along from designer to designer. Each designer gets one art board in a Sketch file. You get to see what the previous designers have done, leaving you to either riff on that or strike off in a new direction.

The only material I supplied was an early draft of text for the website, some photos of the first confirmed speakers, and some photos I took of repeating tiles when I was in Porto (patterns, see?). I made it clear that I wasn’t looking for pages or layouts—I was interested in colour, typography, texture and “feel.” Style tiles, yes; comps, no.

Jon

Jon’s art board.

Jon kicks things off and immediately sets the tone with bright, vibrant colours. You can already see some elements that made it into the final site like the tiling background image of shapes, and the green-bordered text block. There are some interesting logo ideas in there too, some of them riffing on LEGO, others riffing on illustrations from Christopher Alexander’s book, A Pattern Language. Then there’s the typeface: Avenir Next. I like it.

James G

James G’s art board.

Jimmy G is up next. He concentrates on the tiles idea. You can see some of the original photos from Porto in the art board, alongside his abstracted versions. I think they look great, and I tried really hard to incorporate them into the site, but I couldn’t quite get them to sit with the other design elements. Looking at them now, I still want to get them into the site …maybe I’ll tinker with the speaker portraits to get something more like what James shows here.

Ed

Ed’s art board.

Ed picks up the baton and immediately iterates through a bunch of logo ideas. There’s something about the overlapping text that I like, but I’m not sure it fits for this particular site. I really like the effect of the multiple borders though. With a bit more time, I’d like to work this into the site.

James B

Batesy’s art board.

Batesy is the final participant. He has some other nice ideas in there, like the really subtle tiling background that also made its way into the final site (but I’ll pass on the completely illegible text on the block of bright green). James works through two very different ideas for the logo. One of them feels a bit too busy and chaotic for me, but the other one …I like it a lot.

I immediately start thinking “Hmm …how could I make this work in a responsive way?” This is exactly the impetus I needed. At this point I start diving into CSS. Not only did I have some design direction, I’m champing at the bit to play with some of these ideas. The exercise was a success!

Feel free to poke around the Patterns Day site. And while you’re there, pick up a ticket for the event too.

Monday, January 23rd, 2017

Charlotte

Over the eleven-year (and counting) lifespan of Clearleft, people have come and gone—great people like Nat, Andy, Paul and many more. It’s always a bittersweet feeling. On the one hand, I know I’ll miss having them around, but on the other hand, I totally get why they’d want to try their hand at something different.

It was Charlotte’s last day at Clearleft last Friday. Her husband Tom is being relocated to work in Sydney, which is quite the exciting opportunity for both of them. Charlotte’s already set up with a job at Atlassian—they’re very lucky to have her.

So once again there’s the excitement of seeing someone set out on a new adventure. But this one feels particularly bittersweet to me. Charlotte wasn’t just a co-worker. For a while there, I was her teacher …or coach …or mentor …I’m not really sure what to call it. I wrote about the first year of learning and how it wasn’t just a learning experience for Charlotte, it was very much a learning experience for me.

For the last year though, there’s been less and less of that direct transfer of skills and knowledge. Charlotte is definitely not a “junior” developer any more (whatever that means), which is really good but it’s left a bit of a gap for me when it comes to finding fulfilment.

Just last week I was checking in with Charlotte at the end of a long day she had spent tirelessly working on the new Clearleft site. Mostly I was making sure that she was going to go home and not stay late (something that had happened the week before which I wanted to nip in the bud—that’s not how we do things ‘round here). She was working on a particularly gnarly cross-browser issue and I ended up sitting with her, trying to help work through it. At the end, I remember thinking “I’ve missed this.”

It hasn’t been all about HTML, CSS, and JavaScript. Charlotte really pushed herself to become a public speaker. I did everything I could to support that—offering advice, giving feedback and encouragement—but in the end, it was all down to her.

I can’t describe the immense swell of pride I felt when Charlotte spoke on stage. Watching her deliver her talk at Dot York was one my highlights of the year.

Thinking about it, this is probably the perfect time for Charlotte to leave the Clearleft nest. After all, I’m not sure there’s anything more I can teach her. But this feels like a particularly sad parting, maybe because she’s going all the way to Australia and not, y’know, starting a new job in London.

In our final one-to-one, my stiff upper lip may have had a slight wobble as I told Charlotte what I thought was her greatest strength. It wasn’t her work ethic (which is incredibly strong), and it wasn’t her CSS skills (‘though she is now an absolute wizard). No, her greatest strength, in my opinion, is her kindness.

I saw her kindness in how she behaved with her colleagues, her peers, and of course in all the fantastic work she’s done at Codebar Brighton.

I’m going to miss her.

Wednesday, November 23rd, 2016

Smithsonian 3D Apollo 11 Command Module

This is so wonderful! A 3D fly-through of the Apollo 11 command module, right in your browser. It might get your fan whirring, but it’s worth it.

Click through for lots of great details on the interface controls, like which kinds of buttons and switches were chosen for which tasks.

And there’s this lovely note scrawled near the sextant by Michael Collins (the coolest of all the astronauts):

Spacecraft 107, alias Apollo 11, alias ‘Columbia.’ The Best Ship to Come Down the Line. God Bless Her.

Friday, October 21st, 2016

SpaceTime Coordinates Memento ~ your personal place in space by govy — Kickstarter

This is a rather lovely idea—a disc with eight rings, each marked with the position of a planet, the arrangement of which corresponds to a specific date.

Sunday, July 3rd, 2016

Unlabelled search fields

Adam Silver is writing a book on forms—you may be familiar with his previous book on maintainable CSS. In a recent article (that for some reason isn’t on his blog), he looks at markup patterns for search forms and advocates that we should always use a label. I agree. But for some reason, we keep getting handed designs that show unlabelled search forms. And no, a placeholder is not a label.

I had a discussion with Mark about this the other day. The form he was marking up didn’t have a label, but it did have a button with some text that would work as a label:

<input type="search" placeholder="…">
<button type="submit">
Search
</button>

He was wondering if there was a way of using the button’s text as the label. I think there is. Using aria-labelledby like this, the button’s text should be read out before the input field:

<input aria-labelledby="searchtext" type="search" placeholder="…">
<button type="submit" id="searchtext">
Search
</button>

Notice that I say “think” and “should.” It’s one thing to figure out a theoretical solution, but only testing will show whether it actually works.

The W3C’s WAI tutorial on labelling content gives an example that uses aria-label instead:

<input type="text" name="search" aria-label="Search">
<button type="submit">Search</button>

It seems a bit of a shame to me that the label text is duplicated in the button and in the aria-label attribute (and being squirrelled away in an attribute, it runs the risk of metacrap rot). But they know what they’re talking about so there may well be very good reasons to prefer duplicating the value with aria-label rather than pointing to the value with aria-labelledby.

I thought it would be interesting to see how other sites are approaching this pattern—unlabelled search forms are all too common. All the markup examples here have been simplified a bit, removing class attributes and the like…

The BBC’s search form does actually have a label:

<label for="orb-search-q">
Search the BBC
</label>
<input id="orb-search-q" placeholder="Search" type="text">
<button>Search the BBC</button>

But that label is then hidden using CSS:

position: absolute;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px, 1px, 1px, 1px);

That CSS—as pioneered by Snook—ensures that the label is visually hidden but remains accessible to assistive technology. Using something like display: none would hide the label for everyone.

Medium wraps the input (and icon) in a label and then gives the label a title attribute. Like aria-label, a title attribute should be read out by screen readers, but it has the added advantage of also being visible as a tooltip on hover:

<label title="Search Medium">
  <span class="svgIcon"><svg></svg></span>
  <input type="search">
</label>

This is also what Google does on what must be the most visited search form on the web. But the W3C’s WAI tutorial warns against using the title attribute like this:

This approach is generally less reliable and not recommended because some screen readers and assistive technologies do not interpret the title attribute as a replacement for the label element, possibly because the title attribute is often used to provide non-essential information.

Twitter follows the BBC’s pattern of having a label but visually hiding it. They also have some descriptive text for the icon, and that text gets visually hidden too:

<label class="visuallyhidden" for="search-query">Search query</label>
<input id="search-query" placeholder="Search Twitter" type="text">
<span class="search-icon>
  <button type="submit" class="Icon" tabindex="-1">
    <span class="visuallyhidden">Search Twitter</span>
  </button>
</span>

Here’s their CSS for hiding those bits of text—it’s very similar to the BBC’s:

.visuallyhidden {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
}

That’s exactly the CSS recommended in the W3C’s WAI tutorial.

Flickr have gone with the aria-label pattern as recommended in that W3C WAI tutorial:

<input placeholder="Photos, people, or groups" aria-label="Search" type="text">
<input type="submit" value="Search">

Interestingly, neither Twitter or Flickr are using type="search" on the input elements. I’m guessing this is probably because of frustrations with trying to undo the default styles that some browsers apply to input type="search" fields. Seems a shame though.

Instagram also doesn’t use type="search" and makes no attempt to expose any kind of accessible label:

<input type="text" placeholder="Search">
<span class="coreSpriteSearchIcon"></span>

Same with Tumblr:

<input tabindex="1" type="text" name="q" id="search_query" placeholder="Search Tumblr" autocomplete="off" required="required">

…although the search form itself does have role="search" applied to it. Perhaps that helps to mitigate the lack of a clear label?

After that whistle-stop tour of a few of the web’s unlabelled search forms, it looks like the options are:

  • a visually-hidden label element,
  • an aria-label attribute,
  • a title attribute, or
  • associate some text using aria-labelledby.

But that last one needs some testing.

Update: Emil did some testing. Looks like all screen-reader/browser combinations will read the associated text.

Sunday, May 15th, 2016

Content Buddy

I have a new role at Clearleft. It’s not a full-time role. It’s in addition to my existing role of …um …whatever it is I do at Clearleft.

Anyway, my new part-time role is that of being a content buddy. Sounds a little dismissive when I put it like that. Let me put in capitals…

My new part-time role is that of being a Content Buddy.

This is Ellen’s idea. She’s been recruiting Content Guardians and Content Buddies. The Guardians will be responsible for coaxing content out of people, encouraging to write that blog post, article, or case study. The role of the Content Buddy is to help shepherd those pieces into the world.

I have let it be known throughout the office that I am available—day or night, rain or shine—for proof-reading, editing, and general brain-storming and rubber-ducking.

On my first official day as a Content Buddy on Friday I helped Ben polish off a really good blog post (watch this space), listened to a first run-through of Charlotte’s upcoming talk at the Up Front conference in Manchester (which is shaping up to be most excellent), and got together with Paul for a mutual brainstorming session for future conference talks. The fact that Paul is no longer a full-time employee at Clearleft is a mere technicality—Content Buddies for life!

Paul is preparing a talk on design systems for Smashing Conference in Freiburg in September. I’m preparing a talk on the A element for the HTML Special part of CSS Day in Amsterdam in just one month’s time (gulp!). We had both already done a bit of mind-mapping to get a jumble of ideas down on paper. We learned that from Ellen’s excellent workshop.

Talk prep, phase 1: doodling.

Then we started throwing ideas back and forth, offering suggestions, and spotting patterns. Once we had lots of discrete chunks of stuff outlined (but no idea how to piece them together), we did some short intense spurts of writing using the fiendish TheMostDangerousWritingApp.com. I looked at Paul’s mind map, chose a topic from it for him, and he had to write on that non-stop for three to five minutes. Meanwhile he picked a topic from my mind map and I had to do the same. It was exhausting but also exhilarating. Very quickly we had chunks of content that we could experiment with, putting them in together in different ways to find different narrative threads. I might experiment with publishing them as short standalone blog posts.

The point was not to have polished, finished content but rather to get to the “shitty first draft” stage quickly. We were following Hemingway’s advice:

Write drunk, edit sober.

…but not literally. Mind you, I could certainly imagine combining beer o’clock on Fridays with Content Buddiness. That wasn’t an option on this particular Friday though, as I had to run off to band practice with Salter Cane. A very different, and altogether darker form of content creation.

Wednesday, May 11th, 2016

Indie Web Camp Düsseldorf

Indie Web Camp Düsseldorf took place last weekend and it was—no surprise—really excellent.

It felt really good to have one in Germany again so soon after the last one in Nuremberg. Lots of familiar faces showed up as well as plenty of newcomers.

I’m blown away by how much gets done in two short days, especially from people who start the weekend without a personal website and end it with something to call their own. Like Julie’s new site for example (and once again she took loads of great photos).

My own bit of hacking was quite different to what I got up to in Nuremberg. At that event, I was concentrating on the interface, adding sparklines and a bio to my home page. This time round I concentrated more on the plumbing. I finally updated some the code that handles webmentions. I first got it working a few year’s back at an Indie Web Camp here in Brighton, but I hadn’t really updated the code in a while. I’m much happier with the way it’s working now.

I also updated the way I’m syndicating my notes to Twitter, specifically how I send photos. Previously I was using the API method /statuses/updatewithmedia.

When I was at the Mobile @Scale event at Facebook’s London office a while back, Henna Kermani gave a talk about the new way that Twitter handles file uploads. There’s a whole new part of the API for handling that. When she got off stage, I mentioned to her that I was still using the old API method and asked how long it would be until it was switched off. She looked at incredulously and said “It’s still working‽ I thought it had been turned off already!”

That’s why I spent most of my time at Indie Web Camp Düsseldorf updating my PHP. Switching over to the TwitterOAuth library made it a bit less painful—thanks to Bea for helping me out there.

When it came time to demo, I didn’t have much to show. On the surface, my site looked no different. But I feel pretty good about finally getting around to changing the wiring under the hood.

Besides, there were plenty of other great demos. There was even some more sparklining. Check out this fantastic visualisation of the Indie Web Camp IRC logs made by Kevin …who wasn’t even in Düsseldorf; he participated remotely.

If you get the chance to attend an Indie Web Camp I highly, highly recommend it. In the meantime you can start working on your personal site. Here’s a quick primer I wrote a while back on indie web building blocks. Have fun!

Sunday, January 3rd, 2016

Year’s end

I usually write a little post at the end of each year, looking back at the previous 365 days. But this time I feel like I’ve already done that. I’ve already written about my year of learning with Charlotte, which describes what I’ve been doing at work for the last twelve months.

Apart from that, there isn’t much more to say about 2015. And that’s a good thing. 2014 was a year tainted by death so I’m not complaining about having just had a year with no momentous events.

The worst that could be said of my 2015 is that Clearleft went through a tough final quarter of the year (some big projects ended up finishing around the same time, which left us floundering for new business—something we should have foreseen), but in the grand scheme of things, that’s not exactly a tragedy.

Mostly when I think back on the year, my memories are pleasant ones. I travelled to interesting places, ate some great food, and spent time with lovely people—Jenn and Sutter’s wedding being a beautiful blend of all three.

So instead of doing a year-end roundup of my own, I’ll just point to some others: James, Alice, Laura, Eliot, Remy, and Brad.

I look forward to reading more posts on their websites in 2016. I hope that you’ll be publishing on your website this year too.

Happy new year!

Japan Hackfarm Anna and Cennydd Rachel at Jon and Hannah's wedding Bletchley Park Beerleft Brad visits Brighton Visiting my mother in Ireland Jessica and Emil Homebrew Website Club Jessica and Dan Jenn and Sutter Me and Brian Clearleft turns 10 Jessica in Austin Clearleft interns Christmas jumpers Christmas in Seattle

Friday, December 11th, 2015

Where to start?

A lot of the talks at this year’s Chrome Dev Summit were about progressive web apps. This makes me happy. But I think the focus is perhaps a bit too much on the “app” part on not enough on “progressive”.

What I mean is that there’s an inevitable tendency to focus on technologies—Service Workers, HTTPS, manifest files—and not so much on the approach. That’s understandable. The technologies are concrete, demonstrable things, whereas approaches, mindsets, and processes are far more nebulous in comparison.

Still, I think that the most important facet of building a robust, resilient website is how you approach building it rather than what you build it with.

Many of the progressive app demos use server-side and client-side rendering, which is great …but that aspect tends to get glossed over:

Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering, but this is only one of many options.

I think it’s vital to not think in terms of older browsers “falling back” but to think in terms of newer browsers getting a turbo-boost. That may sound like a nit-picky semantic subtlety, but it’s actually a radical difference in mindset.

Many of the arguments I’ve heard against progressive enhancement—like Tom’s presentation at Responsive Field Day—talk about the burdensome overhead of having to bolt on functionality for older or less-capable browsers (even Jake has done this). But the whole point of progressive enhancement is that you start with the simplest possible functionality for the greatest number of users. If anything gets bolted on, it’s the more advanced functionality for the newer or more capable browsers.

So if your conception of progressive enhancement is that it’s an added extra, I think you really need to turn that thinking around. And that’s hard. It’s hard because you need to rewire some well-engrained pathways.

There is some precedence for this though. It was really, really hard to convince people to stop using tables for layout and starting using CSS instead. That was a tall order—completely change the way you approach building on the web. But eventually we got there.

When Ethan came out with Responsive Web Design, it was an equally difficult pill to swallow, not because of the technologies involved—media queries, percentages, etc.—but because of the change in thinking that was required. But eventually we got there.

These kinds of fundamental changes are inevitably painful …at first. After years of building websites using tables for layout, creating your first CSS-based layout was demoralisingly difficult. But the second time was a bit easier. And the third time, easier still. Until eventually it just became normal.

Likewise with responsive design. After years of building fixed-width websites, trying to build in a fluid, flexible way was frustratingly hard. But the second time wasn’t quite as hard. And the third time …well, eventually it just became normal.

So if you’re used to thinking of the all-singing, all-dancing version of your site as the starting point, it’s going to be really, really hard to instead start by building the most basic, accessible version first and then work up to the all-singing, all-dancing version …at first. But eventually it will just become normal.

For now, though, it’s going to take work.

The recent redesign of Google+ is true case study in building a performant, responsive, progressive site:

With server-side rendering we make sure that the user can begin reading as soon as the HTML is loaded, and no JavaScript needs to run in order to update the contents of the page. Once the page is loaded and the user clicks on a link, we do not want to perform a full round-trip to render everything again. This is where client-side rendering becomes important — we just need to fetch the data and the templates, and render the new page on the client. This involves lots of tradeoffs; so we used a framework that makes server-side and client-side rendering easy without the downside of having to implement everything twice — on the server and on the client.

This took work. Had they chosen to rely on client-side rendering alone, they could have built something quicker. But I think it was worth laying that solid foundation. And the next time they need to build something this way, it’s going to be less work. Eventually it just becomes normal.

But it all starts with thinking of the server-side rendering as the default. Server-side rendering is not a fallback; client-side rendering is an enhancement.

That’s exactly the kind of mindset that enables Jack Franklin to build robust, resilient websites:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. Server-side rendering was the default; client-side rendering was added later.

The key to building modern, resilient, progressive sites doesn’t lie in browser technologies or frameworks; it lies in how we think about the task at hand; how we approach building from the ground up rather than the top down. Changing the way we fundamentally think about building for the web is inevitably going to be challenging …at first. But it will also be immensely rewarding.

Thursday, December 10th, 2015

Rabbit pappardelle.

Rabbit pappardelle.

Thursday, August 20th, 2015

dConstruct 2015 podcast: Carla Diana

The dConstruct podcast episodes are coming thick and fast. The latest episode is a thoroughly enjoyable natter I had with the brilliant Carla Diana.

We talk about robots, smart objects, prototyping, 3D printing, and the world of teaching design.

Remember, you can subscribe to the podcast feed in any podcast software you like, or if iTunes is your thing, you can also subscribe directly in iTunes.

And don’t forget to use the discount code ‘ansible’ when you’re buying your dConstruct ticket …because you are coming to dConstruct, right?

Tuesday, April 28th, 2015

Jersey royals.

Jersey royals.

Thursday, January 15th, 2015

Gyoza.

Gyoza.

Kara-age.

Kara-age.

Saturday, March 2nd, 2013

CSS 3D Clouds

A beautiful experiment with CSS transforms and a smattering of JavaScript.

Thursday, January 31st, 2013

What’s the deal with copyright and 3D printing? by Michael Weinberg

Michael Weinberg’s follow-up whitepaper to “It will be awesome if they don’t screw it up.”

Thursday, January 3rd, 2013

Medaler.com

I know have a visualisation of my public data in the form of 3D-printed snowflake, thanks to Medaler.

Friday, August 3rd, 2012

3D-Printed “Magic Arms” - YouTube

3D printing an exoskeleton for a child with arthrogryposis — technology can be so fricking awesome!

Monday, February 6th, 2012

BLDGBLOG: Object Cancers

You think that Digital Rights Management is bad? What about Physible Rights Management?

Monday, January 30th, 2012

Making

There’s definitely something stirring in the geek zeitgeist: something three-dimensional.

Tim Maly just published an article in Technology Review called Why 3-D Printing Isn’t Like Virtual Reality:

Something interesting happens when the cost of tooling-up falls. There comes a point where your production runs are small enough that the economies of scale that justify container ships from China stop working.

Meanwhile The Atlantic interviewed Brendan for an article called Why Apple Should Start Making a 3D Printer Right Now:

3D Printing is unlikely to prove as satisfying to manual labor evangelists as an afternoon spent with a monkey wrench. But by bringing more and more people into the innovation process, 3D printers could usher in a new generation of builders and designers and tinkerers, just as Legos and erector sets turned previous generations into amateur engineers and architects.

Last month Anil Dash published his wishlist for the direction this technology could take: 3D Printing, Teleporters and Wishes:

Every 3D printer should seamlessly integrate a 3D scanner, even if it makes the device cost much more. The reason is simple: If you set the expectation that every device can both input and output 3D objects, you provide the necessary fundamentals for network effects to take off amongst creators. But no, these devices are not “3D fax machines”. What you’ve actually made, when you have an internet-connected device that can both send and receive 3D-printed objects, is a teleporter.

Anil’s frustrations and hopes echo a white paper from 2010 by Michael Weinberg called It Will Be Awesome if They Don’t Screw it Up: 3D Printing, Intellectual Property, and the Fight Over the Next Great Disruptive Technology:

The ability to reproduce physical objects in small workshops and at home is potentially just as revolutionary as the ability to summon information from any source onto a computer screen.

Michael Weinberg also appears as one of the guests on an episode ABC Radio’s Future Tense along with Tom Standage, one of my favourite non-fiction authors.

The 3-D Printer - Future Tense - ABC Radio National (Australian Broadcasting Corporation) on Huffduffer

But my favourite piece of speculation on where this technology could take us comes from Russell Davies. He gave an excellent talk as part of the BBC’s Four Thought series in which he talks not so much about The Internet Of Things, but The Geocities Of Things. I like that.

BBC - Podcasts - Four Thought: Russell M. Davies 21 Sept 2011 on Huffduffer

It’s a short talk. Take the time to listen to it, then go grab a copy of Cory Doctorow’s book Makers and have a poke around Thingiverse