Folders, Metadata, SharePoint 2007, and SharePoint 2010

So you heard the news:  folders = bad in SharePoint land; but why?  We have spent the last 20 years putting things in electronic folders, the past hundred putting them in real folders in real filing cabinets....so why does SharePoint come along and say "folders:  the dodo was better"?  Well, let's talk about the reason we had folders, why we have them now, how they work today, and what can be done to improve the situation.

Physical Folders

So uh, a long time ago...people used paper.  Paper was this collection of ground up trees in a paste that is super flat and thin...when it dries, it's nifty to write on.  Writing is when we use a semi-permanent or permanent utensil to make marks on this paper...we would write what we now type...don't worry, you won't need to remember this.  When a bunch of this "paper" was used to gather information, they needed a way to organize it so that you could retrieve the information later (whenever someone asked or sued for it).  They decided they would use thick paper and bend it in half to hold several pieces of thin paper inside it...we would then mark it with useful information so we would know what was inside it.  We would stack these things called "folders" together, sometimes put them in big drawers called filing cabinets, and that was a great system till people realized that paper - being made of trees - was flammable and permeable by water....and, on top of that, it takes up a LOT of space.  Introduce electronic folders.

Electronic folders

So, we fast forward to the stone age when computers first began.  For a reference on how the first computers worked, google "The Flintstones" and try to find an old video that shows you this animated entertainment clip of life during this time.  We decide that paper is a thing of the past and decide that typing is the way to go (hooray for lefties around the world!  our handwriting is no longer an issue!).  We type up papers, resumes, and all sorts of stuff.  So, we have all these types of documents we type up for work, school, presentations, reports, etc...and the problem came back:  how do we organize this stuff?  We decided to transform a single, magical folder into the digital world where it replicated itself as the first virus to spread across the digital globe.  People started putting documents in these digital folders to help "organize" information.  Do you see the problem yet?  Still bunches of folders, still bunches of stuff, still dealing with a mentally-deficient chimp's method of organizing documents and you aren't allowed to change its methods.  People figured, "hey, this is digital...let's be bold and put folders INSIDE folders for better organization!"  Oh yea, we were that dumb.  So, going to find stuff really was just like regular folders:  took forever and you were at the mercy of who (or what)ever setup your folder structure.  We made really smart searching tools to let us peek inside folders faster, but the problem remained.  Bring in Metadata.

Metadata

The first concept of metadata is quite cool:  let's take all the important information ABOUT a document, and stick it somewhere so we look at THAT first instead of the folders.  We look through a stack of metadata really fast, find the paper we want, and it tells us where to find that paper.  You got it:  a catalog system...you know, like libraries....the place where they would but books....which were collections of paper bound together and forced you to read ALL of it to find that perfect page....yea, no iTunes for book chapters or phrases :(.  Anyway, this new metadata idea lets us keep our folders and all our stuff wherever - we just need to take a few notes about the document before we file it away in the black hole.  Doctor's offices use this a lot - they have color codes, name codes, and tons of shorthand written everywhere...so much so that there's a job and training just to decipher it!  The cool thing is, once you know the code, they would pack thousands of people's medical records into a space the size of your family room.  We would use this on electronic documents to make searches "faster".  Now comes SharePoint.

SharePoint

So, this metadata thing sounds cool, right?  Well, what if you end up in a doctor's office that held 100,000 people's information?  You'd still be looking at a lot of the same problem because you would have a LOT of metadata and THEN you'd have this massive mound of stuff to look through to find your document - even though you know where to look.  So, the way to solve this?  Instead of using folders - which HIDE information inside them till you look there - let's put everyone's information in giant stacks with the metadata sticking out on each document...and let's pretend that we can control gravity on each document so that, when we say we're looking for a purple tab, all the purples come together RIGHT in front of you.  Nifty huh?  That's what SharePoint wants to do for you.  In 2007, they let you make folders.  The only real reasons to make a folder are to separate stuff that needs unique security permissions (locked down folders) or if there's more than 5k items...then use folders to break down some of it into really big chunks...maybe.

The problem:  most people didn't know about metadata and still made electronic folders.  The SharePoint gods became disturbed and rained fire from Mount Despair on all such places - making them slow and difficult to use and making people forget that they do this everywhere else but SharePoint so that they complained to the Admins..err High Priests of SharePoint that they didn't do their job.  So, the evangelists of SharePoint are now proclaiming the wrath of the gods on folders...please, don't use them so you won't be burned.  You can choose not to believe in the SharePoint gods or the warnings of folders - but beware, SharePoint gods don't believe in folder athiests.  Use COLUMNS to ask for important information about documents and items when they go into lists and libraries...have 3 or 4 columns instead of folders.  You can search and filter by columns!  You can find whatever the heck you want super fast!  So, how has it changed in 2010?  NONE!  The only thing they did to make it easier on you folder lovers was to make it so that anything inside a folder got a special tag on it with a piece of metadata from the folder.  This way, every item automatically has some metadata - so poo on you if you don't want metadata, it WILL be branded on every item!  May the SharePoint gods smile on your learning; go, young padawan, and folder no more.

InfoPath Tutorial updates

Hey everyone,
I just wanted to let you know that I've updated the Introduction and Part 1 of my InfoPath 2007 Tutorial.  I'm sorry it took so long (over a year) to update them...work has been crazy and we've been learning so much about InfoPath and SharePoint 2007 that it's been scary...then we decided to push on to SharePoint 2010 so much of my time has been learning and planning on our 2010 setup.  Once I finish my 2007 tutorial, I'm going to put out a series on InfoPath 2010 so that you will have something for either program.  One thing I do have to say:  you can use InfoPath 2010 to make 2007 browser forms...and dear Lord if you have the opportunity to do that...TAKE IT!  There are a few major improvements in InfoPath 2010 that can be used to drastically cut the amount of time it takes to make a 2007 form.  I look forward to releasing InfoPath Tutorial - Part 2 - Color Schemes and Controls next week.

InfoPath Tutorial - Part 1

InfoPath date calculations and date comparisons without code

If you have the unfortunate task of doing some date calculations within InfoPath, you may have already found out the fun news:  InfoPath only gives you TWO functions dealing with date and time:  addDays (which lets you add a certain number of days to a date) or addSeconds (which lets you add seconds to a dateTime field).  This can be a little difficult when you intend on doing some calculations like adding a month to a specific date or subtracting a few days from a date to determine another day.  Here's a few ways you can do date calculations:

1.  Use addDays - the addDays function looks like this:  addDays(insert_a_date_field_here,"type_the_number_of_days_to_add_here").  An example would look like:  addDays(StartDate,"1") and this would add a single day to the Start Date field.  Key thing to note - you can add negative numbers here to subtract a certain number of days.  This can be useful in conditional formatting or data validation for greater than/less than comparisons (e.g. If DueDate field is less than [addDays(StartDate, "10")] then give the error message "Your due date is too soon; please set it for more than 10 days after the start date" in the data validation tooltip.

2.  Use addSeconds in the same manner as addDays - this can be done for time issues like turning an item in by 5pm on a certain day.  The reason this might be necessary is that, often, when calculating dates, the time assumed for a day is 12:00 AM on that day...so if you want a realistic time like 8am, you will need to use the addSeconds to give you a few hours...you'll just have to use a calculator to figure out how many seconds to add for so many hours/minutes.

3.  Adding a month or year to a date:  this is tricky but doable without code.  What you have to do is a little behind-the-scenes work with the date field.  Here's the steps:

1. Have your two date fields, the first one is where the user picks a day (we'll call it UserDate), the second one is for that day plus 2 months (DatePlus2).
2. Create 4 text fields:  temporaryDate, month, day, and year (you'll hide all these but I'm showing you them in the example)
3. Use a rule to set the temporary date to the value of the UserDate.
4. You'll notice that the format that it sets that field in looks like this:  YYYY-MM-DD
5. Now you get to use the dreaded substring-before and substring-after functions to pull out the year, month, and days.  The idea of substring is that a "string" is a bunch of letters and numbers (like a sentence, word, whatever) and that you are getting a portion or less than the whole thing (like subtracting out a certain part of the string...substring).  There are different types of substring-ing like looking before or after a certain symbol (like a slash or dash in our case) or substring a certain number of letters in (e.g. you have a Social Security number field that always starts with SS#...you could say you want to substring starting at the 4th letter and get the next 11 characters to get all the numbers and dashes for a social security number).

6. Use a rule on the temporaryDate field to set the YEAR field to the following formula:  substring-before((click Insert Field and choose temporaryDate), "-")...this will get all the characters before the first dash that it finds (so all the year numbers).
7. Add another action to the rule on temporaryDate to set the MONTH field as the following formula:  substring-before(substring-after((insert temporaryDate here), "-"),"-")  This looks weird, but what it's going to do is substring after the dash (which grabs the MM-DD) and then substrings before the dash of what you grabbed (so it grabs MM since it's the only thing before the dash).
8. Add another action to the rule on temporaryDate to set the DAY field as substring-after(substring-after((insert temporaryDate here), "-"),"-")  This looks very similar to the Month one but it substrings after the first dash (so MM-DD is what we have) and then it substrings AFTER the dash this time (so it gets DD)
9. Phew, almost done, you've now got the numbers in the month, day, and year fields for your day...all you need to do now is add to the month, day, or year field.  The only problem is this:  InfoPath thinks these fields are TEXT fields, not numbers, so if you try to just add 1 or 2 to the Month field, it's gonna laugh at you (because, as far as it knows, you're trying to add 2 to AA and it thinks you don't know how math works...seriously, it'll laugh at you).  So, here's what you do:
10. Add another action to the rule on temporaryDate to set the MONTH field to this formula:  value((insert MONTH field here))+2 (or however many months you want to add to that month field).  The value function will tell infopath that what you have in the MONTH field is really a number - so you can then do some math with it like adding a few months.  The only hard part here is when you get toward the end of the year...you'll need to have another rule that checks to see if the month is greater than 12 and, if it is, subtract 12 from it but also add 1 to the year.  Again, that's only if you are adding months...if you add to the year, then you won't have to worry about figuring out the month :)
11. The final step:  add another action to the rule for temporaryDate to set the DatePlus2 field to this formula:  concat((insert YEAR field),"-",(insert MONTH field),"-",(insert DAY field)).
12. Below are a couple of images showing the 3 rules I used here to first set the calculated date, second and third check to see if the month is over 12 and do different things based on what the number is.  The reason I had 2 rules for that is that, if you subtract 12 from 13, you get 1...which is correct; however, InfoPath will want you to have "01" in the Month field instead of "1"...so I had to change what I say when I'm setting the calculated date field