#About Flutterby# For several years we have been working on large scale enterprise software projects, often spanning several countries, and we got fed up having to use different applications to handle defects, manage work requests, ask questions and generally communicate (not to mention traipsing through the different applications if you ever needed to find something again!). So Flutterby was born!
###So how exactly does Flutterby attempt to tackle these issues?###
##One Web App to Rule them All..## Well, kind of. Flutterby is a single web app built with common collaboration/communication tasks at its core, but presented in a user-centric way, so always presenting information relevant to the user. The problem we had with the many web apps we had to use for different tasks (e.g. defect tracking, team/personal todo lists, work tickets) was that because there were so many of them, none of the apps were "always on" - which meant that to perform any of these tasks involved many needless steps (opening the application, logging in, and then actioning the task). We wanted Flutterby to be something that users stay logged into and use as an integral part of their day to day tasks, and we have put a focus on enabling users to perform common tasks quickly with minimum fuss.
##Real-Time Live Updates## Whilst keen to avoid tags like "Facebook for the Enterprise", it's clear to see that sites like Facebook and Twitter have come up with some pretty clever metaphors for user interaction - Ideas such as "Following" people have been proven to be an effective method to allow users to control exactly which relationships matter to them in a social settings. Similarly, the live activity "Wall" concept has proven an effective way to allow users to digest a high-level view of activity in a structured and coherent way. So we figured it was about time enterprise software started taking advantage of these tricks. Flutterby allows users to select teams/users to connect to so they can manage the updates they get across a project, and delivers all activity via a familiar "wall" mechanism.
##User-Centric Approach## So we have bandied the term "user-centric" around a bit on this site, and all this really means is that when a user logs on, the view of the application is distorted to their perspective so is relvant to themselves. When a user logs on, similar to other popular social sites, they will see their own activity wall/timeline along with quick action options to perform tasks and a further distilling of relevant activities that are particularly relevant to them or require some action (e.g. a user posting a status update is not necessarily going to be of that much interest in a professional setting, but if the logged in user has been asked a question, or assigned some work item then its important for them to be able to identify that from the live activity stream)
##Crowd Sourced Knowledge Base## For a long time, people have tried to tame the beast of a collaborative knowledge base, and its no easy feat, but we think people are getting close now.
The web has long been host to many, many forum/message board sites providing support and attempting to answer questions, and one of the benefit is that a forum is a community based site and the questions are conversation driven, so provide a more engaging experience for users, and ultimately resulting in more activity and user participation. However, the main problem with this is that when trying to go back through a forum to access stored knowledge it can be difficult to determine the right answer to a particular question in a thread. As forum threads are essentially conversations, the correct answer may be at any point in the conversation, and is rarely the last post in the conversation.
Another alternative that has often been tried in large projects is the Wiki. Whilst Wikipedia is an undoubted success, the same cannot be said for internal project hosted wikis. Wikis offer the benefit of providing accurate, easily searchable information, but the problem is they do not offer any real user engagement. You may think you can dress up your knowledge base as a wiki, but at the end of the day, writing a wiki entry is just as dry as writing any other form of documentation. And have you ever tried to get a developer to write some sort of documentation?
So the currently popular approach is crowd sourced question and answer sites (such as any of StackExchange's fine sites) - this seemingly offers the benefit of an engaging community/conversation led user experience but the ability for users to "upvote" or mark answers as correct means valuable information bubbles up to the top, making searching for effective results a lot simpler!
At the end of the day, developers will be much happier to have the opportunity to school other users in the finer nuances of some technology best practice than having to sit and write documentation all day long.