Confluence
Case Study – Red Ant
- Headquarters
- Sydney, NSW, Australia
- Industry
- Website design and development
- # of employees
- 11 employees
- # of people using Confluence
- 140 users located worldwide
- # of Confluence spaces
- 50
A conversation with Ben Still, Managing Director of Red Ant
Red Ant is an award-winning web design and development firm based in Sydney, Australia. As an experienced team of 11 ants, the firm helps their clients produce extraordinary online experiences for their customers. They design online visual and interactive elements, as well as develop the technical nuts and bolts from page templates to personalisation and content management.
Why use a wiki?
We tried a number of different approaches, and looking back they were all based on a central editing model. A wiki made sense because we wanted everyone to be able to contribute and participate. It is also closer to the way that we like to work with our customers. By allowing everyone to be able to add and reshape content, more people became involved. We moved from one person slaving away creating pages and the rest of us having to wait for them, to a situation where one person gets the ball rolling, and then other people can join in to complete the task.
Say, for instance, we've created a design and need to show it to our client. First, a designer makes a page, attaches an image, and they're done with their part. But then I might look at it and realise that it needs a bit more explanation, or a link to a wireframe diagram to give context. One of our developers might have also mocked up how a menu works, and so they stick in a link to that. Our client might email the link around, and then add some comments on the page. This kind of collaborative workflow is one of our strengths, and it is really important for us to be able to add these various types of content easily.
- "We love that we can use Confluence across all of our business areas — to create a project space for a client to show them Flash game prototypes and design images, and then also to use it for detailed software documentation." Ben Still, Managing Director at Red Ant
Why did you choose Confluence?
We're in the business of communicating ideas, and making things easier to understand. Many of the other wiki platforms look like amateur blogs and I think we would have given the wrong impression about our work: "If their extranet is this poorly laid out and hard to navigate, what will the site that they are designing for us look like?" If our client communications were complicated or messy, we would have scared people off. We found Confluence allowed us to quickly make good looking pages out of the box. That's not to say that someone can't make an unnavigable space in Confluence — it's just that we've found it's fairly straightforward to make something that is presentable to a client.
We love that we can use Confluence across all of our business areas — to create a project space for a client t o show them Flash game prototypes and design images, and then also to use it for detailed software documentation. We can pull in lists of JIRA issues, and automatically create status summaries of projects in progress. Another key reason we chose Confluence was the way it manages user groups and security.
Why is security important to you?
Red Ant doesn't make top secret rocket ships for the CIA, but I think security of information is still a big concern for most folks. Professional services are based on trust. Accidentally showing a client's new web site design to a competitor would erode that trust pretty quickly. Being able to set up an account and give someone appropriate access is something we constantly need to do. If it's not easy, people will find it too much hassle and just create "group" usernames (a problem we've had previously). Clients get understandably cranky if they've allocated some time to look through our project updates and have to spend most of the time trying to figure out why their password no longer works! The system needs to work smoothly and reliably. I don't want a user to be able to hack the url to get in to other areas of information.
We've hooked Confluence up to our LDAP, and it works a treat. LDAP now drives the user authentication for all of our applications, including Content Management tools. Having one username that works across everything is a great benefit. Ironically one of the first things we started using a wiki for was to track various usernames and passwords!
Marketing and ad agencies do so much collaboration with their customers, how do wikis compare with other methods of collaboration?
Using a wiki as a collaborative tool has been useful for us in a few areas.
The first is speed of publishing. I was discussing with a friend the difference between a wiki and other types of Web Content Management (WCM). His view was that wikis were just another buzz word, and it was all just WCM. From my perspective, a key difference is how you can quickly get a diagram or description up there, and then invite other people to read or collaborate. There's no template to choose from, no workflow to route through, and the page will appear where you expect it to. I use this a lot when I'm speaking with someone on the phone or in a meeting — I can quickly mockup something and publish, and get them to look at it while we talk. This is better than email, since I can keep on adding material. Other people can add comments and edit, and then summary pages such as our Work In Progress can link through to it.
We still do lots of phone calls and in-person meetings, but another spot where a wiki has been of unexpected benefit has been in documenting meeting notes and actions. We have lots of design reviews and briefings, and it's really important that the issues discussed are documented so that the project can move forward. In the couple years that we've been using Confluence, I still send out the email but it has a link to the wiki page. Any comments and additional files or information get attached to that. It's also good for projects for bigger companies where there are lots of stakeholders, since everyone can view designs and project plans in a central place. It's fantastic for working with clients that aren't local, or even in our time zone.
When, if ever, do you transfer data the old-fashioned way? CD-ROMs, DVDs, email?
We still get most of our stuff, particularly large files, either via email or on DVD, often because that is the way that our client has got it in the first place. I think it will take a while for this to change. Once upon a time, we used to create an 'upload' page where people could load files up using a tool that we'd built. Now we just create a wiki page and get people to attach their files there.
In addition to using Confluence with your customers, are you also using it with service agencies such as printers or sub-contractors?
Yes, we often need to share information with subcontractors or other agencies or developers. Sometimes they will just need to download files, and on other occasions they will need access to add content.
To give you an example, we were recently working on a large project with Huggies. Another agency was also working on the project and we needed to give them access to design wireframes that we'd created. We didn't want to have to recreate and maintain a separate set of files because we were constantly updating. On the other hand, we didn't want to give them access to the entire project space. Sounds simple, but in reality it can be a real hassle. I set this up in about 10 minutes by creating a new group, and then using the restrict view to feature.
The commenting feature is used extensively in your system to manage communications between your staff and clients. Have you noticed any particular comment behaviours?
When we first set up our wiki, we thought that everyone would be interested in adding and editing content, but it didn't turn out that way. It seems that most people are "afraid to break it" so they don't edit it. But once shown how, they are quite happy to leave comments at the bottom of the page.
As a result, we've noticed a few interesting behaviours have emerged:
- participants - these users are very actively engaged, and are constantly reading and making comments. They don't actually make pages, but are happy to leave comments and engage in discussion that way. They complain if we don't make regular updates!
- lurkers - these users read through pages, and scan updates. They never actually make comments or author, but then will surprise you in a meeting with a casual mention of something that shows that they are a regular reader.
- crammers - don't read updates, but then do a huge catchup just before a meeting. I think they really appreciate the 'What's New' list :)
- "Since Confluence sends out a daily status email, it really helps us to communicate that we're working very hard on your project. It also conveys professionalism. New clients often comment about how impressed they are. They can see how quickly we respond to things, and are able to choose how involved they are." Ben Still, Managing Director at Red Ant
You told us once that Confluence has become the most important client-facing application you utilise. What ramifications does that have for how Confluence will evolve?
One of our problems is that because we're a small team. When we're in the midst of a large and complex project, everyone's busy 'doing' rather than communicating with clients. What used to happen was that customers wouldn't hear from us and would assume that we're too busy on other projects. Since Confluence sends out a daily status email, it really helps us to communicate that we're working very hard on your project. It also conveys professionalism. New clients often comment about how impressed they are. They can see how quickly we respond to things, and are able to choose how involved they are.
We're hanging out for enhanced LDAP integration and being able to use it for both JIRA and Confluence, which should make user account management easier and more flexible.
Are you using Confluence in ways that you hadn't expected?
Yes, by explaining complicated messages. When we first started wiki-ing, I thought we'd be posting lots of documents and that sort of thing. What has been unexpected is the way that you can quickly add in diagrams and images as part of a page to better explain something. For example, I was trying to explain a problem that we were having with the design of a pharmaceutical site. The design called for alternating colours on table rows, to make things easier to read. We hit a snag when implementing this, which was quite hard to explain with words. Here was how I explained it:
I was quickly able to add images and a table with some commentary, and by doing so explain something that would have taken much longer over the phone or in an email.
Initially we had thought we'd use Confluence to create lists of links to web pages, which would have updated designs or code for the client to review. What we've found is that it is much easier to embed the visual designs or code into the Confluence page rather than keep it external. This keeps it secure, easy to access, and people are alerted when it is updated.
Do your clients know they're using a wiki? How have they responded to Confluence?
I think the term "wiki" is still a bit unknown to most of our customers, but in the end it doesn't matter too much — they're just interested in getting quick updates and information. When we first set up a client, we send them a welcome letter with access details and passwords, as well as an outline of how we work, where to look for updates, etc. This has been useful for getting people on board and involved from the start of a project. We also do training sessions if it's required to walk them through how things might work and where to find information.
How do you use JIRA in relation to Confluence?
We explain to our customers that we use Confluence for the day-to-day project stuff and then JIRA for the development nuts and bolts. We use Confluence on almost all of our projects, and JIRA for larger projects that are by their nature more complex. We use them together, too — it's useful to be able to show a summary of the project's JIRA issues within Confluence. It's hard to draw a line about what we put in JIRA, what goes in Confluence. We've found them both powerful tools. An example of how they're used together is that we might be halfway through a project, and suddenly it becomes apparent that there's some other work that also needs to be done. Say reworking some CSS code so that it can be applied to another area of the site. If this work is mainly task driven, then it is often easier to write up the tasks as issues in JIRA, create a new component, and then bring that list in as an RSS feed to a Confluence page. This allows us to work really efficiently and our client isn't required to go to JIRA to get an overview — Confluence does it quite neatly.
Also, a big part of our work is in understanding and analysing how a particular project is performing. We feel there's no point in creating a fantastic game or promotion if you don't watch how it performs and tweak it. We perform this tracking and analysis for many of our clients. This involves creating a monthly report showing impact and signups for example. Typically, each report will trigger a series of questions or suggestions for improvement, like "why were those numbers so high", "let's change that", etc. Rather than loading all of the reports into Confluence, we've found it easier to have these as JIRA issues. Then, as additional information and requests are added in, it is much easier to understand and track the relationships. These get sucked in to Confluence to create a nice looking summary page. If you want to dive in deeper to see what relates to what, clicking on the link will take you in to the JIRA issue.