Optimisation is a core element in building any successful product regardless of whether its a website, an app or even a game. But optimisation isn’t just about keeping the file size down its about providing the most fitting possible solution for any given task.
When optimising we think about value, usability, readability, communication and personality as well as the more traditional foundations such as SEO and load times. Covering all these core concepts will ensure you have a deliciousproduct.
So how do we do it?
Throughout each step of design, development and testing we think about these core principles based on our collective experience and through experimenting. Here is one such example…
For one of our top secret projects we have in development we have two large containers which you can navigate between, we found that having a drop shadow these containers caused a subtle but noticeable lag when animating in and out. As with any project there is always more than one technical way to active a task so we brainstormed potential fixes which would allow us to keep the design with a drop shadow.
We decided to trial our current method (A), animating css position values, against CSS Transitions (B). To stress test the demo each container was filled with 2312 child elements all individually coloured and with opacity. The parent containers have the same drop shadow as we intend to use in our project.
Method B out performed A quite significantly in each of the tests. Spending just a little bit of time on this problem helped ensure we had a buttery smooth animation. Although this is a very specific example this logic is used each of the optimisation tests that we run and is essential to making great products.
You can view this test here…. but remember it is a stress test so it may crash your browser.
We’ve been using Git for quite a while now. We don’t have a single SVN repository. This makes for happy developers!
For a while we’ve been using Git Flow as our preferred workflow. It’s been pretty good, certainly from the point of having some sort of a recognised workflow/process. The only problem is, it’s turned out to be a bit heavyweight for what we want.
We love agile development, and for us, this means:
Short sprints of development
Regular releases (minimising serious issues)
Flexibility to experiment and throw away bad ideas
Team spirit and collaboration
The problem with git flow is it’s far better suited to a fairly fixed release cycle. We’ve found the release mechanism is cumbersome for quick/regular releases, and… it’s all a bit heavyweight for the entire team. We want all of our team to feel they can commit and contribute without feeling they might break something in the process. We also want to encourage communication, collaboration and experimentation!
So, the solution is, we’ve switched to Github Flow way of working. So what is it? The basic principles are this (stolen from http://scottchacon.com/2011/08/31/github-flow.html):
Anything in the master branch is deployable
To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
Commit to that branch locally and regularly push your work to the same named branch on the server
When you need feedback or help, or you think the branch is ready for merging, open a pull request
After someone else has reviewed and signed off on the feature, you can merge it into master
Once it is merged and pushed to ‘master’, you can and should deploy immediately
Here’s an excellent presentation that explains it:
What about clients reviewing code before it might be production ready? Well, we simply push a given feature branch to our stage server. If two developers are working on a separate feature branch, they can either merge each other’s feature branches or create a new shared branch for the purpose of a client reviewing code.
We’ve dropped all our develop branches and the team have been merrily discussing pull requests and getting stuff done. So far so good, we are liking the shift a lot.
We get sent a lot of ideas for apps; mobile and web based. Sometimes we get the most amazingly detailed documents that give us a thorough understanding of what the idea is and what it’s supposed to achieve.
Inevitably this is the exception to the rule, as being from different industries most people know what they want yet find it difficult to know the best way to describe it and miss out large chunks that are important to us. In the NLP world this is known as “deletion”. We all do it; “pass me that”, we delete the reference assuming that whoever we are talking to knows what we’re on about.
When we get job referrals like this, at the expense of possibly losing the project we ask the potential client to clarify their idea with two specific processes. This also helps us determine if they are serious about the project.
What’s the essence of the idea? This is essentially the elevator pitch.
User stories. What platforms and users are involved and what can they do. We call this the “stage” and actors.
The five minute elevator pitch
Distilling the essence of an idea into a single sentence is a really great way to communicate your project succinctly. A nice template to get this up and running quickly is as follows:
For [target customer]
who [statement of need or opportunity]
the [product name]
is a [product category]
that [key benefit, compelling reason to buy].
Unlike [primary competitive alternative]
our product [statement of primary differentiation].
As an example for ContactZilla
For teams and businesses who need to keep track of their contacts the ContactZilla platform is a contact management solution that is completely social. Unlike Sugar CRM our productmerges contacts from social media and traditional sources effortlessly.
Just this one statement helps with our understanding in a really big way. It’s quite a fun exercise too. We originally discovered this in the book “The Agile Samurai“.
User Stories
User stories are a pragmatic way to get a project communicated effectively. Essentially you are describing what the application should do for particular types of user and while not telling the developer how to do it. This means you don’t have to keep asking “is it possible?” you just state what is needed. The developer then needs to figure out how; with the resources available.
Project managers will weep that we ask a prospective client to come up with user stories. It is such a simple way to convey interactions, goals and functionality that even if done badly it’s usually more helpful… (we can argue about that in the comments)
First you need to identify the “stage”, this is a simple theatre metaphor that a lot of people understand straight away – the stages in a lot of cases can be an administrative area and a public facing area. We then need to identify the “actors”. These are the different types of luvvie people interacting on your stages. For example an administrator, a guest visitor, a bronze user, etc. This then leads to the user stories themselves.
As an [actor], I can [feature] so that [reason]
As an Administrator, I can delete a blog post so that I can keep things tidy.
You may find that you don’t need the reason, so get rid of it.
As an Administrator, I can delete a blog post.
If we now combine this with the stages we can break up the user stories into sections;
Administration Area – Managing Users
As an Administrator I can delete a user
As an Administrator I can send a message to a user
My profile page
As a logged in user I can update my profile picture
As a logged in user I can change my biography
You can take this much further as a project manager and a development team but for the sake of simplicity this gives a client a really good starting point to convey what they want to achieve in a succinct format.
We find that most clients find this a really rewarding process, it focuses them on what they want to achieve as opposed to how to achieve it. In some cases it also demonstrates the complexity of what it is they want and either validates or invalidates their idea. Which we can all agree is best done early.
Conclusion
Using these two simple techniques helps both parties enormously. It’s not always necessary and doesn’t need to be an extensive exercise but just enough to ensure a level of understanding on the side of the development, project management and sales team (after all its hard to quote for something you don’t understand).
The following is from the Manifesto for Agile Software Development it’s fair to say that we do our best to follow this for most of our projects. I thought I’d reproduce it here for those that haven’t seen it…
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
We’ve just put up the first version of Face Jam. A really simple online tool that once “connected” stops you from forgetting all of the those lovely people you met last night…
A user sends a Twitter name by SMS (to a short code) and receives back a message with their full name, location and other networks. The person will also be saved to your online account so that when you’ve sobered up got in front of a PC the next day you can check out (and connect with) the people that you met last night.
It’s super simple and good fun. We’ve got a few neat enhancements in the pipeline too.
Currently it’s UK and O2 only due to the use of the Bluevia Oauth. We’ve got another etcher post coming about the development journey.
You’ve heard the politicians going on about Twitter and Facebook and the riots? You’d have to be living in a serious hole or must have been on holiday a long time not to have. There’s been a lot said and a lot done.
We recently pitched the government via the Technology Strategy Board for a system to predict where this stuff might happen (better the devil you know!)… They are taking this stuff seriously, there was £600k available to research this “Minority Report” style software and while its not where it needs to be yet, it is not as far off as you might think.
Well now (via a new company) we’ve done the opposite of predicting the future and discovered an interesting twist – humour, however “dark”, plays a large part in social communication and trending. Using control data and then a continuous stream of “chatter” that fits targeted queries, the Churnbar system was “taught” what it should be looking for with minimal human interaction with some interesting results.
Care is needed when using social media to find the instigators of criminal activity. Law enforcement agencies need to determine whether a post is humorous or serious in intent.
We all like cakes. We all like a bit of love. So when a mysterious box arrived at the office on Friday from a client with the most beautiful cup cakes in, we were super chuffed.
The sparkly cakes from the lovely folk at Go Ape were to thank us for delivering their summer campaign with such brevity and fabulousness!
We built the social competition using the pro version of our new Rusic.com product, enabling us to build the competition in days instead of weeks (or months). We think it’s pretty awesome and after only a few days it’s already got some amazing stories going on.
There’s no shortage of help out on the web for building websites, but, what about once you’ve built your site? It has to be made live and published for the world to see.
We’ve deployed quite a few hundred sites in our time and I thought I’d share a few hints and tips to ease the process and make it more streamlined.
Firstly, there are two main types of deployment:
1. Brand new website
2. Update to an existing website.
The second of these is generally far more difficult to deal with, normally DNS and email will already be setup.
Step 1 – Get your DNS in Order
Don’t underestimate how long this might take, often it will involve your customer digging out information they have filed away years ago.
You need to find the following:
Registrar – which company is managing the domain? You can find out by doing a WHOIS on the domain. We use DNS Stuff for this. See example.
If the domain hasn’t been registered, it’s easier to do this yourself with your preferred company. We use http://www.ukreg.com/ normally, and, their system isn’t bad.
If the domain has been registered, you will need the login details to make amendments. Some times, customers might be reluctant to give you this, so you’ll have to do everything via them.
Take a snapshot of the DNS. If you change records later, you’ll want to know easily what to revert back to if something goes wrong. We do a DNS Report for every domain using DNS Stuff and save it. You can also take a screenshot of your Registrars name server setup or save the zone file if you have complete control. We write down IP information for our various servers in our Wiki so when we come to do updates we have the information quickly to hand.
Determine what name servers the domain is on. This is normally the ones provided by the registrar but could quite possibly be another company. Again, you can determine this from a WHOIS or DNS Report. We prefer to use our own DNS company, it gives us more flexibility and we know we can do certain things not all providers offer (such as changing TTL – see the right way to move a domain).
Step 2 – Sort out hosting
Ok, I’m not going to say too much about this. But, make sure you leave plenty of time to get hosting setup. If you’re setting a website up on a dedicated server, and it’s not something you do all the time, you probably need to allow 2 days to get it all setup and working. Things to consider:
Do you have any monitoring? If the server grinds to a halt, you’re going to want an idea why. We use Munin
Have you got backups setup? Are they offsite?
Do you have the web server and database server configured and appropriately optimised?
Can the server send email? If there is an SPF record for the domain (there should be) then you’ll need to add the IP of the server. If the server is sending email directly, it should have a reverse dns entry to the server.
Step 3 – Register SSL
If the site is an e-commerce store or has secure parts to it. It will probably need an SSL certificate. Don’t forget about this. We use GoDaddy.com for certs because they are cheap and actually pretty good for getting things setup.
Check to see if the existing site already has a cert. Ask the client if they have the cert details, they probably don’t want to buy another if they can avoid it.
Getting SSLs setup can take a while (not going to go in to how you do this, maybe another day), mainly because of the verification process. You will quite likely need access to the name servers to add verification information in to prove you/your client owns the domain name. Allow a few days for this!
Updating DNS/Name Servers
Ok, so you’re ready to switch off your old site and move to your new site! Exciting…
But, there’s a right way and a wrong way to do it.
Lots of web companies will say this to their clients when they move a site:
“We’ve done the DNS update, we’re just waiting for it to propagate and this will take 24/48 hours”.
WRONG!
This is what a web company tells you when they don’t know what they’re doing. If you do things correctly you can switch things very quickly and minimise the amount of people that end up on the old site. Follow the following:
Do you need to change name servers?
When you need to switch name servers:
Don’t try and update records at the same time!
Setup your new target name servers to be exactly the same as the old ones.
Switch name servers.
Nothing should go wrong, providing you have copied all the records over. Almost all Registrars will tell you name servers take 24/48 hours to update. This is possible, but rare. Normally, in a few hours all will be cool. But, before you do anything further, check the domain is using the new name servers with a WHOIS lookup.
Changing records
When you are ready to switch to the new server you will need to update one or more A records for the domain. This isn’t a full explanation, but it should at least set you on the right path.
Find the TTL (time-to-live) for the records you want to change. You can do this with a DNS Stuff Domain Report or it should be in your DNS configuration.
The TTL is the amount of time the record will be cached.
If the TTL is 1800 (expressed in seconds), this is 30 minutes the record could get cache. It’s typical for this to be about 1 to 6 hours. Reduce the TTL down to something like 60 seconds or 120 seconds. But… you need to wait the original TTL for things to get flushed out before you are ready to update.
Change your record after the original TTL has expired. There should then only be a 60/120 second window when they might get the old record though…. but this isn’t necessarily true! Why? Because you are only changing one name server normally, and the changes need to propagate. Knowing how long this might take is again down to name server setup (partly why we like to use ours) and further TTLs on the actual domain itself.
When everything is a-ok, put the TTL back up (otherwise every lookup will end up going to the main name servers first).
One more cool tool I like, DNS Stuff provide a ISP cached lookup facility. It will scan all the DNS servers of major ISPs to see if there is a cached record for a domain.
In Summary
There’s quite a lot to domains and moving sites. Hopefully this has helped a few people but all I would say is, give this stuff the respect it deserves. DNS runs the web! Just because I can walk in to a plant store and hire a digger, doesn’t mean I should… well, not without at least finding out how to use it properly.
When we’re working on projects for clients there’s always new ideas being thought up throughout the project. Ideas are great as an indication of a positive development.
The other side to this positivity coin though is the impending doom of “feature creep”. Sometimes its inevitable. It’s just the way it is. Get used to it! Over the years we’ve created a system that has evolved into something that seems to work for the client and for us. It’s even spurred us to build an application to manage the process.
We call this process the “bucket of love”. It’s a virtual bucket that all ideas go into. The term is fluffy and golden enough to take the edge off of a client feeling like they’re being ignored. They’re not of course, it’s just a sound way to remove feature creep until the end of a sprint. When we reach the end of the sprint, if it’s still a good idea we can discuss implementing it. Voila, everybody is happy.
This brought us to actually creating a system to do this and thus Rusic.com was born. A user logs in with their social account (Twitter or Facebook) and they then create “idea buckets”. Each idea bucket holds the basic premise of a question, “how can we improve sprint X?”. Everybody can contribute their ideas, “like” and comment on other peoples ideas. It’s a great way to see what is interesting (and what isn’t).
Interest doesn’t necessarily mean “like” either. I can make a negative comment but it still shows that I’m interested in an idea, just like in a real conversation.
There’s also a lot of social goodness going so that each idea bucket gains some momentum. Momentum is necessary for the generation of ideas. Ideas breed ideas…
We’ve pushed a new product live this week. Rusic.com - It’s for generating ideas based around a topic or question.
It’s early days yet so we’ve got loads that we want to do, we just didn’t want to go down the “beta” route with this. It’s either useful or not?
We describe it as social ideas; in that it only works via Twitter or Facebook and it’s very simple to use and appears to self promote. The basic premise is to generate ideas or responses to questions.
For example:
“How can we improve our local playground?”
“What can we do to improve our website?”
“What shall I wear to the wedding on Tuesday?”
You can even use it to have Twitter conversations that need more than 140 chars.
We’ve setup an “idea bucket” for how we can improve Rusic so please let us know how we can improve. We’re not doing the beta thing, we’ve just put it out there and we’ll see how it goes.
We really do want your ideas for feedback so please let us know.
