Author Archive

Alpha, Beta & Official Releases: What’s the difference

Tuesday, August 24th, 2010 by François

An image of steps

We do our best not to use technical terms or industry jargon when communicating with clients and their stakeholders.

That said, we do regularly use the terms alpha, beta and official release. These terms are extremely useful because they help everyone understand where we are at with a project and what they should expect to see and experience at that stage of technical development.

The difference between an alpha, beta and official release is very subjective but here is our take on the difference between these three terms.

What’s an alpha release?

An alpha release usually means a website or application is working but some functionality is likely to be missing and a number of known and unknown bugs are likely to surface.

The main purpose of an alpha release is to allow users to test a website or application so that they can pass on feedback to the technical team in terms of:

  • bugs found
  • desired changes to existing functionality
  • additional functionality that should be developed.

This feedback is generally logged using bug tracking software such as Trac, Redmine or OpenAtrium.

Generally each issue is assigned a type (e.g. bug or enhancement), owner, priority and severity. This means the technical team can work through the bugs and enhancements in a logical manner.

What’s a beta release?

A beta release usually means that a website or application has had all of the major known issues fixed but has not been tested enough for an official release.

The main purpose of a beta release is to provide a fully functioning demo of a website or application. This second-round of feedback means the technical team can:

  • make user-led modifications to existing functionality
  • capture any ideas for additional functionality (that can be implemented at a later date)
  • resolve any other bugs or performance issues that would prevent a fully signed-off official release.

What’s an official release?

An official or open release usually means that a website or application has gone through a rigorous quality assurance process and that all major technical issues have been identified and resolved. This means that the website or application is now fully functional, debugged and ready to be released to the general public.

Even though the differences between these terms may seem minor this three-step approach is integral to ensuring a stable release which works as intended.

For example, Gmail’s alpha release was only accessible to Google staff as an internal product. A public invitation-only beta release was rolled out in April 2004, before it was made available (as a beta) to the general public in February 2007.

Despite Google’s resources Gmail wasn’t upgraded from beta status to an official release until July 2009!

Why the delay?

It’s really quite simple.

One of the worst things a website or application can do is attract users before the software is truly ready for them to use.

Mainstream users can be unforgiving and a reputation for instability or poor quality of service is incredibly difficult to shake.

It’s aways preferable for a website or application to be more stable and offer a better quality of service than a user expects.

By taking a conservative approach to releasing (whether it be an alpha, beta or official release) you will ensure that you do not disappoint those that really matter – the end-users of your website or application.

Photo Credit: Bill Ohl

Sharing Bookmarks: A better way

Thursday, July 15th, 2010 by François

Delicious Logo

I’ve recently completed testing more efficient ways to share our bookmarks.

Previously we shared links internally and with clients by writing a weekly round-up post on our blog.

Not only was this time consuming it wasn’t user-friendly.

So why persist for so long?

Habit.

Even though we knew we should have transitioned to something like Reddit, StumbleUpon or Delicious we never did.

Why? Because it was such a simple thing to do it kept on being put off. Not good I know, hence this post to absolve my guilt!

The options:

After playing around with RedditStumbleUpon and Delicious and looking into the usage stats of each we’ve settled on using Delicious. You can check out our account here.

Getting Started:

With Delicious importing your bookmarks is a breeze:

First off, you will need to save your browser bookmarks.

If you are not sure how to do this, create a Delicious account and follow the detailed instructions for Firefox, IE 6 & 7, Opera. Please note you must be signed-in to access this page.

In addition to the supported browsers this works fine in Safari too (go to “File” and select “Export Bookmarks”). Although Chrome on OSX is still lacking a bookmark exporter there are work-arounds available.

Once you’ve done this pop over to Delicious and create your account if you haven’t already:

  1. Click on Settings
  2. Click on Import/Upload Bookmarks
  3. Choose the File to Upload
  4. Click on the Import Now button

The import process is surprisingly quick and there is an email notification option that tells you when it’s completed.

Once the import is complete you can start sorting through your tags and the Bulk Edit feature is very useful for this.

Other features you should check out:

  • Export/Backup bookmarks feature makes it simple to download a copy of your bookmarks for safe-keeping. We would recommend doing this regularly.
  • Link Rolls/Tag Rolls is an easily enabled feature that allows you to display your latest Delicious bookmarks/tags on your website or blog.
  • Blog Posting is an experimental feature that can automatically post entries  containing your latest links to your blog every day. This isn’t something we are currently using but it is something we would be interested in using in the future.

Conclusion:

Delicious is a great solution for sharing and storing your bookmarks online.

It is easy-to-use and its import/export features work well. The extra settings available means you can also customise the way Delicious works.

All in all we are really happy with Delicious but as with any hosted solution we’d always suggest you continue to maintain a regular backup procedure.

Wordpress 3.0 Released

Friday, June 18th, 2010 by François

Wordpress logo

WordPress 3.0 has been released and is available to download.

We’ve been eagerly anticipating this since playing with the beta.

Tip: sign-up for the mailing list to receive notifications whenever a new stable release is made available.

We’re big fans of WordPress as a blogging platform (it powers this blog) and have used it as a CMS for a number of jobs in the past.

Given this release it’s safe to say we’re likely to be using it a whole lot more.

Over the coming weeks we’ll continue testing WP3.0 and will do a follow-up post with a detailed assessment of our findings.

Our approach to collaborating on a design

Thursday, April 8th, 2010 by François

Post-it Notes We always prefer to work with a design team throughout the course of a project but when this isn’t possible we’ll provide as much help as we can.

More often than not this entails providing documented guidelines (new website or application) or recommendations (optimisation of an existing website or application). These similar sounding documents have a different purpose.

The aim of our design guidelines is to provide a framework for final screen designs that focus on balancing business and user needs/goals. The aesthetics of the final design is not a driving factor when compiling this document.

The aim of our design recommendations is to target low hanging fruit, or rather low-cost changes to an existing design that make a substantial difference to conversion or completion rates. Again the aesthetics of the design is not the primary focus, usability is.

Industry outsiders are often surprised and somewhat underwhelmed when I’ve shown them previous design (or rather UX) guidelines or recommendations that I’ve supplied in the past.

They always ask, “is that it? That’s so plain!”

I feel a bit sheepish at this point and go on to explain that the final look of the interface isn’t actually where we add value.

I then go on to explain that in actual fact bare-bone wireframes and any supporting text are only a framework or rather creative parameters for the production of the final design.

“So what’s your job then?” is the usual follow-up question.

To which I answer, well we actually focus on helping businesses (direct clients) and agencies (contractors to whom we are a sub-contractor) understand who they are really designing for.

By this I mean we identify what and how people actually interact with an interface before we even consider the final elements of a design.

This is key to everything that follows, as without this we can not measure the efficiency of an interface.

Bottom line people don’t come to your website or use your software to gawp, they’re there to complete a task.

Of course we try to measure satisfaction by asking people how they feel about the design but what really matters is how efficient it is.

So the documents we deliver try to identify what it is your end-users want to do, as well as detailing what they’ve said.

This approach allows us to identify key performance indicators (KPI’s) so that you can measure the effect (through continuous testing) of these changes as well as any future changes you may wish to make.

So to finnish up there are plenty of amazing graphic designers out there (feel free to email me for recommendations) but we aren’t one of them.

Instead we collaborate with a number of talented partners to deliver compelling final designs but each and every one of those goes through this in-house process.

The reason for this is that the end deliverable will:

  • be focussed on who is going to use it
  • facilitate what the people using it wish to achieve

And hopefully:

  • be pleasing on the eye.

In truth though I’d always sacrifice a bit of the latter if it means better performance in terms of completion and conversion rates.

Photo Credit: Valerie Everett

Defining the scope of a project

Tuesday, March 23rd, 2010 by François

A cracked egg

Now first off I want to state that I have learnt this the hard way. There was no epiphany this is just something I’ve learnt by being burnt.

At the start of any project you will try to define the scope of work required by the client.

This usually involves defining the deliverables the client requires and breaking these down into the tasks needed to deliver them.

Why do this?

  • To manage client expectations
  • To establish clear communication
  • To ensure you can deliver what you say you will (on-time and on-budget)
  • To identify the areas you really can add value
  • To help the client prioritise what it is that they really need

What does this involve?

Well I reckon it all boils down to the following:

  • What are the project’s SMART objectives?
  • What are the client’s business goals?
  • What are the client’s needs (short and long-term)?
  • What are their target audience/end-user goals?
  • What are their target audience/end-user needs?
  • What are the client’s constraints (budget, resources and timeline)?
  • Details of the work to be done.
  • What research has been done to inform the above?
  • Why do they want to work with you in particular?
  • How will they measure success?

Now a well written brief should detail all of the above quite clearly.

However, I’ve seen a lot of briefs recently that look more like a wish-list then a strategic document.

How do we address this?

We are honest and direct and rarely take a brief as is.

We analyse it, critique it and pass on our feedback to potential clients.

There is no doubt that this approach may well have compromised our chances of securing a number of contracts.

Then why do it?

Two reasons:

  • it provides genuine value to the client
  • it ensures you don’t find yourself wishing you had once the project kicks-off.

After all you know what can be done, how well it can be done, and how much risk is involved.

As such I see it as our duty to:

  • provide feedback on what is, and what isn’t doable within the constraints of the project
  • go through their requirements and reassess the prioritisation of the work to be done.

If you know a decision they are taking now is going to have long-term implications state them up-front. This is what clients are hiring you for, not just the fulfilment.

Yes, it may be a difficult conversation but if you don’t do this you will certainly come to regret it.

Bottom line it’s better to miss out on a job then find yourself working on one you can’t wait to see the back of.

Not only can you take a financial hit on projects such as these, the impact on your team’s morale can not be underestimated.

Photo Credit: http://www.flickr.com/photos/21560098@N06/3812840962/

Must Read: The 10 Do’s & Don’ts of Web Development

Wednesday, February 3rd, 2010 by François

Fatdux Company LogoThis article has to be shared and promoted.

Written by the always inspiring Eric Reiss of The FatDUX Group, this is a must read if you are commissioning or project managing the development of a website.

This isn’t one of those usual top 10 lists you see doing the rounds. It’s a truly informative and useful primer that all small and medium sized businesses would benefit from reading prior to commissioning a new website.

Why?

It offers non-technical business leaders a concise yet powerful overview of what, and more importantly what not to, focus on if they want to give their website every chance of succeeding.

Here are the core headings:

  1. Don’t confuse your marketing with communication.
  2. Don’t view your website as a software development project.
  3. Don’t couple unrelated initiatives.
  4. Don’t be afraid to set measurable goals.
  5. Don’t confuse your needs with those of your visitors.
  6. Don’t view your website as a fixed term project.
  7. Don’t confuse print design with web design.
  8. Don’t let personal opinion cloud your focus.
  9. Don’t be afraid to ask stupid questions.
  10. Don’t hide in your office.

You can read the blog post or download a PDF to access the full article.

We will be circulating this article to all of our new clients as it effectively addresses a myriad of issues we often encounter.

So thank you Mr Reiss you really are a star!!!

Twitter Picture Goes Live

Thursday, January 14th, 2010 by François

5322c66f0487fa629e6374c07550fda9_52902

Johanna Basford’s latest  Twitter Picture project has just gone live.

Over a 24 hour period I will be creating the second TwitterPicture, an interactive illustration drawn by hand and inspired by Twitter.  Tweeters are invited to send me one suggestion each in 140 characters or less which I will incorporate into a super sized, hand drawn illustration.
The project will run for a continuous 24 hour period and will be streamed live here.
Watch the live creation of TwitterPicture 2 and get involved by Tweeting me your suggestion.
** IF THIS LIVE STREAM IS OVER CAPACITY, YOU CAN WATCH THE ACTION HERE TOO **
The view from the TwitterPicture webcam will be changing throughout the day, so keep checking back to watch the inky evolution!

Over a 24 hour period (9 AM Thursday 14th – 9AM Friday 15th) Johanna will be creating a hand-drawn interactive illustration inspired by Twitter.

Tweeters are invited to send her one suggestion each in 140 characters or less which she will incorporate into a super sized, hand drawn illustration.

The project is being streamed live.

So check out the live stream of TwitterPicture 2 and get involved by Tweeting Johanna your suggestions.

If the live stream on her website is over capacity, you can watch the action on Ustream.

The view from the TwitterPicture webcam will be changing throughout the day, so keep checking back to watch the inky evolution!

Browser Size: A New Tool From Google Labs

Monday, January 4th, 2010 by François

Google Labs recently released a new tool called Browser Size.

What is it?

Browser Size is a visualisation of the browser window sizes people use when visiting websites.

For example, in the screenshot below, the 90% contour means that 90% of people visiting our website have their browser window open to at least this size or larger.

google-browser-size

The sizes represented by the contours are client area sizes, not browser window sizes.

This means they represent the size of the browser without the title bar, toolbars, status bars, etc, and thus give a true representation of how much content can be seen by a particular segment of Web-users.

You can view any website with the same overlaid visualisation by entering the URL of the site you want to check.

Why you should take a look at Browser Size?

Having access to this sort of data is no doubt valuable.

But what I find really special about this tool, is having the ability to quickly check how visible the key elements of a user interface are to a wider audience then your own analytics data could ever provide.

That said, it’s important to note that Browser Size works best on web pages with a fixed layout aligned to the left. For other layouts the results can be misleading.

Google state they are actively looking to improve this tool so expect these issues to be resolved over time.

Happy New Year

Wednesday, December 30th, 2009 by François

As this year draws to a close I’d like to wish all of our customers, collaborators and friends all the best for 2010.

2009 has been quite a year for us, we’ve grown in numbers, worked with some great companies, become dad’s and in general done a lot of growing up.

It has been tough at times but with all of your custom and support we’ve pulled through.

Looking at what we’ve achieved and all that we have to look forward to, I can’t help but feel that 2010 is going to be a really exciting year for us all.

So here’s to each and everyone of you – have a brilliant Hogmanay and all the best for 2010.

Photo Credit: http://www.flickr.com/people/meddygarnet/

AWS CloudFront Now Does True-Streaming

Friday, December 18th, 2009 by François

AWS_LOGO_RGB_300pxAmazon Web Services (AWS) recently announced that CloudFront now supports Flash streaming (RTMP) in addition to progressive downloads (HTTP). Live streaming is also expected to be rolled out at some point in 2010.

This is all being made possible by Amazon’s decision to deploy Flash Media Servers (FMS) at its 14 edge locations. The decision to go with FMS over Wowza Media Server is somewhat surprising given the fact we’ve been streaming off AWS for quite some time using Wowza Media Server for EC2 .

Even though we were really happy with the quality of service we eventually got out of this, setting it up was not a pleasant experience.

Given what I’ve just said why did we go down this route when there are plenty of content delivery networks (CDN’s) we could have used for this?

Bottom line, pricing and flexibility.

Put simply, using a CDN for true streaming (RTMP) more often that not is out of reach for low-volume publishers due to cost, long-term contracts and minimum commitments.

Hence, our decision to stream off of AWS using Wowza.

Now that CloudFront has deployed FMS we will certainly be reassessing our current set-up.

Using Amazon CloudFront for true-streaming offers low-volume publishers like us the following benefits:

  • high performance
  • reliable delivery
  • global coverage
  • ability to leverage other streaming protocols such as RTMPT, RTMPE, RTMPTE
  • no up-front commitments
  • no additional platform or licensing fees
  • no long-term contracts

We will definitely be testing CloudFront for streaming and will report back on our findings in the New Year.