Jason Parks SharePoint & More

Aside from code or configuration examples, my blog posts usually are targeted at inviting discussion around possible solutions or best practices. The purpose of this post is to describe a scenario where leveraging site properties may prove optimal to a case application.

In the field, we frequently encounter business applications which are designed in a "one-to-many" taxonomy. That means we wish to create a hierarchy with a portfolio style approach. In this instance, we'll assume we are looking to create a Project Management application, where a top-level "Portfolio" site should contain team collaboration sites for each "Project" we wish to manage. Note, in this instance, project management is centered around the workspace itself, and is not "document centric". That's a fancy way of saying the project plan is a piece, or output, of our effort, and not the center of our collaboration itself.

Now, given the diagram above, it's clear that we would like to have some information about Project #n, in addition to the content it includes. A common workaround we've seen in the field is to create a custom list within site Project #n. Not a bad solution, but not ideal. You can certainly preserve integrity via permissions, and it's easy to manage. However, the ability to directly classify the "workspace" object seems to be a much cleaner approach. Some thoughts around the two methods:

• For the "list method", we add some extra work in walking our webs and traversing lists and content types during development. Also, if we want to rollup content types inside of the Content Query Web Part, we've got some XSLT work. Outside of the CQWP, we are looking towards some CAML solutions, etc.
• What if we want to automate the site creation process? We can certainly leverage custom site properties using an InfoPath Form. We could also easily build out a custom Site Creation .aspx form to leverage our additional properties. That way, we aren't forced to work back to the list after creation.
• After dropping in a Feature Receiver for the site properties, all that is left is some trivial XML to add new properties to new site definitions. Creating new lists or content types via code can be tedious.
• There are some considerations for the site properties approach: Do we intend to have "choice" fields? If so, do we need to build a data store and page/web part for the site admin to manage? What if we want to mark metadata for content dynamically based on site properties (i.e. document x is tagged with the appropriate project # value)? We could do a lookup column in a list. If we are writing a custom field, we'll add some more dev time (but it would be reusable).

Just some thoughts. I'm sure there are quite a few people on both sides.

References:

http://www.tonstegeman.com/Blog/Lists/Posts/Post.aspx?ID=13

http://www.tonstegeman.com/Blog/Lists/Posts/Post.aspx?ID=5

http://jgparks.spaces.live.com/blog/cns!60482D4E2A8D1BF9!516.entry

One of the hot topics for SharePoint right now is implementing Social Networking. Microsoft has released a whitepaper that describes how this maps to MOSS. Some random thoughts from the field on this topic and My Sites in general:

• At its core, Social Networking is about users having the ability to find people and information based on relevance to a topic. Those results should give the user an idea of degrees of separation. Given that, the real planning involves the user "object" itself. That means identifying the metadata for each object. Classic Information Architecture stuff.
• While you are planning your profile information, you'll be identifying the profile stores. You need to have a firm understanding of the authoritative store for profile information. Who wins if multiple stores hold the same info?
• "Shared Documents" libraries are meant to be a place where users can temporarily keep files while they are in development or collaborate with other team members. If you don't create policies or quotas, it is likely that many users will leverage these libraries in a manner similar to their "My Documents" folder on their local drive. This defeats the purpose of moving to an environment promoting structured data.
• When employees leave the company, have you considered a workflow or policy for shutting down their My Site and re-filing any content they left behind? Do you have an ILM in place? Can you work with HR on developing a process?

A common project snafu is not clearly defining how you plan to implement creative design/branding. Project plans often account for "UI Design" and "Master Page/Page Layout Design". Who will be building the nice and shiny creative piece? Typically, it will be an internal creative team or a 3^rd party marketing/design company. The planning and implementation team often believes they are on "the hook" for porting design elements to MOSS consumable Master Pages. This seems obvious, but your project will start to flow, you'll get your first Information Architecture deliverables in, and want to build a POC for stakeholders; only to realize that you haven't put the wheels in motion or dedicated budget for creative services

Having worked with SharePoint technologies for some time now, one gray area for customers and consultants is relationship between Information Architecture and Taxonomy. Some core Information Architecture deliverable documents show how we classify data (Metadata, Content Types), make that data searchable (Vocabularies), where we file the data (Taxonomy), and ultimately how we present it to the consumer visually (UI/Wireframes). Taxonomy is a component of IA, not vice versa.

For those of you who read Ton Stegeman's article on Setting site properties in a SharePoint 2007 site definition by using a feature, this little snippet will allow you to retrieve a value based on a specific key. I left some extra namespaces in the code and so forth, but you should get the picture. Note that the "key" we pass in is lowercase, as the StringDictionary will convert all property (key) values as such.

What are you really building? An intranet? An extranet? A business application? Keep your eye on the ball. If you are redesigning an intranet, your planning should revolve around building an application that delivers the highest value for the company. This is a common mistake we've seen made in the field. What type of navigation provides the highest value to the company? What are the best practices around UI that other companies have found to be successful? Forget about what was built in the past, what are we going to build now that is going to "wow" our users?

When you design your intranet utopia, you begin to unlock the richness of the platform once you build. If you design purely against the platform, you end up (intentionally or not) fitting requirements against what you know about the software.

MOSS can help you fulfill your application dreams, so don't hold it back by "fitting" your requirements. Design the best application you can, and start from there.

Well, it's the New Year, and getting back on the blog roll is similar to committing to the gym. There are a few areas that I think need some serious posting:

• Information Architecture as it relates to the SharePoint Platform – everybody's version of IA is different, but the core concepts still ring true
• Running a successful MOSS project – There are quite a few areas where you can burn hours quickly if you don't keep things boxed nicely
• UI Design and Testing – What once was old is now new. UI, along with IA are really the core components of your SharePoint projects. How can you even begin to give a level of effort if you don't know what you're moving, where it will go, or what it will look like?

Of course, there's quite a bit more outside of IT consulting that is interesting (skiing, travel, etc). We'll try to keep up on that, too.

Happy New Year!

For those of you who need to get ADAM up and running on your SharePoint 2007 environments, I can tell you this: Do not try to use the ActiveDirectoryMembershipProvider!

The fact is, while you may be able to finagle some authentication to work, you won't get everything you need (think profiles). I had this confirmed by one of the MSFT field techs.

Instead, you'll need to use the LDAP provider. When importing your profiles into the SSP, you'll also need to use the LDAP connection type.

I'll post a walkthrough shortly, but in the meantime, Liam's Blog will get you started in the right direction.