Structured Versus Unstructured Data – Part 2: The Long Filename Debate
Guest Author: James Love
Chronicles of a Chronic E-Junkie
I caught wind recently of an email sent to others in my organization where the user complained that Windows allowed 255 character length filenames but SharePoint didn’t. I wanted to see what the issue was so I asked a good friend and colleague of mine to forward me the message to see the library in question. The result was a folder within a library, filled with files named using a familiar and archaic nomenclature.
The naming convention he had was YYYY-MM-DD-NN-Title.PDF, where NN was the initials of the author, and the Title often being very long and complex report titles. After thinking about this for a moment, and trying desperately not to defend SharePoint by thinking of the technical reasons why (such as use of the "title" as unique identifiers in the SQL database, perhaps), I had thought of why this limit was in place.
I remembered soon after that each file in a document library also has a "Title" field. And therein lies the rub.
If you have issues with long file names in your SharePoint environment, then you probably have deeper issues with your Information Architecture.
Storing metadata about your file (the file author and date, in the above example) in the filename itself is a very limited approach. What if you wanted to only display files by a certain author? Or created within a certain date range? Or how about, as in the immediate requirement, to store long and complex report titles?
SharePoint already has fields to store file creation dates and authors. There is also even a field built-in to store the Title separate from the filename! Transferring a file system straight from a shared drive to a SharePoint document library might be easy, but the hard part is making use of the elements that make SharePoint great for storing files and records, especially if you’re transferring a large document set from a file share to SharePoint.
Going one stage further is educating your users of these features, making them aware that they’re there and why they’re useful.
In summary, SharePoint can be designed (and is such, out of the box) that you shouldn’t need long filenames.
Guest Author: James Love
Chronicles of a Chronic E-Junkie
James Love works as an Information Officer for a small non-profit organisation in York, UK. Whilst developing solutions for the company’s intranet environment, he also spends time looking after IT operations and strategy. As well as web development & design, James has a keen interest in Information Architecture best practices for the corporate environment. He is a regular attendee of Sharepoint User Group UK events in Northern England.
- Structured Versus Unstructured Data - Using SharePoint To Get Value From Your Business' Information
- Structured Versus Unstructured Data - Part 2: The Long Filename Debate
While I agree users need education away from file server techniques if I may take a different tack on your ‘education’ theme by suggesting the roll out has not examined ‘what the users want/need’ and place the emphasis on development rather than user behaviour.
OOB document library does not have the columns for author and document date, which can be identified as ‘required’ by examining business functions and requirements, and applied accrodingly.
**heavySarcasm** If we just bring back the “eight-dot-three” file-naming convention, all will be solved! **/heavySarcasm**
I agree with Mr. Bunyan in that Microsoft did not look at user behavior when designing library functionality. And this whole thing is a much more complex issue than just saying, “Oh, well, SharePoint provides for all this metadata in the various fields, so just do it.”
For one, many organizations ENFORCE file-naming conventions, so just saying “convert to SharePoint’s way of thinking” will not work. In addition, many users are moving FROM some other file-storage scheme (file servers, document management systems, hard drives) and INTO SharePoint, and they often move many many documents at once. The users I’ve worked with just want SharePoint to do its job so they can go about theirs. It’s an unnecessary (in their minds) imposition on their “real jobs” that they should have to unpack the metadata from the filename and into several new SharePoint metadata fields.