There's more to life than Javascript

Oct. 30, 2014, 12:21 a.m. in Web Design

Web development and mental health - my story

I'm 12 years old, taller than everyone else in my year, dorky, with thick eyebrows and bad skin. School has finished for the day and I stand in the playground where kids are meeting their friends to walk home, and I wait for him. I see him coming with a friend of his, and I approach them. I tell him that I like him, and I nervously, but hopefully await his response. He laughs in my face and walks away. I stand mortified.

I'm 13 years old and a sixth-former approaches me. One of the cutest, most popular guys in my school. "Hey", he says. "You're pretty..." I swoon. "Pretty ugly".

I'm 15 years old and I'm with my best female friend, and two guys. We're drinking alcopops under a bridge. They crowd her, making their attraction clear. I feel invisible. She pairs off with one, and later, when the other is drunk enough, he kisses me. I feel like a back-up plan. The next day, the kiss is forgotten.

I'm 16 years old and in a nightclub. Boys dance close to my friend. She acquires yet another phone number. I try to dance, to be seen, but nobody notices me.

I'm 17 and I'm dating somebody. I don't understand why he likes me.

I'm 19 and I'm dating somebody. I don't get what he sees in me.

I'm 23 and I'm dating somebody. I must be a back-up plan.

I'm 29 and I'm dating somebody. And I'm still trying to believe that I'm good enough.

Relationship anxiety, insecure feelings, and struggles to accept myself are things I've got used to feeling throughout my life.

But one place I found to feel secure, to feel proud of myself and to really know who I am is my web development career. Finding my place, doing what I love and being able to be good at it, becoming an expert of my craft, and using my skills to be able to help others - that really gave me a purpose in life and so much self-confidence.

Throughout my life anxiety struck me, especially in crowds, and I often avoided going out on my own. I always felt so self-aware, and "strange". The feelings of being weird, or ugly, or a misfit, that had come from silly thoughtless comments from school-kids. They were hard to shake. But if I was doing web development, I was okay. At one time I worked half the time in London, and half my time in a smaller city. In London, as part of a web development team, I could be in the busiest city in the UK, I could be in a room with twenty people, but I was confident. I was a developer.

Back in the smaller city, away from the web development team, in a room of five people, I still felt awkward and anxious.

Web development feels like where I belong, and doing it feels like I've found my place in the world. But as seems to be a common theme through geek mental help week, I too fell into the well of "omg there is so much to learn and I can't do it all".

Almost three years ago, I moved jobs, from a team I had worked with for about five years, to a new team. The new team was great, but being how I am, the massive upheaval - though exciting and awesome - was also pretty unbalancing for me.

The Javascript monster

Now, the point of this entry is not to say that Javascript made me depressed (though I'm sure some javascript-hating programmers may be amused to hear that. ;) But at the point I joined my new team three years ago, I was quite a hybrid techie. I had spent quite a lot of my career on design as well as coding, though I found design so much harder - and actually worse for my mental state - that scary blank canvas! I was so happy to return fully to code in my role as a front-end developer, I really wanted to leave design behind at that point because it wasn't making me very happy. And due to my hybrid role in the past, I really wanted to get better at front-end development and all the things that make it up these days.

A big part of that was Javascript. I'd known basic Javascript for a long time, and I'd learnt jQuery. I could probably make pretty much anything you asked me to make, so long as I could google for some advice. But I was probably a "hacker" when it came to Javascript. I got all the basic stuff - variables, if statements, arrays, and I understood functions enough. I could make those things do stuff. But I didn't really feel adept, let alone an expert. But I *should* be an expert at this! This is my job now! For a long while I felt vastly aware that I had probably the least Javascript skills of my 5+ front-end development team. That wasn't good enough for me! Once I told a female friend that I felt Javascript wasn't really my forte, and she pointed out that as the only woman on my team at the time, I should be good at programming! I should show people I'm as good as the guys! (this is a really bad reason to do anything, btw)

Don't get me wrong, I had enjoyed Javascript challenges in the past, and I really enjoyed learning jQuery. At one point in the past programming was the route I wanted to take, and I had been told I had the skills for it. But suddenly, Javascript went from being fun to being this big thing hanging over my head, that I had to get better at if I wanted to be a good front-end developer. My day job let me do Javascript - and was a large reason for me wanting to improve, but I didn't feel I could learn fast enough to keep up. I had to learn in my spare time. And why wouldn't I want to? Countless people I worked with told me how they would go home and code after coding all day at work. They would be doing side projects, or even freelance work alongside their main work. They did it because they loved coding, and it was fun and why wouldn't I want to do the same? If I wanted to be better at Javascript, why didn't I just spend all my free time learning it?

I'm 29 now, and back in my early 20s, I would be constantly making websites, it was my hobby as well as my job. And now.. well.. I loved web development. "If I really love web development, why don't I spend all my spare hours learning Javascript?", I asked myself. So, I bought books, I found tutorials, I started trying to learn. The problem was I just started trying to learn so hard, and with so much pressure on myself. The books I had bought sat there, and I would get home from work, mentally tired, but see them and know I had to try and learn, I had to be a better front-end developer.

I use Javascript as my example in this post, but "there's more to life than ..." could apply to anything, especially anything you have felt overwhelmed by. I ended up spending so much time and energy thinking about how much I should be learning, and trying to learn. I don't know if it makes sense to anyone, but I really do feel like I used that time and energy up, like.. I never relaxed, but at the same time I never really got very far with learning. What I did get, was tired, unmotivated, stressed, with feelings of guilt for what I didn't remember or still hadn't done, for what I should have made, or side projects I told myself I would do.

It just wasn't fun. At all. And I was tired. I burnt out - not even from necessarily doing a lot, but from a whole lot of constant pressure in my mind that I should be doing a lot.

Now, poor Javascript isn't to blame, nor was my new role. I always had good feedback that I was doing a good job - my CSS was good, my attention to detail was good, other things. But it was so difficult to feel like I was doing good enough to reach my own standard! I just got gradually overwhelmed by everything I thought I should be doing, to the point where I just wanted to rebel against it and give up on it all.

I mentioned earlier about anxiety, and some of my issues with confidence. Whilst anxiety and self-confidence issues had pretty much been on and off throughout my life for a long time, I'm not sure when I realised that these things had cultivated into depression. But there was one point where, the times I felt low just got longer, I was tired a lot, unmotivated, and randomly sad for no reason. I struggled to fall asleep at night, but struggled to wake up in the morning. I got through the day, I did my work - though with the feeling I wasn't reaching my potential - but then I wanted to just get in bed as soon as I got home, and cry or sleep more.

I had always tried to deal with these "phases" all by myself, even feeling responsible for it, like I was just being lazy, especially on those times where my body wouldn't let me get out of bed and go to work and I had to phone in sick, then feel worse with the guilt that gave me. Guilt because I didn't understand what my body or mostly - what my mind needed, that it was asking for a rest.

Eventually it got bad enough that I didn't enjoy life much at all anymore, and I felt almost non-functional, like I was just dragging my body through the days. That's when I finally saw a doctor. And that's one thing I would really recommend. It can feel so hard to do so at first, especially when you're not aware you're depressed, or you wonder if you're over-reacting, or as depression can often do it just causes you to feel responsible and blame yourself rather than seek help. I would also advise writing stuff down and handing it to them, so you don't have to remember what to say. Good, well trained doctors will take mental health seriously, and you can start to get help.

My other bit of advice is.. talk to somebody, a friend or a colleague. It can be really hard to open up at first, but you can be really surprised how much it helps, and how people will listen and understand.

I think my manager at work was the first person I ever admitted my depression to, other than my boyfriend at the time. I told my manager before I even told my parents - because I was really worried at the time of upsetting them. I feel so lucky that my employer has been so supportive to me during this time, and understood the seriousness of what was going on with me, and didn't question it. Of course - this is how mental health should be treated, the same as any other illness - but I know that the stigma around it is still something we're all working to change, and I know that others telling their manager may not have been so lucky to have amazing support. But I really hope that most of you have somebody you could turn to for support - and sometimes, even telling people who you may not expect to understand, you can really be surprised. The support I received from my work just.. it really touches me even to this day because it helped me so much, it helped me continue getting help and tell other people what was going on.

Anyway, since I started opening up and seeking help, things have got back on track for me now, a lot. As one of the speakers at mkgn said, he doesn't like to use the word "fixed" as it's such a cut-off term. I would say the same. Depression and anxiety, especially the kind that manifests itself long-term, well..I'm not sure it's something that can be "fixed" completely. Some of it is the result and sum of our experiences. I believe that some of the experiences I started this entry with, as small and insignificant as they may seem 15 years later, ingrained some of the ways I feel about myself today. I think that who we are is a result of everything that happens to us, and that's okay, because we're human. We're fragile. We can't just be "fixed" and we're the more beautiful, and interesting for it.

I feel like I've found my place in my role now. In the end it wasn't from bombarding myself with Javascript books. It was by looking after myself a bit more, noticing what I enjoyed, and what I was good at, and what made me happy at work. Using my CSS expertise to help others, using my eye for detail to help scope and look after projects. Realising that working with a team motivates me a lot, talking to others and helping them, working on stuff together. Speaking to other people in the process, and helping improve processes where I can. There are lots of things I enjoy and am good at, that mean I can do well at my job, but I can still look after myself and recognise what motivates me and what overwhelms me.

When you think about our jobs, the kind of work we do in the web industry.. we're not using our bodies.. well, besides typing with our fingers, and looking at a screen with our eyes. But we're using our minds. We're being paid to use that bit of equipment that is more important than any retina imac. And that needs looking after, and maintenance. And importantly - down-time.

So don't feel bad for taking a break, and don't feel guilty for slouching in front of the tv or a videogame sometimes. I used to feel guilty for doing those things, but I don't anymore. I don't because if I'm unhappy doing what I think I *should* be doing - then there's no point. The only real point to being alive, at least in my opinion, is to find joy in things. Work is something we spend such a large majority of our life doing, and web development especially has so much going on and changing that it can be overwhelming. I still love my job and I love front-end development, but I can love it by being part of it in a way that works for me, and makes me happy. I also love my brain, and I'm definitely going to keep trying to look after it more.

Thanks for reading :)

I wrote this entry for Geek Mental Help week - you're not alone :)

Fronteers 2014 - part 2

Oct. 23, 2014, 8:41 p.m. in Web Design

fronteers-logo

Hello! Welcome to the second part of my blog posts about Fronteers 2014 - a front-end web development conference held in Amsterdam at the start of October.

My last entry focused on some of the user experience and user consideration talks that really resonated with me. For this entry I want to talk about some of the other cool stuff I learnt at Fronteers, with an emphasis on web animation, and I want to begin with one very awesome lady!

me and rachel nabors
Rachel and I in Rotterdam! I'm the slightly shorter nerd. XD

If there's anyone in the web development world I've always been a bit of a fangirl of, it's Rachel Nabors, an awesome lady who started her career as a comic book artist, before becoming a front-end web developer. I find it's somewhat more common these days to find front-end web developers who come from a programming led background, or are heavily interested in Javascript as their main "thing", but less common to find those of us who maybe come from more visual/designery/arty backgrounds. Even though there is so much new and awesome Javascript stuff (uhh, "stuff" is a technical term :P), MVC frameworks and whatnot these days, I still personally believe that there's a lot of room in front-end development for the more visual-led of us.

As doodling is one of my favourite hobbies, I love when I can find ways to incorporate art or cute character designs into web development. With my affinity to visual media on the web, I've always been a fan of the idea of CSS animation - not least because I love how lightweight, maintainable, and device-agnostic it is, but also because of how it's a lovely way to combine art and code, and a new way to provide more visual goodness to our websites and applications.

Anyway, I was super happy that as well as getting the chance to meet and hang out with Rachel during my Amsterdam trip, I also got to attend her CSS animation workshop, and hear her speak at Fronteers. As I say - I have always been a fan of CSS animation, and this little codepen - Mr. CSS lion - is so far one of the few things I've played around with that combines my drawing style with CSS (worth mentioning because Rachel's work heavily inspired this!).

That was a while ago, and there haven't been too many animation challenges for me at work recently, even though we do get the opportunity when working on interactive ipad edetails to use animation to liven up an otherwise static presentation. Rachel's talk reignited my hope that some more of those challenges come along in the future! These are a couple of my favourite things that she talked about to help us with CSS animation:

  • Steps! - Even though I've done CSS animation quite a bit, I didn't know about these for some reason. Steps are a cool way to split up stages of an animation without having to add loads of extra points to your keyframes. One super cool use for this, is if you have a sprite of various images that may make up an animation (eg a walking animation or maybe a logo animation or whatnot), you can use steps to tell the animation how many states to have without manually setting all of those states. Say you have 5 sprite images in a file, you could set the starting background position, and the end background position and tell the animation via steps, how many in between states there are. Rachel demonstrates this better than I can explain here. But anyway, I wasn't aware of this previously and would have previously added more percentage values for different states, so this seems like a really handy way to handle certain animations, especially if you want to animate sprites.
  • animationend - and other handy javascript events that get fired through CSS animation (there is also animationstart and animationiteration). These events give us a nice way to control and also link our CSS animations to each other, for example firing one when another has finished. We could also trigger the animationstart event when hovering over a logo for example. One of my main issues with CSS animation in the past has been controlling a large number of them and keeping them maintainable and not too dependant on every other part of the animation. I've often tended to string delays together (for example the first part starts at 0.5s, the second animation starts at 1.5s), but this means that making changes somewhere in the middle of the chain can really confuse things. I like the idea of combining these animation events, along with some simple jQuery, perhaps manipulating classes too, to make animations more modular and able to be amended at different points more easily.

Anyway, my attempt to explain the coolness of CSS animation in text may not make a huge amount of sense, but make sure to check out some of Rachel's codepens for more examples - this walking cat one combines steps and animation events and is a simple but cool example of some of the possibilities we have with CSS animation now.

Is this useful for my client?

Obviously animating drawings is cool and fun, but does CSS animation have a place in our day-to-day jobs and client work in various industries? I think it absolutely does, and Rachel actually drew a lot of attention to the benefits of CSS animation when it comes to improving how users interact with our interfaces. I liked this quote below that she included, alongside an example of a typical dropdown menu, and how the shift in states, whilst obvious to some of us (the younger or more tech-savvy), it can be harder for other users to make that connection, and small animations and transitions can really help with that.

“By offloading interpretation of changes to the perceptual system, animation allows the user to continue thinking about the task domain, with no need to shift contexts to the interface domain. By eliminating sudden visual changes, animation lessens the chance that the user is surprised.” E. Hudson and John T. Stasko (1993)

I know that Rachel sees the web as much more than static documents - as a canvas with so many possibilities! I think CSS animation and transitions can be used subtly to bring static things to life, or can be used to guide our users around certain bits of our interface and help them see what's going on. And even if some of our users are on old versions of Internet Explorer - we can make these animations more of an enhancement for the users with modern browsers, and degrade gracefully for others.

Rachel rightfully pointed out that CSS animation and transitions shouldn't be something we attempt to tack on at the end of a project, as an afterthought, but rather that we should think about how we design our sites with these possibilities in mind. I definitely would like to see interaction design making more use of CSS animation because I think it gives us some great new options for interface design.

The Google Material Design documentation has some great responsive interaction examples of how animation can help our users.

SMIL-e... more animation! :)

Going nicely hand in hand with Rachel's workshop and talk, Sara Soueidan gave a wonderfully information-packed talk on animating SVGs using CSS and SMIL (Synchronized Multimedia Integration Language if you want to know!). SVG animation gives us a few extra nice options for more advanced animation with SVG shapes, for example if we want to animate more advanced graphics, have them scalable and still be able to use CSS on them. One thing that's cool alone is that:

"Basically, any transformation or transition animation that can be applied to an HTML element can also be applied to an SVG element." Sara Soueidan

But not only that, SVG animation gives us even more options than CSS animation in some cases! Using the <animate> element within an SVG, we can tell it things like how to animate, and even how to start animating (e.g. "begin = click"). I especially like that you can do things like "begin=click + 1s" to start an animation a certain time after an element is clicked.

Another really nice thing is that you can chain animations by doing things like setting one element to start animating a certain amount of time after another has started (or stopped). SMIL has many more properties that let us do some really cool animation functions without much code, and I think the possibilities for these on scalable graphics is awesome. Animations along SVG paths are another cool thing. There are so many cool things to know about these, and Sara is an incredible font of knowledge, which her talk showed! I recommend reading her guide on CSS Tricks to learn more, and there are some great examples in her fronteers slides also.

As for support, SMIL is widely supported - well... with the exception of all Internet Explorer browsers. :P But since we could use modernizr to check for SMIL support and provide fallbacks, or have this as an enhancement for all the other browsers that DO support it, it still seems like a pretty good time to think about trying some of this stuff out!

Infrastructure FTW

I realise I've written quite a lot about animation alone.. you can probably tell that it's one of my favourite areas of front-end development! I'm going to more briefly mention the other talks purely because this entry could go on forever.. (you can have a cookie if you're still reading :)

Daniel Espeset talked about the role of frontend infrastructure at Etsy, with a focus on the importance of having continuous deployment and letting "anybody touch anything", which I liked. At Incuna we generally have front-end as well as back-end developers being able to deploy sites to staging after they've worked on them and it's super useful I think to have all developers being able to do that. Daniel talked about tools like "Ranger" and "Builda" that Etsy built themselves for tracking deploys and code, and also discussed how the team had moved to using Scss for more maintainable CSS. At Incuna we use Sass and I would never go back now - the usefulness of CSS preprocessors such as these is amazing. Read Daniel's slides.

Nicolas Gallagher from Twitter gave a somewhat similar talk, about Twitter UI infrastructure. I liked that his talk focused on making the infrastructure as reusable as possible, allowing people to "spend time on creative things" instead of having to spend a lot of time on infrastructure everytime they work on a new project. This is something we've worked on a lot in the past couple of years at Incuna (and I have to give Perry Roper a mention for initiating a lot of those changes such as incuna-sass). We factored all of the CSS that we kept reusing in projects into our own Sass component library so that we can use it on projects every time and not spend time rewriting things. It's super useful!

Some of the other advice I found useful from Nicolas:

  • Have a shared language between design and engineering teams.
    I think this is something we can get better at!
  • Design for adaptability, not perfection.
    Use components to help people work on different parts of a larger app without effecting others.
  • Consistency is the best option.
    Make it so that anybody in a team can pick something up and work on it.
  • Make skilful use of what is at hand.
  • Documentation and ownership over institutional knowledge.
  • Hide complexity of infrastructure from developers
    and allow the infrastructure code to be changeable without effecting the dev's existing work. (This is another thing we're doing quite successfully with an edetail library that we use as a base for interactive ipad edetails)
  • Create habits among engineering teams

A round up of the rest

Dave Olsen gave a great talk on optimising web performance. He pointed out some of the perils of responsive web design that only considers layout - where we end up downloading too many elements on mobile by over-using "display: none". He recommended some useful tools, such as:

and of course if you're not already using chrome dev tools, the network and timeline are always super useful!

I also like that Dave Olsen discussed how you would get performance measuring into a client's budget or into your project workflow. He recommended having a "performance budget" and aiming to beat a baseline - for example, decide that your page speed score will be 25 percent lower than your nearest competitor. I think this was an interesting way to try and justify why it's worth spending time on webpage performance and also have something to aim for rather than a hard to measure goal like "make it perform better".

Fronteers featured some cool mini sessions on gaming in the browser. Being a massive videogame fan I always think I should try and make a game and never get round to it. Phaser sounds like a very interesting framework for HTML5 games.. if i can ever get round to stop playing them to make one! ;)

Forgive me if I've not mentioned all of the Fronteers speakers in my blogs, I've focused on those that are most relatable to my personal interests and role in front-end development. There were some talks on WebRTC, but they were a bit more technical and went over my head a little. XD (or was it that big lunch...? ^_^) I'm sure they were very useful for some other attendees! Anyway, here are all the slides from the conference if you would like to catch up more on anything I've mentioned or some of the other talks!

Collection of Fronteers slides

All in all, Fronteers was a wonderful conference to attend (not least because I love the city of Amsterdam!) - it reignited my enthusiasm for CSS animation (and grew it for SVGs!), it reminded me that Incuna are on a pretty good track with our increasingly modular and consistent codebase, and it also made me see the areas we can improve on when it comes to user needs and really merging our design and front-end practises more which is something I really hope we might be able to do more in future.

A more fluid, dynamic web

I've written before about how closely I see the link between web design and development, and how the canvas should be the browser, and I think it's true more than ever these days. With the different devices we are working with, and the animation and interface possibilities - the pure fluidity and changeability of the web, design isn't the static thing it may have once been. Some of us still have fairly waterfall processes in our companies, but I really hope we can all try and combine our design and front-end development processes much more closely because I really think that we are working towards the same important goal - what the user sees, uses, and interacts with, and making that a more useful, easy, and pleasurable experience.

Thanks for reading! :)

Fronteers 2014 - part 1

Oct. 14, 2014, 9:17 p.m. in Web Design

fronteers-logo

Last week I attended Fronteers 2014, one of Europe's largest front-end web development conferences, in Amsterdam. It is the third web conference I have ever attended and my first time attending Fronteers, and it was a great experience!

Before I talk about what I got out of the conference, I just want to say that I was really impressed with the organisation of Fronteers, the atmosphere, and approachability of the staff in particular. I was pleased to read and hear that they had a code of conduct, and thought the way that the staff drew attention to it, and were always on hand to talk to at any time during the event, made it feel like a safe and inclusive environment, which is super important! :)

This is going to be a two-part blog entry, focusing on the main learnings I took from the conference. For the second part, I'll talk about some of the more technical talks (including CSS animation and game making, yay!) but for this first part, I'm going to focus on one the over-arching messages from the conference, which I think one of the speakers, Petro Salema, summed up best:

"The goal of technical innovation is user experience" Petro Salema - #fronteers14

Web development has really come on in recent years, and being a front-end developer these days encompasses a lot more than it used to. From designing layouts, creating html, adding a bit of Javascript, and uploading our code via FTP, these days front-end development involves much more. Knowing version control such as git, CSS frameworks like Sass, as well as all manner of Javascript frameworks and libraries for all sorts of things that they web gives us power to do. New libraries are cropping up all the time, and technically - we're doing great! We're in a more knowledgable, powerful place than ever with all manner of tools to help us out. But in this transition, in this "best practise" focused environment that we're currently in, have we forgotten some of the basics of the days when we called ourselves "web designers", and coding was a smaller part of what we did?

Heydon Pickering kicked off Fronteers with a talk that discussed just this, questioning how much our obsession with "best practise" is actually relevant to the user, and whether it improves the product as a whole, or how much of it we are doing to maintain our own developer standards - are we sometimes obsessing over the wrong things for the wrong reasons?

"A front-end developer asks 'How should I do this?'. A designer asks 'Should I do this?'" Heydon Pickering - #fronteers14

So often we focus on "best practises", but UX - "user experience" - is still an afterthought. UX is the kind of thing we want to pay somebody to come in afterwards and check, or that we think about at the end. Maybe we see it as a separate role.

Heydon's message was one I feel strongly about myself - that as developers, we all need to start thinking more in terms of design. About why we're doing things, if we should be doing them, and realising that user experience should fall into our role as much as knowing technologies should. It's great to be striving for good code practises, but maybe we should be striving to get a user experience focus higher on our radar again.

Heydon's slides - "Getting nowhere with CSS best practices"

"We are all web designers because
we are all contributing" Somebody at #fronteers14.. sorry, my notes failed me

Design products for less than perfect situations

This was another strong message coming from the conference, which goes hand in hand with a larger consideration of user experience. Alex Feyerke's talk, Offline first drew attention to just how many apps are treating offline as an error, rather than the default state being that the user may have no (or no decent) connection. He talked about how his library Hoodie treats offline as a default and strives to ensure that a user can get to their data when they need it, and not just when they happened to have a connection. Personally I have experience of both being annoyed that I can't use an app offline, and also developing an app where we think "oh yeah, we should put in an error if the user has no connection", so it was useful to shift our thinking back to a user's default state being less than perfect.

Alex's slides - "Offline first"

Walk in somebody else's shoes

"Gov.uk stopped asking what departments want to say, and instead asked what citizens want to know." Meri Williams - #fronteers14

Meri Williams talked about the importance of accessibility and how we need to try and "bake it in" to our workflow, so that it doesn't get forgotten. We may often think that somebody with a disability or accessibility challenges is a minority, but just by talking to your family or somebody you know, we can find out that the use case for our product goes way beyond us, in our offices with our large mac screens and fast connections. It was interesting to be reminded that around 8% of users have difficulty lifting or grasping a mouse for example, a percentage that is almost equal to or higher than some of the percentages we try and include when we schedule in Internet Explorer development. Too often accessibility is an afterthought, or an "extra cost" but Meri rightly pointed out how vital it is to start considering how different people in different situations are using our products and how integral this should be to our process.

Meri's slides - "Baking in accessibility"

"We need to find a way to walk in somebody else's shoes, & see what's different for them." Meri Williams - #fronteers14

Know your accessibility bias

To finish off this first part, I'll return to Petro Salema, whose quote I used earlier. His closing talk "Dream big, think small" on day 2 of Fronteers, opened in a rather harrowing, post-apocalyptic way. He told us a story of planes returning from war, with bullet holes in the wings. The engineers would take that to mean that those parts of the plane needed more work on protecting them from the bullets, and would focus on fixing that area of the plane. What they failed to realise, and what one person eventually realised, is that the opposite was actually true. The planes that returned could withhold the bullets, and so they came back - the ones that couldn't, never came back.

" You can't get a better answer than the question you can ask, limited by your experience" Petro Salema - #fronteers14

Petro's tale, and the rest of his talk, was an eye-opener on how much our own "accessiblity bias" dictates the questions we ask, and the problems we solve. We want to think big, and solve big problems, but we need to remember to "think small", to not simply design ideal solutions to ideal problems, but to increasingly consider the smaller things that take place, the things users may be doing that we haven't even thought about - simply because of our own bias. As he discussed - we can't help our experiences, and we can't help that they naturally effect the questions we ask and answers we come up with, but it shows the need, ever more, to try and find the smaller questions, so we don't miss out on solving the smaller problems that we're not even looking at.

Panda thoughts

I think that, as resonating as these talks were, and as important as the messages were, it's often going to be a challenge in a commercial client world to get some of these considerations to the forefront. Many of us still work in "waterfall" type processes, and don't always have access or resources to get as much user feedback as we would like. Following the conference, I returned to work, feeling like it was wrong that we're all developing in Chrome, seeing our websites 90% of the time in their "best case scenario". However, I then tried to do some development in an Internet Explorer virtual machine again and.. I remembered why we don't develop there by default. XD Even so, I really do think it's time to get user experience back into the limelight again, as much as coding practises are to front-end developers, and find ways to put ourselves in other situations more when we're using the products we develop. I think UX is the responsibility of everybody, and it's going to take some thinking to see how we can get this into our workflow. Thoughts, or comments, or anything I have got incorrect above, appreciated. :)

Part two, where I will talk about some exciting web animation stuff, and some bits and pieces from the other talks at Fronteers, coming soon!

176 doodles and the importance of joy

Aug. 17, 2014, 11:38 a.m. in Art

zebras
It's a joke about pencils... Never mind.

When January arrives it's always time for New Year's resolutions - you know, those ones about quitting chocolate or taking up running that you realise a week later were not really a fun idea at all. I often hear people say things like: "Oh I don't make new year's resolutions because people just break them" or "I could do that anytime of year, January is a bad excuse!". Whilst I agree that if you want to do something, you should just start anytime, sometimes we need to help ourselves with a bit of a motivational kick and January - being a nice clean start to a new year, or at least feeling like one (even if it's technically just another day) can help.

I've seen "365" projects a few times before, sometimes photography, sometimes drawings, where you set yourself the challenge to create a little something on every day of the year. I generally don't like to dictate when or what I draw, as I find that never works out, maybe because I find it difficult to draw on demand and I just have to be in the right mood for creative pursuits. The typical pandalion thrives when enjoying a varied lifestyle with multiple hobbies, flitting between coding, doodling, and other creative or geeky pursuits, as well as playing far too many different videogames and not finishing many of them. I've always felt both in my personal and professional life, that I've never been quite content or good at focusing on just one "skill tree". There's just so many different fun things to do in the world! However sometimes the fact that there's so much I want to do and never enough time for it all, means that stuff I would like to do more of can fall by the wayside, purely from there not being enough hours in the day.

So, I decided to start a 365 doodles project in January of this year, with the aim of doodling something - anything - every day of the year. My hope was that I would motivate myself to exercise that drawing muscle more, giving myself smaller goals that would be easier to meet (it doesn't have to be a masterpiece! Just get something on paper). The main reason being that creating and putting something out into the world, as well as observing, consuming and passively taking things in, always feels like a great thing, regardless of what you create. Perfectionism is one of my most annoying traits and actually holds me back from creating things sometimes because of the fear that it might not be that good anyway, so again, this felt like a way to draw but say "hey, it doesn't have to be great."

litwick
If I'm not trying to catch them all, I'm trying to draw them all

I love videogames (what do you mean you didn't realise?? ;), and as a 29 year old woman, when I talk about this, I still often get reactions like "videogames are a waste of time", "I'm too busy for games now I'm older", "I create things these days, I can't just sit and play games". As I've said above, putting things out into the world is great, no matter how small that thing is, but I think it's missing the point if you don't appreciate the merit of enjoying the things that have already been created.

I've already written in some detail about how videogames are a fantastic blend of the creations of artists, artists in all kinds of fields - visuals, programming, storytelling, and music to name just a few. I really believe that inspiration is the beginning of all creativity. If you haven't experienced things that you enjoy, that have invoked emotion in you, how can you hope to invoke the same feeling in others through the things you create?

365-sonic
Sonic - inspiring me since 1991
365-wefightbears
Doodle for @nicollhunt, creator of awesome indie game We Fight Bears

I don't have any technical training in drawing, and I don't see myself as a "serious artist", because for me it's really just something that comes from my heart. Everything I draw just comes from a picture in my mind that I think could be pretty cute, how it looks is some combination of the things that have inspired me over the years, the things I've seen and thought "ahhh that's adorable".

During my personal challenge to doodle daily, if I hadn't been doing much outside of doodling, if I hadn't experienced something recently that had brought me joy, it would be much more difficult for me to know what to draw, and I certainly had those days. But other days, I will have just been to see a superhero movie, or just played Borderlands for several hours and I would want to get those experiences on paper in my own little way.

365-gaige
If I ever stopped playing Borderlands 2, I had to carry it on in my doodles
365-foxy-blackwidow
One of my favourites of a foxy Black Widow, drawn after seeing Winter Soldier.

I didn't get to doodle #365. I got to #176, and then stopped. I had a lot going on with work and moving house, but those weren't really the reasons, I guess I just wasn't enjoying it anymore, and it was feeling too forced. I felt like I was ready to stop, and wanted to go back to it not being a "chore", but picking up a pencil at random moments when I felt like it. And I'm glad I stopped when I felt like that too. It's part of the reason for me making this blog post - to explain the personal benefits of giving myself the project but also that not "meeting the goal" doesn't feel like a failure to me.

176 drawings is way more than I would have created had I not done this project. I feel like I exercised my "drawing muscle" and I helped myself create time in the day to not leave my hobby behind despite the other busy goings-on and responsibilities of life. I experimented over that time, tried different styles for drawing people, tried different characters or animals I had maybe not drawn before. I tried slightly different paper or techniques, I found what I liked or didn't like.

totoro
I don't really blend markers much so this was a kind of attempt at that
Fennec
Trying out a "no lines" style

After that many drawings, I still don't feel like I "know" what I'm doing. I still feel like art comes to me on a whim, when I wake up on a Sunday morning with a picture of something cute in my mind and want to get it on paper. But, after I stopped drawing daily, I noticed that ideas would come to me, ways of drawing things would appear in my mind - inspiration from games or people or characters or situations - and my drawing muscle felt on better form.

Achievement unlocked?

So, what was the goal of 365 doodles? Obviously three hundred and sixty-five doodles, on one hand. But reaching that number for the very sake of it, I believe would have stopped me making some of what I think are "better" pieces later on, through letting that muscle have a rest. Though it helped and was nice to have friends watching my progress and cheering me on, the project was for my personal benefit - and do I feel like I've benefited? Yes, hugely. I'm happy that the project helped me devote time to this hobby, to try a lot of different little things and break out of my comfort zone a bit.

I'm happy that it resulted in being able to make a lot of my friends happy too, with doodles of their pets, favourite characters, or anthropomorphised versions of themselves. And when something like this happens - a photo of my friends beloved cats, which I turned to doodle form, and somebody else turned to a sculpture.. that for me just sums up how the joy of the things we love is the very thing that can spark inspiration, that carries on over different mediums, different people, and even generations.

kaidan-liara
My friend @EmzvasNormandy's beautiful cats
365-siamesecats
My drawing of Emma's cats, and the sculpture she had it turned into
cards
Pokemon "art cards" drawn a few weeks after I finished my project

So, to summarise - I didn't reach 365 doodles. But I don't feel like I've failed either. I got so much out of this personal project and to have been able to see others get some joy out of it too, that was awesome. Creation should be about enjoyment, as much as playing games or anything else we do should be, and it shouldn't be a chore.

So go forth, play games, read books, listen to music, watch shows, do whatever the heck brings you joy, and I'm pretty sure that joy might make you want to spread more of it in your own little way :)

Incuna at jQuery UK 2013 - part 2

April 23, 2013, 1:15 p.m. in Web Design

White October cupcake
Amazing cupcakes from White October

This continues on from my first post - Incuna at jQuery UK 2013 - part 1, I wanted to finish up discussing a few of the other talks from the day and what I took away from them. :)

Following on from where I left off, the final talk before lunch was Douglas Neiner talking about Machina.js, a framework for Finite State Machines in Javascript. I’ll be honest, I’d never heard of a “Finite State Machine” before, so at first I was worried it was going to be something over my head. But not at all, and this was one of my favourite talks because of the clear and concise way it was presented. The basic idea was that Machina.js provides a cleaner way to deal with situations where your code may otherwise end up with a nest of if/else statements. I’m quite a visual person, and I think I find it easier to understand certain bits of code or concepts if I can see how they would be applied to a real situation. So, I definitely felt engaged in the talk when Doug provided some interesting, visual, real-world demos, the main example being a router. As well as being a great, simple example of what Machina.js was actually doing and how it can help you manage those different states, it was also a great example of some lovely CSS transitions/animations and attractive front-end work (something I’m a big fan of :) I’m not sure of any exact situations we may want to use this right now at Incuna, but it’s definitely something I’ll remember thanks to the excellent talk and demo.

After lunch (which included the delicious cupcake above!), Garann Means gave a talk on using events to glue full-stack frameworks together. Unfortunately I didn’t have a good view for this talk and couldn’t see the code examples very well and the rest went over my head a little :( Following her talk, my Incunauts and I did take a look at Marionette, the library she was using for Backbone, as we use Backbone in our projects at Incuna. So I’m interested to learn about that a bit more, also because the website is so pretty.. (there I go with the visual stuff again! :)

The next talk was Ilya Grigorik and was entitled “Wait, Chrome Devtools can do that?”. This was probably the most useful of the talks for me in terms of concrete information that I knew I could go away and look into, and hopefully use to improve some of our workflow processes and testing/debugging. The main thing to take from the talk is download Chrome Canary now! I hadn’t realised how far ahead Chrome Canary was in terms of the devtools, so that was useful to know. He also talked about some really useful and interesting features such as:

  • Better use of the timeline, including saving timeline traces as HAR files so others can recreate it, to see where something is loading slowly for example.
  • How frames per second apply to webpages as well as games, and how slow paints or costly CSS effects can affect this and cause (as Chrome puts it) “jank”, and how you can use the devtools to diagnose this.
  • How if you change CSS in devtools, Canary can actually give you a diff of your changes (yay)
  • How you can add custom panels to Devtools, the ones that sounded particularly interesting of these were jQuery Debugger and PageSpeed Insights. One of the coolest things mentioned about PageSpeed Insights was that it would suggest compressing an image for further reduction and at the same time offer you a download of that image at the reduced size! Oooh..

Finally, it was very useful to hear that Canary has remote debugging, for Android at least, with the ability to use all the same DevTools features whilst debugging on the device. Remote debugging is something we sometimes still have issues with at Incuna, so anything we can do to improve this process is great. There was a lot more useful information, you can read it in Ilya’s slides, there’s also a super useful Chrome Devtools course on Code School and it was interesting to hear about a weekly Chrome Youtube show The Breakpoint.

After Ilya, John Bender gave a talk about faster DOM manipulation with category theory, and he had some great slides, but it was admittedly a little maths-heavy for me. So, uh, moving on..!

I enjoyed the final two talks - it was interesting to hear Joe Petterson talking about his experience of still having to develop for older versions of IE, also as it the talk was around a pharmaceutical site, similar to the things we work on at Incuna. He gave some good thoughts on using IE VMs for testing (which we currently do), but also how you might use Selenium or an external service like Saucelabs to be able to test accurately on the VMs. Front-end testing is still something we need to do more of and look into more at Incuna, so this felt pretty relevant to recent work conversations.

Finally Jason Scott from Blackberry talked about building “an experience, not just another framework”. I was interested to hear a talk from this perspective, as ultimately, the reason we’re all writing jQuery, and the end point of all of our sites and apps is the user. He talked about using jQuery Mobile and customising the theme for your user. This was quite familiar to me, having used jQuery Mobile a few times at Incuna when working on Phonegap mobile applications, and I found myself agreeing when he pointed out how it doesn’t make sense to try and replicate all native functionality with things that just don’t work as well in a webview - for example transitions that require a a heavy amount of rendering. He also mentioned Grunt JS as a build tool for minifying and uglifying files. We have scripts for doing this on our projects at Incuna but it still sounds like it could be a useful thing to look into.

Overall, it was a great day with a really interesting range of content and it was nice to meet some new people in the jQuery community. It definitely left me feeling inspired. Yay!