On a recent mobile-focused project we ran into a few challenges over getting what turned out to be a fairly complex layout working smoothly and responsively over a range of target devices. It also highlighted a number of real edge-case quirks in how different phones and browsers deal with modern web technologies such as the audio element, and even how ‘shake to undo’ can affect a form that the UI hid several transitions ago.

(There was a time mobile phones were simpler… or not…)

Libraries

To help with the total payload of the project we chose to use the Zepto library rather than jQuery. This has an API very similar to jQuery’s and the advantage of size but is focussed on modern, mobile browsers so drops support for IE and – significantly – doesn’t cover Windows Phone. That wasn’t a problem on this particular project but worth bearing in mind for the future.

We found a couple of niggles in the Zepto API, mainly related to our own coding styles and the requirements of the project. We missed jQuery’s ability to set a hash of functions against AJAX http response codes, for example.

In the end, given the eventual size of the rest of the application’s payload, the filesize saving of Zepto over jQuery probably didn’t make a whole lot of difference.

How to be responsive

The biggest problem encountered while implementing a responsive layout with the given design was how the DOM flow needed to change depending on whether the screen is portrait or landscape. It would have been ideal if we’d had the option to change the design and eliminate the worst of the problems, but once we realised how complicated it would be it was already too late. So a lesson learned…

One of the big problems in trying to fit a fairly fixed size application design to a phone screen is orientation. Fine in a native app; you can just specify if the app fits to portrait or landscape, or both, but in a browser that level of control is not available.

Fitting the level of interaction we needed, responsively, into a landscape phone viewport meant quite a lot of juggling of DOM elements and events when switching from and to portrait layout. This was particularly tricky on iPhones as Safari in landscape orientation has three different possible sizes (address bar visible, address bar hidden, fullscreen) and generally smaller screen sizes than our target Android devices. The eventual experience in landscape wasn’t as satisfying as in portrait but we did manage to make it work.

Because of all the complexities that are not possible to handle only with CSS and media queries, we heavily depended on a Javascript layout manager to handle resize events and orientation changes, calculating available screen estate and rearranging elements.

A simpler way to get around this, although perhaps a cheeky one, would be to use the ‘orientationchange’ or window’s ‘resize’ event to effectively hide the main app with a “please turn your phone round” message. Unfortunately the ‘orientationchange’ event is not available on older Android devices.

Preloading

The procedure we used to preload assets for our single page web app was to have separate CSS files for the preloading/splash screen and for the main app.

The splash page was part of the app, so we didn’t want users to proceed from here and start using the main app until all the assets were loaded. To achieve this, we made one stylesheet for the splash screen with all the generic styles that didn’t require any images and another for the main app which referenced all images and assets (i.e. icons and background images) and only linked the splash stylesheet to the HTML page. We then used a Javascript preloader which requested all the image assets and the main stylesheet, attached this CSS file to the HTML page once everything was loaded and ready.

This method could also be used to load different stylesheets and assets depending on the screen size or device, if required.

Sounds

A new technology for us on this project was the Web Audio API which is a programmatic way of cuing and playing sound files rather than relying on a DOM element such as <audio>. Support is limited for now with only modern desktop browsers, and Safari in iOS 6, able to use it, but it looks to be a great way of adding spot effects to browser games and other interactions.

We used the Howler library to add sound to the application, with the expectation that we would use its fallback methods to increase support across devices and browsers. In the end due to other technical constraints (see ‘Device Quirks’ at the end of this post) we chose to only play sound through the Web Audio API, so if we were to refactor here we could have removed Howler (not that there’s anything wrong with it) and go direct to the API.

Jam off the boil

We’ve used the Jam package manager on a few projects now, and while it does have some advantages in dependency management and compilation it also uses its own module install system. So it relies on package owners keeping the versions that are published in Jam (rather than their main Github, etc, repo) up to date. We’ve had a few cases where the version of a library we needed isn’t available yet in Jam.

Jam interface with the browser is a modified version of Require, which we like for its clean module loading mechanism. So for future projects we’d look to dropping back to regular Require and find something else, perhaps a Grunt task, to handle the file concatenation and minification which Jam also offers.

App logic

The application logic required a fairly complex state to be maintained, and for these we used our old friend Knockout. We did consider lighter MV* libraries but ultimately felt that with Knockout’s very comprehensive view binding built-in we would save ourselves a lot of trouble. The other main aspect of the Javascript architecture was the use of a PubSub (publish-subscribe) library to communicate between the various parts of the app. So for example the AJAX API methods were fairly isolated – to enable their easy reuse – with their success states publishing the returned data for the viewmodels to pick up.

This decoupling did present a few edge case bugs around timing issues later on in development, but overall the ability to have communication, view state, preloading, sound and so on implemented independently and talking to each other via PubSub suited the Require modular loading we used as well as resulting in cleaner code.

This complexity of the application was borne out in the eventual size of the DOM, as we had several ‘pages’ within one document which were hidden and shown as required. For smoothness of experience this was useful, but retrospectively we’ve wondered if it might have been better to have a minimal HTML document with more extensive use of Javascript templating through Backbone or similar. Ultimately its hard to tell without implementing, but at least we have a steer for future iterations in this programme of projects.

Phonegap and other gotchas

It is well known that the performance of a web app wrapped in the Phonegap library is not as good as a native application.

Our previous Phonegap projects had a lot more DOM elements involved than this one so we hoped for better performance, but there were still a few performance issues on older iOS devices. Aside from that the Phonegap wrapping was pretty straightforward with minimal changes needed.

In the end perhaps the weirdest problem we discovered was that mobile service providers such as T-Mobile and Virgin appear to strip comments in HTML when sending data to mobile devices. This caused failures in our Knockout implementation, which used the library’s containerless control flow (i.e. specially formatted comments) to reduce the number of DOM elements – a very unexpected surprise. We ended up replacing all comment bindings with regular DOM bindings.

Device quirks – iOS[I] vs Android[A] vs Blackberry Z10[B]

- on-screen keyboard

[I] no viewport size change when hiding/showing the keyboard

[A, B] viewport size changes when keyboard is showing

[older A] even when the form page is hidden, the on-screen keyboard will not be dismissed unless the focus on the textfeld is forcibly removed.

- in-page scrolling

[A] even with overflow settings its still very buggy on the stock browser but Chrome doesn’t have problems.

- overflow: hidden

[older A] cannot interact with elements inside of “overflow: hidden” even if they are visible

- shake to undo (only on iOS)

[I] we found a filled-in form which was subsequently hidden triggered the iOS ‘shake to undo’ event. Unfortunately there was no known way for users to disable this feature easily but having an iframe somewhere in the DOM and changing its src (to anything) disables the “feature”. This hack doesn’t work if the app is wrapped in Phonegap but you can explicitly turn off shake to undo here.

- <audio> elements

[A] when a sound clip plays in an audio element it stops other background music from other apps

[B] the sound clip files are added to system playlist and so become accessible through its music player

- ‘devicemotion’ event

[A] on Android Chrome browser the ‘devicemotion’ event is not supported, although it is available on the stock browser. Future Chrome updates should add support.

- ‘orientationchange’ event

[older A] not supported

co-written by Stephen Fulljames

Red Badger recently switched away from Exchange Server to Google Apps and, after 5ish months, I can honestly say I think it’s one of the best decisions we’ve taken and we are collectively more productive because of it.

It was with some interest and surprise then that I was reading the hacker news thread last week about how Google have “ruined” Gmail with the latest tweaks. I guess I’ll preface this and say that until Red Badger moved to Google Apps I wasn’t a regular user of Gmail and so have pretty much learnt my way around based on the app as it stands now. I know a few long-time Gmail users in the Red Badger office have moaned about the new compose window etc, but I guess what you never had, you never missed and it’s never bothered me. I like it.

One of the books I’m reading at the moment, The Art Of Unix Programming, spends a lot of it’s time presenting the design patterns and ‘rules’ commonly used across Unix and the lessons we can take from those patterns to put into practice in our own development endeavours.

Three of these rules state that your application should be discoverable, transparent and obey the rule of least surprise, with the caveat that stuff can be surprising, so long as the first two rules are maintained such that those surprises are easy to learn. These three rule applied together often result in, the author argues, software that appears to be intuitive.

When I first read that, I guess I thought of Gmail. I always try to learn keyboard shortcuts to make my life easier and in doing so within Gmail I’ve found it incredibly intuitive. As a result I feel [random unprovable stat]% more productive dealing with mail and IM in Gmail than I ever did before.

Learning keyboard shortcuts can be a bit daunting. Obviously everyone can read the keyboard shortcuts, but my theory here is to present them in the context of common tasks (aka recipes) hopefully making them easier to pick up.  I’ve also thrown in a few modes of operating which, I hope, will help you learn a good chunk of the Gmail keyboard shortcuts and help save the world*.

Make sure you’ve enabled all the keyboard shortcuts first. Also I’m only noting down the Mac keyboard keys because I’m lazy and you can lookup the Windows keys yourself.

Empty Inbox

This is where all of this is heading. Aim to only have stuff in your inbox that you have to action. Everything else can be archived. That way when you start your day, or ask yourself “what next”, you should be able to carry out a Mailbox Triage starting from the oldest mail in your inbox regardless of whether you’ve read it before or not. Keep repeating the Mailbox Triage recipe until you have an Empty Inbox, or as close to it as is physically possible.

If I have more than ~15 emails in my inbox I’m not being ruthless enough or need to break out some common tasks to a Short Term Label.

Mailbox Triage

Start from the oldest email in the inbox, so that emails get treated in a first come first served priority order.

Open the oldest email in your inbox. Read it. Decide what action to take.
Respond. r to reply, a to reply all of f to forward.
Compose the message and hit Cmd + Enter to send.
If you want to apply a label, hit l + type the name of the label + Enter.
If no further action is required on the thread, hit } to move previous (ie. newer/up the inbox) and archive the current message in one fell swoop.
If further action is required, and you want to leave the mail in your inbox, hit k to just move previous.
Repeat until you reach the top message in your inbox.

The j and k keys move you next (older/down your inbox) and previous (newer/up your inbox).
The { and } keys move next and previous and archive the active message.

These two sets of keys alone save an epic amount of time and are the key (excuse the pun) to effectively triaging your mailbox.

Avoid using shortcut keys like v (for move message to label) – whilst useful, this will move the message to a label and return you to the inbox. The theory with this recipe is to remain in the current message, triage it and then move straight onto the next one until you’ve been through every email in your inbox.

Short Term Labels

Think of labels as being short term sorting pens. Ultimately you want to shepherd everything into Archive (and you’ll use search to find it again, if you need to… which you probably don’t), but labels are handy to get groups of actions out of your inbox and allow you to process them together at a later date.

For example, we’re on a recruitment drive at the moment so any CV that comes my way get’s labeled under ‘Recruitment’ and moved out of my inbox. When I have enough to process in one go, and the time, I can process them all at the same time (by applying the Mail Triage recipe), ultimately removing the ‘Recruitment’ label (and thus Archiving it) once I’ve progressed them to a natural conclusion. Once you’re finished with a label, remove it.

There maybe a few exceptions to this rule, but even as I look at my 1 long term label now, for product keys, I question if I really need it and couldn’t just as easily search for the product name when I wanted to find the key again.

If you have tons of long term labels, you lose the value of labels because you have to remember which label you might have applied when trying to find a message. Learn to use search.

Search

One of the reasons you can just Archive stuff in Gmail is that the search is so powerful. Anytime you want to quickly get hold of that email, hit / which will focus you into the search bar and start typing.

Most of the time you can use a keyword and find what you need, but there are lots of facets to help you be more specific.

Want to find something you sent? from:me
Want to find something that was emailed to Bob? to:bob@mail.com
Want to find something with a PDF attachment? filename:pdf

Moving Between Folders/Labels

Moving between the main folders (or system labels as they really are) in Gmail is simple, there are a number of g + key shortcuts, such as g + i takes you to the inbox (think ‘goto’ ‘inbox’). g + t slightly less obviously takes you to ‘sent’ items, being as g + s is reserved for taking you to ‘started’ messages.

Moving to custom labels is achieved via search. You could of course hit / and then enter ‘label:[your label name]‘ which is pretty quick. But even quicker is to hit g + l (‘goto’ ‘label’) and Gmail will pre-populate the search box with ‘label:’ for you. Enter your label name and hit Enter.

Once in a label, you can apply the same Mailbox Triage recipe until everything has been Archived and the label can be removed.

One Off Reply

For this to work you need to enable the “Send & Archive” button, within settings.
Use the up and down keys to focus the specific thread you’re interested in. Note the blue highlight, indicating which thread has focus. Hit Enter to open it.
Hit r to reply, a to reply all or f to forward.
Compose your message.
Hit Tab to focus on the Send & Archive button + Enter to action it.

Responding to an Older Message in a Thread

You’ve opened a message thread from your mailbox, and you want to go back up the thread and perhaps respond to an older message.

Press p to move previous/up the thread (older), n to move next/down the thread (newer). Note the blue marker indicating the selected message.
Hit Enter to open a message.
Hit r to reply, a to reply all or f to forward on the selected message.
Compose your message.
Hit Cmd + Enter to send.
If no further action is needed on the thread, hit e to Archive it. Don’t forget it will return to your inbox if anyone replies.
If further action is required and you want to leave it in your inbox, hit g + i to return to your inbox.

Moving/Labelling Multiple Messages

This is especially handy when, let’s say, you send out a meeting invite to a whole bunch of people and get lots of responses clogging up your inbox.
Use the up and down keys to focus a message.
Hit x to select the focussed message.
Move to the next message, hit x again. Repeat until all relevant messages are selected.
Perform an action, such as e to Archive them all. Or l to apply a label to them all.

If the action you applied didn’t move the message from the current view, they will still be selected. Hit * (shift + 8) and n to ‘select none’

The Interesting, but not Important

How long has it being hovering in your inbox for? Do you really need to read it right now? Archive it and search for it later when you have time/realise you needed to read it.

Hitting e on any message, from anywhere in your mailbox will Archive it.

Don’t Delete Anything

Unless you’re actually anywhere near to running out of space, why delete anything? (Apart from maybe emails from recruitment consultants or notification emails).

Chatting Whilst Doing Other Stuff

To start a new chat q + search for the contacts name + Enter.

If you complete the chat Esc to close and return focus to your mailbox.
If you want to leave the chat window open and deal with your mailbox, Shift + Esc and your mailbox will have focus.
Pressing Esc again will re-focus you back to your last active chat window.
Alternatively you can hit Cmd + , to focus the last chat window. This has the added benefit of cycling through all your open chat and compose windows, when continually pressed, allowing you to move between conversations.

What did I just press? What just happened?

Something unexpected just happened? Press z to undo the last action.

What keyboard shortcut can I use to do this?

Can’t quite remember the keyboard shortcut? Feel like you can probably achieve something with the keyboard instead of reaching for the trackpad? Shift + ? will bring up the keyboard shortcuts cheatsheet. I love this. It reminds me of the days when I was learning all of Resharpers keyboard shortcuts and used to have the cheat sheet taped to the desk in front of me.

That’s it – now go practice. It will take time, but I promise it will save you time and improve your life. Relatively speaking.

@dwynne

*Now you’ve got more time to help save the world instead of dealing with email!

“What distinguishes great leaders from average ones is their ability to perceive the emerging nature and rules of a game as they are playing it.” Brian Arthur

 Globalization, Technology and Information overload are making organizations, their environments and their activities more and more complex. For that reason, management science has turned toward complexity science to find appropriate models to help understand the challenges faced by organizations nowadays. An early conclusion of this approach is that managing complexity or managing in a complex environment requires specific sets of skills and tools.

I recently went to a seminar by Dave Snowden who has created a framework aimed at understanding the nature of contexts based on the relation between causes and effects, so appropriate tools are used and appropriate actions taken. This sensemaking framework is called the Cynefin framework. A Welsh word for a place where a being feels it ought to live. This blog is about what I have understood and gathered during that seminar.

The framework looks like a quadrant with two vertical sections, ‘ordered’ and ‘unordered’, and two domains per section, ‘simple’ and ‘complicated’ in ‘ordered’, and ‘complex’ and ‘chaotic’ in ‘unordered’. There is also a 5th domain in the center of the quadrant called ‘disordered’.

Cynefin Framework by Dave Snowden – cognitive-edge.com

What is the nature of my system’s context?

In the ‘simple’ domain, problems and solutions are known. There is a one-to-one relationship between cause and effect. The connection between system components is strong and centralized.

In the ‘complicated’ domain, problems and solutions are knowable. Here knowable simply means that deeper investigations are needed, it is not obvious. There is a one-to-many relationship between cause and effect. The connection between system components is strong and distributed.

In the ‘complex’ domain, problems or solutions are unknown. There is a many-to-many relationship between causes and effects. The relationship between causes and effects can only be identified with hindsight, it is called retrospective coherence. The connection between system components is weak and distributed.

‘Chaos’ is the realm of the unknowable and feedback loops. Nothing makes sense.

Situations that do not fit in any of the above domains because of a lack of information or are in transition go into the disorder domain.

The above characteristics of each domain are not always easy to identify so Dave Snowden recommends the use of narrative techniques to help determine the nature of the situation.

What do I do?

In the simple domain, the right approach is ‘sense the facts, categorize them and respond’. Best practices, processes and autocratic management work very well in that domain.

In the complicated domain, the decision path is ‘sense the facts, analyze them and respond’. This is the realm of experts, good practice and systems thinking. Finding the right solution(s) can be time consuming in the complicated domain.

In the complex domain, solutions can only emerge, therefore the right approach is to probe first and then analyze and respond. While probing, the key is to find desirable patterns and ways to consolidate or amplify them. Iterative approaches are adapted. Rules that facilitate emergence replace processes.

In chaos, the decision model is ‘act, sense, respond’. Nothing makes sense and just observing may have consequences therefore it is necessary to act until the situation moves to another domain.

If a situation is in the disorder domain, it suggests that it has to be broken down into constituents that can then be allocated to other domains.

Where do I want my system to be?

The Cynefin framework is not a categorization framework; systems or situations can overlap different domains and move from domains to others. In fact visualizing these movements thanks to the Cynefin framework helps understand changes within systems. Furthermore there is no domain deemed to be intrinsically a better place to be than the others. However depending on the type of system under study some domains might be more adapted than others.

For instance being in the simple domain is not necessarily, rather counter intuitively, the best place to be for an organization because the risk of falling into ‘chaos’ due to complacency is very high. It is typically what happens when a corporate, not sufficiently aware of its environment, suddenly starts losing consequent market share because of a competitor disruptive innovation.

Organizations more often find themselves in the complicated or complex domain, or both which is perfectly fine as long as the tools used are adapted to the domain. The most common pitfall in these domains is ‘entrained thinking’ i.e. re-applying what has worked before, without ensuring that the ontology remains the same. The risk is particularly strong in these domains because the shift from one to the other may not be obvious although they are fundamentally different, one is ordered and the other unordered.

Finally, although corporates do not want to be ‘in chaos’, some Management gurus advise that organizations should try to set themselves at the edge of chaos to favor innovation. It may be a good punctual technique but probably difficult to maintain in the long run.

Logically, as the rise of complexity in organizations increases, so does the need for sensemaking capabilities. Sensemaking is now taught by the MIT Sloan School of Management as one of the four leadership capabilities alongside relating, visioning and inventing. With the Cynefin framework, Dave Snowden provides us with a tool to help us take the first step toward ‘making sense’ by understanding the nature of situations.

I’m sorry Bootstrap but things just aren’t working out between us. I think we should have a break from each other.

To be honest, it’s not me, it’s you.

When we first met I was kind of infatuated. You were so opinionated and successful, persuasive even, so many of friends couldn’t stop talking about you. It was easy to fall head over heels and looking back I think I let my heart rule over my head.

With you everything felt so straightforward. Prototyping was quick and easy. We put admin screens together in a snap, smiling and laughing the whole time. I began to think there was nothing you couldn’t do, I started to let you lead me.

But then I looked around and realised you’d been seeing other people. It was a real shock.

Everyone was starting to think the same way and it was all because of you. You made such a compelling case for the way that things should be that everyone, myself included, just kind of went along with it. Looking back I realise now that you were too controlling. If a great design didn’t quite fit to the way you wanted to do things, I would just change it to make you happy. It was a lot easier.

Then I came to realise, that wasn’t what I wanted after all. I mean, the designers I work with really know what they’re doing. They’re the ones I should listen to first, and if you can’t help me in the way I need you to then I guess it’s time to move on.

I got on just fine before you came along, and I know that I can get back to how things used to be without you. I’m sure I’ll be happier out there on my own, CSS is a wide world and there’s new stuff to see all the time. I just think I’d rather make those discoveries for myself rather than have you colour them.

Don’t be sad, Bootstrap, I’m sure you’ll find someone else. Just be good to them, okay?

Photo: prorallypix, Creative Commons licenced.

How can we attract talented graduate designers? Can we be a serious contender in the design industry?

The traditional (or conventional) wisdom says the best place for graduates to learn their trades is at successful creative agencies or consultancies. But is it possible for tech start-ups to nurture design talent too?

I took a (very subjective and personal) look at pros and cons of options from a graduate’s point of view to see if joining the start-ups can be a viable option for them.

Pros and cons of established medium to large design agency or consultancy

Pros:

• There are many peers you can learn from – a team or teams of designers who compete and inspire each other (in theory, at least)

• There is a variety of work going on, giving you wider insight.

• Higher possibility of doing projects for large, well-known brands

• Longer term projects allow you deeper understanding of brands

• Design is at the heart of the company

• Large alumni network can help you in the future. Or add some kudos in your CV.

Cons:

• Smaller part / say / influence in a project (you will probably have to be very assertive to be noticed) to begin with

• Pay is often linked to a job title – okay for the first few years but it will become increasingly painful as you reach senior positions

• More office politics (just because there are more people…)

• Tendency to design for the peers and awards

• Less disruptive in general

Other characteristics:

• Many processes and templates to follow

• The projects tend to be longer

Pros and cons of tech start-ups for designers

Pros:

• Greater responsibility, influence and contribution as there are generally less people

• Early exposure to clients

• Get to see the end results quickly

• Multi disciplinary team environment for insights and inspiration

• Emphasis on great user experience

• Likes to be disruptive

Cons:

• As it tends to be small you have less peers to learn from. The worst case scenario is you could just get thrown into the deep end without any support.

• The projects tend to be for smaller clients. (Having said that, more and more large enterprise are seeking out start-ups for innovative solution as you can see from our client list)

• The projects tend to be shorter with less time for crafting design

• Less emphasis on design

Other characteristics:

• It’s usually small

• The projects tend to be shorter 

So, what can tech start-ups do?

1. Invest on support

You will need good senior designers who are willing to help others to begin with. If you do, then the small setting is actually a positive thing as graduates can get more personal, hands on attention.

Make sure training is provided and appropriate tools are available. There might not be many peers inside the company, but there are millions out there in some form of on- and offline communities. Join up.

2. Promote user experience

While visual design might not be at the heart of the company, the user experience should definitely be, alongside technology.

Visual design (including branding) is basically the physical manifestation of user experience. It can’t be ignored. Even if the technology works well, if it fails to communicate and be usable, no one will use it or identify with it. It’s not just about making things look pretty. It’s vital that you get the design right.

You also need to understand that design is something constantly evolving and improving. Let’s try not to call that jpeg “FINAL”…!*

*Dear graduate readers: You will soon encounter a filename that ends with “FINAL FINAL FINAL” or “NEW NEW NEW” when you start working. Someone has obviously been very optimistic.

3. Be disruptive and cutting edge (and fun)

This is the biggest advantage start-ups have over bigger, more established firms. You are more agile and flexible, and you can be more disruptive.

Any designers can make difference, create something new from day one. Surely that is very motivating.

4. Inspire

Working within a multidisciplinary team can inspire designers in a different way from a team of designers. It is not about designs for designs sake. It’s the art of looking sideways in a sense.

In the bigger firms, especially those that operate with a waterfall methodology, sometimes you don’t even get a single opportunity to talk to a developer during a project.

Start-ups should create an environment that encourages all the team members to communicate – if you are running in agile that incorporates UX and design properly (If you’re interested in how to do this, here is my previous blog: Agile Survival Guide for Designers), then that should happen naturally.

Are you a graduate?

There is a lot happening with design in tech start-ups right now. It feels a lot like 1960s was for graphic design. There are opportunities to innovate and experiment. While I agree that there are loads you can learn from being surrounded by designers, surrounded by developers and other disciplines enables you to achieve something equally exciting, and potentially new and groundbreaking.

Maybe you need a bit of entrepreneurial spirit and drive to improve. And a love of creating something you can be proud of. It’s more about what you create and do, rather than what other people think you do.

I am not saying all the tech start-ups are great place for a budding designer. But as long as they hit the four points I listed above, I think they can be a great place to be. Maybe more than what the traditional wisdom says. If you are a graduate / budding designer and interested in working with us, please give us a shout at hello@red-badger.com.

(If you’re interested in seeing the Lego plant pot being made, here is the stop motion animation I made while building it. And it’s inspired by Being Geek Chic blog.)

In March, I went to see Dan Pink discussing the “The Science of Buoyancy” at one of the consistently excellent Intelligence² debates.  The subject of buoyancy is one that Dan has explored in his recently released book, “To Sell Is Human”.  A text that uses selling, ultimately as an example to describe human nature.

Dan describes buoyancy as a quality that combines grittiness of spirit and sunniness of outlook, and this will form the basis of my post. I’m going to highlight the points that Dan covered in this area, and conclude with some considerations for how you might also help to keep your employees “buoyant”.

We Are All In Sales

Dan Pink’s previous book “Drive”, raised some points, asking how motivation works in a sales environment. The response to “Drive” got Dan Pink interested in Sales and “To Sell Is Human” is the result of his research. 1 in 9 people are in sales jobs in America but Dan argues that we are all in sales, despite the role of a salesman often having a negative stigma in our mind (We’ve often seen salesman portrayed as slimey, manipulative creeps in movies – see apt screenshot from Napoleon Dynamite!). 

Research has shown that on average, 41% of our time is spent on what he calls non-sales selling. By this he means, convincing, persuading and influencing others to do things we want them to. This opens us all up to the environment and/or response that salesmen are used to and in an adapting digital world where information is at our fingertips, we have also switched from a “buyer beware” market, to a “seller beware” market. In other words, a salesman no longer has the benefit of having the advantage of knowledge that the buyer doesn’t have. As a result, Dan Pink recommends a change in the foundational qualities of selling, with ABC (“Always Be Closing”) taking on new meaning to now represent “Attunement, Buoyancy and Clarity”. And as we’re all salesmen, whether we like it or not, this affects us all.

Attunement is to bring things into harmony with individuals, groups and contexts. i.e. Can you see the world from someone else’s point of view rather than your own? Having a sense of power reduces your ability to have a sense of perspective. So reducing your feelings of power can improve your acute perspective abilities. It is more analytical than empathy, looking at things such as strategic mimicry and practising to be an ambivert. Extraverts rarely make the best salesman and a buyer is now more likely to buy from someone they like.

Clarity is all about making sense of murky situations. It’s providing clarity to your prospect by asking certain irrational questions in a structured way, curating your questions and information well to make it accessible. It’s also not necessarily trying to offer to fix problems that your prospects already know they have, but rather finding problems they did not know they had.

If you want to find out more about Attunement, Clarity and the rest of the contents of “To Sell Is Human” I would recommend you buy it. It’s an excellent read. Now to discuss Buoyancy…

Buoyancy

Chapter 5 of the book and Dan’s talk at Intelligence² are focused on buoyancy. The line of research takes learnings from social psychology on how to bounce back from rejection. Dan uses sales as an example to illustrate his research as it is a role in life that has a great deal of rejection to deal with. However, the same principles can also be applied to everyday life, when you are rejected in the process of trying to convince someone to do something. Dan quotes Norman Hall’s phrase – “Every day you get up and face an ocean of rejection”. Buoyancy is how you stay afloat on that “ocean of rejection” that Hall talks about.

The research on buoyancy is split into what you do before, during and after an encounter.

Before an Encounter

Dan bases some of his research on what to do before you enter an encounter on Delores Albarricin’s work. Self help gurus will often tell you to think positive, affirmative, be bullish. Say to yourself “I can do this!”. The research actually shows that this is not the best approach. Phrases that ask a question such as “Can I do this?” rather than “I can do this” are far more effective.

Albarricin calls this “Interrogative Self-Talk”. Questions by their very nature illicit an active response whether you’re talking to yourself or to someone else. It prepares you for the encounter and forces you to rehearse. You prepare more thoroughly and are thus stronger than the more bullish declarative self-talk despite the latter sounding stronger.

During an Encounter

During an Encounter is all about “Positivity”. Someone is far more likely to be influenced by someone with a positive affect even if the subject matter is unchanged. So how do you make sure you have a positive affect?

Barbara Fredrickson’s research shows that positive emotions open us up. They broaden our actions, open awareness to a wider range of thoughts and make us more receptive and creative. Fredrickson worked with a Brazilian mathematician, Marcial Losada, to help her discover that affectiveness and flourishing occur when positive emotions outway negative emotions at a tipping point of roughly 3:1. A ratio of 2:1 is no different to 1:1 or entirely negative emotions.

To monitor your positivity ratios you can start by visiting Barbara Fredrickson’s website www.positivityratio.com. As well as this, there are certain positive emotions you should try to be more conscious of – joy, gratitude, serenity, interest, hope, pride, amusement, inspiration, awe and love. If you select a couple (E.g. Take ten minutes to think about three things you are grateful for) and look for ways to display them, it can have a profound effect on your positive affect and thus enable you to better influence people during encounters.

Note: Check out Fredrickson’s book for more in-depth insights into her research.

After an Encounter

The best predictor of success is how you explain failure. Martin Seligman, a professor of psychology at the University of Pennsylvania has demonstrated through research that Explanatory Style in explaining negative events has an impact on our buoyancy. The best way to do this is to ask yourself three questions and to construct an answer “no” to each. The three questions are: Is this personal? Is this pervasive? Is this permanent? 

So, if you have just lost a bit of business in a pitch what might you ask yourself?

• Is this personal? i.e. Was there something wrong with the way I presented? Example Answer: No. The presentation could have been better, but the company just wasn’t ready to buy just yet.
• Is this pervasive? i.e. Is everyone I visit going to reject this particular pitch? Example Answer: No. This particular company just didn’t have the vision to see the value. Another company probably will.
• Is this permanent? i.e. Have I completely lost my skill for selling? Example Answer: No. I just had a bad day. I was tired. The next will be much better.

The more you explain bad events as temporary, specific and external the more likely you are to persist. This is an analytical way of improving your buoyancy and thus improving your likelihood at being a better salesman in the future. This is not to say that you shouldn’t look for holes in your presentation, take learnings from the feedback from the client and try to improve your pitch for the next time. It is not delusional. It is learned optimism.

If you go too far on the side of positivity (above and 11:1 positivity ratio to be precise), you might consider yourself to be in la la land! It is important not to be in denial. Using some of the methods above will help you get the balance right between levity and gravity to reach the optimum buoyancy. If you de-catastrophy things in a methodical way, it can make you more effective in sales and more effective in life. 

The lovely term coined by Seligman is “Optimism with its Eyes Open”. Perhaps we should all start practising it.

Helping your employees stay buoyant

I haven’t yet tested the theories set out in the book for my own personal well being. However, as a business owner I am interested in not only my own well being in doing my job, but also the well being of my employees.

Feedback

One of the main reasons I like to attend talks such as Intelligence² is that you get to interact directly with the likes of Dan Pink to see if he can provide you with some insights specific to your questions. Being at the talk gave me the opportunity to ask how you stay buoyant if you lose out in a competitive environment (E.g. a pitch for some business against other businesses) but you are ignorant as to why another pitch may have been chosen above yours. Dan’s response was that this is a feedback problem, not a buoyancy problem. This question raised an interesting topic about feedback both from your client prospects but also internally in an organisation and how it can influence buoyancy.

A common problem is that people in the workplace don’t necessarily have a sense of how well they’re doing. Research in the field of talent by Teresa Amabile, professor at harvard business school, shows that employees are most happy when they feel like they are making progress in meaningful work. But making progress is dependant on rich, regular, feedback.

For feedback, an annual performance review just doesn’t cut it. We don’t do performance reviews at Red Badger or any performance linked bonus but rather a quarterly one-to-one meeting with each employee that is informal but basically provides encouragement by telling them what they are doing well, discusses where they could improve and also asks how we can improve to help them and what their ambitions are (what they want to get involved in etc…). We also supplement this with a more agile, informal but constant programme of feedback that is project specific. It’s basic common sense but something that is all too often, easily overlooked.

For your own buoyancy when trying to sell to prospects, it is equally important to demand as much feedback from them as possible so you can implement the above factors, learn where you went wrong, iteratively improve and stay buoyant.

Teams

So what is the right balance inside a team? Should you have a team of all optimists? What about grouping people who work well together historically? 

Brian Uzzi has done some interesting research on teams and came to the conclusion that having a team of people who have always worked together doesn’t produce the best results. Equally, having a team of people that have never worked together doesn’t either. The most optimum teams are a mix of people that have worked together a lot and some who haven’t worked together. This keeps the team both dynamic and coherent, producing the best results. 

Whether you want to mix the team up to include a 3:1 ratio of optimists to pessimists I don’t know. This sounds like an incredible challenge with no quantifiable research showing whether it will provide any benefit. But it’s some food for thought.

Conclusion

This doesn’t feel like the answer to all things. These techniques are not going to help you win business alone. You’ll need to iteratively improve your ways of working (using feedback and experience to help you), pitches need to be on point and appealing to the prospects, opportunities need to be qualified properly and all of the other basic practices of business development need to be in place. However, a pitch is also very creative. It paints a vision. Practicing the above techniques can put you in the right frame of mind to make you more creative, helping to build a better pitch but also help you have more influence over those you are trying to persuade. Inside a company, the precursor to this is to provide better, more constant feedback, change up teams, keep things new and different for your staff and present them with new challenges and that will give them the tools to manage their own buoyancy.

Outside of business, these techniques may also allow you to lead a life with a greater sense of fulfilment. 

Time to start working on the interrogative self-talk, positivity ratios and explanatory style…

So as day one closed we were ready to get our heads down into hacking some code and try to produce something we could release.  We broke up the responsibilities for UX, creative and technical tasks to the relevant roles.  As I mentioned in day one we had chosen a technical set that was mostly familiar.

A problem did arise in the fact we had decided to go with Backbone.js and Marionette, not a problem with the framework itself but the fact we were not so familiar with its inner workings.  I have to say that it wasn’t the best choice to go down with for the event i.e. a single page application route using a technology we had little experience with at the time.  

It was challenging but we did make some great progress in the morning.  Authentication was up and running with Facebook along with the ability to post content.  Haro did some sterling work in getting MapBox integrated into the application to display hotel details in around the Las Vegas area.  The hotel data itself was to be added manually (I had collated the hotel details the night before in a Google Spreadsheet) but obviously this wasn’t the most ideal solution but for now it would suffice.

As lunchtime came about we decided to get the team together and go to the local pub for some well deserved fish and chips.  After a few pints and a bit of banter with team we got back to it and continued hammering out as much as we could.  Sari got her magic wand out and managed to come up with some branding in no time at all, working with Samera the UX was also really taking shape.

All in all were coming to the end of the afternoon and it was apparent as much as we tried we were not going to get a completed application out of the door this time.  This was mainly due to trying to create a one page application with new technologies as previously mentioned.  I would safely predict that if we had gone down a standard web application with the technologies we have used many many times before in projects we may have got it out of the door.  Having said that we now have good knowledge of Backbone.js and Marionette to allow us to judge when or when not to use it in future projects.

The event itself to me was a success and I have mostly gotten what I wanted to really jump start the application to get something delivered.  The biggest downside I had after the event was losing the vision of delivering a true Minimum Viable Product.  This is something I need to work on for future events and any ideas I want to deliver in the future, “it’s all about delivery” and at the moment the phrase “close but no cigar” comes to mind.  

It really rams home what / why people say single member teams rarely succeed due to not ever ending up shipping their products.  An example of integrating yelp! really steered me off track and I have ended up adding more features that I could of left out to deliver grazr earlier.

 What I need to do right now is literally get the last bits of functionality delivered and delivered fast, I am in what I would call a “lingering phase” and if left to linger too long grazr will rot away.  It needs to be out there for the world to see, it is the worst position to be in as I can’t even say “I tried and failed” as no users have even tried the product at the moment it is just that “I tried”.

I intend to follow this up next week with the launch of grazr, and hopefully some statistics on what happens with users I send it out too.

If you are interested in one page applications the guys over at airbnb are doing some very interesting things with Backbone.js to allow client and server side rendering of templates for single page applications (see blog post here).

The full technology stack we ended up using was as follows:

• Node.js
• Backbone.js
• Marionette
• MongoDB
• Heroku
• Jade Templates
• Grunt
• LESS
• Bootstrap

Watch this space (no really I mean it)…. 

If one should do a word cloud out of the Agile literature one word that would be big and bold is ‘pragmatic’. It is the essence of Agility, which is a response to prescriptive methodologies elaborated far from the reality of the field. However pragmatism, extracting intelligent practices from experience, has a limit: these practices are contextual. For this reason some Agile practitioners and thought leaders would like to see one or more theories underlying Agile practices. Not that there is a need to justify Agile, countless success stories are sufficient, but because with theories comes understanding and the ability to apply them differently in different environments. 

Two related bodies of knowledge, System thinking and Complexity sciences are the main candidates for providing theories behind the success of Agility. In this blog I will give an overview of Systems thinking as taught by Russel Ackoff, A.K.A. the Dean of Systems Thinking, and its applications at the level of organisations. There are other schools of Systems Thinking but I have chosen to present the work of Russel Ackoff because firstly he was the first to apply Systems Thinking to Management,  and secondly the more recent schools of Systems Thinking tend to have a ‘new age’ aspect certainly very valuable at the individual level but not necessarily relevant when it comes to Management.

Since Descartes the most common approach to understand systems is to break them down in smaller parts easier to apprehend. This is the analytic approach. While this approach has proven itself valuable, it has an inherent limitation: it ignores the properties of the whole that the parts do not have. It is also argued that the analytic approach produces knowledge (how?) not understanding (why?). Systems thinking is the opposite but nonetheless complementary approach, a holistic approach. A system is a view of the world, composed of at least two interacting parts, which has properties the parts do not have. Different classifications of systems exist, Russell Ackoff proposes the following one based on choice:

• if parts and system as a whole do not display choices it is a mechanical system, an example is a car.

• If some parts do display choices but not the whole then it is an ecological system, an example is Nature.

• If parts do not display choices while the whole does, it is an animate (relating to animal life) system, an example is Humans. These systems are also often called organic systems but it is a slight misuse of the word as plants are organisms that do not display choice.

• if both parts and the whole do display choices it is a social system, an example is an organisation.

For long organisations have been studied and run like mechanical systems (taylorism) for profit generation and then like organic systems aiming for growth, profit becoming a mean. This model still prevails. In both cases parts or subsystems are mechanical, they do not display choice. This is not deliberate but a consequence of the analytic mindset and its underlying assumption that parts of a whole are independent. It is not even a bad idea, humanism put aside, in an environment where members of an organisation are expendable and where there are more opportunities for growth and profit than the organisation can handle.

However it is not the environment of organisations nowadays, these models are obsolete and system thinkers see this mismatch between model and reality has the source of many organisation’s issues. Typically mechanical parts perfectly fit together. Just like Sales and IT ? Not really.

Indeed when both the parts of a system and the system itself can display choices, the complexity of the system raises drastically. This is when systems thinking really comes into play. If analytic thinking is the reason for many system failures, then analytic thinking should not be used to address these failures. As Einstein stated: “We can’t solve problems by using the same kind of thinking we used when we created them.” The answer is systems thinking, which is a synthetic rather than analytic process and explained as follow by Russel Ackoff:

“1) Identify the whole of which the system to be explained is a part 

2) Explain the behavior or properties of the containing system 

3) Dis-aggregate the containing system so as to identify the role or function within it of the system to be explained.”

Stage 3 implies the study of the interactions of the system under study with the other sub-systems. This is a key concept of systems thinking. The interactions between the parts of a system matter much more than the individual action of its parts because its emergent properties derive from these interactions. Emergent properties are properties of the system but not of its parts. For instance, consciousness is an emergent property of the brain but a neuron on its own is not conscious. In other words, a system is not the sum of its parts but the product of their interactions. Systems thinkers do not solve problems with solutions likely to create other problems but dissolve problems by redesigning interactions and systems. “Design is to systems thinking what Research is to analytic thinking” says Russel Ackoff.

Based on this approach, Russel Ackoff developed a new kind of planning called Interactive planning, which is  based on the idea that the future of organisations depends as much on the actions of organisations in their environment than on the effects of environment upon organisations. Interactive planning has two phases: idealization and realization. Idealization consists of identifying two elements, the ‘mess’ and an ‘idealized design’. Systems need to adapt to their environment to survive, therefore systems contain the seed of their own destruction. Should they freeze in a changing environment, they would die. Formulating the “mess” is about finding this seed. This seed is likely to be not only one problem but a set of problems. Problems rarely appear in isolation. Once the mess is formulated, systems thinkers know what not to do, what they want to avoid. However, effective management is directed at what one wants, not avoiding what one does not want, thus the need for an “idealized design”. It consists of imagining that the systems you want to improve has been destroyed and that you can redesign it with only three constraints:

1) it has to be technologically feasible,

2) operationally viable,

3) able to continuously learn and adapt.

The realization phase is about filling the gap, getting closer and closer to the idealized design. Interactive planning is continuous and iterative. Working backward from where you want to be to where you are, reduces the number of variables to be considered, it is the the best way to ‘beat the system’. (e.g. if Wimbledon starts with 65 players, how many games will be played?…think about it…If you took the problem from the front you are still searching, if you took the problem backward:1 winner, thus 64 losers, thus 64 games).

To endeavor that kind of transformation in organisations requires a new kind of leaders. Leaders aware that organisations are social systems. Leaders who take into consideration not only the objectives of their organisation but also those of its employees and environment. Leaders who are creative because structural issues are not dissolved with a quick fix. Leaders who have sufficient courage and influence to redesign organisations. Leaders who manage the interactions between subordinate teams or employees and not their actions. Leaders who encourage and facilitate an increase in competences at the level of both employees and organisation in a win-win situation.

This is obviously not a demonstration that Systems thinking underlies all Agile practices. Nonetheless we can recognize in Systems thinking many Agile key concepts such as iteration, continuous planning, importance of people, non-controlling leader and importance of interactions, to name a few. Hence, it is not pushing inductive reasoning too far to assume that what Russel Ackoff showed at the level of an organisation is also true at the level of a team. Also I am not sure if approaching problems backward is directly related to systems thinking although encouraged by Russel Ackoff but it seems somehow related to TDD. 

Now if you wish to appreciate the power of theories and see systems thinking applied to other fields than management, for instance the work of Marvin Minsky on cognition is fascinating.

Over the last few months of last year we have been crafting away and exploring many new exciting frameworks and technologies.  So many to mention…… but our core stack as of late has mostly consisted of node.js.  As people of node.js know the npm package manager that is bundled is a fantastic tool to resolve dependencies for the project in question.

With this in mind myself and Stu have been busy hard at work with a large client in the finance sector and looked to ‘resolve’ our client side dependencies in an equivalent manner.  We had a look around at some of the options and for our use case the same two kept cropping up.

Bower

The folks over at the Twitter Engineering team have been hard at work again and built Bower as a client-side package manager.  It allows you to resolve your dependencies via a component.json file and install the relevant git paths as required.  This approach is at a lower level than other alternatives it doesn’t limit you to any transports, ultimately you decide how you wish to deliver your packages client side.

The great thing is that you can just point to git paths and you are away without dependencies on other people to own and manage the updates of packages that exist.  From the experience we had working with Jam.js I suppose it might also be fair to say that it would have taken less “tinkering time” to get the transport with require.js working client side along side some out of date package versions we couldn’t update.

Jam.js

Jam.js is  a package manager with a different spin in that it will install packages from a core jam.js package repository, resolve dependencies and using AMD / require.js to configure transporting your packages to the client.  The configuration for the packages are defined and are stored within your standard package.json file.

There is a down side that is quite commonly raised with the fact you upload a package to a repository separated away from github.  Once a package is uploaded the owner is the only person in which they can update it (unless the owner adds other users).  There is an option to setup your own repository and have jam search the core repository in addition to the one you create, to me this is a big limitation in regards to package management.  

Package management should, in my opinion, be sourced from one place in that it is concise, self managing, effective to install and configured to deliver to the client in the best possible manner.  Jam.js for me meets three out of four in this criteria.

I have started a pull request to try and help with the update of packages via pull requests.  The idea is taken from github / git and allowing users to submit pull requests to repositories.  The initial implementation of this feature with a description and can be found at:  https://github.com/caolan/jam/issues/128

In Summary

We made the choice of Jam.js for out project as it suited our needs to have require.js be configured and setup up as the transport to the client (once we cracked some of the require.js path configuration).  All you need to do is quite naturally add your jam dependencies within your package.json and type on the command line jam install just like npm install and away you go.  

It is not to say we will never use Bower as it does it’s job well and the fact it is lower level may suit other projects where transport via AMD is not a preference.  We may also switch if we find the package management and the central package repository not being kept up to date by community, this is where Jam.js can and may fall down.

So it has been a little while since I last talked about the Firestarter event that I proposed and successfully ran on the 31st January, finally I have managed to get around to giving you a cheeky flavour of what it was like along with what did and didn’t appear to work over the jam-packed two days.

So day one, named “from conception to canvas”.  The fridge was stocked, the beer was ready and everyone was wondering how and what the heck we were going to be doing.  I first did a small presentation to everyone explaining firstly what the scheme offers (see previous post for more information) and what was going to happen over the next two days.  Coming into the event I already had a strong idea of what product / application I wanted to produce.

With this in mind part of the presentation included me basically performing an elevator pitch to everyone…

The idea that I wanted to “ignite” (had to get a pun in there somewhere) using the Firestarter scheme was something that I came up with in the music festival and social media space.  The idea was formed from a need that I had when booking my recent tickets for the Electric Daisy Carnival in Las Vegas on the 21st, 22nd and 23rd June 2013.  Looking at Facebook and the buzz generally happening around events I felt there was a strong need for more focussed application in this area.

Allowing people to easily connect to others via hotels where other people were staying, pre-parties, car shares, check-ins and a whole gamut of other features that could form a great social platform for festival goers. 

The application itself I put forward should cater for the lifecycle of a music festival.  The lifecycle being “before”, “during” and “after” phases of a music festival.  I did have some strong ideas but wanted to get everyone’s thoughts and ideas without being to specific in what the application could become (no idea is ever a bad idea).

So at this point we are all on the same page of what the Firestarter scheme can provide the team if they had a product idea they wanted to develop.   Alongside this hopefully everyone now had a basic idea of the type of application we were going to hopefully build over the two days.

The first job we got to work on was to grab the old faithful post-it notes and sharpies to produce all the features we think could be a possible for each of the phases of a music festival and indeed what Grazr could become as a fully fledged application.  We (very pleasingly) underestimated the amount of ideas and we soon found ourselves having to find a new home on an office desk behind us instead of the wall brimming with fantastic ideas.  We have such a dynamic team in the office, those who were around and had some spare time just got involved with the day alongside those I had “officially” booked resource for.  

The next step was to form the features that should become the “Minimum Viable Backlog” for the MVP.  We decided to produce the application specifically for the Electric Daisy Carnival event only.  This would allow us to test a small amount of users for the application (fail fast, fail cheaply, one of the Red Badger mantras) adding more events as we learn what users actual want (or don’t).  

To get to the specific features we wanted to tackle, everyone had a discussion and voted on the features / post-its that we thought would be most important to the user and viable to get completed in the time frame we had.  

Building these features would allow us to gauge if there is indeed a need for Grazr as an application at all.  Towards mid-afternoon / the end of the day we had produced a minimum viable backlog and had a decent idea on what we needed to produce from creative / branding to UX for the features decided on.  

The technical badgers got started producing a basic web front end using “bootstrap” as a basic framework for layout.  We all have a lot of experience with node.js from the awesome projects we have been working on here at Red Badger.  I did throw a bit of a spanner in the works by adding Backbone and Marionette into the mix (more on that in day two), but hey we all love a challenge so why not.  For a full list of tech that we use here at Red Badger checkout our tech page, it really gives a great insight to the skills we have on board here.

The combination of node.js and other tools such as bootstrap allowed us to get the basics up and running quickly whilst the UX and branding from Sari would start to take shape.  Day one came to a close and after copious amounts of sugar intake and pizza we were ready for day two…. “from canvas to conception” (the hard part, actually delivering something!).

I can safely say that day one felt like we were on the right track, UX under-way, name sorted, domain name registered along with technology chosen and a focussed set of features.  The summary of our hard work and efforts would be as follows:

Name:
Grazr - ”Experience festivals. socially.”

“Minimum Viable” Backlog:

• As a user I want to be able to login via Facebook and enter which hotel I am staying at so that I can see connect with people in my hotel.
• As a user I want to be able to post a message so that I can chat and connect with others going to the event.
• As a user I want to be able to tag a hotel within my message so that I can connect with other people staying in local hotels.
• As a user I want to be able to find hotels so that I can see where other people are staying during a festival along with messages and what is going on.

UX:
Started based on the backlog produced.

Application Delivery:
Started basic set-up of application architecture.