discussing web services

It’s perhaps time for us to lay down what ‘web services’ are for developers, as in itself, the web provides a multitude of services. One of our very own web developers, Will has taken on this task in an article originally posted at the red ant community area of our website.

It’s a pretty great article to describe what a developer/programmer/engineer is talking about when they discuss web services, and we’d thoroughly recommend that to anyone. As a taster, these are few comments that Will has made;

web services are a means for one application to talk to another, or a sort of Internet form of communication that allows different platforms – written in whatever language – the ability to converse and share information.

In order for applications on the Internet to freely exchange information we need an open protocol that can be interpreted and implemented easily by many different systems.  HTTP, the underlying protocol of the humble web browser fits these criteria. Web services, SOAP and REST it goes without saying fall into the realm of geekery that are unlikely ever to require the average website owners attention.

If you want to see and read more, Wills full article that fully describes what web services are is found in the community/blog area of the red ant site. You cannot post comments there, however, we’ll happily enter into discussion here!

designing with icons

We know that we have a lot of opinions on accessibility and usability, and just in general producing a website that will not treat visitors to an experience that makes the house of horrors seem like a picnic, but until it stops, we’re not going to!

From design to development and through to planning and executing a digital marketing strategy, every ant thinks about how the person viewing and using our work will react to it. Our goal is to provide our clients with a website that attracts traffic and retains visitors because it provides a positive user experience. One of the key points that we address and consider is accessibility.

Fitz takes up the designing for accessibility torch in the following excerpt from a published article about the use of icons in web design;

The use of icons are not only used to make the interface look “pretty” they are used for usability. A site interface should be intuitive and by using icons to represent what the action will do this makes us think less, perfect!

If it’s not broken don’t try and fix it. There are icons which have a meaning associated with them. Examples such as an envelope implies email or sending a message and a magnifying glass is to search… A basket or bag are used to store your virtual goods, then you proceed through the checkout to pay.

All this is familiar to every one of us, however purchasing goods online is very different to physically doing so. AGFG is a woman’s clothing retailer and using a bag instead of a basket make sense. Adding more items changes the icon from one bag up to an icon with three. From personal experience of going shopping with my fiancée I know the feeling of lots of bags, I’m glad these are virtual!

There can be a negative impact of using icons and that is if the user doesn’t understand what it is or what it does.

You can read the full article over at our main website, but this was a short excerpt from Fitz’s article Web design and usability – Keeping it real. We’d like to take this moment to wish him well with carrying his fiancees shopping bags.

Planning Time for Social Engagement

In Dan’s recent blog post digital consulting and digital strategy he highlights the need to plan for success and to be able to support digital campaigns; as part of many digital strategies the same holds true for social engagement. Andy Budd recently tweeted much the same sentiment:

“Social media marketing is like alcoholism. Getting that initial buzz is easy but keeping it going takes time and effort!”

Having an understanding of the amount of effort required to maintain a social engagement programme is clearly something that is key to digital consultancy. In the remainder of this post there are a few pointers on how to estimate the level of time required on a weekly basis to run and support a social engagement program. These pointers combine to build a simple spreadsheet model that can be used to plan and evaluate.

How will you use social engagement?

The first steps in planning the time required for social engagement is to list out which social networking channels you will be using as part of your digital strategy. Some channels and simple ideas are contained in my blog entry on social engagement. When listing the social networking channels aim to note down each social networking activity as a channel. So you may have a Facebook fan page, but you may use a number of applications on these, complete your list to the granularity of each application you are using as part of your digital strategy. To make it clear it is worthwhile noting the aims of each channel.

How proactive do you intend to be?

Within the social engagement part of your digital strategy how much content is being written / seeded per week? If you have a blog and/or Twitter account how often are you going to write blog posts or tweet new information. Each of these takes time and needs to be accounted for. In the spreadsheet list the social networking channels, how many times per week you intend to post to each channel and how long an individual post takes in minutes. Multiple the first by the second to get the time per week you expect to spend seeding each of your social networking channels.

How engaging will you need to be?

Social engagement is just that, engagement; you cannot start along a digital strategy of social engagement and not take the time out to engage your audience. Not all audience posts will be positive, there may need to be a degree of moderation. Some engagement will also require research to respond. Each social networking channel will also have by its very nature a degree of expected participation by an active member of your audience.

Within the spreadsheet place the columns social networking channel, participation, moderation, response time and response rate. Under participation for each social networking channel note how many posts an active user will post a week. Under moderation place the values 1 for proactive moderation (every post is moderated), 5 for reactive moderation (posts go live, but may then be removed after an administrator has reviewed them all), and 10 for community reactive moderation (members of the audience report on posts that may not be appropriate). Response time and response rate should be completed for the estimated time it will take to deal with an average post and as a percentage the amount of average posts that will require a response from the social networking channel.

Once completed the time taken per active member of your audience per week can be calculated:

(Participation/moderation) + (participation* response rate * response time)

The participation / moderation part of this calculation uses the estimate that each moderated post will take approximately 1 minute, please feel free to adjust for your moderation methods.

Define your audience

Each different social networking channel within your digital strategy will have its unique audience characteristics. For each channel note down the expected size of audience, the percentage of the audience that is expected to be active weekly and the human factor.

The human factor defines how much additional work may result from that audience, e.g. malicious posts etc. For the human factor place one if the audience is expected to result in a typical amount of work, lower the factor if the audience is expected to be easier and raise it if the audience is expected to be more difficult.

The human factor, size of audience and expected audience participation can then be multiplied by each other to generate a metric by which the channel audience can be rated.

Summing up

To calculate the weekly management time required for the social engagement section of a digital strategy the final step is for each social networking channel use the following calculation:

Proactive Engagement + (Audience Metric * Reactive Engagement)

Actual time spent to estimated time spent will of course differ over the time of the social strategy, but the above should be a good starting point.

This blog entry was written by Paul Bidder.

Digital Consultancy and Digital Strategy

This year aligned to expected interest the main theme of our Internet World presentations and literature was Social Engagement, just one of the areas that Red Ant consults in. Whilst more can be read about Social Engagement in Pauls blog post on Social Engagement on talking to people at the stand the theme inevitably turned towards the wider digital consultancy and digital strategy that Red Ant performs for our clients, sometimes even along the theme of what digital consultancy consists of. Through the remainder of this post I will attempt to cover areas of digital consultancy and areas that I believe marketing departments should be considering for their digital strategy.

Digital Consultancy

Digital Consultancy in short is about finding the best way of achieving goals, normally promoting a brand or service, through electronic connected media. This could be online on the web, through specialist Internet applications or through mobile phones (both network and Bluetooth connections). Digital consultancy also can tie into traditional media outlets either as traditional first bringing an audience into a digital campaign or traditional last by using an existing digital audience as content generators. As is the case all consultancy Red Ants approach to digital consultancy and building digital strategies is tailors to each of our clients, however there are some key requirements and steps that cross over all campaigns.

• Know the aim
• Know the brand / client
• Know the audience
• Know the tools and be clear in their limitations
• Plan how to measure return (KPIs), and expected return
• Plan how you will support your strategy
• Deliver, measure and repeat

All of these are simple, but necessary steps to delivering a well constructed campaign.

Digital Strategy Aims

Discussing aims with clients are often the first barrier we come across. The part that we find clients normally find the hardest is knowing what is achievable and in defining initial digital strategy aims they are normally either very generic e.g. we want to do something social, or they are detailed to the point of being limited by the initial vision. Aims on any digital strategy should be first and foremost business goals and limitations. Goals normally include increased awareness, building an audience and / or educating that audience, increasing reputation, but ultimately making the sale. Limitations generally consist of conflict of interest with existing business practices and / or outlets, initial perception (both audience and reputation), and budget. Working with these goals and limitations digital consultants can start to build clear strategies to meet these aims.

Understanding brand

Before any meaningful digital strategy can be put in planned the brand must be understood inside and out. Misplaced brand identity within a digital campaign will at best lead to a misfiring digital campaign, at worst it can lead to long term damage for the brand in question. The message for any digital campaign must be on brand or at least on brand aspirations as defined in the aims of the strategy. Whilst a subjective viewpoint is all well and good living and breathing the brand will open up ideas for digital strategy that will take the brand to the next level.

Understanding the audience

Along with the brand the audience is a key factor in any digital strategy. It is particularly noticeable in brand reinvention that when the new brand message is not attuned to the audience the reinvented brand does not stay reinvented for long. Digital campaigns that have a message that is not aligned with the audience are weak, of limited value and like incorrect brand messages potentially damaging.

Understand what is capable

At Red Ant we encourage all of our Ants to take the time to learn new products, ideas and technologies. Only when they understand what is capable and are able to share the knowledge can we deliver digital strategies that are truly optimised and have that creative sparkle that stands out. We find that knowledge plus imagination delivers a plethora of ideas, invariably including those that are not on brand (but through education rarely those that aren’t on audience), but for every 99 ideas that do not make it passed initial brainstorm one is an absolute gem. However being ignorant of what can be done is an immediate limitation on what is possible and what will be delivered for the digital campaign.

KPIs and ROI

KPIs and ROI are discussed in detail in Richards blog post about an ROI and performance framework, but they are a key component in any digital strategy. Gone are the days that money can just be thrown at a project without proof of return, and without proof there can be no success.

Digital Campaign Support

An area that is often overlooked in digital consultancy until it is too late and to the detriment of the digital strategy is supporting the digital campaign. It is odd to be cautious of success, but planning for the success of a digital campaign is an essential element of ensuring the success of the digital campaign. If sales increase tenfold is the stock available, or easily acquirable, can the fulfilment be managed? If engagement with your consumer base has rapid uptake do you have the staff available to engage and potentially police areas of engagement? If your goal is to drive traffic to a website can that website handle large upswings in traffic? If you cannot meet the conversion of goals then the digital strategy will have failed and as per other areas this may have an adverse effect on brand, audience and future digital efforts.

Delivery

Red Ant has a team that delivers, but this falls outside of the remit of digital consultancy. What is important to remember is that no digital campaign should be treated in isolation. The measurement of existing digital campaigns is the yardstick and starting point for future digital strategy.

This blog post was written by Dan Mortimer.

SEO and making tea

Making the perfect cuppa is a formula to follow, pour boiling water over a tea bag in a cup. Stir, add milk, sugar, remove tea bag, stir once more and drink… but is it really?

That’s not how I make my tea, and it may not the way you make yours. Alongside a huge range of personal preferences, there are number of aspects of tea making to consider, mostly from tips to making the perfect cuppa that other people will have given that you have adopted over the years.

Approaching building a website and the search engine optimisation is very similar to making the perfect cup of tea, the basis of which is knowledge of what your audience likes and investment in the ability to provide that. I’ll go through a few scenarios of tips that I have had here and equate that to offerings for an almost perfect online experience.

1. Never buy cheap tea. Nine times out of ten, cheap tea bags make cheap tea and leave no satisfaction. Similarly, if you realise the tea that you have decided to buy on face value suddenly turns out to have a slightly bizarre taste, you now have a box of it sat there looking at you! Always get recommendations from other people before committing your business to a web project.
2. My fiancé has the smallest amount of milk in his tea, cannot decide if he wants 1 or 2 sugars and leaves the tea ‘to cool’ before I pour half of it away at the end of the night because it’s become ‘too cold’. He wants a full mug, not a smaller cup. If he would make up his mind how much sugar he needs and add a little cold water to his mug, it would be the right temperature and he would drink it all, not wasting any resources. Discuss your business need with your teams, the listen to your teams, listen to your colleagues and employees input and feedback, listen to your web project managers, listen to those who are able to deliver what your business needs, even though it may be not as you thought it should be done; they know how to deliver to your budget and maximise resources. At the end of the day, the better the end product, the better everyone feels about it, and the more benefit is reaped all round.
3. One of the designers here at Red Ant likes his tea weak, milky and very sugary; I like mine to be strong, with a dash of milk and the occasional half spoon of sugar. But we can still both stand in the kitchen and make tea for each other. So provide ingredients not only for your visitor, but also enough for their friends so that they can recommend your services to them. However, you do not have to provide services for everyone; we have English tea – no infusions to offer and regular coffee but no cappuccinos’. Sticking to the basics for our caffeine needs, but not getting too fancy because it is not the time or the place. We know our audience, we know if we want something a little extra we get it ourselves and we always return to our favourite staple diet of tea and gallons of it!
4. Many years ago, a friend named Craig told me off for putting the sugar and milk into the cup while the tea is brewing. Apparently the molecules of the milk stop the flavour from coming out of the teabag perforations. I needed to wait until the tea was brewed and ready to have milk and sugar added. So in terms of optimisation – don’t put everything in at once, watch, taste, learn, add, watch, taste, learn, add…
5. My very cool grandparents retain and store to compost their used tea; then granddad uses that compost to grow vegetables and give out to the family. His careful use of something that has already given him one thing and follow up means we all get some very tasty courgettes! Repeat visits are a great way to determine how successful you can become and brand evangelists are great to help grow your business. Perhaps each visitor should be treated in such a way that they are able to provide further enrichment back to another area of the business at another time of the year, or contacted to give some enrichment back to them in the form of loyalty vouchers. Their evangelism of your brand then becomes a great reputation for your company.
6. My cousin Simon came to live with us for a while and displayed what can only be described as tea dictator traits. One of which was the day he told me off for squishing the water out of the bag before I took it out – apparently that makes the tea bitter. Gentle infusion is key to a harmonious relationship, and treating the infuser gently when removing it means the experience is less harsh for all. I guess that this is an example of providing a great experience, and customer service. Provide good follow up and treat even the smallest sale as your biggest client for a great reputation and lots of word of mouth/social exposure.

Now you know how I like my tea – and my websites – why not make me a cup of tea that I’ll like and build me a website that makes me want to come back, or even purchase from!

This blog post was written by Sarah

Web Services

What are Web services?

If you are a developer or you have listened to one of us wax lyrically you may have heard of web services. You may not understand how they work or what they do though. Basically web services are a means for one application to talk to another, or a sort of Internet form of communication that allows different platforms written in whatever language the ability to converse and share information.

XML was written in part for this purpose and has freed us from the limitations of HTML, CSV files and proprietary formats. It is being used along with the SOAP and REST web service protocols to bring us things like ‘Tweets’, Amazon affiliate programs and a plethora of mash-ups.

In order for applications on the Internet to freely exchange information we need an open protocol that can be interpreted and implemented easily by many different systems. To achieve this we need an information exchange method that is widespread across multiple different systems; HTTP the underlying protocol of the humble web browser fits these criteria.

The Web has been using HTTP since it was born. It can be very secure using 128bit encryption over HTTPS, and has been tested thoroughly. HTTP also supports verbs / actions such as GET, POST, DELETE, and PUT, and it has locations or URIs. In short it is a perfect fit and is very flexible.

SOAP

SOAP stands for Simple Object Access Protocol and goes hand in hand with a WSDL which describes the web service and how to use it. It was primarily designed to exchange information unobtrusively between systems over the web. It does this pretty well and many code editors like Visual Studio have tools that let you get on with writing a web service very easily. The protocol understands things like primitive data types (whole numbers, natural numbers, strings, etc.) and object orientation and highly useful applications can be made with this. It became a W3C recommendation in 2003.

REST

REST is an acronym standing for Representational State Transfer. A man called Roy Fielding came up with this to describe the Web itself as an Architectural style of network. It is has no specification because it is basically some rules about how to achieve things. It lists some constraints and things to bear in mind while writing a web service.

• What are the resources or URIs?
• What is the format?
• What methods are supported at each URI?
• What status codes could be returned?

With this set of rules you can make a web service that will work in the same way that the world wide web works. Each resource can be uniquely described and acted upon as easily as writing a URL eg. http://www.mysite.com/employee.aspx?EmployeeID=5&Type=Retrieve. A REST web service should act like a really well made website but instead of using HTML it uses XML.

Web services, SOAP and REST it goes without saying all fall into the realm of geekery that are unlikely ever to require the average website owners attention. However hopefully the above gives just enough of an understanding to allow you to follow the developer next time they start waxing lyrically.

This blog entry was written by Will.

Semantics and web content management

The migration of the web toward semantics

In terms of formalisation for most of the web the prefix WWW should stand for Wildly Wrong Web, rather than the accepted World Wide Web. However the pervasiveness of the Internet and the web often obscures the fact that it is still relatively young with only a little over ten years of mainstream commercial and consumer adoption in the UK; and the growth of new technologies and techniques with their relative ease of introduction bodes well for greater formalisation.

In early commercial sites the prime concern with web sites was how they looked in Internet Explorer on Microsoft Windows, the consumers’ browser of choice. Certain companies may have pushed the boundaries a little and considered other browsers (Netscape), and even other platforms (Apple / UN*X). In each case the primary concern was how a person might view the site via whichever tool the site author considered they might be using. Beyond how easy a piece of HTML might be to maintain little thought was generally given to the underlying structure and meaning of the HTML source, only the visual aspect of a site was important.

The growth of search engines, triggered in no small part by the exponential growth of the sites available to search over has caused a degree of reassessment; and as search engines have grown cute a move towards semantics has occurred. The original search engines had a somewhat over reliance on meta-data, which forced commercial sites to adopt keywords and descriptions on each page in best practise trying to tag and describe the content of the page, in likelihood these would be abused to the terms that best matched what people might be searching for.

The abuse of meta-data led search engines to start reviewing the content of the pages. As content was reviewed visual tricks (shrinking text, commenting text, making text the same colour as the background), were used to lead to higher rankings. Again the hands of search engine programmers were forced into devising more intelligent algorithms.

Since the web is big business this pattern has continued, but engines are now reaching a point that encourages well crafted websites and increased semantic adoption. Web pages and sites that rate highly in engines are those that split presentation from content and follow good syntactical practise. By necessity the migration of the web has:

Overtaken cunning [...], had sped past devious, had left artful far behind and had now, by a roundabout route, arrived at straightforward.

The meaning of web semantics

As a general term the title wraps it up, semantics are the study of meaning. In reference to the web semantics are about trying to place meaning on the content being returned by web sites and web pages.

The relevance of meaning is highlighted in the previous section in reference to search engines. Crawling search engines are driven by computers and computers are by nature not intelligent. A computer program may download, store, run algorithms against any particular web page, but it will not be able to understand adequately the meaning, content and context.

Semantics are closely tied to ontologies. Ontology is the study of what elements are and their relationship to other elements. Referring back to search engines and computer programs. A computer program may download a web page with content on it, but it does not know what that content is. Rather it will have a collection of words; maybe some structural inclination if the page is put together properly, but it cannot tell whether it is a press release, news article, bank statement etc. The program will have little idea about the content on the page or the relationship it has with other content both on the same page or remote.

Together semantics and ontologies combine to provide machine readable web pages and/or frameworks that describe what the content is and what the content means in context. When machines can follow what is going on across the web they can better serve the needs of people.

W3C Semantic Web

The W3C framework of providing semantics to the web uses two core technologies Resource Description Framework (RDF), and OWL (Ontological Web Language). In relation to a web page the RDF could be the following:

Looking at the Dublin Core meta-data standard for web pages an RDF might take the following format:

In the example the Dublin namespace has been used to define general meta-data for the page, this can be extended to support multiple namespaces as in the following example:

OWL (Ontological Web Language), pushes back the boundaries of RDF and provides increased classification when describing ontologies.

Although OWL and RDF provide a framework until there are widely adopted standard ontologies this approach will be the future semantic web.

Semantics in HTML

Semantics within HTML documents are limited to document paradigm semantics (headers, lists, emphasised words etc.), which do not truly reflect the nature of the content. Whilst the nature and structure of the document can be defined using a collection of title, header, paragraph and list elements; the nature of the content itself is somewhat limited. Using the previous RDF example of a news article sitting on the same page as a piece of content, HTML provides no standard way of differentiating between each item of content.

An attempt to tackle the lack of semantic constructs within HTML is the microformats project. Microformats are a collection of open data formats using common HTML patterns and CSS class definitions. An example would be the hCard microformat which follows the vCard standard (RFC2426):

The corresponding hCard is:

Microformats are the leverage mechanism for grassroots developers to enhance the existing semantics of the web for increased semantics.

Need for Standardised Ontologies and Co-operation

Hopefully by this point the need for standardised ontologies is straightforward. Without standard ontologies, software even structured ontological grammars such as OWL and RDF will not be able to correctly interpret the data.

Microformats must follow / lead OWL/RDF initiatives to provide the linkage between the existing web semantic and the future web semantic. By adopting both routes towards semantics, each co-operating with the other as and when required the split between haves and have-nots over technical and feasible limitations can remain controlled.

With each of these points there is a foundation through which semantics can both evolve and grow around the web.

The Role of Content Management in Semantics

Use of a CMS is not an immediate panacea to web semantics. In fact many content management tools (both commercial and free), pay scant regard to even the most basic of semantic constructs. This is a pity since by constructing a CMS in the correct way a majority of the semantic overhead can be dealt with automatically. To a point where a computer will be generating what another computer can understand.

Areas of a semantic ready CMS

• Ontological Breakdown

  It may sound like a mystical riddle, but “When is content not content?” The answer is a little less cryptic in that it is always content, but sometimes it’s a different type of content. Web pages are built from HTML, but that HTML may contain news articles, event listings, shopping baskets and a plethora of other types of content that is in addition to the document paradigm which forms HTML.

  A content management system that is semantic ready will have devised ontologies that link the more standard concepts of site, page and sub-page with more abstract concepts such as news, events, products, baskets, etc.

  The structures used within the ontological breakdown should wherever possible use or extend acknowledged existing formal grammars.

• Content Abstraction

  Once the type of content is defined it must be possible to extract the data of the content from both presentation and render. If the data of the content is embedded within presentational or render information then any connecting semantic browser will have to attempt to extract the data, which is little better than having it sitting on the web page.

  For ease of interchange content data should be malleable. XML is a method of malleable message and data passing, with RDF, OWL and xHTML adopting XML it is and obvious choice. XML allows extension over time and rapid support of future standardised ontologies through XSL.

• Best use of existing semantic constructs

  Whilst the semantic constructs available in HTML are limited to the document paradigm any semantic ready CMS should make best use of them. It should help authors and editors control document structure and encourage the use of semantic elements over purely visual elements.

• Content in Context

  Content should be atomic in nature and therefore within the bounds of a CMS aware of its context. Consider a news article sitting within a page; if the page is already defined then within the semantic nature of the document it is likely to already have a H1 element, therefore on the render of the news article it should not include an additional H1 element. However if the news article has been referred to atomically it would take precedence and the title of the news article should form the H1 element and page title.

• Multiple Delivery Mechanisms and the Semantic layer

  By using XML and controlled ontological breakdown it is possible to introduce a semantic layer into a content management system, as is shown in the following diagram:

  

  The introduction of the semantic layer allows delivery in a number of different formats and technologies such that the underlying data can be passed seamlessly.

  By introducing the semantic layer content only is required to be entered once for each of the different delivery methods. Also future ontologies can be adopted easily by adding further delivery mechanisms.

  The last render method in the diagram was that of a SOAP render. Whilst there would be further steps to consider in any web service implementation; the application of a semantic layer to CMS is a distinct move towards being able to provide coherent web services and service orientated architectures.

Semantic Content Management

Content management is the leveraging technology that shields content authors from the technicalities of semantics. In the migration towards semantics and formalised ontologies it is the responsibility of content management system programmers to introduce semantics into their respective content management systems; those procuring content management systems should be requesting semantic delivery methods as standard and bodies such as W3C should be adopting not only ontological frameworks, but ontologies. There is a long way to go to delivery a semantic web, but it is a journey worth taking.

This blog entry was originally written by Richard Conyard 23^rd June 2006.

Colony CMS

Sometimes here at Red Ant we have a habit of forgetting to talk about the basics, since they are so tightly ingrained in what we do we forget that not everyone else has the same outlook. One of the areas we tend to ignore is content management and at Red Ant our old friend Colony.

Colony is our CMS and content management framework since 2003 over 90% of all websites released by Red Ant have had Colony sitting quietly behind them, doing its job and allowing editors to keep their sites in trim. When Colony was first written the guidelines from Dan were simple at no point should having a CMS dictate and / or restrict the look and feel of the website. Sounds a simple request, but at the time (and to a fair degree even now), those that know content management systems can look at the occasional site and say “that was written in X”. From a technical point of view my requirements were a little more exacting, Colony had to:

• Be easily extensible
• Handle large volumes of traffic
• Be easy to maintain
• Work for different types of businesses

Although there is still improvement to be made, I believe we have hit those requirements. Looking under the hood of Colony makes it a little clearer on how we achieved each of them.

Extensible CMS

Colony runs on XML in all the data behind all the objects and in each of the database tables there is XML. We also run with our own proprietary forms technology called sxForms (simple xforms), which use XML again; this means that if we want to add an additional field into a record we can, simply and comparatively quickly. These are tied into the very core of Colony giving a consistent look and feel across the administration area. I always enjoy showing developers with a history of working with the web their first sxForm and watching it dawn on them that we’ve removed the risk of typos and that the last minute addition that always crops up can be dealt with quickly and simply.

Handle large volumes of traffic

Most websites see very little traffic, certainly nothing that would blanche most content management systems. However I knew that we couldn’t hope that Colony would never see lots of visitors (that would be perverse and contrary to what we were / are trying to achieve for our clients). In Colony we have lots of little techniques and “tricks” to speed things up and some of these must have worked because it certainly can handle traffic. The heaviest levels of traffic Colony has seen is with Property Price Advice after their coverage in The Sun; that lunchtime saw traffic in excess of 100,000 visitors and whilst it was a little slow (5 second page loads), it handled it.

Easy to maintain

Just as good web design is layered into HTML, JavaScript and CSS Colony also splits its code out into distinct layers one controlling data, another business logic and another render. Colony wasn’t the first to do this, but it was unusual, and in some instances still is with normal ASP.NET and PHP more than happy to mix up program code and HTML rather than separate completely.

Work for different types of businesses

With over 300 Colony installs I think that this can be said to hold true . The way Colony does this is to split the structure of the website from the content of the CMS. This means we can have any type of content and any set of business rules sitting comfortably in Colony.

It sounds a little geeky, but I am quite proud of Colony and the work that Red Ants have put into making it what it is today.

This blog entry was written by Richard Conyard.

An introduction to Web Accessibility

Developing a website with accessibility in mind not only maximises your market but has the added benefits of easier maintenance and greater support for search engines.

What is accessibility?

Some people use assistive technology such as screen readers, Braille displays or magnification, and access the internet on a variety of platforms including desktop computers, laptops, mobile phones and other devices. Accessibility is about making sure as many people as possible are able to access and interact with your website, regardless of disability or the restrictions of their browsing environment.

There are several guidelines and standards in place to ensure websites conform to a decent level of accessibility, most notably, the Web Accessibility Initiative (WAI) Web Content Accessibility Guidelines (WCAG). In the UK, the Disability Discrimination Act makes it a legal requirement for service providers to take reasonable steps to allow disabled people to access their services – and that includes websites.

Page Structure and CSS

HTML is designed to describe content, not to dictate styling. Traditionally, some web designers may have used a combination of text size and colour alone to distinguish headings and other page elements. While this may look correct visually, there is nothing in the HTML code to actually identify the different levels of headings, paragraphs and lists.

Assistive software such as screen readers rely on semantic HTML markup to correctly convey information to the user and to provide easy navigation methods to those who are unable to use a mouse. For example, many systems allow users to skip between headings – this only works if headings have been correctly identified in the source and not simply given a special colour or size.

Using correct markup and implementing Cascading Style Sheets (CSS) to dictate styling, keeping content and appearance separate, means that each content element has true meaning, regardless of its appearance. This separation allows the appearance of a web page to be customized to suit the user, and in addition to aiding accessibility, has the added benefit of providing search engines with useful information about the web page and again, allows for easier maintenance.

Links and Navigation

Imaging you find a link that says “click here”, without any surrounding text or explanation. Where will that link take you? Why should you click on it? Many users of assistive technology navigate web pages by ‘tabbing’ through the links on each page or by viewing a separate list of all the links, in a similar way to how sighted users can scan the page visually to look for what they want. “Click here” may make sense when read within a sentence, but when you encounter it out-of-context, there is no way to identify the target.

All text links must be descriptive and must clearly identify the target when read without the surrounding content. This technique has equally beneficial results for search engine optimization when keywords are included. Where images also act as links, the image alt attribute should be used to both describe the image and identify the target of the link.

Keyboard Navigation

Not everyone is able to use a mouse. Blind people cannot see where the mouse pointer is on the screen and users with mobility problems, including older users, don’t always have enough control in their hands to operate a mouse. Many of these usergroups will use their keyboard as an alternative and most tasks can be achieved using this method if the website is designed with these people in mind.

It should be possible to navigate to every page of the website using only the keyboard. If navigation systems are used that require mouse control, as is the case with some drop-down menus, an easily identifiable and accessible alternative route must be provided. It is also important that users are able to navigate through each page, in a logical order, and without triggering unexpected results such as popup-windows or causing the keyboard focus to be lost.

The Title Attribute

Often abused and misunderstood, the title attribute can be used with most HTML elements to provide additional information which is normally rendered by web browsers as a ‘tooltip’ when hovering over the element. Screen Reader support for the title attribute varies and they are often not announced if using the software’s default verbosity settings. For this reason, only additional, non-essential information should be provided in the title.

A common misconception is that every link must have a title. In the case of text links where the link phrase is descriptive enough, a title is unnecessary and simply repeating the link text in the title is worthless, particularly for screen reader users who may have to listen to the phrase twice.

The Alt Attribute

The alt attribute is used to give alternative textual content for non-textual elements, such as images. Users with screen readers or Braille displays cannot ‘see’ images – screen readers will announce and image when it finds one, but it cannot tell what the image shows or what its meaning is within the context of the page.

The alt attribute allows us to provide a description of the image, which can then be announced by a screen reader, transcribed into Braille or displayed in place of the image. As with the title attribute, there are situations where alt text should be omitted. Where images are used purely for decoration or layout and have to real meaning or impact on the page content, alt text is often more of a hindrance than a help.

Forms

One of the major benefits of a website is the ability to collect information from your visitors and the easiest way to achieve this is by using online forms. However, forms can present several barriers to accessibility if incorrectly implemented. Form fields should be correctly labelled with correctly positioned and associated ‘label’ lags – this allows screen readers, for example, to announce the correct name when interacting with each field and has the added benefit of providing a larger clickable area for mouse users.

Mandatory fields (those that require information to be entered before the form can be submitted) must be clearly identified in the field label – simply highlighting these fields with a different colour or other visual clue is insufficient for users who are able to see the screen. Similarly, if a form is returned with errors, it should be made obvious to which field the error applies and what the user has to do to correct their mistake.

JavaScript

Another common misconception is that users of screen readers and other assistive systems browse the internet with JavaScript disabled, or in a special browser that does not support JavaScript. In reality, the majority of these people use standard browsers such as Microsoft Internet Explorer and Mozilla Firefox and have no need to alter their basic configuration.

If JavaScript is used, it should not cause the user’s browser to behave unexpectedly such as spawning new windows without warning or causing the page to refresh or redirect. Equally, the website should remain usable if JavaScript is disabled.

Website ROI and Performance framework

It is not a simple step to purchase a website; rather it is an investment with a high initial cost in terms of time and money bringing together aspects such as:

• Design and Brand
• Functionality
• Content

To get the most from a website there are on-going requirements such as:

• Hosting
• Maintenance and Support
• New Development
• Marketing

Whilst these areas are not the normal buzz terms associated with website deployment they start to make clear that a website is a business investment, and as such it should have a measurable business return and should be judged against performance and targets as a normal investment would.

Website Return on Investment (ROI) pulls together various statistics about the website:

• Page views
• Visitors
• Contact forms completed
• Total purchases

These key metrics (and others), are the building blocks of website ROI and performance modelling; however by themselves they are just numbers. Measuring website ROI and performance requires the concepts of worth, value and adherence to goals rather than simple numbers.

Establishing worth and value can be a haphazard approach; the remainder of this document seeks to create a simple framework to allow the creation of website ROI and performance models before the website is built. Building ROI and performance models before the creation of the website allows focus for all parties to what is important and an agreed structure to monitor performance.

The Framework

Setting the scene

Background

In creating the model the background to the company and any previous website must be known, and should be documented as part of the model creation in clear English.

The purpose of documenting a background is to establish a starting point for that can be agreed by all parties creating the website that can be used to judge the feasibility of expectations and aims; e.g. the feasibility of a website with no previous presence to attract 100,000 visitors in the first month is distinctly lower than that of an established website already receiving 100,000 visitors.

Aims and Expectations

With a background in place the aims and expectations of the site can be formulated. The aims of the website are generally on-going and can be documented in clear English, since year on year it is unlikely that these will change.

Expectations are derived from the aims in light of the background of the site. Expectations should be performance driven and treated in the business case; later in Areas of Worth we use the four precepts of Information, Conversion, Breadth and Focus to group each return, expectations should be aligned with one of these precepts. Expectations should be brief and bulleted; if expectations are convoluted there is the potential for misunderstanding. Expectations should also be rated in order of importance (most important first).

Website Returns

Website returns are the metrics by which ROI and performance can start to be measured. These are the simple building blocks such as:

• Page views
• Visitors
• Contact forms completed
• Total purchases

They are not yet rated into worth, value, or compared against expectations; they are the points at which fixed numbers are collected. Against each return (tangible or non-tangible), a fixed measure of when that return is achieved has to be specified.

Tangible Website Returns

The easiest returns to measure are tangible website returns. These have a direct measurement against normal website metrics; examples of these would be:

• Sales through the site
• Leads generated through contact forms
• People signing up to the newsletter
• People calling a dedicated website telephone number

Each of these actions can be given a simple definitive value to a company and can normally be mapped against ROI and performance on any existing marketing efforts.

Non-Tangible Website Returns

Non-tangible returns are somewhat harder to derive since these have a layer of analysis over and above direct measurement; examples of these would be:

• Brand Awareness
• Reputation / Impression
• Presence
• Education

Each of these could be a direct benefit of a website; however they are not directly measurable. To derive the return on these simple metrics (visitors, repeat visitors, people browsing certain sections of the site), can be used to calculate when these benefits have been achieved.

Worth

Areas of Worth

All aspects of worth on a website development have to be tied into business case to have any worthwhile meaning. Returns should be placed into the areas of Information, Conversion (measurement of goal achievement), Breadth (measurement of access variables) and Focus, as the website expectations have been previously. Although a website can have returns and expectations in all areas Information and Conversion are the opposite in the worth they return as are Breadth and Focus.

• Information

  Information is passed freely from a website without barriers.

• Measurement of Goal Achievement

  Conversion seeks to take anonymous members of the public into leads, recurrent triggered marketing opportunities and sales.

• Measurement of Access Variables

  Breadth follows the approach of many things for many people, in online marketing it is sometimes referred to as the long-tail approach.

• Measurement of specific focused messages/terms

  Focus invokes a specific message or route tied to speciality.

  • Each area of worth should be rated 1 to 10 in order of importance (1 = Trivial, 10 = Critical), the rating of these should align themselves with grouping within the Aims and Expectations.
  • Each return should be rated 1 to 10 in order of importance (1 = Trivial, 10 = Critical)
  • The area rating should be multiplied by the return rating to establish a measure of worth.
  • Worth can then be mapped on a graph the X axis would be Information to Conversion. They Y axis would be Breadth to Focus.

Worth Map

To create a worth map the following steps should be taken:

Placing Value

The value of a website is split into the financial value of website returns and the performance of the website. These should be displayed in a table to allow quick reporting over reporting periods.

Establishing Financial Value

It is easy to over simplify certain areas of fiscal value reporting. In ecommerce sites it is tempting to measure performance on total transaction values ignoring elements such as margin per transaction. It is also for non-tangible returns difficult to place a fiscal value.

For a simple framework fiscal values can only be approximations; however over the lifecycle of the website ROI and Performance framework fiscal values can be amended based on evidence to give better approximations.

Fiscal values can either be fixed, or be calculations based upon simple measurements; e.g.:

Return	Fiscal Value
Total Sales	20% average margin
Sales above £100	5% additional margin
Brand Awareness	1% given brand value for each 10,000 visitors over 100,000

To avoid counting the same value twice each return and value should be aware of previous returns (e.g. If a visitor is worth 1p and a newsletter subscriber is worth 3p: since a newsletter subscriber is already a visitor the additional fiscal value of a newsletter subscriber is 2p).

Establishing Performance

Whilst value is a useful reporting and measuring tool, perhaps what is more useful is performance. Since performance can only be measured by achievement of the site, it needs to factor the worth of each return. Performance is calculated:

Performance = (Fiscal Value of the Return x Worth ) / Mean Worth for all Returns

For reporting the performance should extend the fiscal value table to allow both measurements to be seen side-by-side. The report should be structured:

Return	Worth	Fiscal Value	Performance	Mean Worth
Total Sales	64	100,000	128,000	50
Sales above 100	76	10,000	15,200	50
Brand Awareness	35	10,000	7,000	50

Conclusions

Reporting and Amending

Whilst building a Website, ROI and Performance model benefits in clarifying the goals and associated importance. The key for the model is regular reporting after site launch to measure the performance and ROI of the site. By following the framework, all of the key indicators and values should be established to allow rapid reporting over given reporting periods (suggested monthly).

As important as monitoring the ROI and performance using the model it is also important to monitor the accuracy of the model itself. Simple amendments to the model can be performed by changing the fiscal values, indeed fiscal values can also be calculated against reporting period trends. To this end the model should not be considered static, and should be amended and grow alongside the website.

Analysing Reports

Each model created using the framework is likely to be different in the same respect as each company’s Aims and Expectations are likely to differ. The framework has to a greater degree normalized outlying areas of the site in accordance to value and worth as defined by the Worth Map and incorporated into performance.

By reporting performance and ROI normalized against expectations a number of trends can occur; some of the more common are below.

Performance Values exceed Fiscal Values

The model is weighted toward increasing the performance values of those areas deemed important. This trend highlights either the success of the site in core areas, or that specific areas of the site have been given to greater importance. The model will normalize instances where all areas of the site are important.

Fiscal Values exceed Performance Values

If Fiscal Values exceed Performance Values this is an indicator that the site is not performing in the chosen areas. It may be that prominence is given to areas that detract from targeted returns, or the returns are too hard to get to. If the bottom line Fiscal Values are within or exceed the expected ROI for the given reporting period it may be that the targeted returns do not reflect accurately the goals of the site.

Performance totals are primarily from low worth Returns

Although unique in each case this could be an indicator that the website is not maximizing the opportunities to move people towards higher worth returns. This could be routes to entry; this could be by targeting groups that have little interest in higher worth returns.

Performance totals are primarily from high worth Returns

Whilst this is an indicator of a successful site, it could also be indicative of low audience levels or too higher worth being assigned to certain goals.

During each reporting period reports should be analysed to ascertain where improvements can be made to the site. The bottom line totals should be analysed against expected fiscal returns (e.g. Factoring ‘break even’ periods against the total cost of the project).
This blog entry was written by Richard Conyard.