Folders are not the solution, · familiar paper paradigm -Paper inside cardboard inside boxes...

Folders are not the solution,

they are the problemDisplacing folders from the centre of information design

byTrish O’Kane, Intellectual Lead for EIM

Knoware The Knowledge Warehouse Ltd

Analytics and Information Management Services Consultancywww.knoware.co.nz

About Knoware – 1.1 slides, that’s it

Why do we have a love affair with folders?

“Ready, fire, aim”

Faceted (component-based) analysis: Case study using shared drives

Metadata-first approaches:

Case study using SharePoint

Today we will cover

Ready?

Photo by Trish O’Kane

About Knoware

Analytics and

Information Management Services Consultancy

Our core service offerings

Knoware is fully certified to the ISO 9001 quality standard, providing peace of mind that we’ll provide rigour and quality processes to your project. We’re also certified ISO 14001 for

Environmental Sustainability.

Why do we have a love affair with folders?

Photo by Trish O’Kane

Why folders?1. Behavioural� We’re used to them � They come out of a familiar paper paradigm ◦ - Paper inside cardboard inside boxes

� “Ready, fire, aim.” ◦ Solution first. Now what was the problem?

� We don’t trust each other◦ So we set up fiefdoms

2. Personal control (it’s about “me”)� I can create folders, � I can move stuff around� I can put it “there”, ◦ and if I can’t remember where “there” was, I can create several places and save “it” in some of “them”

� I can control “my folders”, “my stuff”, ◦ I’m not worried about what happens when I leave

Why folders? cont3. Belief systems

“the Triumph of Hope Over Experience”….� Offer the prospect of certainty. “It will be in here”

� or if not, it will almost certainly be in there,

or there, or there…..”

� Appear to be◦ Precise, exact, fixed, reliable, hierarchical, ordered

� But can become:◦ Bob’s stuff

/New/Old

/General/Miscellaneous”

/Other

4. Technical

� It’s all we’ve got; we don’t have a database/EDRMS/ECM

� “If your only solution is a hammer, everything looks like a nail”

� We do have technology and it includes (drum roll…) folders! See 1. Behavioural

“Ready, fire aim”We are trying to achieve too muchWe are trying to: Assumptions

Build folders • Build first, analysis later

Create reliable pathways for people or systems to

save and retrieve information

• The emphasis is on “path” rather than “way”

Cluster information to minimise scrolling • Assumes that scrolling is how people will navigate

• Need to keep building ever-lower folders

Be compatible with access permissions and keep

groups away from each other

• Assumes that the organisation knows who should

read/edit what

Build in the context of Function and activity • Assumes that this has to be obvious to everyone

Apply Disposal Rules • Assumes folders supply right info. Distorts usability

Use it as a reporting tool !!! Really???

Cross-reference • Assumes robustness and stability– in fact it is fragile

Build irrelevant layers e.g.

• Which team

• Location of that team

• Put systems under governance layers of

Programme/ Project

• Region above Country

• Location then Customer

Assumes that:

• We have to duplicate context that is already in

another system

• We have to express relationships between entities

• Everyone understands the groupings

Think again� What information do we need in a hierarchy?◦ What is clutter?

� Navigation not the best/only way◦ What else improves retrieval?

� Cluster information◦ Favourites/shortcuts to create our own views

� Hunt - use search and saved searcheswhere there is reliable information in

� A folder name � A document name� Metadata� Text in a document (e.g. documents generated from templates or by other systems)

Keep thinking� Simplify permissions model◦ Align with systems e.g. case management◦ Challenge the need for restrictions

� Processes matter to people, start there◦ Link to Function/Activities via registers/background systems

� Disposal◦ Separate administration from work outputs◦ Use rules based on context, users don’t apply disposal

� Eliminate relationships from a folder structure◦ Use reporting systems for reporting! Or build a register◦ Use unique identifiers, don’t rely on hyperlinks

� Eliminate the irrelevant◦ If another system knows the detail, leave it out of the folder structure

� Flatten lists, use type-ahead/search/favourites

Information Architecture

an integral component of successful

Information Management

What is Information Architecture?

Source: All of Government Information Architecture and the ICT Strategy and Action Plan, August 2013

Management, Discovery, Sharing and Useof information

Principles, Processes,Models and Semantics

involved in designing a cohesive set of information collections and their classifications and relationships, in order to support effective:

What do you really need?Info Architecture components

Standardised description • Entity models• Standardised fields• Controlled lists and rules for populating fields

Taxonomies • Business classification schemes• Ontologies• Thesauri• (where needed) File plan design

Management rules • Access control models• Retention and disposal schedules• Information sharing rules

Implementation • Site and library architecture• Content types• Document sets, etc

Faceted (component) analysisAnalyse components, determine which are relevant, THEN arrange them

Case study – legal technical rulings

� Interpretations of legislation

� Each interpretation is a case.

� They have a Case Management System (CMS)

� Several teams within a group, within a large organisation

Where to use

Components Folder Document CMS or

Register

2 types of cases:

• Private ruling - identifies a

person/organisation

• Public Ruling - doesn’t identify a

person/organisation

Y - Y

Case identifiers (created by case management

system)

Y Y Y

Case names (in case management system) Y - Y

When the case started and completed - - Y

Standardised sub-folder pattern for every case Y - -

Sub-types of cases - - Y

In the group, which team/person is working on a

case

- - Y

Team/person location - - -

Area of law - - Y

Relationship between cases - - Y

Person or organisation for private rulings - - Y

Document type - Y -

Date of document Y -

Version or status of document Y -

Unique identifier

Y

Helps humans

Y

Predicable rhythm

In ECM would be automated

- Facets

Design for Rulings

Aligns with Case management system

Implementation� Security ◦ Trust. All teams can access every case, as they can in the CMS

� Template◦ There is one templated set of folders for each case, applies to both types

� Big bucket◦ Many cases, set up favourites, move inactive cases out of the way

� Retrieve◦ Search by case identifier or short name, both in the CMS.

� Storage◦ The CMS knows which cases are inactive◦ Inactive cases can be hidden/moved to tiered storage

� Migration◦ The teams tidied up existing case folders in existing folders, refining the sub-folder pattern

◦ Tidy-up - 3 months, around existing commitments◦ Migrated in one day

� Documents◦ Naming convention independent of folder◦ Case identifiers included - favourites/shortcuts/links still make sense◦ Obvious which document is the right one before you open it

Outcome

� They are very happy with it

� Simplicity and predictability very valuable

� They patrol it themselves

� They adapted quickly to case-basedrather than team-based

Metadata-first approachesCase study – an authoritative repository for a large IT projectusing SharePoint 2007

I understand the

concept of

metadata….

just not as it

applies to me

Photo by Trish O’Kane

About the project

� Huge project to consolidate IT systems ◦ Two organisations at risk

◦ Keen oversight from committed Directors

� Needed authoritative repository for key documents◦ Create an authoritative record of a significant programme

◦ Facilitate decision-making

◦ Meet audit requirements

◦ Create a resource for future re-use.

� Had very strong governance◦ Used well-established project management tools

◦ Had well defined deliverables

� We focused on the information repository� In 2012, still using SharePoint (SP) 2007

Beyond folders

� SharePoint offers “hierarchical” tools◦ Site collections◦ Sites◦ Libraries

� And ◦ Lists◦ Document Sets (Smart Folders)

◦ Content types◦ Document grouping in a library◦ Metadata schemas – internal/external to SharePoint

Folders are hierarchical passive containers, just like in Windows

Resist the impulse to use them

SP Document sets

� Embed and control metadata

� Get metadata from lists

� Pass metadata to documents

� Integrate with workflows

� Run rules

� Use for cases/jobs (start/stop)

How to get reliable metadata

SP lists• Provide metadata• Integrate with workflows

Big bucket – use metadata

� Not much metadata

� Display it in columns

� Filter to find

� Saved searches◦ You see it your way, I see it mine….

◦ Different views in the same library

� Hundreds to thousands of documents in one “bucket”

� All manageable, all easily retrievable

Approach

� SharePoint 2007� “Out Of The Box” (OOTB) functionality ◦ to enable future migrations ◦ just a little bit of Java scripting to help users save and migrate documents

� Use content types to implement standardised metadata

� Use columns and views within each library, to display metadata and enable easy filtering

Simple site structure

� 8 libraries, no folders◦ Thousands of documents

� Built to suit the BAU teams who inherited the project outputs.

� Technical libraries ◦ By system type

◦ Not by project work streams.

◦ Project work streams show as columns within each library

Image of site

Filter to findMulti-system Library held 200 documentsFilter on: Workstream= Enterprise Architecture + Doc type = SAD Result: 2 documents

Green = System metadata

Behind the scenes

� We talked to users about “tags” (metadata)� For any library: ◦ Workstream, Document type, Status

� For technical libraries, add on◦ System – ID and Name◦ Testing Phase

� For governance library◦ Name of Committee, Date of Meeting

� Controlled lists developed to populate each field� Some fields permitted multiple values, to associate a document with◦ More than one system, more than on project milestone, etc.

� Testing documentation◦ System-testing documents – which system(s)◦ End-to-End testing documents are system-independent

Different content types • Request specific metadata

• Have relevant pick lists

Eliminate false dilemmas

By work stream or by system?

� Each is a column in the library

� Filter on either

� Filter on both

� Add on other filters

� Create the views you like

What was most challenging?

� Simplifying the list of document types

� Showing people they needed very little metadata◦ Typically only 4 fields needed, e.g.

� Document type, work stream, content type, system◦ + 2 more for the governance programme

How long to build the site?

� 1st site◦ 3 months

◦ 2 people working part-time

� 2nd and 3rd sites◦ 1 week to build both

� Migration typically ½ day or less, per group◦ Can use List view to drag and fill metadata

Outcomes

� A demo site is worth a thousand words� A revelation to folder-lovers � Document title not very important� A prototype of document-library design� Typical reactions ◦ “This is beautiful” and ◦ “This is how we should be working”

� Meets project audit requirements� Easy to apply retention and disposal rules in a metadata-rich environment

To sum up

� Information architecture approach

� Analysis - before design - before build

� Faceted (component) analysis

� Use metadata

� Remove clutter

� Keep it simple

� Challenge every folder…