Understanding SharePoint Metadata – It Really Isn’t Something New – Part 1

As many of you know, I have been promoting the use of metadata rather than folders as a way to organize the information you store in SharePoint libraries. Some of you have found this transition to be difficult to grasp. I am here today to assure you that you actually have been working with metadata in libraries for years, although you may not have thought about it in those terms.

First, what is metadata? Metadata is any information that helps classify an object, a file in this case. Let’s take a look at a standard Windows library, something we are all familiar with. In a standard Windows directory, you can view information such as the date the file was created or last modified. This information classifies changes to a file basically providing some insight to its origin and most recent changes. You might use this information to list all the files in a directory by the date created to help find a file you know you created last month.

You might also use the modified data to list the files in reverse chronological order to identify the files you worked on last.

You might even have used the Size column to sort the file by size to determine which ones were taking all the space on your thumb drive. On a network drive, the Authors column also may have helped identify who created or modified the file. The Type column might also have helped to group files of similar source type. But you know that there are many other columns that could be displayed for a normal Windows directory? Just right click on the directory header to display a popup of the available data.

By design, the popup displays the 10 most common/recent columns used, but these ten are not the only things tracked for files. In fact, if you click on the More… option at the bottom of the popup, a dialog appears that lets you choose which columns to display in the current library.

To select a column, simply click the checkbox to the left of the column name. You can even click on the column title itself and then use the Move Up and Move Down buttons to the right of the dialog to change the order in which the columns appear when you display the library. For the selected column, you can define the default width of the column in pixels with the option at the bottom of the dialog. Both of these last things can be changed directly in the list itself by clicking on a column header and dragging it to the right or left to change the order or by clicking on the faint line separating the column headers to change the column width of the column to the left of the line.

Perhaps you already knew that, but did you know that some of the column data applies to only certain types of files? For example, if you have a file of pictures, you may still be interested in creation dates, sizes, and authors, but you may also find columns like the Dimensions column interesting. This column will tell you the size of the picture in pixels while the Size column tells you the size of the file in KB. These two values will help you determine if you should resize a picture before uploading it to your web page to minimize the time it takes the network to transfer the image from the server to the end user.

Similarly, music libraries have their own set of default metadata specifically to help you track the order of songs from an album, the album name, the composer, the length in minutes and seconds, and other information about the songs.

Well, that is it for the introduction. Next week I will explain a few reasons why metadata is so much more important in SharePoint than it was in Windows and then explore a way to convert from a nested folder document library structure to a metadata library structure.

C’ya then.


Jargon and TLAs

Today Richard Branson of the Virgin Group posted an entry on the use of jargon. In a nutshell he says, ‘it slows things down, confuses people, and causes them to lose interest.’ I could not agree more Richard. In fact, I would also expand this to include the use of TLAs (Three Letter Abbreviations).

When I started working for the school district, everyone was referring to the DOE. I could not understand how or why they would care about the Department of Energy. You see, I had previously worked for an energy consulting company and the DOE was referenced there was the Federal level Department of Energy, not the Florida Department of Education. Just for your information, at the Federal level, it is the Education Department. Confused yet?

Perhaps not as much as I have been reading documents with TLAs or other technical jargon about education in every sentence. While technical or career related jargon may aid in communicating ideas quickly amongst people who are all familiar with the terms and abbreviations used, it leaves the rest of us mere mortals confused and wondering just what is it that they are talking about. Even worse, TLAs can lead your brain down the wrong thought process.

During class I often asked my students what they think of first when I say: CIA. Here are some of the answers:

    Central Intelligence Agency

    Culinary Institute of America

    Christians in Action

    Chief Internal Auditor

    Cheers in Advance

    Cost Impact Analysis

In fact, the web site called The Free Dictionary (http://acronyms.thefreedictionary.com/cia) lists over a hundred meanings for the CIA TLA.

Some people use jargon so much at work that when they leave work, they continue to use jargon, not to show off or just to abbreviate ‘common’ words or phrases, but because the jargon has become so much a part of their natural way of talking that they don’t even realize that they are doing it. Of course there are those that just use jargon and TLAs to appear smarter than their listeners or at least to impress them. My fiancée calls these people ‘intellectual bullies’. After all, who would you trust more, someone who could explain things clearly to you or one who expressed their ideas in jargon that went completely over your head?

One final example are the 24/7 lectures at the Ig Noble awards ceremony held annually at Sanders Theatre, Harvard University. The 24/7 lectures consist of a complete technical description of a research topic in 24 seconds. During this time, the use of jargon and TLAs is uncontrolled but often leaves one totally confused about the point of the topic or even what the topic is. This 24 second description is then followed by a clear, accurate summary that anyone can understand in seven words which usually clears up any confusion resulting from the first part.

So the point of this blog is simply this, “Use jargon amongst colleagues, not with everyone.”

C’ya next time.

Just Give Me the Steps

“Just give me the steps I need to know to get my job done. I don’t really care about why those are the steps or what else you can do with the software/tool/machine. I don’t care about your videos or your in-class training sessions. Just give me the steps in a nice neat printed list that I can use and let me get out of here.” Does that sound like one of your training classes? While I hope not, that attitude toward training has become increasingly prevalent.

We provide SharePoint training to what I sometimes call ‘reluctant’ users. These are users that were told they had to come to class because they are now responsible for their department or project sites. They never built a web site before in their lives and their only familiarity with on-line web sites is when they go to MSN to check the latest news, visit Facebook or go download their e-mail. Their approach to learning how to build web sites with web parts, content editing, approval workflows and page layout issues is a cross between fear, dread, and loathing. But now they sit in your class with arms crossed just waiting for time to pass. You can tell the ones pretty quickly. They are on their phone, not to text back what they are learning to their staff, but rather to play Candy Crush or Flappy Bird. Sometimes they are just sitting in the back of the room talking to their co-captives about where they can go eat when the class breaks for lunch.

Of course, not everyone falls into that category. Some people come to training sessions excited about what they are about to learn and anxious to implement their new skills when they leave. But those few people who really do not want to be there tend to ‘poison the well’. I tend to favor explaining the concepts behind how different aspects of the software system work so that people can adapt those concepts to new situations, often in ways that I would not have anticipated since I do not intimately know all aspects of their jobs. And these shining stars exist and it is for them that people who do training get the most job satisfaction.

However, over the years (and I have been teaching computer classes since the days of the TRS-80 and Apple II) there have always been those who want some kind of magic list of all the steps they need to do, complete with illustrations, for the very specific task they need to accomplish at the moment. Perhaps I’m a bit old-fashioned, but I consider this approach more of a one-on-one mentoring or custom training. I have even seen computer books written like cookbooks with step-by-step instructions on how to solve specific problems. However, these books do not help much when your problem falls outside of the narrow scope of the examples covered. Therefore, it is my opinion that it is not the goal of a general training class to provide a cookbook style set of instructions to using a programming language or a very generic piece of software such as Word, Excel, or even SharePoint.

I do recognize that times have change and different people learn in different ways. To that extent, I tend to encourage the use of a combination of classroom style training along with written documentation, whitepapers, websites, and videos. I also recognize that no matter what approach is used for an individual training class, those individuals that really do not want to be there will always find fault in something about the way the training was conducted. One might say the material covered was too general while the next person may say that it was too complex. Someone else may complain that the pace of covering the material was too fast for them to keep up while someone else may comment that they only got to the ‘good’ stuff by the end of the day. Some people protest when new functionality is introduced by using written documentation only because they are visual learners. Yet others at in-person class training lament that they could have gotten the same information from written instructions and would have been done in half the time and then they would have something to go back to later. We have even had people complain that videos of the training they are currently attending and can watch over and over again do not help them learn how to do their specific job.

I suppose the comment that bugs me the most is when people complement us on our training generally, but then follow that up with a ‘but’, such as, “The training was great, but it did not show me the exact steps I needed for my job.” So I sat back last night and wondered whatever happened to the need to learn fundamentals first so that the person could apply what they learned to any situation. You learn the fundamentals on how to drive so that you can drive on any road. Similarly, learning the fundamentals of how to play an instrument allows a musician to pick up any music sheet and learn to play that song. Of course, you could argue that merely knowing the fundamentals of a sport will not make you an Olympic medal winner. Simply knowing how to drive will not land you the poll position at the next Daytona 500. Nor will your ability to read sheet music make you the next pop super star. However, in all cases, a firm grasp of the fundamentals were a necessary starting point for those who do succeed.

So will I change the way I approach training software? Probably not substantially. I believe that approaching your job, if it is knowledge based, requires more than just the ability to follow a set of pre-defined steps. There typically is not enough time or infrastructure to support building the style of ‘cookbooks’ lists for each knowledge-based task that you might find in manufacturing tasks. In additional providing a combination of in-person training along with printed documentation and videos for every possible alternative is not always feasible, especially not for small organizations or teams. Maybe we need to place a greater emphasis on learning the fundamentals so we can apply that knowledge to whatever circumstance we find ourselves in. Perhaps that should also factor into our hiring practices by looking for people who show that they have been adaptable to changes and new systems in the past and have a demonstrated willingness to learn and succeed.

C’ya later.