Category Archives: Improvement

You can’t always have what you want

This entertaining diagram that I saw on LinkedIn this morning touched a chord.

Interfaces

Like all good humour it makes a critical point, or perhaps even several points.

It certainly typifies different approaches. Apple’s fanatical insistence that anything can be achieved with a simple interface. Google’s equally fanatical insistence that everything can be achieved with a simple search interface. And the common application development teams resigned insistence that you can just throw all the data capture onto a page and call it a business application.

The thing is that often Apple (who routinely make things incredibly difficult by trying to make things too simple) and Google (who make things undiscoverable by finding everything) often overlook that fact that some business processes are actually complicated.
The Einstein Principle applies (http://www.c2.com/cgi/wiki?EinsteinPrinciple).

Continue reading

Leave a comment

Filed under Improvement, UI and UX

15 Reasons Not to Use Folders in SharePoint (and 3 reasons why you could)

I hate folders as a means of organising content. It’s a deeply broken approach and carrying it over to SharePoint is one of my pet hates. I have even written a song about it. So I pulled this together from my involvement in various conversations and involvement in a discussion arising from an article written by Gregory Zelfond. http://sharepointmaven.com/12-reasons-folders-sharepoint-bad-idea/

  1. No right place – this is the biggest issue and most easily understood; folders force you to put a document or file in a single location, even if it might legitimately be associated with several places. A project report could be put in a folder with all the other documents for that project, or in a folder for reports, or in a folder for documents that are archived; in reality it should be in all three but that creates duplicates. SharePoint metadata would let you tag the document as being a Report, associate it with a Project, set its status to Archived and more. Different views would let you see (or hide) all Archive documents, all project reports, all documents that are not in draft that have be modified by me in the last 7 days and include the Technology tag, etcetera, etcetera. And you can switch between views with a single click.
  2. Usability – Unless you have a rigorous and actively managed file plan (and, let’s face it, no one actually does this well) then the folder structure is only known to the person/team who created it. Everyone else has to inefficiently browse the contents hidden in the folders in the hope of finding the document or file.
  3. URL length limitation – SharePoint builds the URL using all folder and sub-folder. However the URL length is limited to around 255 characters; beyond that you get an error. Deep folder structures simply break in SharePoint.
  4. Unfixed URL – Moving a file from one folder to another changes the file URL, so any fixed links to it will break.
  5. Security – You can use folders to define security for groups of files in SharePoint, however ongoing management of this is as big an administrative nightmare as it is on file servers.
  6. User experience – The user experience (UX, navigation, finding the documents) is marginally worse than it is on file servers – it’s slow, content is hidden until you open the folder. Moving content within folders is terrible within the browser, navigating between folders is horrible too. (though you can open the library in Windows Explorer).
  7. File duplication – Folders actively cause file duplication, partly because there is no one, right place for a given document or file (in fact you often have to put a file in multiple paces because folders are so inflexible), partly because you can’t see that the file already exists elsewhere. If you are striving for a ‘single version of the truth’ then creating duplicates immediately undermines this principle.
  8. A single view – One of SharePoint’s many great features is the ability to have multiple views of content, with the flexibility for users to filter and modify the view on an ad hoc, temporary basis. But not with folders, in a folder view you get just one view of your content and it is pretty poor, for the reasons above and below. Using metadata, you can create unlimited number of views by whatever properties you have setup (i.e. organize documents by date, by customer, by project, etc.) .
  9. Can’t Sort & Filter – Burying files in folders means you can only benefit from the sorting and filtering capabilities of document libraries and metadata navigation within the folder you are in.
  10. Inflexible – It’s hard to change the folder structure (though again you can use Windows Explorer), while changing metadata is easy and can be done as bulk actions.
  11. Lost documents – It is so very easy to misplace documents by putting it in the wrong folder and not knowing where it is. So then you create a duplicate copy, and the mess begins.
  12. Navigation – When you are in a particular sub-folder, there is no easy way to tell which folder you are in and no easy way to navigate to the parent folder, a sibling folder etc. since there is no breadcrumb trail or tree view by default.;
  13. Cost – If all you are doing is recreating the same mess of nested folders you had on file share within SharePoint all you have done is increase the cost (SharePoint infrastructure is more expensive than a file server) and you have cunningly avoided almost all the benefits of SharePoint.
  14. Visibility – the only way to know how active a folder is/how many documents it contains is to open it. It could be empty; it could have ten thousand documents; you just don’t know. A grouped SharePoint view in SharePoint using metadata shows many docs are in each group (and lets you carry out counts and other basic arithmetic on column values, such as Average file size). If there are no items in a group then the group doesn’t clutter up the screen.

    The power of SharePoint views - who needs folders when you can have groups, filters, metadata navigation and more?

    The power of SharePoint views – who needs folders when you can have groups, filters, metadata navigation and more?

  15. Data Integrity – There is little control over the naming of folders, so you can have spelling errors, non-standard conventions, unhelpful abbreviations etc. Metadata driven views can be driven by lists and taxonomies to avoid this.

Exceptions

The big problem is that folders are traditionally used to categorise content, whereas they were originally designed to group content. Just because we have learned to use folders inappropriately doesn’t mean we should continue to do so. However folders have some legitimacy for their original purpose. If you genuinely need to group files together then you can use a folder in SharePoint; this is usually because you need to perform a group action on them, such as delete them all. Similarly folders may be used (despite point 5 above) to assign grouped security to the content – simply moving a file into the folder gives it some security; as long as the security rules are very simple to apply and understand. In both cases you still should avoid folders – use a Document Set instead, since they are much more powerful, intelligent and intuitive. Even then we strongly advocate having only a single level of folders and never, ever more than two,

The only other reason for retaining is that you can’t get users to adopt the new, better way of doing things. At this point you have to use your judgement – generally staff work for the company and the company can dictate ways of working; there are rules for not operating machines without guards, even though they can be somewhat inconvenient for operators (until it saves one losing an arm); the digital health of your knowledge is as important. However if a team or individual chooses to stick with folders for their own content then that may be OK; as long as it doesn’t disadvantage other staff and that they aren’t wasting company resources (working time, support desk resources, computing time) in the process. A suitable policy for use of your intranet can address this – shared content, core business processes, managed information should not allow use of folders in libraries; personal and team working areas may use folders, but should avoid deeply nested folders, should also use flat views (where the folder structure is hidden) and must be actively managed by the team to avoid duplicates and misfiling.

1 Comment

Filed under Improvement, Intranet, SharePoint

Zero Tolerance and the 1%

​Reading the Friday morning blog of the rather excellent Ed Reid  this morning on how many small improvements can make a big difference I was struck that it resonated with part of my talk at the NHS event Cloud2 hosted in Manchester the day before. As with Ed’s comments, I referenced the Olympic 1% improvements approach, but I also asked delegates to think about New York Mayor Rudy Giuliani’s Zero Tolerance programme. While Giuliani was focused on crime, mine was on the legion tiny business ‘crimes’ we allow to go unaddressed: the little delays in processes, bad habits, tolerated poor practice or slightly broken systems and the tendency of not fixing small things when you find them. All the many, many inefficiencies that not only mount up and erode business efficiency, but also create a culture for staff where larger inefficiencies are tolerated and where your team doesn’t believe things can be changed for the better because not even the little things get attended to.

This is not just in the wider context of business, but equally true in SharePoint development and acceptance of almost good enough implementations. It is so very easy, near the end of the development cycle, to leave the little things unfinished or to fail to optimise applications and the UI for the actual user (rather than the developer’s idea of what is OK for a user).

Every now and then I have a rant about people (our developer team and end users alike) not filling in things like the Description field in sites, libraries etc. in their SharePoint portals. Inconsistent metadata, variable navigation, different UI and branding, variant naming conventions, governance rules, spelling mistakes ands typos. Things that just don’t quite work correctly. It’s details like this that can make all the difference to the user experience, search, etc. Their absence or inappropriate content can stop a site feeling professional or polished and actively niggle users whenever they interact with a site of process.

The irony, of course, is that the minor things are often so easy and quick to fix, and mostly by team members themselves, if only you ask and give them the freedom to do so.

Accepting these minor transgressions become the ‘gateway drug’ to bigger cultural and business problems. But being seen to have a Zero Tolerance to little issues, of fixing the 1% problems, tends to reap massive rewards for much less effort and cost than mounting another big improvement project.

I recognise that the Pareto Rule applies, and that the last little things can take a while to fix, but not if you get everyone involved to actively help. We should properly finish what we started.

2 Comments

Filed under Improvement