As ArchVision began contemplating entering the crowded content management market we spent a lot of time trying to identify what was missing. We have dabbled in content management over the years as we attempted to provide solutions to manage our RPC subscription content and provide customers with easy ways of managing thousands of pieces of content. We learned a lot over the years and developed some philosophies to build on.
While at RTC 2013 as I looked around the exhibit hall I half-jokingly started saying “we’re going to be the 159th company with a content management solution!”. You start to question what makes you think you’re different. Why hasn’t this problem been solved? I think the answer probably lies in the fact that it’s hard to get people to change their habits and that’s what most solution providers have offered. In regards to change I often say “of course it’s hard, it’s biological. We’re wired for stability, not change”. An exercise in futility would be to bank on convincing people that a new process will be better.
We started asking anyone that would indulge more questions about how they manage content and kept hearing a couple of things over and over. When asked how they manage their centralized libraries of content there was 100% unanimity. Heads would inevitably lower and voices soften as if embarrassed by their answer. The dark chorus was in unison on their reliance and contempt of Windows file folders. We had more than a hunch that would be the answer. After asking the first couple of dozen times and hearing the same answer from teams that ranged in size from a handful to thousands we knew there was an opportunity to try to help solve a big problem.
Windows file folders make for a terrible database. I think everyone can testify that digging through directory trees to try to find something can be a frustrating experience. When added up would you want to know how much time you waste each year digging? A couple of minutes here, ten minutes there, no occurrence is painful enough to cause a revolution but in aggregate the pain is real. It’s the classic “death by a million cuts”. With Windows file folders, each individual file is relegated to a single location or worse, copies have to be made if you want the same thing accessible in different locations. Why do we do this?
We also had a suspicion (I’m painfully aware of my own habits) that many people also “keep their own local stash” apart from the central repositories. When asked how much of that went on in their operations that reality was also confirmed . But perhaps more interestingly, we began hearing another theme. When you need something, particularly AEC-related content, you’re likely to try to dig back through an old project file to find it rather than fight the Windows folders someone spent an inordinate amount of time organizing. “Hey Bob, what was that project where we used x” or “Kim, do you remember if we used x in project y?”. And then off you go, a new scavenger hunt. Sound familiar? The archived project file served as a better database than the central file folders!
Parsing these hundreds of conversations led us to identify what we think is at the core of efficiently getting to content. Context matters. Duh! It’s how people think. We’re frustrated with Windows file folders because it forces us to try to think in unnatural ways. We dig back into archived projects for nuggets of gold because the initial project context was a well-defined path and the first thing that entered our brain when those synapses started firing. If you enjoy learning about this kind of thing you should read Daniel Kahneman’s Thinking Fast and Slow. It helps explain not only how people think but why our brains are wired that way. Here’s the short version… the brain is an amazingly complex organ, biologically wired for efficiency. Given this understanding we think the way we go about organizing and accessing content needs to change.
Windows File Folders Do Serve A Purpose
The reality is that Windows file folder can work… for the person who created them. That’s why everyone else (sans the person who created them) gets frustrated with central repositories. It’s also why everyone keeps their own stash. It fits “their” context, at least until it doesn’t. Those file folders can work as a logical way to store content. All those files have to be named something and physically go somewhere don’t they! The trick is to separate the problems. Divide and conquer. Treat the storage problem separately from the retrieval problem. This led us down a new path.
With all of this newfound knowledge we set out to attack the problem in a new way. #159 will be different! We established these primary criteria for a solution…
1. Don’t disrupt current work flows. It’s futile to start there. Rather, augment what’s already going on.
2. Don’t require anyone to move their existing content (ie. you can leave it in those awkward Windows file folders). Admittedly this was probably driven initially by a desire to position opposite all of the “store it in the cloud” offerings that are popping up daily, but in reality it’s about separating the storage problem from the retrieval problem. Who cares where the content lives as long as your users can get to it easily. Moving content “to the cloud” doesn’t solve the context/retrieval problem.
3. Provide the end users with a visually driven, context-sensitive way of finding content.
4. Be content agnostic. There are any number of important types of files that need to be centralized, organized and retrieved.
Here’s how AVAIL works. First, we let you create Channels for accessing content. The concept of a Channel in AVAIL is the primary way of beginning to provide proper context for content. You can create any number of Channels and each Channel can contain any combination of content.
Secondly, want to build two or more Channels that contain some of the same content? You can, and without making copies of the file(s). AVAIL doesn’t move content around, it’s indexed. That’s how we begin separating where the content is “stored” from how it is “consumed”. The index provides flexibility on the front end. It let’s you get to content from multiple entry points (Channels) and is the key to providing unlimited contextual entry points to the same piece of content.
Thirdly, provide a visual way to drill down to the content you need. AVAIL does this with a new tag-driven filtering technology we call Panoply. Panoply provides the ability to create contextually sensitive arrangements of tags per Channel. As you click on Tags in the Filters panel of a Channel you are essentially expressing intent, a direction. Tags that are irrelevant based on your choices disappear. It’s a dynamic contextual path of sorts. It’s one of those things you have to experience to fully appreciate its effectiveness. A massive amount of meta-data can be encoded as Tags and arranged for logical context in AVAIL. You can parse through thousands of files to get to just the right content in a handful of clicks. Need to see the same content in a different context? The same content can live in a different Channel with filtering designed to fit the new context.
We think we’re onto something and working hard to fulfill the promise. The first place you can experience AVAIL and the new Panoply approach to filtering is in the recently released Detail Warehouse product. AVAIL is providing the interface for managing a library of over 27,500 native-built Revit Drafting Views. We’ll also be showing off AVAIL at a couple of events before the end of the year. Look for us at the RTC Europe (booth# 18) event in Budapest, Hungary at the end of October and soon after at Autodesk University (booth# 1213) the first week of December in Las Vegas, NV USA. If you can’t catch us at any of those event you can sign up for updates at avail.archvision.com.