Hearty congratulations are due to Parkinson’s UK, which we helped rename and rebrand a little over a year or so ago. They have just won Charity of the Year (more than a million income) at the annual Charity Times awards. The judges said: “With a new brand and a new strategy, many of the ambitious goals set, especially in fundraising and raising awareness, have already been achieved or surpassed, transforming the charity with outstanding results.”

So well done all round! We know how hard you worked. You deserve it.

Photo credit: bweisner

I love words, me. The more you know the less you know and my interpretation of a word is, well, just that.

I was reminded of this several times over the last few months as we have been working with clients turning to their brands to help them met the challenges of ambitious business strategies, reposition themselves and get the attention (and funding) they deserve, especially in the third sector.

What I think a word or phrase means may be the complete opposite of someone else’s understanding. Take ‘stand by’ for example. In research groups recently some participants thought ‘stand by’ was a good thing: embracing someone, supporting them, acting as their confidant, being on their side, being warm. Others saw it as passive, literally standing at the side, not alongside, waiting, not being active, being cold.

Coming up with the words that make up brand models is no mean feat, especially when we are confronted by the usual professional, innovative, passionate malarkey. But there is a change in the air. A lot of folk now appreciate that these are hygiene factors of any business, the things often written into or implied in job specifications and employment contracts.

There are a couple of other problems with the hygiene words. First, they are often used to try and overcome a culture which doesn’t exist, or does exist, but doesn’t shine. Worse, they are an outright admittance that there is something wrong in the organisation. How many brands have ‘working together’ in their model?

And secondly, they are aren’t quantifiable. One person’s professional is another’s less than professional. It’s all about appropriateness and if brand models are to guide behaviours and ultimately customer experience then the usual suspects need to be shot and much more inspiring, interesting ones brought into play.

The new words on the block are interesting, adding to the distinctiveness of the brand and generating real excitement beyond the branding team and the board.

Stop being professional, I say, and start being interesting.

Photo credit: Chris Blakeley

A few days ago, there was an interesting article in The American comparing Steve Jobs to Thomas Edison. The gist is that Jobs’ legacy doesn’t measure up to Edison’s – mainly because people are generally unaware of how much Edison achieved in his lifetime (it was a lot).

Putting to one side the fact we’re not comparing apples with apples, if you’ll pardon the pun, I think we’re still a long way from realising the extent of Jobs’ impact. You can see it far, far beyond Apple’s product line. By setting the bar so high, he’s forced the entire technology market to change the way they design their products over the past 10 years. I see Jobs’ legacy in every phone, every computer, every tablet – anything technological which has an interface. Products formally seen as ‘good’ are now mercilessly mocked, and don’t last long.

Our expectations have gone up. Through the roof.

But the true legacy reaches much further than the technology market. It can be seen in the way we design everything – from physical products, to services, to transport systems, to web sites. We want everything to work better, no exceptions, no excuses.

Of course there have always been companies with a strong customer service record. But given how technology in general, and the web in particular, weaves its way through every aspect of our lives, having such a fantastic cheerleader in the technology world for putting the user experience first – and actually showing how it should be done, rather than just talking about it – has benefitted everyone and everything.

Our ambition for every project reflects this march of progress. We’re always thinking about the end user, whether it’s a company employee, citizen, customer or student. Whether we’re designing services, products, websites, posters, or anything else. All good companies and agencies do this now. And I think Steve Jobs and his colleagues can take a lot of the credit for this, whether directly or indirectly.

Thanks Steve!

(Thanks also to Jonathan Mak for the Apple / Jobs logo)

A few weeks ago at The Team, inspired by the Atlassian model of FedEx days which we have have successfully employed before, we managed to make some time for the development team to spend the day away from the office to work on something for themselves. No clients and no managers, just our own requirements and some time to work in new ways together. It yielded some valuable results.

The notion of creating value from activities like this is not immediately obvious to all, but there is value to be found in many different places when working together on a project like this. I’ll try to mention a few of them here as a kind of a primer for anyone who is looking to arrange a similar day of their own. That might be useful when you need to convince the folks at work who need to look carefully at things like utilisation, opportunity cost and project resourcing.

When arguing for the value of this kind of activity, it can be difficult to protect the time needed to make it really useful and valuable. I’d suggest that this is actually a vital activity in helping a development team to remain fulfilled, motivated, efficient and sharp.

This was a modest hack day. First of all it was just a single day, while I would have preferred to have it last for two. We had just the time that we could stay awake and productive for one day to plan, design, develop and deploy our project. Also, while I would have liked to involve a wider team in order to profit from a range of disciplines and specialisms, it was just our small development team who could be spared for one precious day. Nieman Journalism Lab recently wrote about the benefits of similar hack days at NPR which involve wider disciplines and dubbed them Serendipity Days. I rather like that.

We cheated a little. We had something in mind that we wanted to build. A simple need that we felt could be basically fulfilled with modest amount of development. That idea, we labelled Scamp Cat. So named as a bit of a hat-tip to Sprite Cow, a little side project by Jake Archibald which we each had some fleeting involvement in, and also just because we needed a way to refer to this thing, and Scamp Cat made us giggle. We are easily amused. Having something in mind to build, and having the opportunity to talk to potential users of this application ahead of time was a great way to get started quickly on the day. We already had an idea of the high-level requirements, and had identified a likely ‘customer’.

Having a customer was my first tactic for justifying the day to my boss and to my Financial Director. We would be making something that has an application right here at work on a regular basis. Yes, there are tools around that provide a similar service, but none quite satisfied the needs of are colleagues in the EA and Design departments. Building this thing would be of value to us right here at work.

When I presented what we built back to my elders and betters, I was eager to point out that Scamp Cat, the most tangible product of the day, was perhaps the least valuable output. More important to me, are the various processes and conventions that we used during the day, and the insights into some new technologies and conventions we gained. For instance, during the day, we made use of Git Flow, a code versioning model in Git. This served us tremendously well and resulted in very few code conflicts and high confidence in our small but active codebase over the day. We now use Git Flow on all of our active client projects. Win!

We also started tuning our approach to provisioning our infrastructure using Puppet and normalising on virtualised development environments with Vagrant. More Win! In addition there were a number of small but useful pieces of reusable code which came from the project. These got rolled into our set of code snippets and plugins which form part of our project bootstrapping suite. Winning again!

My favourite part of the day was the fantastic sense of team spirit which was evident. We set ourselves a tough challenge, and together we knuckled down and met that challenge. Creating an opportunity for a team to pull together away from outside influences and commitments develops some great trust and mutual respect, which is perhaps the most valuable output of all.

But for those wanting to see an actual thing as an output from our day, Scamp Cat has found a little home on the Web, and is functional enough to use. Just. It can be used to upload, or reference, an image and add annotations to that image. The resulting annotated “scamp” can be freely shared via a public URL. There are similar products out there already, but none quite ht the spot for us.

We’ve already got some great feedback and are planning several iterations to evolve the functionality.

This post was originally posted on hawksworx.com. More photos from the day on Flickr

Following two days of constant sirens around London, when I saw the riot vans racing past my street, I assumed looting had finally broken out in my south-east London suburb. I set up a Tweetdeck column to follow the local story and quickly saw there had been a stabbing, sports stores emptied, windows smashed and it had all “kicked-off” just around the corner down the main street. I regularly shop there and wondered why our community was smashing up our community. Opportunity aside, what had sparked this group of locals to come together and act like this?

That got me thinking about what happened in the London riots (most of which seemed to be just opportunistic looting and stealing) and whether this herd behaviour could spread and if there were any parallels in organisations. Read on and you’ll see how I made this connection. During the riots I saw a couple of things:

1. People acting criminally by taking things they perceived to be denied.

Does this happen within organisations?  Is it the same as absenteeism, dodgy expense claims, taking stationery, and time on Facebook?  Are these things deemed acceptable behaviour because everyone does it and they feel entitled to get something back at some stage?

2. People defiantly rejecting those who had taken something away and trying to reclaim or start a community.

Employees can often stand up for something they all strongly believe in with strikes, walk-outs and peer groups. Mostly these communities develop in a ‘them against us’ culture. It’s seems far less common that a group of strangers will come together around a positive cause.  What surfaced post-riot were teams and communities of people who decided to take action. Broom armies turned up to clean up the mess left by others. A call to action was put on Twitter (#riotcleanup), people met, worked together and reclaimed their community and local businesses responded with rewards of free food and drinks. That proved that it was indeed possible to bring complete strangers together in a sense of unity around a common goal.  Social media has been talked about within organisations for years now but aren’t broom armies the opportunity that exists?

• Create a call to action that resonates with a diverse group of people
• Empower them to meet up and connect in their own way
• Allow them to work together creating their own rules; and
• Reward them for their efforts.

Aside from witnessing, first-hand, the criminally-motivated groups followed quickly by the positive-change groups in action, I observed some other great things:

• Deep discussion and reflection
  • Reflection by everyone on deeper societal issues not frequently discussed
  • Unfortunate segregation into ‘them and us’ with an assumption that us is right
  • Ill-considered opinions and judgement borne out of lack of facts, ignorance of differing values or ethnic backgrounds
• A return to the value of values
  • Almost everyone drew upon their personal values in sharing their opinions
  • People united with those who shared similar values – read: those who thought they had a proper upbringing vs. everyone else
  • It demonstrated how important our values are in guiding our actions
• Greater communication
  • People talked a lot, even with strangers, about something that was very important to them and their lives; and
  • Every taxi driver asked me where I lived and was I affected.  Since when do strangers care for my suburb or safety?  This is a good thing.

I didn’t consider that the London riots, a turning point for the UK, would have any parallels for our business, but when I stood back, listened, watched and contributed it was obvious there was a lot to learn. I can guarantee your business is thinking about how to create communities, how to improve collaboration, the importance of values and improved communication. There’s a fundamental shift taking place in society as now, people are able to communicate with strangers, build trust, take action and even change laws while sitting in front of their computers and maintaining their anonymity. Perhaps it’s time to allow employees to do the same?

Finally, here is one of the most heartening images of positive action from Peckham, South London. The residents created a ‘wall of love” on the boards of a smashed local business window with Post-it notes of support for their community. The council has decided to preserve it for good at the local library.

This post was originally posted on blacksmith.co.nz

One of the reasons Apple is successful is their model of vertical integration. From hardware to software to distribution (both off and online) Apple has sought to own and control as much of the user experience as possible as they believe that it is them, and not any other company, that is best placed to provide the optimum experience for the user.

Google’s purchase of mobile handset maker Motorola got me thinking about what Apple might do next.

The iPhone has clearly changed the mobile market, it’s not necessary to go over the details of this here, it’s been well documented elsewhere, but there is still a glaring weakness in the user experience of mobile devices. The mobile network.

The handset may look and feel great, have a good browser and offer lots of functionality, especially via apps but this can all become useless if the phone cannot get a signal or the transfer rate is too slow. Mobile voice networks have been around for decades now, although data for less, and it is remarkable how patchy a solid 3G signal is. Even a full strength 3G signal feels like dial-up compared to the 10Mb or 20Mb broadband lines that are common at home. When it comes to mobile on transport (which if you think about it are two domains that should fit together very well) the situation is even worse, no signal at all on the Tube and a poor service on overland rail due to tunnels and the landscape. Some other countries have solved this so it’s clearly not insurmountable.

I think Apple would do well to purchase a global mobile network operator and invest in the hardware necessary to ensure that the signal and bandwidth available matches the other aspects of the mobile user experience.

Following on from Darian’s recent blog about registration creating a barrier to usage of apps I’d like to add some of my thoughts to the arduous process of dealing with logging onto websites or apps following registration.

Having to remember multiple passwords is a fact of life for most of us now, a study a few years ago⁽¹⁾ showed that users typically manage about 25 accounts requiring a password. This led to the average user entering 8 passwords every day, given the expanding reach of technology this number may have since increased. Any improvements, however small, that can be made to assist the user logging on should be grasped.

I have a suggestion that will help some users remember their passwords for some websites and it is a suggestion that requires no technical development, new technology or shifting of user behaviour, just a bit of user centred thinking. When registering for a website it is common for the sign-up form to specify the password constraints e.g. must contain 8 digits, a capital and a number; however when it comes to logging back onto the site there is usually no such prompt to help steer the user in the direction of the relevant password.

See below from Google on the sign-up page:

And then nothing on the sign-in page (below left), even though they have even given you a prompt about the format of an email address is. There is still no prompt after clicking a link indicating you are having problems signing in (below right).

Another example here from Barclays Cycle Hire where you are prompted on the requirements of the password at the sign-up stage.

But then not reminded of this at the login stage:

In fact this pattern is widespread across websites.

Users prefer usability to security

Study after study^{(2,3 4)} has shown that users prefer usability to security and select the easiest passwords they can get away with and re-use a small number of passwords over and over. It has even been argued that given the cost and benefits involved, favouring usability over security is actually rational⁽⁵⁾. A user may have a six letter password they use when they can and also an eight letter password for when that is required and some capitalisation or number rules that can be repeated when demanded. When a user visits a website where they aren’t sure what the password is they are faced with some choices:

1. Guess which of their passwords is needed
2. Request a password reset
3. Leave the website

Having to type in password after password is clearly not desirable. Neither is requesting a password reset, which may involve multiple steps, and also potentially having to think of a new password thus contributing to the overall password burden. And obviously just leaving the site benefits no-one.

Small changes can significantly improve usability

Giving the user a little help by indicating any password constraints at the login stage can reduce the number of possible passwords the user might need to try thus increasing the chances they will attempt a login. It can also convey to the user that you’ve thought about them and are trying to help, rather than leaving them staring at this blank field with no memory cues. A six letter password with no other constraints is common practice so this approach would mostly benefit those websites which impose greater constraints such as the inclusion of capitalisation or digits. Why don’t websites already do this, who can tell, lack of thought, designers blindly following other sites or perhaps it’s the security department not wanting to help ‘hackers’ by providing more information. Although this last point is an impotent argument as any self-respecting hacker would just go to the registration page to see if there are any constraints on the password.

If you do find sites which help users with a prompt then be sure to submit it to LittleBigDetails.com. More blogs by Jeremy Rosenberg at his site.

Here at the theTeam we’ve recently been working on a few internal projects/web-apps designed to further aid in the companies everyday activities; whenever possible we like to create tools that will help us with process & workflow – it helps keep us more organised and our projects on-track which is very important in the world of a busy creative agency.

One problem any company will face when creating internal tools is uptake – as in, actually getting the intended audience to use them. There are many ways to solve a problem such as this; just touching the surface would include training, usability & design of the application. However, this article will be focusing on removing ‘barriers to entry’ by 1) decreasing the effort involved in any given registration process and 2) utilising existing data and infrastructure to perhaps forgo the need for a registration process at all.

Reducing your apps’ largest barrier to entry: registration.

If you absolutely cannot do away with registration then the barrier to entry can still be lowered by simply reducing the effort involved in signing up. Nobody, and I really do mean that in the global sense, wants to see a form with 20 fields to fill in just before they can even utilise the function or feature that the web app had already promised. Alfredo has already touched upon the benefits of being a lazy developer and I strongly believe applying that mindset to being a user works wonders for fostering activity, conversions, community, etc.

So what can you do? A short list:

• Try and implement a way for users to utilise your site with the majority of features without having to register; this can lead to up-selling the opportunity with extra features once they have already started using the site. This also works for e-commerce checkouts, ask the user to create an account *after* the checkout/payment process; by that stage you should already have all their details and account creation is merely a click away rather than a big wall a user has to jump over before getting to the till. You end up with the same result but with a much higher conversion rate.
• Reduce your required (and displayed!) registration fields to an absolute minimum. Even if none of your 20 fields are required, their mere existence will still scare off many a user. I’m talking email, password and perhaps username here; a bare minimum, you can ask the rest later.
• Pre-fill registration forms with sensible defaults or known data. A half filled out form is better than an empty one.
• Kill multi-page registration processes unless absolutely necessary. If they are required, give a good estimation as to how long they’ll take and what stage the user is at throughout the entire process.
• Reduce the amount of copy surrounding your registration procedure. Sure text is informative, but in this context large chunks of it can be seen to have an off-putting effect. Do you ever read that EULA/T&C text? No..? You’re no different to 99% of people wanting to use your registation form.
• Validate in-line. Don’t wait until the user submits the form to tell them that the username they chose is already taken – by that stage their password fields would have been cleared causing extra time and frustration as they desperately hope their next choice is free so they don’t have to do it all over again. Make your forms for an impatient world because that’s how the web is.

So, that being said, what did we do?

Utilising existing infrastructure

Before we started a recent internal project which would require registration to use, we sat down and drilled out the minimum information needed so that they could register an account and use the tool. On looking at the data, we quickly realised it was no different that the standard data you provide on joining the company and therefore  if we already had already taken that data at some stage, why on earth were we asking for it again?

After a quick conversation with our IT department, we realised that this was indeed the case and all the data was already held within the group’s Microsoft Active Directory system which utilises LDAP for single sign-on throughout the company. After implementing LDAP sign-on within our application we just reduced what would have been a 5 minute registration process into a simple login with email & password; provided the user has already set up an account with IT, they are ready to go.

and…. how?

Integrating Django with Microsoft’s Active Directory

Luckily, due to the abundance of 3rd party modules/packages in the Django & Python ecosphere, integrating with our parent group’s LDAP server was a relatively painless process. django-auth-ldap is a custom authentication back-end for Django written by Peter Sagerson which simply plugs in on top of Django’s shipped authentication back-end and provides a rich set of settings and method designed to make integrating your Django project as easy as possible. It’s built on top of python-ldap and therefore the OpenLDAP libraries.

If you’d like to read more about the technical details and exactly how we managed it then you can get a more in depth article at my site here: Getting Django going with Active Directory’s LDAPS.

Photo credit to tompagenet.

We hosted the inaugural UX Bootcamp last week, organised by Leisa Reichelt. The subject was ‘Prototyping in Code’ – so I thought I’d write a few notes explaining what this is, and why it might be helpful.

When designing a website, it’s important to test your work with end users along the way. The designer does their best to relate to the end user, and there are tools such as personas that can help with this, but inevitably several assumptions are being made. These assumptions need to be tested.

Wireframes or designed pages are commonly used for prototyping, and these are very easy to amend based on feedback (sometimes even in the testing session itself). But it’s possible to create a working, clickable prototype using the basic tools of the web – HTML, CSS and JavaScript – and render the site in a browser. Why would you want to do that? There are a few potential reasons:

• With experience, and a set of good templates, it’s possible to create and amend a prototype really quickly
• It allows you to include and test complex interactions, such as click events or fancy form elements. You can also test for different browser widths / screen sizes, including mobile, especially if you have an understanding of media queries
• By improving our understanding of web site architecture, it strengthens our ability to describe intentions to web developers
• By designing sites in this way, you don’t have to spend money on other tools such as OmniGraffle or Photoshop

The UX Bootcamp was, first and foremost, a crash course in creating basic code. We learned how to mark up content correctly, how to style it using CSS and how to introduce funky interactions using JavaScript (predominantly JQuery, but also Chosen for forms). We learned where to find useful grid templates, for large screens and mobile. There were kittens. We also learned how to use an app to streamline the workflow (I used Espresso, others used Coda). The course material was fantastic, and the facilitators (Anna, Peter and Alex) were incredibly patient and really knew their stuff. We definitely finished the course with a great foundation to build on.

But would we use code for prototyping? That’s a harder question to answer. To my mind, if you’re starting from a point where you know this stuff, and have a set of familiar templates from which to draw, it might well make sense to use thesetools for creating prototypes. However my feeling was that this wouldn’t work as well for designers learning to code for the first time. We depend on these designers to give deep thought to the layout and flow through a website, considering the user’s goals at all times – and hacking code could be a big distraction from this. It’s far easier to draw a box in OmniGraffle, which is better for subsequent annotation as well.

That said, there’s no doubt in my mind that all designers would benefit from a working knowledge of the tools that power the web, and I’m well chuffed with the course. Nice one, Leisa!

Many thanks to heraldpost for sharing the Boot Camp photo under Creative Commons.

As a creative agency we usually need quick turn arounds and we always have time sensitive deadlines. To deliver our products from the technical side of things there are tasks that we need to perform once or several times, such as:

• Create the project codebase
• Provision the server, or servers stack
• Make sure that all our developers work with the same stack and codebase
• Integrate the codebase to our continuous integration process
• Deploy the application

At theTeam we have a useful stack of tools that help us “hit the ground running” and reduce the time we spend on the above tasks. Most of these tools are available on the web and open sourced, others have been developed in-house and are already available on our github page while new ones are making their way there, so watch this space.

Since we let this set of tools handle all the boilerplate we can concentrate on the things that really matter: making our customers happy by providing them with the right solution to their needs, writing more tests for our application and giving it some nice techie features. We love being good citizens of the web, and we will go great lengths to build our applications the right way.

So how do you find out if you need a tool to do [INSERT TASK HERE] for you?

Well, what we use as a thumb rule is: if we find ourselves performing a task several times then let’s automate it and never worry about it again (OK from time to time we will need to amend it because this is the nature of the web, but you get the idea).

So yes, I am a lazy developer because, when possible I will automate as many tasks as I can and save myself time, and as an extra bonus the tool won’t forget any of the steps that the task involves.

So if you find yourself with not enough time to write those unit or integration tests, or implement that extra feature, or wondering why the application is not working on the production server, maybe you should be a lazy developer too.

Photo credit: machintoy on flickr