Category is: Interwebs

(Cross posted from the company blog at MetaBroadcast)

I’ve been taking about a thousand photos a month for years now, and at last month’s #MetaBeerTalks I did a short talk on the reasons why people look at your pics, and how to pander to them (ideally by taking pics of them holding cats).

What I didn’t touch on is that by far the best way to make people look at your pics is to delete most of them. This often surprises people but it stands to reason: your audience has limited attention spans so after taking a few hundred pics of an event the question becomes: which would you rather they saw; the first 20 or the best 20?

It sounds flippant but deleting down photos is actually the hardest part of the editing process. You have to distance yourself from the memory and take each photo out of context, stop thinking so much and just go on gut feeling, then decide which will work best on Instagram, Facebook, or Flickr.

Of course like many I blog and tweet too; the total time spent on content curation is insane but it’s not uncommon; Pinterest and Tumblr are basically wildly successful content curation tools. Editing down is underrated and everywhere; YouTube ads that have 5 seconds to intrigue, info pages that have 2 seconds to convince viewers they’re authoritative. It’s all the same game, condense as much meaning as possible into a single picture, a smaller layout, a soundbite, a tweet.

It’s tempting and so much easier to just make more space, add more content, put some extra into a carousel (in spite of them being demonstrably rubbish) but most of the time you should be saying less instead. In the age of micro-blogging and mobile sites your message should be constantly refined. Try to be all things to all people and you’ll end up with vague half-read articles, background noise. Ditch the fluff. Edit down.

Choose your own RWD adventure

Interwebs

There’s been debates up and down the internet about the pros and cons of responsive vs adaptive vs native apps, so it’s easy to get bogged down by buzzwords and semantics. Instead, answer some fairly simple questions about real choices and whether to use RWD will answer itself.

Real-world choices

How many layouts will you design?


A few years ago everybody built sites on a 960px grid, and probably most still do.

Designing 3 widths that correspond to “mobile”, “tablet” and “desktop” views is a common approach, though the lines between them are increasingly blurry.

Grids: fixed or fluid?


Giving your layout fixed widths suits the static tools used by most designers and allows for pixel-perfect development.

Fluid grids and elastic design; swap pixels for percentages and make your design stretchy!

How are you going to work out which to show?



Show the exact same content to every device, regardless of size.

Tweak styles, typography and layout with CSS media queries and use feature detection to pull in richer content when the browser can handle it.

By detecting what devices are being used you can infer screen size and capability, however this needs to be done on the server side: serve up entirely different code depending on the kind of device your customer is using

Old school

Responsive might be the new shiznt, but it’s not what you’re looking for. On large screens your content will sit in a centred column, and on small screens zooming and scrolling is necessary.

Classic Responsive Web Design

You’re looking at using a simple layout with some CSS tweaks that’ll elegantly flow into any container that the web of things can throw at it. Consider capping your design at high and low widths, so things don’t get unpredictable at either end of the scale, and be aware that the fluid nature probably means you’ll want to design this partly in the browser. This is a popular choice for mobile-first design or simple content sites like blogs.

Over engineered?

Given you’ve only got a single fixed layout to display, there’s probably no point using device, width or feature detection.

Over engineered?

Although media queries can be used to tweak styles, if you’ve got one design you’ve got one set of mark up so there’s little point in a server side solution.

Liquid layout

Your super-stretch approach predates RWD, but using a fluid grid means at least partly designing in the browser, and depending on your content things can get strange on very narrow and very wide screens, so it’s so probably only useful for a very masonry-like or image-heavy grid layout, lest an awkardly long word break your layout.

Confused?

If you’re trying to show multiple views you’re going to have to distinguish which are to be shown where, for example by detecting width, browser features or devices.

Server side solutions

Is your site just too heavy to work on a phone? Does it have radically different requirements between desktop and mobile? Serving up different sites to different devices can be a legitimate mobile-friendly solution. However it’s a tailored back-end solution instead of a front-end one-size-fits-all, so it’s not responsive. There’s a few downsides to this approach: it requires a list of all devices which requires constant expensive maintenance, it’s trickier to maintain content parity due to different codebases, and you’ll likely have doorslams as desktop links are picked up on mobile browsers or vice versa.

Also it should be noted that the separate sites might themselves be responsive, for example an “m-dot” mobile site might work on both mobile and tablet devices.

Modern Responsive Web Design

As far as RWD is concerned you’re doing everything right: combining two or more layouts with CSS media queries and progressive enhancement for a rich device-agnostic solution. It’s not easy though, the fluid sections that go between static designs should be designed in close collaboration with the designers. Alternatively abandoning the outmoded page-centric approach and instead design modules with a separate content hierarchy and design the layout directly in the browser!

Mind the gaps!

Targeting certain “best practice” widths that in today’s device-rich market are essentially arbitrary is risky. New form-factors and screen resolutions arrive regularly, they all need to work in portrait or landscape, and there’s already a lot of overlap between mobile, tablet and laptop. It’s fairly likely that a given device won’t your target widths and you’ll need to zoom or scroll as with a single width site.

The plus side is little-to-no designing in the browser, but a semi-fluid approach would be more extensible.

CSS media queries changes up the layout and typography depending on browser widths; there are many examples of media query driven sites, one of my favourites being The Great Discontent. The caveat is that it’s not suited to serving different content or radical redesigns as everything needs to co-exist in the page simultaneaously and reliably, so can be expensive in terms of developer time.

With JavaScript feature detection like Modernizr you can pull in rich imagary or video where appropriate. This progressive enhancement is a great solution when you need to deliver working pages to every browser (even edge cases like kindles and wap phones). Some examples of large responsive content- and accessibility- driven projects include BBC News, The Guardian online, Gov.uk or the new Entertainment Weekly site.

Over 2013 I immersed myself in the emerging discipline of Responsive Web Design, reading dozens of articles on it, spending a day at a workshop and another at a conference about it, building a half dozen websites with it, and writing pages and pages of notes on it all. It’s been an interesting journey and I’ve made a few U-turns on what I thought would be best practice, but it’s time to boil my thoughts down to a post or four. First up what RWD really is:

Before the buzzword, the responsive Origin Story:

The ideas behind responsive web design were initially set out by Ethan Marcotte in his 2010 talk at An Event Apart, which is well worth watching as it’s proven seminal. Boiling it it down to practical axioms, the main tenants were:

  • Media Queries: A method of delivering different CSS rules to pages of different width, allowing page layout and typography to change to fit different sized screens without changing the content or the HTML.
  • Flexible images: Images online have historically been fixed widths to aid browser performance, but thanks to browser evolution and some new CSS there’s a simple way of making foreground images squishy, and another to make background images stretchy, so either way you’re golden.
  • Fluid Grids: Instead of using pixel values for arranging layout, use EMs (a measure relative to font size) for heights and percentages for widths. Very quickly you’ve got a fluid layout that responds to browser widths.

Riding the wave of the mobile explosion the idea of Responsive Web Design took off in a big way, but the meaning’s been clouded, overused and buzzwordised. It started – and at its core still is – a design philosophy, a few CSS tricks that enable a new kind of fluid design. The likes of Jeremy Keith have been evangelising the screen-size independent approach for a decade now, but designing liquid layouts and fluid grids can be difficult without a very good understanding of web technologies and it’s hard to represent in Photoshop; an awkward and ill-suited tool for representing any non-static design.

Four years later that mobile explosion might be old news but it’s only becoming more diverse with every new phone, tablet or “phablet” released. It’s self-evident but often overlooked that mobile devices are increasingly the first choice for social: facebook, twitter and emails full of links being shared. Those links don’t open apps, so sites need to look decent on these multi-platform multi-resolution devices.

RWD and fluid design offers ubiquity, flexibility, content parity and cross-device future-friendly thematic consistency. It’s about generalisation not optimisation. It’s less about the mobile, tablet and desktop views, more about the gaps and the overlap between them that an increasing number of devices fall into. It’s not a silver bullet; you need great design, a solid performance strategy and probably progressive enhancement to deliver the goods. It’s also not just something for developers to worry about.

Next on RWD, navigating the sea of buzzwords to work out if Responsive is really what you need!

Waterfall legacy

Interwebs

I recently wrote about the specter of the “infallible” PSD hanging over the development process, and how it can be damaging to have the success or failure of a site dictated by something that describes a website so poorly. It was taken up by Typecast (which was awesome), edited a bit and posted on their blog . It was interesting to read the comments, though they mostly the missed my point a little: they were discussing using Photoshop as a tool, while I was talking about the PSD specifically as a static artefact, after sign-off and so when the design has stopped.

But that got me thinking: why is that a given? Though nobody argues that content shouldn’t inform the design, invariably design is frozen at sign-off, development stops at go-live, but content can change at any time. Similarly few would say that design should have no input on the subtle UI interactions that make for a tight UX, but as that will never be detailed in a static PSD for sign-off, under the current system it’ll never be in scope.

I don’t know how industry-wide it is or whether it’s a feature of a certain kind of agency, but it seems process dictates that once the look of a site is sold to the client, the designers need move on to selling something else. We have sprints and stand-ups and all the trappings of agile, but outside the umbrella of development the yoke of the waterfall stays with us.

I went to yet another conference last week, but this one was a little different. For one thing it wasn’t a web conference! Mostly not. At Geekyconf there were a load of talks on a load of subjects as well as games and food. It was more about delight than take-homes and it’s hard to draw together a writeup, so I’ll just point to a few pics I’ve put on my Flickr and touch on some highlights:

Expectedly good:

  • Sex, Love, Dwarves, Bacon
    Dr Esther MacCallum-Stewart
    About “Love” or emotional attachment in computer games, which is hard to manufacture, basically, giving odd abstractions like how the affections of most NPCs can be bought with the right bribe.
  • The Wonders of Stuff
    Zoe Laughlin
    Materials science. Invisible balls, gecko tape that only sticks to smooth surfaces, regenerating concrete, optic concrete; SCIENCE!
  • Scandinavians hitting you with sticks
    James Wallis
    Larping, like tabletop RPG, is something I like to think about but could never provide the level of commitment needed, so it’s nice to hear other people talking about it so knowledgably.
  • How to turn Drunk Ideas into Books
    Mr. Bingo
    That guy with the nasty postcards. Seen a similar version of this talk a couple of years ago but it’s still funny.

Unexpectedly good:

  • Omnibus Racing for Beginners
    Simon Abernethy
    Did you know there used to be such a thing as pirate buses? And because individual buses competed, they used to race to stops? RACING PIRATE BUSES.
  • Determining the fastest person on two wheels
    Edd Sowden
    I begin to switch off when cycling’s brought up as I can’t even ride a bike! But Edd gave an excellent collection of nerdisms and infographics.
  • On The Counting Of Sneezes
    Peter Fletcher
    Hillariously deadpan talk on a frivilous exercise that boiled down to a few profound reflections.
  • Five Facts About Smell
    Alice Bartlett
    Fun, funny, interesting. Explaining how smell works. The answer? NOBODY KNOWS.

It was great, so I was surprised that the attendance seemed to be pretty low. Maybe the vague premise of geekdom is too hard a sell? The (surprisingly lovely) hall could have held double or triple the attendees and looking at their website some speakers, sponsors and caterers must have pulled out or been downsized, leaving when MAC met CHEESE to feed everyone and Giddy Up Coffee to dole out continuous coffee. Maybe it wasn’t a bad thing though as both were really excellent (and free for attendees).

Bottom line is I was in dev / gamer / geek / spicy-mac-n-cheese / deep-fried-oreos / good-coffee-on-tap heaven and I hope it happens again next year!

Full Frontal

Interwebs

Earlier this month was Full Frontal, a javascript web conference in Brighton. It’s been going for a few years but this is the first I’d attended. Though I’m not as hardcore into JS as many front end devs, I actually found it much more accessible than the jQuery UK conf earlier this year. Basically it was excellent, with good coffee, fab freebies, a nice vibe and above all excellent talks.

ES6 UNCENSORED by Angus Croll

I’m not so much a programmer so I didn’t get the fine points of this, but thanks to clear examples it was easy to see that Angus was excited about the upcoming ES6 JS upgrade enabling terser syntax for a few common tasks, and I do love me some dry code. Honestly though my main take home was that he gave a great talk around a stutter, which made my public speaking anxieties seem awkwardly trivial.

JAVASCRIPT IN THE REAL WORLD by Andrew Nesbitt

Robots and rabbits and live demos galore! Andrew builds and programs robots to interact with his super cute rabbit. It didn’t think much of the laser pen robot but was pretty keen on the automated food pellet dispenser. Things got real when he fired up the quad copter controlled with an xbox controller, got it send back a video feed of the audience, and then used facial recognition technology to replace everyone’s faces with troll face. Awesome. Oh, right, yeah and it was all done through Node, which is cool. Soon we’ll be running drones from our browsers!

MOBILE IS NOT A THING; IT IS EVERYTHING. by Joe McCann

Seems a conference isn’t complete these days without a talk on the importance of mobile, and this one had all the standard impressive charts and stats about the growth of mobile. Joe took it a bit further however, talking about the extended mobile ecosystem from tablets to wearable devices wearables without a screen, and even cars. It tickled me to think of a “mobile device” being so large but apparently cars with built in connectivity is already fairly standard and becoming more so.

PUSHING THE LIMITS OF MOBILE PERFORMANCE by Andrew Grieve

This talk was right on the money as I’ve been pretty reluctant to use JS on mobile sites due to performance issues, but apparently mobiles being slow to parse JS isn’t an issue anymore! It was also nice to hear that we shouldn’t waste time modularising as I’ve never gotten on with Require. Lots of easily digestible takehomes, great stuff.

OUR WEB DEVELOPMENT WORKFLOW IS COMPLETELY BROKEN by Kenneth Auchenberg

It was funny after a full day workshop on the exciting and fast-moving word of chrome dev tools to hear one of the speakers bemoaning the state of in browser inspectors, though superficially they’ve not really changed since IE dev tools back in the mid 2000s. Still, even relying on Chrome can leave you in hot water when it comes to developing for other browsers and asking devs to actually develop in chrome can be controversial, a dev’s choice of IDE a uses is super partisan, though Sublime Text seems to have been in the ascendant for a while, many will never leave Eclipse, Visual Studio, *cough* Dreamweaver. Anyways his idea was simple, and the solution he’s working on is it connect up Chrome’s api to the IDE and various browsers. He live demoed manipulating a FireFox DOM from chrome devtools to many gasps of delight from the audience, followed but a too-quick plug of his project RemoteDebug.

STUNNING VISUALS WITH MATHS AND…NO JAVASCRIPT? by Ana Tudor

As a CSS nerd I’ve marvelled at loads of these migical JS-free animations on Codepen and such places, but any time I looked under the hood I ran a mile; waffly code and endless lines of keyframes scares me. It seems I need to take another look though because the special sauce here (apart from some basic trig) is getting around that scary verbosity with SASS, and almost programmatic shortcutting. Definitely something I should tinker with.

BUILDING WITH WEB COMPONENTS USING X-TAGS

Angelina Fabbro
Some mozillians making a framework of mobile app widgets called Brick (not X-Tags). I think I was suffering from a combination of some cake-pop related sugar coma (I might have had 3) and CSS animation mind-splosion because most of this drifted over the top of my head.

TIME by Jeremy Keith

Jeremy Keith’s been one of my favourite speakers as long as I’ve been going to these, and it was a real treat to see him give a lovely talk about the relative ephemeral nature of web work, cut with an old video about powers of ten. The main points were that the old adage about stuff on the web being there forever is just patently false, that we should be thinking about the longevity of our work, and at the moment the closest thing we have is html, mostly because it gracious error handling and human readability. which makes me worry a little about my blog: it totally falls apart if the back end fails. Maybe I should be looking into transferring to Jekyll?

So yeah! One of my favourites this year (the others being Ampersand and Responsive Day Out). Recommended.

“Debug & know thy tools”

Interwebs

As a long time Front End Dev I’ve used Javascript a lot but my focus has always been CSS and I often find debugging JS awkward. So naturally I jumped at the chance to go to a workshop on debugging by Remy Sharp, one of those names that keeps popping up in the field of JS. (You wouldn’t think it to look at him but he’s been a developer since the 90s.)

Though tools like Weinre or Dynatrace were mentioned, “Thy tools” turned out to be mostly Chrome Devtools, but even with that narrower focus there was loads to get through. Remy rattled through dozens of these tips and tricks almost faster than I could follow!

Debugging tips

  • Disable plugins and cache, use incognito mode and create a test user for a clean bug-free slate.
  • Develop right in devtools! Right-click > “map to file system resource” to be able to save to disk!
  • Shortcuts: ctrl-o: open a file, ctrlshift-o: open a function from that file and in DOM inspector press H to hide a given node, clicking “{}” prettifies the JS.
  • For element-specific breaking, right-click simply write click on it and select “break on”. You can also set event listener breakpoints in the right hand nav of the Sources tab.
  • Hover over functions, variables etc to get more info on them.
  • Chrome inspection works both ways: type simply type “inspect this” in the console to jump it’s location in the dom. Genius when you’ve got scope issues.

Bleeding-edge Canary devtools

Once you get past the obvious much can depend on what devtools you’re actually looking at; Chrome autoupdates regularly but the latest beta features are only found in Canary, and even then there’s additional experimental features that are switched off by default. For example to make devtools ignore certain files, you first need to navigate here in Chrome Canary and enable developer tools experiments, then go to Settings (the cog icon) > Experiments (left hand nav) and click “Enable frameworks debugging support”. Close and open the inspecter, head to settings again and under “General” you should now have an option called “Skip stepping through sources with particular names”, where you can type “jquery” or whatever other plugins you’re not interested in debugging. Simples!

Bottlenecks to watch out for.

Connection speed
The network tab is a pretty easy one to parse, looking for too many simultaneous http requests, too many in general, too much content in terms of file size (normally images) any 404s or text files not not g-zipped. Basically you want to streamline everything so you get a quick “Time to glass” because if nothing shows people lose interest fast.

Local memory
When the browser gets slower over time it’s probably down to memory leaks, caused by programmatically setting more and more event listeners and variables. In devtools go to Timeline > Record > Memory, play with the page and watch memory go up. When you force garbage collection it should go back to where it was. For a more detailed view go to Profile > Heap snapshots > Compare snapshots and click around looking for red highlights which mean something garbage collection couldn’t get rid of because they’re still being referenced in the js.

Animation
“Jank” is something close to my heart: Google’s name for visual distortions caused by animations not keeping up with the 60fps refresh rate, particularly on scroll. It’s recommended to use setTimeout 16ms, or better yet requestAnimationFrame whenever doing something onScroll. You can check it with Timeline > Frame to see if things are cool. Another problem can occur when small animations cause the entire page to redraw, which can be checked with settings > general > rendering > click things to show what’s redrawn. The only solutions to this that I saw were hacks though, namely selecting an appropriate frame and giving it the style transform: translate3d(0,0,0);

Commands cheatsheet

  • $$ grabs all elements that match
  • $0 grabs the element you just clicked
  • v$_ gives whatever was last returned by the console
  • $_ + copy copys…
  • console.trace() find what calls a thing
  • console.clear() clears, obvs

At the end of the workshop we split into groups and used what we’d learned to check a site randomly allocated from a collection we had submitted; it was surreal to have people baffling about a site some colleagues at VML had built, but then it was also bizzarre how totally thrown a couple of people were by responsive sites. “Whoa! It looks different!”? I’m disappointed if a site doesn’t! I know that it’s a web devs’s conceit to jiggle the portal size on any unfamiliar site but I didn’t think it was purely a front end thing…

Anyways, lots of tips, lots of take homes. It only went too quickly, I honestly could have done with double the time!

“Make it like the PSD”

Interwebs

It’s disheartening to hear this after weeks spent strong-arming HTML/CSS into near-perfect shape; “It looks different” they say. I want to reply “Of course it does, this is a website! That’s a picture of one!”

While the early design process likely involved wireframes, sitemaps, user stories and days of client meetings the thing that’s given the ostensibly binding “sign-off” is always the Photoshop documents; essentially “artists impressions” of what the site should look like. That they’re used to sell to the client is unsurprising, what’s baffling is that these idealised screenshots are still given to developers, project managers and QA as instructions of intent. As web technologies progress the adamant expectation that the site match the PSDs to the pixel is only getting more absurd.

Where PSDs fall short

  • Portal sizes A PSD has a single set of dimensions while the size of the browser varies greatly. It’s more prevalent now with mobile devices and RWD but it’s far from a new problem.
  • Things move In our blindingly obvious category: interactions, hover/focus states, animations, “content choreography” transitions between different portal sizes; none of it is even guessed at in a PSD.
  • Fonts oh god fonts They render slightly differently in OS and Windows, in Firefox and Chrome, and certainly in a browser and Photoshop. This is maybe the most overlooked issue; the number of times I’ve had a bug raised to the tune of “the font is wrong” when it’s exactly as specified in the PSD is just crazy. Webfonts need to be tested and tweaked in situ.
  • Copy it saddens me that designers have to spend time awkwardly putting real copy into dozens of PSDs but the fact is it’s very likely to change before going live. Designing around the size and shape of copy is doomed, especially if the site is to be translated, CMSed or responsive.
  • Un-transferable rigour When you see a page with 5 font weights and 11 font sizes with fractions of pixels, you know something’s going wrong.
  • Mistakenly inferred rigour small variations in margin, colour or font size that turn out to be oversights or mistakes rather than part of the design intent. Not worth spending hours hunting down but they’ll still be raised in QA because it’s not like the PSD.
  • Impossible stuff. Design problems that only come to light at the build stage. It happens.

You say “pixel-perfect”, I hear “brittle”.

So what’s to be done?

  • Designers should learn to code is often an end point of these discussions, but it runs against agency siloing, ignores how much time they spend selling, and to be honest I’ve had as many problems with designers knowing a bit of markup (e.g. being stuck in the tables mindset) than designers knowing none.
  • Get rid of Photoshop! It would be lovely if it was used more appropriately, like for sketching or jpeg imagery, wouldn’t it? But this would be a drastic overhaul and clients want to see shiny things, so if you need to use it, this guide on Photoshop etiquette can help.
  • Style guides In dozens of PSDs and hundreds of amends it’s easy for inaccuracies to creep in, so having a concrete reference point for developers (and new designers) can be invaluable: defining the palette of colours, font sizes, buttons and link behaviours.
  • Design QA This is certainly the most easily implemented; make the original designer part of the QA team and making sure things are in line with the vision, assuming they have availability and the project budgets for it. But that’s just the first step to…
  • Collaboration Front end developers and designers need to work together much more in a tight prototype-and-tweak cycle, moving closer to the browser and de-emphasising the PSD from the position of ill-suited absolute authority it currently holds.

I’d go as far as to say FEDs should be considered a downstream designer under the direction of the Creative Lead. We might as well admit it as it’s already happening, and though FEDs are awesome at filling in the gaps left by the Photoshop-driven design process, we’re still wasting a lot of time chasing down unimportant details and guessing at things that might be critical: We can’t replicate the vision or the understanding of the designer that’s been in back and forths with the client for weeks or months.

Quit treating PSDs as sacrosanct canon. Work closer and prototype together. The creative process continues into the browser whether you like it or not.

Agency Siloing

Interwebs

I wrote recently about my love of conferences; among other things they’re a great for getting a sense of what’s going on outside the office in the wider world of webmongering. One thing that always surprises is they’re chock full of designer-developers, exotic cross-disciplinary creatures that represent a distant ideal to me. Where do they all come from?

I’ve worked in agencies for nearly 8 years now, home of the design-development divide where capital-C Creatives never leave Photoshop, back-end developers have little interest in look and feel, and those with wider skill-sets are outright banned from practicing. It can get pretty bizarre: I’ve seen inexperienced freelance designers brought in at great expense because the guy who’d been designing and developing HTML emails for 5+ years had the wrong job title (in the end he had to redesign them anyway) and similarly tech PM’s forced to negotiate for a dev’s time to change some copy in a line of HTML.

In the ill-defined no-mans land between the design and development lies a handful of Front End Developers, the awkward go-between bridging the gap between form and function, coaxing Creatives into giving a crap what happens post sign-off, explaining to project managers that the PSD can’t be the canon representation of the site, and fixing the layout after the templates go through the CMS meat grinder.

Don’t get me wrong, I love the job and most of those problems can be fixed with a quick chat (few more blog posts in the works about that), the odd part is the identity crisis. Ostensibly as a senior dev I’m supposed to be an aspiring software developer, but I feel no affinity there. Being succinct and inventive with js/jQuery is sweet, but so is being terse with SASS, clean with markup, word-crafting a tweet or curating photos. I work daily with code, but that doesn’t make me a programmer any more than the fact I designed this site makes me a designer.

So I guess that’s part of the reason I take comfort in the designer developer conferences, and reassure myself that my position isn’t so strange. I’ve even reworked my CV to be more unapologetically unsiloed, because like fellow FED Brad Frost says, maybe there’s no des/dev divide at all.

Introverted conference junkie

Interwebs

I’ve been to a fair few conferences since my first in 2007; this year alone I’ll have attended six and I had to stop myself from adding a couple more. I love them for the ideas and the inspiration, every one is like a uni lecture on your favourite subject by your favourite lecturer. It’s all pretty awesome but with going to so many lately I’ve had the increasing suspicion that I’m missing the point.

I love conferences

The talks at dConstruct were great:

  • I missed Amber Case due to a train-based screw up which was a great pity.
  • Luke Wroblewski gave a lecture on how we’ve gone from mouse and keyboard to about two dozen potential inputs forms in a scarily short time.
  • Nicole Sullivan gave advice and reflection on the phenomenon of trolls and trolling. Particularly interesting was how to manage your inner troll, the hangups you wish you didn’t have.
  • Simone Rebaudengo asked what might happen if products (toasters, specifically) started communicating with each other instead of exclusively with humans.
  • Sarah Angliss gave a fascinating and left field talk about unnerving sounds and awe, followed by a sweet performance.
  • Keren Elazari’s talk was basically a loveletter to hackers. Quite uplifting if oddly idealistic.
  • Maciej Ceglowski was maybe my pick of the day, on slash fiction writers and managing communities on the web.
  • Dan Williams spoke on some unexpected results of the technology that surrounds us, from unlikely gadgets to stalker bins. It’s the future. TAKE IT.
  • Adam Buxton was hilarious as ever but phoned it in a little tbh.

My favourite conferences this year are still easily Ampersand and Responsive Day Out – both at the same venue by the same people – but all the talks were nerdy and thought-provoking and a joy; that’s not my problem.

But I can’t networking for my life.

I’ve often heard it said that the main point of conferences are the networking opportunities, but as an introvert going alone I’m unlikely going to impose myself onto other people’s afternoons. My reluctance was nicely highlighted when web-luminaries Laura and Aral randomly sat next to me, both of whom I’ve followed online for a year or two. I was amused and delighted to discover the weekend before that Laura used to live with a friend of mine, but when she began an exchange with me about whether the seats were taken I kept it as short as possible. Bizarre. I guess I’m too used to London where people are white noise and conversations are a terrible faux pas? It’s probably not that strange, but it does make me feel I might be missing the point.

Normally I spend the elongated lunchbreaks wandering around Brighton with a camera which is lovely, but this year I’ve been unlucky with the weather, and an hour+ sitting alone in the café is pretty sobering. It’s something I need to solve if I want to keep getting my fix of web nerdery:

  • Going with friends would be amazing, but I’m a bit mental taking time off work and paying a couple of hundred quid to hear some people hold forth on these subjects, so it’s a difficult sell to friends and colleagues. It would be awesome if I worked somewhere that had a culture of attending these things.
  • Get a laptop. A bit sad but I could trawl twitter or stay productive and not worry about not having anything to do? I can’t really afford a laptop at the moment though, what with all the conferences…
  • Stop going to so many. Yeah, probably not likely. The next one I’m going to is Full Frontal which I’m really looking forward to, and GeekyConf after that which I even managed to rope my boyfriend into. It’s gonna be good.

I think I have a problem.