Body:
One of the big shifts that people have to make when creating a SharePoint site is the fact they're used to a digital asset having a digital location, much the way an actual object would live in an actual location, such as a file drawer.
Just this last week, I had a client who kept asking me how she would mark a project as "complete" in the new system I'm designing for her. I started to ask her what "complete" meant to her, and she stated that when a project is "complete" in her old system, it no longer shows up in her "active projects" view. I explained to her that she has a meta data field called "Project End Date", so she can simply create a view of her projects based on whether "today" is before or after the end date; that way the view moves with her, so to speak, and she doesn't have to manually make the change to the project file to mark it "complete". She kept coming back to me with, "But how do you move the project to its archive location if you don't know it's complete?" I tried to explain it to her using the file cabinet scenario; instead of having 2 file cabinets (one for "active" and one for "archive"), there's just one really long file cabinet, and you just determine which five hanging folders you're going to look at within that cabinet.
To look at a different commonly asked question by end users, I saw this question on the Microsoft message board:
"I have products that are sold under two or more different business units, and I need to be able to replicate the product page to each business unit's location in the site, yet remain able to edit it from any of its locations.
What if any, is the best way to accomplish this?
Thanks"
What if any, is the best way to accomplish this?
Thanks"
Here was my response:
-----------------------------------------------------------------
A key concept for SharePoint is the concept of taxonomy, or site organization. One of the big benefits of SharePoint is that it's possible to organize information in more than one way. I like to give people this example:
Say you have a folder in your "My Documents" folder on your hard drive, and it's called "Projects". Inside your "Projects" folder, you have a bunch of folders, each named for a name of a project. Inside each of those folders you have all the documents relating to a project, such as a project plan, status reports, etc. One day, your co-worker says, "Hey, I need the project plan for Project XYZ." You're in a hurry so you give her access to view your "My Documents" folder over the network. Pretty soon you have her calling, "Hey! Where's your 'Project Plans' folder?" She's asking that because on her computer, she doesn't have a folder for each project; instead, she has a folder for each type of document.
This example is just to show that there are multiple ways of sorting or grouping the same information. What if it were possible to view the same information, but grouped in different ways? What if you could see all your project documents at once, but your coworker could view all the project plans at once? The key is that where a document sits logically describes it in some way, but that's not the only way to describe it. It could also be "tagged" so that all the items tagged with the same tag can be grouped together.
In SharePoint, this is done with something called Site Columns. A site column is a piece of metadata that can be used to describe your page. The thing to wrap your mind around is the fact that on a file system, where a file sits is what gives it meaning, (i.e. "It's in my Projects folder so it's a project.") In SharePoint, you can have a single "Product" page, but you could simply tag it as being carried by one or more locations. The location of the product becomes metadata describing the product.
So, instead of having a web site for each location, and having a product page inside that unit's site, think of this scenario: you've got a site for each unit, but you've also got a common site for all your product pages. You tag each product page with the unit or units that carry that product. On your unit site's homepage, you use a web part called the Content Query Web Part to retrieve all the pages in your "Products" site that have been tagged with that unit's name.
This can be a big change from how traditional web sites are built, but if you can start thinking in this way, your sites become very flexible, and you can start showing different kinds of views of the same information - views which might be pertinent to different kinds of people (such as employees vs. consumers vs. business partners, etc.)
Say you have a folder in your "My Documents" folder on your hard drive, and it's called "Projects". Inside your "Projects" folder, you have a bunch of folders, each named for a name of a project. Inside each of those folders you have all the documents relating to a project, such as a project plan, status reports, etc. One day, your co-worker says, "Hey, I need the project plan for Project XYZ." You're in a hurry so you give her access to view your "My Documents" folder over the network. Pretty soon you have her calling, "Hey! Where's your 'Project Plans' folder?" She's asking that because on her computer, she doesn't have a folder for each project; instead, she has a folder for each type of document.
This example is just to show that there are multiple ways of sorting or grouping the same information. What if it were possible to view the same information, but grouped in different ways? What if you could see all your project documents at once, but your coworker could view all the project plans at once? The key is that where a document sits logically describes it in some way, but that's not the only way to describe it. It could also be "tagged" so that all the items tagged with the same tag can be grouped together.
In SharePoint, this is done with something called Site Columns. A site column is a piece of metadata that can be used to describe your page. The thing to wrap your mind around is the fact that on a file system, where a file sits is what gives it meaning, (i.e. "It's in my Projects folder so it's a project.") In SharePoint, you can have a single "Product" page, but you could simply tag it as being carried by one or more locations. The location of the product becomes metadata describing the product.
So, instead of having a web site for each location, and having a product page inside that unit's site, think of this scenario: you've got a site for each unit, but you've also got a common site for all your product pages. You tag each product page with the unit or units that carry that product. On your unit site's homepage, you use a web part called the Content Query Web Part to retrieve all the pages in your "Products" site that have been tagged with that unit's name.
This can be a big change from how traditional web sites are built, but if you can start thinking in this way, your sites become very flexible, and you can start showing different kinds of views of the same information - views which might be pertinent to different kinds of people (such as employees vs. consumers vs. business partners, etc.)
-------------------------------------------------------------
As someone who lives and breathes Site Columns and Content Types, it's always good to remember that people are going to compare the system with a real world scenario they are familiar with, and I need to find a new point of reference for my end users.
Category: General
Published: 9/12/2009 7:34 AM
No comments:
Post a Comment