Desktops, metadata and filing: Difference between revisions
Amwelladmin (talk | contribs) Created page with "{{a|technology|}}SharePoint gets a lot of hate from people who don’t use it properly. To be sure, Microsoft has not made the job of learning how to use it easy — Microsoft’s design decisions across its platform are pretty weird, so we should not be surprised — but here is a basic rule of thumb: {{quote|In SharePoint you organise by ''metadata'', not by ''folders''.}} ====Folders==== Folders are very old economy. The folder metaphor is, literally, based on ph..." |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 2: | Line 2: | ||
{{quote|In SharePoint you organise by ''[[metadata]]'', not by ''folders''.}} | {{quote|In SharePoint you organise by ''[[metadata]]'', not by ''folders''.}} | ||
Folders are top-down. Metadata is bottom-up. Folders prefer form over substance. Metadata prefers substance over form. | |||
====Folders==== | ====Folders==== | ||
Folders are very old economy. The folder metaphor is, literally, based on physical artefacts that can only be in one place at any time. If I put this item in the “Litigation” folder, I can’t ''also'' put it in the “Knowledge Management” folder. | Folders are very old economy. The folder metaphor is, literally, based on physical artefacts that can only be in one place at any time. If I put this item in the “Litigation” folder, I can’t ''also'' put it in the “Knowledge Management” folder. | ||
| Line 7: | Line 9: | ||
Where the same unitary item deserves to be in both folders, I must therefore ''duplicate'' it. Where it is a “living thing” plotting its own miserable trajectory through the cosmos — a contract under negotiation, or a periodically updated legal template for example — then ''duplicating it'' is a ''bummer''. It duplicates the manual task of updating all copies of the document as it changes, and that introduces the opportunity for human error. There may be miskeys. A document may be forgotten. Version control is a pain. | Where the same unitary item deserves to be in both folders, I must therefore ''duplicate'' it. Where it is a “living thing” plotting its own miserable trajectory through the cosmos — a contract under negotiation, or a periodically updated legal template for example — then ''duplicating it'' is a ''bummer''. It duplicates the manual task of updating all copies of the document as it changes, and that introduces the opportunity for human error. There may be miskeys. A document may be forgotten. Version control is a pain. | ||
Also your preferred hierarchy can ''change'', as | Also your preferred hierarchy can ''change'', as personnel, business priorities, or circumstances change. Changing your hierarchy means ''completely re-engineering your folder structure''. | ||
So: a folder structure assumes a ''single'' hierarchy and multiple copies of each item. | So: a folder structure assumes a ''single'' hierarchy and multiple copies of each item. | ||
====Metadata==== | ====Metadata==== | ||
[[Metadata]] looks at the world the other way up. It says, “let there be a single canonical item, and multiple hierarchies.” Metadata allows you to non-destructively add hierarchies as you please. The more metadata fields you have, the more possible hierarchies there are. Unused hierarchies are almost costless. | [[Metadata]] looks at the world the other way up. It says, “let there be a single canonical item, and multiple hierarchies.” Metadata allows you to non-destructively add hierarchies as you please. The more metadata fields you have, the more possible hierarchies there are. Unused hierarchies are almost costless. | ||
Excel is a, well, ''excellent'' tool for managing metadata: Each row is an ''item'' and each column is a ''metadata point''. You can add additional columns as you see fit without impacting what is already there: newly added columns are ''non-destructive'' as they augment without affecting existing ones. | |||
In Excel you can filter sort and pivot by reference to any column in a table, in any order, and in doing so you impose a dynamic hierarchy on the items in the list. This is the magic of metadata. | |||
''SharePoint allows you to do exactly the same thing with a document library''. | |||
We intuitively understand the power of metadata when we are presented with a spreadsheet. But the same power does not occur to us when we are presented with SharePoint, even though it is, in essence, a supercharged online spreadsheet. | |||
It is as if we take a preconceived notion of a physical library with us, and ignore our understanding of spreadsheets. | |||
{{sa}} | |||
*[[Metadata]] | |||
Revision as of 11:53, 17 July 2024
|
JC pontificates about technology
An occasional series.
|
SharePoint gets a lot of hate from people who don’t use it properly. To be sure, Microsoft has not made the job of learning how to use it easy — Microsoft’s design decisions across its platform are pretty weird, so we should not be surprised — but here is a basic rule of thumb:
In SharePoint you organise by metadata, not by folders.
Folders are top-down. Metadata is bottom-up. Folders prefer form over substance. Metadata prefers substance over form.
Folders
Folders are very old economy. The folder metaphor is, literally, based on physical artefacts that can only be in one place at any time. If I put this item in the “Litigation” folder, I can’t also put it in the “Knowledge Management” folder.
Where the same unitary item deserves to be in both folders, I must therefore duplicate it. Where it is a “living thing” plotting its own miserable trajectory through the cosmos — a contract under negotiation, or a periodically updated legal template for example — then duplicating it is a bummer. It duplicates the manual task of updating all copies of the document as it changes, and that introduces the opportunity for human error. There may be miskeys. A document may be forgotten. Version control is a pain.
Also your preferred hierarchy can change, as personnel, business priorities, or circumstances change. Changing your hierarchy means completely re-engineering your folder structure.
So: a folder structure assumes a single hierarchy and multiple copies of each item.
Metadata
Metadata looks at the world the other way up. It says, “let there be a single canonical item, and multiple hierarchies.” Metadata allows you to non-destructively add hierarchies as you please. The more metadata fields you have, the more possible hierarchies there are. Unused hierarchies are almost costless.
Excel is a, well, excellent tool for managing metadata: Each row is an item and each column is a metadata point. You can add additional columns as you see fit without impacting what is already there: newly added columns are non-destructive as they augment without affecting existing ones.
In Excel you can filter sort and pivot by reference to any column in a table, in any order, and in doing so you impose a dynamic hierarchy on the items in the list. This is the magic of metadata.
SharePoint allows you to do exactly the same thing with a document library.
We intuitively understand the power of metadata when we are presented with a spreadsheet. But the same power does not occur to us when we are presented with SharePoint, even though it is, in essence, a supercharged online spreadsheet.
It is as if we take a preconceived notion of a physical library with us, and ignore our understanding of spreadsheets.