Kyan blog

WXG 2013: Kyan is doing that event thing again!

2013-05-13T17:40:00Z

In October last year, we stuck our heads above the parapet and ran our first speaker event, WXG*. It’s a one day web development & design conference, packed with speakers and with lots of time for networking. You can read more about why we launched the event here and check out the 2012 talks here.

We all had a great time (which was just one of our measures for success) and had a lot of great feedback. So WXG is back for 2013:

October 25th, G Live, 9am to 5pm, and then the after party, until … (there’s a reason it’s on a Friday).

We’ll be looking to do the same again, but better of course. More of the little chocolate cake things at lunch. Perhaps more Haribo in the swag bags.

Not more speakers though, because fitting so many great people in across the dev and design tracks felt just about perfect, but perhaps more practical advice on creating the best web experiences possible.

Visit wxg.co.uk to register your interest and follow us @Kyan for updates.

Hope to see you on October 25th!

*WXG = Web Expo Guildford. The sharp amongst you may have noticed that it is a speaker conference, so not an Expo at all in the popular sense, although it is one according to the dictionary definition. And yes, we know we’re cheating by using the X phonetically in the acronym, but who wants to call an event WEG?

A Responsive Day Out

2013-03-07T14:27:00Z

Recently Clearleft put on Responsive Day Out, a one day conference with thirteen short talks and some fireside chat. A seaside day out for our designers & front-end developers: how could we resist?

The event was held in the Corn Exchange theatre

A quick aside: what is a responsive site?

The name is applied to many different aspects of modern web production but at its core it’s a simple proposition: content should be the focus of a design, and that design should adapt to fit whatever device the reader is using.

With this in mind, what techniques can we use? A favourite is @media queries (as seen on the recent Kyan responsive rebuild). These let you query the width of browser window and hence set styles that adapt the website layout to better work with the reader’s requirements. Taking a step back, we can design page components that will work across multiple configurations rather than being a fixed size. We’ve done this before when fluid layouts were more commonplace but with new CSS abilities we can keep the visual fidelity we’re used to across a multitude of screen sizes.

The day

The venue was the rather lovely Brighton Dome (which incidentally has just had a rather lovely rebranding); the format a set of quick-fire presentations on a whole range of subjects pertaining to responsive design. There was a mix of technical dives and philosophical overviews; overall it was a well balanced day.

In particular we liked Anna Debenham’s Playing with Game Console Browsers – console browser support is a subject that’s hardly touched on in the standard web circles – and Laura Kalbag’s Design Systems that introduced the benefits of a pattern library for responsive designs.

Other talks that stood out were Tom Maslan’s Cutting The Mustard – expounding the ‘mobile first’ development methodology in a way that immediately made the benefits seem common-sense – and Bruce Lawson’s What’s Next In StandardsLand – in particular his overview of the upcoming Flexible Box Layout specification which will be a real change to the way we build sites once support is there for the majority of users.

What we’re going to do

This year we’re really ramping up our efforts with responsive design and development; for the majority of our sites it’s now clear that this is the correct default approach. The interesting part is going to be the necessary amends to our workflow. We have previously produced pattern libraries when requested by a client, but making them a key part of the design will help both the developers and the clients understand the core design concepts for the site or application. It feels that a responsive workflow will also lead to greater co-operation between the front-end development and design teams, which can only be a good thing.

One thing remains certain though: this is an exciting time to be building the web.

Slowly adapting

2013-03-06T14:30:39Z

I’m Jenny, Kyan’s first intern ever. I’m a front-end developer from Hyper Island in Sweden. And I’m here to learn how to become a rock star in front-end development.

I never thought it would be this scary to write about what you’ve been doing for the last three months. But here it is my first blog post.

One of my first projects has been to make our own site, kyan.com, responsive. It felt like a huge project when I started, since I had never done a responsive website. Reading about it made me more confused, where was I even supposed to start?

The hardest part wasn’t to make the site responsive; if you’ve planned for responsiveness, it’s not that complex. The big challenge was to dive into someone else’s code, getting to know the website’s bits and pieces.

If I change this here, will it break there?

The hallmark of the Kyan website is definitely the illustrated animation. I’ve been going through hell to make it adapt to all the sizes, a real trial and error project. As a pixel perfectionist it’s a pain to not be able to get it 100% perfect – but I keep telling myself that it is ok.

The Kyan animation on its way to be 98% perfect.

Another bump in this road was a table that came out of nowhere. It didn’t really come out of nowhere; I just hadn’t checked out the cookie page yet. At first it seemed like a hopeless task but some research pointed me in the right direction. Since I haven’t been doing coding for too long I never worked with tables, I had to get help. The solution we chose was to stack the table cells on top of each other, and then remove the table headings and just bold the cookie name instead.

The broken table became a stacked table.

Get the Jenny 5.0 plug-in

When working with this project I came across a tool called Xcode, it’s a brilliant piece of software that, together with Safari, enables you to debug for iPhone and iPad (originally it’s created for developing iPhone and iPad applications). It makes responsive development a bit easier by seeing the mobile version on your computer, rather than updating on your phone all the time.

But it has its flaws. It works as a real device so the debugging isn’t as smooth as it could have been. The most annoying part is that you need to be in Safari, to refresh with your keyboard. Otherwise you need to go to the top and refresh in the address bar. Another thing is that you can’t scroll so you need to drag the pages with your mouse, emulating touch-scrolling.

I also came across a little tool called mediaQuery Bookmarklet. It gives you a ruler and the sizes of your browser window, both in pixels and ems. You can also see the x and y value when moving the mouse. But the best part is that it tells you when your media queries kicking in.

Learning by reflection

My greatest tip to someone else doing a similar project might sound strange, but print out the source code. I love print, it gives you a good overview and it’s easier to see the structure and how the site is built. With this overview comes easier planning, which always seem to be a big challenge. I bet I could write a big note and put it next to my screen and still forget to plan something, or just not plan well enough.

When looking through my notes I can see that the sentence “start with the biggest breakpoint and work your way down” always gets written down. I think you get a lot for free if you start by defining the styles for the biggest breakpoint, in this case tablet, since it’s inherited to the lower breakpoints.

I also believe it’s a good thing to do one page at the time or the same modules in the same go. So you keep your focus on one thing and finish that before you start on something else. It’s easy to say but harder to do. Always do the big bits before you get to the details.

This leads up to my next point: don’t rush. It will make you skip the planning and miss your milestones, leaving you confused and unfocused.

I also want to push for breaks. Scribble down some notes on your next steps, then take a break and do something else for a while. Return to your masterpiece with fresh eyes, and voilà new perspective and a surge of new energy.

It’s been a long and, sometimes, tiring project. But if I got the chance to do it again I definitely would. One of my goals for this internship is to speak HTML fluently. Which probably made this assignment the best one, so far, during this internship.

Writing is hard, so do it

2013-01-29T13:13:00Z

Over the last few months I’ve been working on something that I wouldn’t have seen myself doing at any point in my life, and that’s the task of writing a book. I’m not talking about a ‘Janet & John’ novel, or some sort of ‘Fifty Shades of Grey’ sort of affair, but a proper printed dead tree, trip over it kinda technical book.

It all started back in May/June time when I was approached by a good friend at Heroku, who had been approached in turn by O’Reilly, to produce a book about the platform and some rough ideas for what sort of book might be relevant and saleable. At the end of a fairly lengthy process it ended up that I was the author, had a contract in my hand and a schedule to try and stick to.

Cripes.

Getting started

The first problem I found when starting out on this project was the getting started itself. A technical book is such a strange beast – there’s no real start to a subject such as Heroku, nor any end, so how do you approach it? If I were writing some sort of grotty novel then there’s a clear approach with introducing characters, developing them and then climaxing with a, er, climax – so how do I approach this with a technical book?

At this point I should probably talk about targeting. If I were writing a book about a subject such as Ruby, I would be starting in the same way as any other programming book would. A spot of “Hello World” and “Fizzbuzz”, moving on in a very predictable fashion. However, these books by people who have decided ‘Hey! I want to learn Ruby!’.

That’s not so much the case with a book about a product, which is essentially what Heroku is. People buying this book are more likely to have used the Heroku stack before, and deployed some stuff to it, and liked it so much that they are now willing to spend $20 on a book about it in order to learn more.

So, where to start?

Well, with this sort of book you end up with a massive list of excerpts that you think should be in. You want to talk about X, Y and Z, but with a bit of A, B and C thrown in for good measure. Only by dumping everything on paper are you able to get down to the business of making sense of it all and the writing itself. There are so may corners to a complex topic such as this that structure is the only place to start thinking about what to write and how. Only by having the skeleton of what you are writing can you move forwards – much like writing code.

Toolchains

So, what do I write with? Pen and paper? Some sort of ye olde clicky clack typewriter and a pipe, so I can discard pages like that guy at the end of the A-Team ?. Or Vim, which I use each and every day to write code? Actually, I settled for IA Writer – a no-nonsense, zero fluff text editor that lets you think purely about the content at hand.

No crap, no formatting, no flashy bits – just words.

Which at this point leads me onto formatting and structure, which all books need to make any sense. In the print industry, and especially O’Reilly, books are generally written in some sort of internal toolchain supported markup. This means that a publisher can drop a load of markup into one end of a pipe and get a formatted printed book / PDF / EPub / Mobi book out the other end. This obviously saves some significant effort on one side but can introduce some pain for the author at the other end.

Therefore, you’re limited to writing in a certain way. Markdown (which I prefer, and what this very article is written in) is not generally supported as it’s not as feature complete as you need for most of the conventions in a full-blown book. This leaves you with a couple of common options:- Asciidoc, a sort of Markdown on steroids, and Docbook, writing in pure XML.

Obviously I went with Asciidoc.

Pushing this all into Git let’s me push and publish out a new PDF to see how my text looks, and means that my editor can get down to looking at content as it arrives. Without the familiarity of Git, I’d be lost.

Changes

So, we were writing, and chapters were starting to take shape and things were going well.

Then I broke my leg in a very dramatic fashion. Well, someone broke it for me by knocking me off my motorcycle at 60mph, but there you go.

Now, with a major injury and X-Rays leaving you looking like Wolverine, it’s gets kinda hard to focus on the concept of writing, and as such I had to take a three month break from writing the book.

This is where bringing in a co-author (Richard Schneeman from Heroku) is a massive boon, and frankly, a stroke of genius by whoever suggested it. You have two pairs of eyes checking over the content, two people writing the content chapter by chapter and two pairs of ears to listen to the feedback that people give you.

Having a co-author is, in my eyes, essential when writing a technical book.

But why write a book, it sounds hard?

First off, you should never write a book for the money. I’ve no idea how much money I might make from this work, or even how many copies I might sell, but I do know that even with a thousand copies sold the per rate hour is appalling.

For me, the reason to write is a simple one.

It’s a challenge.

It’s a challenge to whip up fifty thousand words about a topic that you think you know inside out, but it’s more of a challenge to write a chunk of that on content that previously you never knew, nor cared that much about.

Every topic has corners that people will avoid, either because they don’t need to know it, or they don’t want to know it. Writing a book enforces you to not only look at these things, but also look at them enough that you’re able to write well about them, and pass on your new-found knowledge. What’s more, you also end up having to hunt out the bits that you haven’t mentioned and make sure you’ve covered everything that you need to cover.

You may start a project thinking that you’re proficient in any given subject, but I’ll tell you now, writing a book about it will make you feel stupid in comparison with how much knowledge you’ll need to cover off in order to produce a topic that people will be willing to spend real money on.

So, get writing

The act of writing itself is not hard.

Writing is easy, anyone can do it. Anyone is able to impart information to the page, but the key comes from being able to write and edit in a way that makes sense and this is where the challenge comes. You will constantly improve with practise but only by pushing yourself into areas that you feel stretched. If I were to compare my writing with that of a year ago I would say it’s night and day.

Whether other people agree with me is a different matter.

So, as a developer, I will strongly recommend that writing is something that you need to do. I’m not saying go write a book, I’m saying write anything, anything at all. If you don’t have a personal site, set one up, and start dumping in content that you feel you know about and others will find interesting and learn from.

Once you’ve done this, do it more and more.

Eventually you’ll get to the point where the writing comes easy, but more importantly, you’re learning as much as your readers are.

Developers need to learn constantly. If you fail to keep learning you will be left behind quicker than in any other industry. By writing you are learning, but also helping others to learn things that they don’t already know.

Everyone benefits from writing, but most of all the author. So do it.

Write something – it’s challenging, but rewarding.

(NB: This article was originally posted here)

Kyan Festive 50 2012

2012-12-20T12:09:00Z

♫ ♪ Christmas time is here — sherry, schnapps and beer… ♪ ♫

Anyway, yes it’s Christmas, and yes in time-honoured tradition and in honour of the late great John Peel we’ve prepared a list of tunes that have kept us tapping away (feet and keyboards) over the past year.

We think it’s been a great year for new music, as ever it was hard to whittle it down to just 50 tracks. Those that didn’t quite make the list include the fantastic neo-krautrock of Geoff Barrow’s BEAK>, great girl-power pop from TEEN, a delicious taster of the sophmore outing from Unknown Mortal Orchestra amongst many more…

So, without further ado… here is the Kyan Festive Fifty 2012.

Bat For Lashes – Laura
Orbital – Never
First Aid Kit – The Lion’s Roar
Tame Impala – Elephant
Todd Terje – Inspector Norse
Alt-J (∆) – Breezeblocks
Kindness – House
DIIV – How long have you known
Daphni – Ye Ye
Purity Ring – Obedear
Errors – Tusk
Totally Enormous Extinct Dinosaurs – Garden
Julio Bashmore – Au Sève
Here We Go Magic – Make Up Your Mind
Major Lazer – Get Free (feat. Amber of Dirty Projectors)
Lone – Crystal Caverns 1991
The Tallest Man On Earth – 1904
Grimes – Oblivion
Maccabees – Ayla
Grizzly Bear – Yet again
Jessie Ware – Running
Azealia Banks – 212
Django Django – Waveforms
Beach House – Myth
The 2 Bears – Work
Allo Darlin’ – Capricornia
Lower Dens – Brains
RM Hubbert (with Aidan Moffat & Alex Kapranos) – Car Song
Matthew Dear – Her Fantasy
Atoms For Peace – Default
LIARS – A Ring On Every Finger
Zammuto – Yay
Jake Bugg – Lightning Bolt
Chromatics – Kill for Love
Lotus Plaza – Strangers
Foals – Inhaler
Chairlift – I belong in your arms
Tanlines – Brothers
Father John Misty – Nancy From Now On
Best Coast – The Only Place
Yeasayer – Henrietta
Field Music – (I Keep Thinking About) A New Thing
Twin Shadow – Five Seconds
The Weeknd – What You Need
Wild Nothing – Shadow
Teen Daze – Erbstruck
Dutch Uncles – Fester
Tall Ships – T=0
Mystery Jets – Greatest Hits
Woods – Cali In A Cup

Here you can stream the top 50* using the embedded Spotify player.

* Currently 49, Foals – Inhaler not yet available.

Kyan Festive 50 2011 (YES! I said 2011 ...)

2012-11-26T15:16:00Z

Like whoa, timewarp! As we approach the year end and a young(ish) man’s thoughts turn to end of year lists I realised that we never got round to publishing last year’s Festive 50, ah well, better late than never …

So here they are, in no particular order:

Bon Iver – Calgary
Beirut – Santa Fe
Metronomy – Everything Goes My Way
Woods – Pushing Onlys
Slow Club – Two Cousins
Glasser – Tremel (Jamie XX rmx)
Neon Indian – Polish Girl
SBTRKT – Pharoahs
Jehst – England
John Tejada – Unstable Condition
Real Estate – It’s Real
Joe Goddard – Gabriel
Kurt Vile – Baby’s Arms
Smith Westerns – Weekend
Cults – Go Outside
Elbow – Lippy Kids
Iron & Wine – Walking Far From Home
Radiohead – Bloom
The Field – Is The Power
James Blake – Wilhelms Scream
Washed Out – Amor Fati
Bombay Bicycle Club – Shuffle
Braids – Lemonade
Friendly Fires – Hawaiian Air
The Naked and Famous – Young Blood
The Horrors – Still Life
Battles – Futura
Jonathan Wilson – Desert Raven
Joan As Police Woman – The Magic
Lana Del Ray – Video Games
Panda Bear – Alsatian Darn
Puro Instinct (feat. Ariel Pink) – Stilyagi
M83 – Midnight City
Atlas Sound – Parallax
Okkervil River – The Valley
Woodpigeon – Spirehouse
Fruit Bats – Banishment Song
Lykke Li – Get Some
The Rapture – How Deep Is Your Love?
Fleet Foxes – Bedouin Dress
Alex Turner – Stuck On The Puzzle
Lanterns on the Lake – Keep On Trying
PJ Harvey – Last Living Rose
Wilco – Art Of Almost
The National – Exile Vilify
TV On The Radio – Will Do
Holy Ghost! – Do It Again
Cut Copy – Need You Now
Toro Y Moi – Still Sound
The Kills – DNA

Version control for design

2012-11-16T17:44:00Z

It’s a subject that’s been talked about before and something where solutions have been put in place but yet something that hasn’t been taken upon by the design community at large.

For development GIT & Github have been crucial to how Kyan have worked ever sinced the service launched. I admit it does have more merit within development as projects are usually much more collaborative, with design work usually being created by one person. However with that said I still feel being able to look through a designs history, seeing how you’ve come to a conclusion is a pretty valuable tool not many designers are using.

Also say you enter into a project, and the client wants to see a slight revision that was sent but never saved in it’s own copy. Now you’ve got problems, you have to track down the comp that was sent and check with the original designer which is which and a lot of time is wasted switching on and off photoshop layers.

LayerVault / Dropbox

A service which has emerged in the last year, which got me thinking on the subject is LayerVault, I was trialling this for a while when it was in beta, and it felt very polished and well designed. I believe it’s come along much further recently.

I ultimately found LayerVault as a solution not too dissimilar to how many use Dropbox, online storage & history for your PSD and AI files ( which dropbox now has previews for ), with a sleek web interface and the ability to scan back and forth between file versions. It is more tailored than Dropbox and others as it comes with nice features such as being able to instantly send comp’s of a PSD file to clients, it’s certainly an option for many – but relying on your version control with a hosted platform may not be to everyone’s taste. If you’ve been using it and have your own experiences I would love to hear how you’re finding it.

Another company doing a very similar thing to LayerVault are Pixelapse.

Adobe Version Cue

Now I bet the majority of designers experience with Version Cue was when clicking the ‘do not install’ option when you installed a fresh copy of Creative Suite. And if you haven’t seen it recently that’s because Adobe removed it in CS5+. I personally thought Adobe Version Cue was a great option for managing your digital files, it was simple, built into all Adobe apps and worked on your own servers ( although your experiences may of varied here ). I had forgotten about VersionCue and had only dabbled in it, but I think for many teams it would be a great option, it was certainly a great option a few years ago… though never widely adopted.

But as I mentioned Adobe have stopped supporting Version Cue. So it’s no longer a feasible option for many. Perhaps the folk at Adobe are working on something as a replacement? I would love to see something of a mix between Version Cue & Layervault, Self stored files and cloud management? Could that be a thing?

So I imagine the reason that designers haven’t taken to version control in the way that development in projects is almost integral is that there just isn’t the software of service out there yet ( or there was and it’s had it’s door closed. )