Tag Archives: Information Architecture

Office 365 collaboration – somewhere between easy and hard

The Microsoft Story around Collaboration Has Never Been a Straightforward One, with Different Styles of Collaboration from Email, through Skype and into SharePoint Each Being Supported by Their Own Microsoft Technical Team; at Times It’s definitely felt like the different teams compete rather than collaborate (and the irony is not lost on us).

With the emergence and massive growth of Office 365 the tale now has some additional subplots  in the form of OneDrive for Business, Office 365 Groups, Microsoft Teams and the still relevant  SharePoint Online. It’s not easy to unpick these different offerings and decide which to use where, especially as they share a lot of the underlying technology as each other.

Here are my summarised thoughts:

  1. OneDrive For Business
    • Think of this as effectively a file server in the cloud, but note that the assumption is that each person has their own area. With most Office 365 plans you get  1 TB of storage per person, which is a serious amount traditional  storage for your organisation. However it’s not the same as using a file server; best practice is to create a set of high-level folders within each person’s OneDrive: Personal, Team, Everyone In The Organisation, and External content. Share access of the last three appropriately. It is possible to have an admin or super user who can set their account up to provide something equivalent to departmental shares. It probably only takes a couple of days effort to implement this for a small organisation and that includes training and structuring the folders.
  2. Microsoft Teams
    • This is  both a browser-based and desktop application, which uses the Office 365 services on the backend. It’s described as conversation-centric collaboration (https://products.office.com/en-GB/Microsoft Teams/group-chat-software ); the front-end uses the chat capabilities of Skype for Business to provide the conversation element, though does have the ability to share files etc. and  includes OneNote  (you can also add other apps). The ability to configure it according to different needs is limited and there is no concept of an organisational hierarchy. It’s great for near real-time collaboration, discussion with team documents, but not so great for creating an organisational file store. Set up effort is also just a few days.
  3. Office 365 Groups
    • These are recently updated and provide email-centric collaboration, though with both simple file sharing and a full SharePoint site on the backend for each team or group (the language is starting to get difficult now, I’ll use uppercase when I’m in the product and lowercase when I don’t). ThUser experiences a bit of a mess  in that  the interface varies according to where you try to access Groups from – Outlook, Yammer, OneDrive for Business and SharePoint all provide access but the UI is different in each case). As with Microsoft Teams, there is no organisational hierarchy. Office 365 Groups are good for team collaboration and ongoing projects; also because the file store is actually in SharePoint, it does allow customisation so that libraries can have additional metadata and the full power of SharePoint; you can also create additional libraries within each Group;  however these are only  visible when you step into the SharePoint view of the Group,  not in this simplified view in Outlook etc. Our suggestion to make this really work for bigger organisations is to combine it with Cloud2’s Connect product, which will provide the hierarchy and a powerful entry portal. Individual Groups are very easy to set up, but there  is always some effort required to train users, determine best practice and extend some of the Group sites to meet organisational needs.
  4. SharePoint intranet
    • SharePoint is a huge application, highly suited for enterprise needs and with a massive range of capability to support collaboration, content management, communication, business processes and people. However this comes with complexity and the need to configure everything before it is effective (which is why Microsoft have introduced the previous three items). It will pretty much do everything that an organisation needs but a typical SharePoint Project in the corporate world takes upwards of 100 days of services. Even with digital workspace accelerators,  such as Hadron, the effort is still around 30 days, though these tend to incorporate other parts of the O365 stack such as Yammer and Skype for business. Where SharePoint really shines is for organisations with complex process needs , a requirement to govern some types of content and where the organisation itself is sophisticated with  a large amount of structure and enterprise level business needs.


    Clearly this isn’t a one size fits all situation and is unlikely at any one of the above will answer all the collaboration and content needs of an organisation. The right thing to do is to mix and match the technologies in the Office 365 suite in a way that suits your organisation, your strategy and budget. Whatever you do, research the tools and think hard before jumping in.

1 Comment

Filed under Intranet, Microsoft, SharePoint, 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.


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