Contents tagged with SharePoint
-
SharePoint Content Type Cheat Sheet
Principle
Any application or solution built in SharePoint must use a custom content type over adding columns to lists. The only exception to this is one-off solutions that have no life-cycle, proof-of-concepts, etc.
Creating Content Types
- Web UI. Not portable, POC only
- C# or Declarative (XML). Must deploy these as Features
Rule
Do not chagne the base XML for a Content Type after deploying. The only exception to this rule is that you can re-deploy a modified Content Type definition only after completely removing it from the environment (either programatically or by hand).
Updating Content Types
- Update and push down to child types
- Web UI. Manual for each environment. Document steps required for repeatability.
- Feature Upgrade. Preferred solution.
- C#. If you created the content type through code you might want to go this route.
- Create new modified Content Types and hide the old one. Not recommended but useful for legacy.
References
- Create Custom Content Types in SharePoint 2010 (C#)
- Content Type Definitions (XML)
- Creating Content Types (XML and C#)
- Updating Approaches
- Updating Child Content Types
Agree or disagree?
-
Applying Quotas Across all My Sites
Just a quick snippet this morning. If you need to apply a new quota template to all users My Sites here's a quick script to do it. Changing an existing quota is fine but if you're migrating users from another system or you just want to up everyone's storage a bit here's what you do.
- Create a new quota template. This is found in Central Admin under Application Management | Site Collections | Specify quota templates. There's already a default "Individual Quota" created you might want to create your own or have a special one for your users
- Open up the PowerShell Management Console and enter "Get-SPWebApplication". This will list all your web applications on the farm.
- To apply it to all My Sites (each site is a site collection of its own) run this script below.
1: $webapps = Get-SPWebApplication;2:3: $webapp = $webapps[4];4:5: foreach ($site in $webapp.Sites) {
6: Set-SPSite -Identity $site.url -QuotaTemplate "Your Quota Template"
7: }The first line gets all the web applications on the server. In our case, the forth one is the mysite web app (yours will probably be a different number). Just run Get-SPWebApplication from the console to figure out which one to use. You could get fancy and pipe the name to find it but I'm too lazy for that.
Then we loop through all the sites on the list using the $site.url property and pass it to the Set-SPSite cmdlet and specify the name of the our custom QuotaTemplate.
Easy. Now all users are updated with the new quota template.
-
Do’s and Don’ts Building SharePoint Applications
SharePoint is a great platform for building quick LOB applications. Simple things from employee time trackers to server and software inventory to full blown Help Desks can be crafted up using SharePoint from just customizing Lists. No programming necessary. However there are a few tricks I’ve painfully learned over the years that you can use for your own solutions.
DO
What’s In A Name?
When you create a new list, column, or view you’ll commonly name it something like “Expense Reports”. However this has the ugly effect of creating a url to the list as “Expense%20Reports”. Or worse, an internal field name of “Expense_x0x0020_Reports” which is not only cryptic but hard to remember when you’re trying to find the column by internal name.
While “Expense Reports 2011” is user friendly, “ExpenseReports2011” is not (unless you’re a programmer). So that’s not the solution. Well, not entirely.
Instead when you create your column or list or view use the scrunched up name (I can’t think of the technical term for it right now) of “ExpenseReports2011”, “WomenAtTheOfficeThatAreMen” or “KoalaMeatIsGoodWhenBroiled”. After you’ve created it, go back and change the name to the more friendly “Silly Expense Reports That Nobody Reads”. The original internal name will be the url and code friendly one without spaces while the one used on data entry forms and view headers will be the human version.
Smart Columns
When building a view include columns that make sense. By default when you add a column the “Add to default view” is checked. Resist the urge to be lazy and leave it checked. Uncheck that puppy and decide consciously what columns should be included in the view.
Pick columns that make sense to what the user is trying to do. This means you have to talk to the user. Yes, I know. That can be trying at times and even painful. Go ahead, talk to them. You might learn something.
Find out what’s important to them and why. If they’re doing something repetitively as part of their job, try to make their life easier by including what’s most important to them. Do they really need to see the Created *and* Modified date of a document or do they just need the title and author? You’ll only find out after talking to them (or getting them drunk in a bar and leaving them in the back alley handcuffed to a garbage bin, don’t ask).
Gotta Keep it Separated
Hey, views are there for a reason. Use them. While “All Items” is a fine way to present a list of well, all items, it’s hardly sufficient to present a list of servers built before the Y2K bug hit. You’ll be scrolling the list for hours finally arriving at Page 387 of 12,591 and cursing that SharePoint guy for convincing you that putting your hardware into a list would be of any use to anyone.
Next to collecting the data, presenting it is just as important. Views are often overlooked and many times ignored or misused. They’re the way you can slice and dice the data up so that you’re not trying to consume 3,000 years of human evolution on a single web page.
Remember views can be filtered so feel free to create a view for each status or one for each operating system or one for each species of Information Worker you might be putting in that list or document library. Not only will it reduce the number of items someone sees at one time, it’ll also make the information that much more relevant.
Also remember that each view is a separate page. Use it in navigation by creating a menu on the Quick Launch to each view. The discoverability of the Views menu isn’t overly obvious and if you violate the rule of columns (see Horizontally Scrolling below) the view menu doesn’t even show up until you shuffle the scroll bar to the left. Navigation links, big giant buttons, a screaming flashing “CLICK ME NOW” will help your users find their way.
Sort It!
Views are great so we’re building nice, rich views for the user. Awesomesauce. However sort is not very discoverable by the user. For example when you’re looking at a view how do you know if it’s ascending or descending and what is it sorted on. Maybe it’s sorted using two fields so what’s that all about?
Help your users by letting them know the information they’re looking at is sorted. Maybe you name the view something appropriate like “Bogus Expense Claims Sorted By Deadbeats”. If you use the naming strategy just make sure you keep the name consistent with the description. In the previous example their better be a Deadbeat column so I can see the sort in action. Having a “Loser” column, while equally correct, is a little obtuse to the average Information Worker. Remember, they usually don’t use synonyms and even if they knew how to, it’s not immediately obvious to them that’s what you’re trying to convey.
Another option is to simply drop a Content Editor Web Part above the list and explain exactly the view they’re looking at. Each view is it’s own page so one CEWP won’t be used across the board. Be descriptive in what the user is seeing but try to keep it brief. Dumping the first chapter of I, Claudius might be informative to the data but can gobble up screen real estate and miss the point of having the list.
DO NOT
Useless Attachments
The attachments column is, in a word, useless. For the most part. Sure it indicates there’s an attachment on the list item but in the grand scheme of things that’s not overly informative. Maybe it is and by all means, if it makes sense to you include it. Colour it. Make it shine and stand like the Return of Clippy on every SharePoint list.
Without it being functional it can be boring. EndUserSharePoint.com has an article to make the son of Clippy that much more useful so feel free to head over and check out this blog post by Paul Grenier on the task (Warning code ahead! Danger Will Robinson!)
In any case, I would suggest you remove it from your views. Again if it’s important then include it but consider the jQuery solution above to make it functional. It’s added by default to views and one of things that people forget to clean up.
Horizontal Scrolling
Screen real estate is premium so building a list that contains 8,000 columns and stretches horizontally across 15 screens probably isn’t the most user friendly experience. Most users can’t figure out how to scroll vertically let alone horizontally so don’t make it even that more confusing for them. Take the Steve Krug approach in your view designs and try not to make the user think.
Again views are your friend. Consider splitting up the data into views where one view contains 10 columns and other view contains the other 10. Okay, maybe your information doesn’t work that way but humans can only process 7 pieces of data at a time, 10 at most (then their heads explode and you don’t want to clean that mess up, especially on a Friday night before the big dance).
It drives me batshit crazy when I see a view with 80 columns of data. I often ask the user “So what do you do with all this information”. The response is usually “With this data [the first 10 columns] I decide if I’m going to fire everyone, and with this data [the next 10 columns] I decide if I’m going to set the building on fire and collect the insurance”. It’s at that point I show them how to create two new views “People Who Are About To Get The Axe” and “Beach Time For The Executives”. Again, talk to your users and try to reason with them on cutting down the number of columns they see at once.
Vertical Scrolling
Another big faux pas I find is the use of multi-line comment fields in views. It’s not so bad when you have a statement like this in your view:
“I really like, oh my god, thought I was going to scream when I saw this turtle then I decided what I was going to have for dinner and frankly I hate having to work late so when I was talking to the customer I thought, oh my god, what if the customer has turtles and then it appeared to me that I really was hungry so I'm going to have lunch now.”
It’s fine if that’s the only column along with two or three others, but once you slap those 20 columns of data into the list, the comment field wraps and forms a new multi-page novel that takes up your entire screen.
Do everyone a favour and just avoid adding the column to views. Train the user to just click through to the item if they need to see the contents.
Duplicate Information
Duplication is never good. Views and great as you can group data together. For example create a view of project status reports grouped by author. Then you can see what project manager is being a dip and not submitting their report. However if you group by author do you really need the Created By field as well in the view? Or if the view is grouped by Project then Author do you need both.
Horizontal real estate is always at a premium so try not to clutter up the view with duplicate data like this. Oh yeah, if you’re scratching your head saying “But Bil, if I don’t include the Project name in the view and I have a lot of items then how do I know which one I’m looking at”. That’s a hint that your grouping is too vague or you have too much data in the view based on that criteria. Filter it down a notch, create some views, and try to keep the group down to a single screen where you can see the group header at the top of the page. Again it’s just managing the information you have.
Redundant, See Redundant
This partially relates to duplicate information and smart columns but basically remember to not include the obvious in a view. Remember, don’t make me think. If you’ve gone to the trouble (and it was a lot of trouble wasn’t it?) to create separate views of your data by creating a “September Zombie Brain Sales”, “October Zombie Brain Sales”, etc. then please for the love of all that is holy do not include the Month and Product columns in your view. Similarly if you create a “My” view of anything (“My Favourite Brands of Spandex”, “My Co-Workers I Find The Urge To Disinfect”) then again, do not include the owner or author field (or whatever field you use to identify “My”). That’s just silly.
Hope that helps! Happy customizing!
-
SharePoint Document Libraries and Horrors Oh My
I thought I would capture a few ideas around document libraries and share with the rest of the class. These are not “best practices” as I don’t want to sound too preachy so let’s call them “pretty good practices that you might want to consider if you have some time” (which is far too long for a blog title, hence the one I came up with is going to have to do).
SharePoint Fight Club
The first rule of SharePoint. I want you to repeat after me.
“SharePoint Document Libraries are not file shares.”
Good.
Now say it again.
Good.
Remember this, above all other things we’re going to talk about here, and you’ll be golden.
Document Libraries are not File Shares
I have to repeat this here because it is key. If your users are asking you to put a file share into SharePoint then you need to beat them upside the head when they talk about “replicating the folder structure” or “like for like” or “make it just like *that* (and points to file share)”.
If you really must make some kind of analogy and your audience knows something about databases (even Access), rather than saying document libraries are like file shares say “document libraries are like databases”. While SharePoint sits on top of a database it’s kind of irrelevant what the backing store is (side note, Dear Microsoft, please make a pluggable store for SharePoint in the next version) a list or document library is pretty much like a database. A document library may “look” like a file share just because it lists documents (which originated as files) and contains folders (assuming you left this feature on, more on that later) but it’s more like a database than a file share. Each document is just a blob associated with metadata (title, size, date, author, etc.).
A team once built a “document management system” in Oracle using… wait for it, blobs associated with tables with columns to hold the metadata for the blob. I laughed when they couldn’t store certain types of blobs and spent a ton of time trying to index the system and build a web UI on front of it (and yes, SharePoint was in the environment, that team chose to talk to me after they built it in isolation). True story.
Would you create a folder in a database? No. Great, let’s move on.
Working Online
Something that is going to be a big hurdle for your users (and yourself if you haven’t got into the mindset) is that you do not need to create new documents on your hard drive. Ever. I see this behavior all of the time:
- Start Word/Excel/PowerPoint
- Create content
- Save file to “My Documents” or some such silly place
- Start browser
- Navigate to SharePoint site and document library
- Click on Upload
- Navigate to find document on local drive
Really. Drives. Me. Nuts.
With the Office integration with SharePoint 2007 or SharePoint 2010, you’re able to fully integrate your editing experience with SharePoint. If you know your document is going to go into SharePoint then either a) save it to SharePoint when you’re done or b) launch a New document from the document library (which in turn will open the client app and save back to the SharePoint library by default).
It’s really simple to show users but will take some coaxing to get them to do this. Of course not everything belongs in SharePoint but it drives this SharePoint guy batshit crazy when I see documents in My Documents, a USB drive, a network share *and* SharePoint (of course every location has a different version).
Start using the tools as Microsoft intended you to and you’ll be in a better place.
Do_x0020_not_x0020_use_x0020_spaces_x0020_in_x0020_names
When you first create a new document library please don’t name it “Project Documents” or “Expense Reports – March 2010” or “Famous kittens I would like to juggle”. Instead name it “ProjectDocuments” *then* go back and change the name in the library settings. The reason why is when you create a new document library and call it “Project Documents” it takes on an internal name of “Project_x0020_Documents” and accessing that library in the browser will result in a url of “Project%20Documents”. That’s fugly not to mention a PITA to deal with.
Make everyone happy by crunching the name then going back to rename it to something more human friendly. Frankly I wish SharePoint did this automatically (like it does for publishing pages) but until that happens, we should make a mental note to do it ourselves and be good SharePoint citizens.
Hint: This is my golden rule for lists, columns, and views too!
Don’t Get So Attached
The worst sin (well, one of many) is some guy sending me an email with a document attached to it, usually about a minute after I get the alert the document was added to the library. Better yet, the document copied to a dozen people on my team. I can see the need for this if you have external users who don’t have access to your SharePoint site so that’s perfectly acceptable but you should really compose an email to them with the attachment and send the link to your internal team (I know, two emails are better than one? Your internal team doesn’t need the attachment).
It’s really simple to get a link to the document. Right click, copy shortcut, paste. Another tip when pasting the url into an email is to write a word to describe the document (or even “Document is here” is fine too) and highlight the word or phrase and hit Ctrl+K to create a shortcut. SharePoint links can get somewhat long and ugly so pasting that directly into an email can break up the readability. It’s an extra keystroke but worth the effort IMHO.
Lather, Rinse, Repeat
If you do live in the world where you are interested in versioning is important then go over the draft/publish model with your users. Draft versions have two attributes. First they’re minor versions (0.1, 12.3, 8,348,23.58,328). They’re incremented each time you check a draft version in (and have major/minor versioning turned on). Second, they’re only visible to people that have edit capability on the document library.
For example you have some requirement document that’s going to evolve and perhaps go through a few public versions (say one version for each phase; architecture, design, construction, etc.). The team agrees to use versioning and you twist their arm into a using draft/publish model. It’s really simple. Every time they have a minor edit, they check it in (leaving it in draft). The team juggles around reading it, making comments, pontificating, whatever until they’re in agreement of the contents. Then the custodian of the document checks the last version in and chooses to publish it. It becomes the next major version up and visible to readers of the site.
This works well because all of your minor edits are behind the scenes (and the number of them can be limited if you choose) and people get to see the polished product. Then it’s back to draft modes and “dot” versions, the cycle repeats itself, until the next major change. Treat documents as living entities that grow up (like an application, or a kid but without the mess) and maybe apply Semantic Versioning to them (publishing a major version when there’s something useful to communicate rather than bumping up the major version on every check in). This will cut down on the chatter between the team and readers don’t have to keep asking what the big change from 1.0 to 2.0 was (remember to add comments when you check in a major version).
Document1-draft.doc
How many times have you seen a document named this in a document library? True, you might not have versioning turned on but c’mon people. Really? That’s like using zip files for version control when you have a perfectly good SCM system in-house. The best part is that you look in the doclib and see Document1-draft.doc, Document1-final.doc, Document1-final.docx, etc.
Sit down with your users and explain the virtues of versioning. Maybe it’s not for them and maybe they don’t need full blown major/minor, draft, publish versioning. That’s fine. However if they’re going to be working on documents that evolve and need to be reviewed it’s probably time to show them a draft/publish model.
Bottom line, if you see the –draft, –final behavior then nip it in the bud before it becomes a problem. You don’t have to call your user out in the daily stand up and berate them in front of the team, but be supportive and helpful. Not everyone is a SharePoint Guru like you (and for good reason).
SharePoint Inception
There are some people that have done some nice things with folders (Laura aka “@wonderlaura” Rogers has a great article on Per Location Views). I feel these are exceptions to the rule. Systemically it probably stems from the file share stigma. People organize information using folders so it’s natural to them. The problem is that (remember?) document libraries are *not* file shares. Stop treating them like that.
Folders are like IFRAMEs. They were a great idea but as time went on, without people knowing any better or good ways to use them, they became ugly and nowadays IFRAMEs are pretty evil and frustrating and we don’t have a lot of them around. We’ve grown past them. Now let’s move on from folders.
A few things about folders that make them different from nuclear reactors:
- Document libraries have a path limitation (actually I think the limitation is on IE or maybe even HTTP) so nesting lots of folders inside of folders chews this up real quick. Trust me when you exceed the path. The error message you sometimes get is a blank screen.
- You generally have to know where something lives in order to find it. This can lead to dozens of clicks on folders depending on how great your folders are named.
- Folders are neither discoverable (other than the top level ones) nor searchable. Metadata is.
Folders don’t help organize information. Yes, I create a folder named “Expense Reports” but that doesn’t mean my smart users are going to put expense reports in them. Or a folder named “Architecture”. I guess I’m going to expect Visio drawings or stickmen or something in here but what happens when I start seeing server inventories in spreadsheets. Is it architecture or detailed design (or a document misfiled from some other project). Metadata and Content Types help you organize information.
Folders attach a fixed path to a document. If you drop something in a folder that’s how you retrieve it. If you decide one day to simply move it up or down the folder hierarchy, guess what? All those links are now broken. Using metadata to organize information means “I don’t care where this is but I know what it’s about”. Get into the habit sooner rather than later.
Where Am I?
Just a bit of a follow-up to using folders. One of the worst things you can do is drop a document library onto the home page of a site. Your site is for information. Try putting announcements, tasks, or pictures of kittens on your team/project home page. Not documents.
If you put a document library on the home page and have folders-from-hell enabled have you noticed the evil that is unleashed? No. Take a look again. Click on a folder. Now another one. Now another. Keep going until you’ve descended into the 9th level of Hell. Now take a good look at that url in your address bar. Go ahead. Click it. Now send it to someone with a note “I left your termination notice here” and paste in the link. When your unsuspecting suspect clicks on said link, nine times out of ten, he or she will be taken to… THE HOME PAGE of your site. Cool beans. Note that I said “maybe” so it’s not a guarantee but it’s also not very pretty. Like any Jessica Simpson movie pretty. And your users will grumble and gripe and blame SharePoint, not Jessica Simpson.
The other pro (or con depending on how full or empty your glass is) you get from dropping that beloved document library on your home page is the all important bread crumb trail. Pro or con, the breadcrumb trail that you see above a document library when you’re navigating through it is gone. It only exists when you send your users to the doclib itself so forget any navigation up the levels of Hell (or even knowing where you are if you care).
Metadata, metadata, metadata
Oh but Bil, I can’t find my documents without putting them in a folder called “My Documents”. Now after you noodle on that statement for a minute think about it. You unleash the fury of SharePoint on your team spouting commandments like “THOU SHALT PUT DOCUMENTS INTO THY DOCUMENT LIBRARY” and your team has no clue how to organize documents in a document library (let alone their own desktop) and you yell at them for not “categorizing” or “classifying” them properly.
Give yer head a shake.
You can’t bash people for playing the game incorrectly if you don’t give them the rules to the game.
Metadata is king in the SharePoint world. If you need to organize your documents dump them into a doclib and stick a column on said doclib called “Category” (or “LOLCATegory” if that turns your crank). Make it a choice field and let users add their own or make it a lookup into a list (or better yet use the metadata feature in 2010 but if you’re on 2007 we live in simpler times). Then create a view grouped by category. Create some searches on the category column. Create some views for categories the team feels important like “Important Architecture Documents” or “Things I would like to do to Bil if I could”. Pretty soon the team will be happy because they don’t have to spend 3 hours looking for a document that’s in front of their face.
Note that the space-in-names rule doesn’t apply to choices in a choice field. It doesn’t form a url and SharePoint doesn’t go tossing in its “_x0020_” macro on you. Be wild.
Breaking Boundaries
One final question about document libraries is how much is enough? How many document libraries do I need to store my documents. The answer my friend is “it depends” (oh you knew I was going to say that). Only you or your team or the collective wisdom of whomever is using the library knows what the right division is.
There are a few factors you can use to decide where to draw the line. Size might matter (although less so in SharePoint 2010). You might want to break up document libraries based on security. While you can apply security to (gasp) folders or items in SharePoint, it might make more sense to just seclude off a library for privacy. Remember when you created the first team site and got a “Shared Documents” library for free? There’s nothing but fear and common sense preventing you from creating a “Team Documents” and only allow members of the team to have read access (“Unshared Documents” just sounds a little badly in the grammar department).
I can tell you I don’t know what the right division of document libraries is but I can tell you what the wrong one is. One document library per document. Yeah, I’ve seen it. It’s evil.
Christmas Time
Okay, to wrap up let’s just remember two key things:
- Document libraries are not file shares
- Dumping files into folders is not organization
I’m sure there are more than two key things you can take away from this, but I had to end this post or else face eviction from my home.
Enjoy!
-
WordPress versus SharePoint, another big smackdown
Previously I did a compare and contrast entry about DotNetNuke versus SharePoint. Now its time for WordPress to have a turn. Don't worry, there's more to come (Drupal, Joomla, Central Desktop, Box.net, etc.) but I've been working with WordPress for a few years now in personal blogs and sites and frankly I'm really, really impressed at the software. Architecturally it's no SharePoint and isn't the silver bullet that everyone touts SharePoint as, but for what it can do it does a good job. So here we go.
There seems to be a plethora of choices when you venture into standing up web sites where the content isn't completely created by a developer in Visual Studio. Call it content management, call it dynamic web delivery, call it modules and web parts and user centric assembly. Call it whatever you will, it's the the ability to empower people to contribute content (files, articles, etc.) to a website without the need for an "IT guy" to be the one doing all the work. Recently we just moved away from using CMS 2001 where (for whatever reason) all content was done by a guy in our department. Someone would send him an article, call him, or direct him to a website and he would create the content in CMS and publish it. As you can imagine having a single resource doing this all the time is pretty taxing and basically ignores the fact that users have been able to do this for hundreds of years themselves. No software in the world is going to fix a process where you rely on someone to do this for you, but these packages help you empower users to do it without having a lot of technical knowledge (the desire to create it still needs to be there, or a pointy haired manager with an equally pointy stick).
Introduction
WordPress is (IMHO) primarily a blog tool, however it does offer the ability to upload and serve up media (photos, videos), author pages of content, and with the vast number of 3rd party add-ins available the ability to hook into other resources (Twitter, Flickr, RSS, Paypal, etc.) and create a dynamic site that can no only serve up content but help you run a business. For this reason it seems appropriate to compare it to SharePoint. While the two are somewhat different in principle (and vastly different in architecture and infrastructure) they share the notion of delivering a user driven content site. You can just as easily accomplish most of what you can do in WordPress using SharePoint and vice versa.
Looking at some showcase sites you can see that both tools can deliver content in a similar fashion. Best Buy is hosted on WordPress (a surprise to me as I write this article) while Ferrari.com recently launched on the SharePoint 2007 platform. One thing to note about Best Buy. I went to the "showcase" site which is the WordPress driven site and essentially a store blog. I also launched the link to one of my own local stores. The local store site seems to be driven by ASP. When you visit the "store blog" site, the front page is fine but when you say select an item from the menu you're whisked away to http://www.bestbuy.com/ and in JSP land. Do they use ASP in Canada but JSP in the States? In any case, the WordPress site is really just a nice place to visit but isn't actually powering the entire site (including purchasing or reservations). In contrast, the entire Ferrari.com site and other SharePoint sites are 100% SharePoint and don't "shell" out to a "real" website to handle eCommerce. So as you're looking through the WordPress showcase sites understand that some sites are just window dressing for the real non-WordPress site.
As far as SharePoint goes, head on over to Top SharePoint Sites which showcases the best of the best and over 1200 internet facing sites running SharePoint. Ian Morrish also has a (bigger) list of about 1500 sites using Live Labs Pivot. It’s very cool and can be found here. Of course it would be highly entertaining to have a window dressing site hosted on WordPress that backs onto a SharePoint site.
A Fair Comparison?
For the record, we’re talking about the current version of WordPress 3.0 against SharePoint 2010. They’re pretty similar in the grand scheme of things. You might think it would be fair to compare WordPress to SharePoint Foundation 2010 but WordPress is a CMS as much as any so IMHO it better compares against SharePoint Server than it does against Foundation (or WSS if you’re looking at 2007). Feel free to debate what versions should be measured here and write your own damn review.
Architecture
These two ducks couldn't be so vastly different in architecture and infrastructure than Michael Jackson and Fidel Castro are. SharePoint is an ASP.NET application using a MS-SQL backend while WordPress is written using PHP and a MySQL backend. While WordPress sites can be snappy in terms of performance, it still is running on an interpreted language vs. a compiled one like ASP.NET.
SharePoint is designed to run either on a standalone server (up to 1,000 users comfortably on typical hardware) or scale out almost indefinitely. I know personally of SharePoint deployments housing millions of sites across multiple data centers with many web front ends, dedicated index servers, etc. Microsoft itself hosts SharePoint team sites internally which at last count was around 50,000 sites. It's unclear how scalable WordPress is. It is a web app and basically any kind of load-balancing scheme to serve up multiple web servers will work. The MySQL backend database can scale out in a cluster scenario just like MS-SQL and with WordPress there's no intermediate app server so really it's just web and database servers all talking to each other. From what I can find out there I don't know of WordPress limits in this regard (there's a 32,000 blog limit in WordPress itself, much like the limits on SharePoint sites, subsites, etc.). Even wp.com, the WordPress blog hosting site (in addition to Wordpress.org, see here for a comparison of the two) doesn't talk much about it's architecture but it does run on hundreds of servers with "several separate data centers" spread throughout the U.S.
Another clear winner here is the setup. SharePoint in a stand-alone scenario still requires you to remote into a server, run a setup program and create your site, then shuffler over to Central Admin to do a fairly lengthy setup. On a good day I can maybe get a new system up and running (so that it doesn't fall over in a week) in a few hours. Compared with WordPress this is a lifetime of despair. Time to create a new WordPress site (including creation of the database and website). 10 minutes. WordPress offers the "5 minute installation" (which frankly has *never* taken me more than 2).
SharePoint still tried to compete in the hobby hosting scenarios and there are plenty of knowledgeable sites out there offering hosting (pretty cheap too) but even in that scenario you're still at the mercy of the host and their ability to setup (or not setup) SharePoint properly. WordPress on the other hand simply requires a server that supports PHP and MySQL. Create a website, FTP up the files and you're pretty much 90% of the way to your new site. Perhaps someday WSS is going to be packaged in such a way where you can upload it to a shared host via FTP and as long as the site supports MS-SQL and .NET you're golden. Until then, turn to your hosting people to provide a SharePoint site.
Core Functionality
At it's core both products are web content delivery tools. If you look at MOSS, we're talking about content authoring and something more aligned with WordPresses page authoring model. WSS is much more static in terms of page design (for example if you don't like the layout of the default home page of a WSS site it's not that easy to change it) whereas WP can pretty much be anything you want to be. While the flexibility of WP outshines SharePoint's more rigid constraints, SharePoint blows the doors off of content collaboration. I'm sure there are some plugins for WordPress to upload documents and potentially rate them but it's going to be pale comparison to SharePoint lists and collaboration features.
WordPress is primarily a blog engine although it supports “Pages” which can contain any content. Like SharePoint’s publishing pages you can create the content just as easily in both tools. Creating custom layouts in WordPress requires a little bit of knowledge of PHP and some HTML skills. With WordPress you can just upload a layout page and create pages using it. With SharePoint pretty much the same except you’ll need a few skills in understanding ASP.NET Master Page markup and a copy of SharePoint Designer to get your page into the system.
Other than posts and pages and some admin functionality, WordPress really doesn’t have much in the function category. There are no built-in polls or discussion boards. It does have a userid/password registration/login system which is basic. On the flipside you could argue that SharePoint doesn’t have these things either as they’re really a bunch of Features that you just activate (most are already activated by default) and light your site up. With a few (free) plugins you could easily bring WordPress up to snuff with *most* of what SharePoint can do (sans the document stuff).
WordPress works off of PHP template pages, themes, and widgets. Basically the entire site can instantly transform with a new theme (which are a mixture of PHP pages, CSS, images and whatever other assets you need like JavaScript, etc.). SharePoint combines ASP.NET Master Pages with Layout pages with CSS. Pretty much the same. The pain and suffering (described below) in creating SharePoint Themes is similar to the pain and suffering in creating WordPress themes but there are tools out there like Artisteer that will get you most of the way with WordPress. Widgets in WordPress, Web Parts in SharePoint. Same diff.
Look and Feel
By design, WordPress was built with a "Web 2.0" look and feel in mind (I know, I hate that word). SharePoint 2007 has made some advancement in getting more towards the Web 2.0 world but progress is slow and steady with SP while WP themes continue to re-invent ways how information can be presented and served up. SP suffers from some very hard constraints. Some of the OOTB master pages provided with SharePoint don't have a DOCTYPE specified so adding things like jQuery plugins fail miserably. Even adding a DOCTYPE to SharePoint sometimes causes problems with some of the other functionality (specifically the DataSheet view has been known to break). While there are work-arounds, basically SharePoint sites are stuck in IE 5.5 "quirks" mode. In 2010 at least we have some “proper” master pages and some of the quirks are gone. The OOTB master pages in SharePoint at least are “modern”.
I mentioned themes. WordPress has a design for themes around a template system which physically separates components of the theme, making it fairly easy to "skin" your website. There's a fairly extensive set of resources to create themes (including a countless number of pre-created themes spread all over the Internet) but you can get started building themes for WordPress here. SharePoint has similar things called Themes for WSS sites which are defined by resources (image files, CSS, etc.) and some XML glue to define the theme itself. There are several articles by MVPs and the community on how to create themes for SharePoint. The MSDN documentation in the SharePoint SDK also has the steps involved.
Themes are a thing of the past in SharePoint 2010 (they exist but only for color and fonts) so basically ignore them. Your main way to theme/skin SharePoint is master pages and/or custom CSS files to override the base styles. There are still over a billion (yes, I’ve counted) CSS classes with SharePoint so good luck with that. In my UI presentations I basically tell anyone who’s even remotely thinking about doing SharePoint UI customization to a) always start with a 2007 minimal.master (or Randy Drisgill’s Starter Master Pages for SharePoint 2010), a copy of FireFox, Firebug, and the Web Developer Toolbar. Don’t waste your time with IE and the “developer toolbar” (that doesn’t even let you modify things at runtime). And really, do this for any web development, WordPress included.
As for delivery of the theme, that's another story. With WordPress you simply upload a zip file of the theme you want and activate it (with the option to preview it using your site data so you can see what it's going to look like). Don't like downloading a zip file only to upload it again to your server? Then just browse the themes available and install them. With SharePoint once you have a theme you want to install, it's a matter of adding it to the 12 hive folder structure, modifying an xml file on the file server, and then doing an IISRESET on the entire server (yes, an Application Pool recyle won't suffice so if there's anything else on that server it's gone for 15 seconds during the reset). Basically the stone age compared to the modern age.
For SharePoint 2010, you can create themes in PowerPoint and upload the result to SharePoint to use as a basis for your theme, or just customize it in the browser. In 2007 you have to sacrifice a small virgin and give up your first born to deploy a theme. Don’t bother, it’s not worth it. Just upgrade to 2010 and don’t bother with themes. Master pages and CSS files can just be uploaded to the site but for editing Master Pages you *must* use SharePoint Designer. While you can get away with opening it up in something like Visual Studio, it won’t resolve a lot of the server side tags and frankly, it’s a lessening experience. SharePoint Designer isn’t a joy to work with on HTML editing (why can’t they just provide a collapsible DOM tree like every other editor on the planet) but it gets the job done and helps with visualization.
Themes (and website skinning) is an interesting beast as far as availability and abundance goes. On the WordPress side, you basically can't go anywhere on the Internet without falling over a new WP theme. There are without a doubt literally thousands of themes out there and we're not just talking about the "10 variations on a colour" themes. Just look at Free WP Themes (one of my personal favs) offering 200 designs, all mostly unique and interesting. Even the WordPress.org site itself has over 900 themes available (also available through your admin dashboard). Where are the SharePoint themes? Does Microsoft host a site to house them for you to preview and download them? Sadly no, but for some reason when Microsoft releases 10 new themes, the entire planet gets up and dances for joy. Hmmm. Okay, sure.
WordPress slips into a dangerous area with authoring themes or even page layouts. Template tags are PHP code and this can drive web designers or site admins away at the very mention of "code" (just ask Bob Fox to code you up a page layout to see what I mean). HTML-like tags (similar to DotNetNuke tokens) might be easier to figure out rather than WP's PHP syntax. SharePoint layout pages (MOSS) or master pages or themes are more standards web based (yeah, it's a bit of a stretch) so web designers are more familiar with these and might be able to get up to speed on creating new layouts faster than they would with PHP. However my motto is usually don't send in a mouse to do a man's work and template/theme creation is something better left to web designers and programmers no matter what the platform.
Community
There are few open source projects in the world that have as strong a following as the very active WordPress does. SharePoint comprises of a lot of users that are very passionate about the product, but the community is highly fragmented. Is there a single place people go to (besides Google) to find SharePoint information? Wordpress.org is the community site for WordPress users and is easily accessible, especially since just going into your WP dashboard presents you with news from the community (as well as your stats being tracked at wordpress.com). SharePoint information is out there and can be found, but it's hit and miss. SharePoint does have the advantage of the Microsoft Forums where you have MVPs, Technical Staff, and End Users all helping out. There are online forums for WordPress but it’s hard to find things and there’s so many posts it’s hard to keep up.
Extensibility
This is where WordPress kicks the llamas butt with SharePoint. Just go to the WordPress Plugin Directory and you’ll be able to access over 10,000 plugins instantly. Where are the 10,000 Web Parts for SharePoint? Scattered to Hell’s Acres and back. What’s even cooler is the knock-down, drop-dead easy way it is to extend your WordPress site. Go to yoursite/wp-admin –> plugins –> add. Type in some search criteria (or browse popular or featured ones). Click install and activate. Bob’s yer uncle.
With SharePoint 2007 you’ll need a properly packaged solution (in a WSP file or MSI or something) or else you’ll be hand bombing things on the server. Oh, did I mention the remote desktop to the server in order to get the freakin file into the solution store. Then there’s deployment and finally activation. So that’s one command line, one central admin website, one site collection and you’re off to the races. Lather, rinse, repeat for each solution you want to add.
At least in SharePoint 2010 we’re getting better. The deployment story is pretty good with Sandboxed Solutions and while they have some disadvantages, there’s plenty of advantages over WordPress like resource throttling and process isolation that will make up for it.
Still, the number of pickings for what is out there in SharePoint land is pretty slim but then quantity != quality. And frankly if you look at the types of WordPress plugins, they’re mostly geared to internet sites with pretty specialized functionality. Hard to say if there’s any winner in this section but you have to admin, if you can’t find a plugin to do it in WordPress you probably shouldn’t be doing it. There’s something for everyone and everything.
Development and Documentation
Both products are pretty mature. The WordPress site has a pretty impressive documentation landing page that has pretty much everything you can think of on WordPress online for free. There are over a dozen WordPress books so there is a lot of momentum behind it and no shortage of knowledge. WordPress has a nice thing called the Codex which is their way of saying Wiki. Anyone can contribute to it and you can consider it a Wikipedia for WordPress. It’s nice to have all this information centralized, easily searchable and discoverable all in one place.
SharePoint offers up MSDN documentation which, in my experience, is a nightmare to navigate, many times completely incorrect or misleading, and sometimes fixed (content where you cannot even leave just a comment). The MSDN documentation for the most part offers asinine descriptions of methods. For example the description and documentation around the SPRole.PermissionMask is “Gets or sets the rights used for the permission mask of the site group”. Riiiight. So *what* is a permission mask? *what* is valid? *what* is the value I should use to set full permissions? Eventually you can weed your way through to the content that makes sense but it’s a long trip.
MSDN has changed. For awhile, they adopted the comment model. This was great, you could enter comments that corrected things in the documentation around a class or method or property. It was very much like the PHP documentation model. For example here’s the PHP documentation on the Static Keyword. Basic docs but a whack of comments from the community in the form of threads. Corrections to the documentation, examples of use, gotchas, etc. *THIS* is what MSDN Documentation needs for the SharePoint API. It’s just that since the last look and feel change, that ability is now gone.
As part of the WordPress Codex they have a Developer Documentation section. This is a nice, easily organized, list of programming topics including theme and plugin development, testing, widgets, and all the APIs in WordPress. It’s very much like the MSDN content for SharePoint but a little easier to follow. The pages are static looking, but it’s a wiki. Sign up for the codex, read the guidelines (very much like Wikipedia) and get editing. MSDN should re-instate this.
From the development perspective WordPress is pretty straight forward. Get a local copy of PHP (xampp is great for this) and a text editor or any of the numerous PHP IDEs out there, and get coding. Deployment is just saving a file.
For SharePoint you’ll need Visual Studio 2008 (for SharePoint 2007) or Visual Studio 2010 (for SharePoint 2010). The SDK offers instructions on building web parts, event receivers, etc. For Master Pages, Layout Pages and other things you’ll need a copy of SharePoint Designer (free) for each environment (or get crazy like me and have 2007 *and* 2010 installed). SharePoint deployment isn’t as simple as “save file” but with WSPBuilder and the WSPBuilder extensions it can be pretty painless (at conferences I demo going from a blank Visual Studio to deployed Web Part with Feature Receiver in about 10 minutes). Other tools you can check out are STSDEV or just build the content yourself. There’s nothing magical about SharePoint solutions, they’re just .NET class libraries. Visual Studio 2010 has a better developer story with “F5” development and some simpler tools (including a Visual Web Part that gives you a design surface).
For me, there’s the frustration of building code solutions in SharePoint and going through various hassles of packaging and deploying it properly but working in an uber cool language like C# vs. a not-so-cool language like PHP (I can tolerate it and it’s not bad) but a simple deployment cycle that’s low footprint and easy to spin up. Again, no clear winner here.
Wrap up
Overall SharePoint could learn and model a *lot* of features from the WordPress guys. Simple things like themes and look and feel should be a pleasant UX, not a complicated IT task. WordPress is all about dynamic look and feel and provides a lot of "previews" to what will happen before it's done. This is in stark comparison to SharePoint's "do it and we'll tell you if something broke" approach. The integrated administration the WordPress offers (the ability to download and install themes, widgets, and plugins right inside the dashboard) makes it an easy sell for the hobbyist and simple admin. SharePoint is getting there and the 2007 administration is an improvement over 2003 but it's still got a long way to go.
SharePoint could look at the community integration that WP offers. Imagine opening up your Central Admin and seeing news about patches, new web parts, and blogs from the community? Microsoft has taken the attitude that this information is best left to sites like SharePointPedia.com (which seems to be suffering from lack of anything) and it's own SharePoint.com for this type of aggregation. Perhaps this is the difference between a corporate system (that would potentially live behind firewalls and you don't want to be punching out to the big bad interweb from your server to get news) vs. the public hosting aspect of WordPress but I do feel a more community-driven dashboard built into SharePoint Administration would be more value-add for the SharePoint admin.
WordPress of course isn't the best thing since sliced bread and if you're going to go after that "Intranet Portal" crowd in the Enterprise it's going to be a hard sell to Corporate America, being open source, free, and built on PHP and MySQL. It also suffers from the stigma of being a "blog platform" and not something seen beyond that. I think showing WP as a corporate intranet isn't a far stretch, however it lacks SharePoint's seamless integration with the client and Information Worker tools so you have to pick what's best for your organization. Free (as in beer) can be a good thing or a bad thing for a company. While it's "free" as in download, setup, play. There's hidden costs associated with MySQL backends, backups, restores, IT people to keep the web servers burning, and all that jazz. Also if you start hooking up something like WordPress to a SQL backend to try to pull "corporate data" into the fold you start constructing a Frankenstein monster and we all know how costly that is in the end.
As a collaboration platform WordPress shines and is sexy provided that your idea of collaboration is online comments, forums, and rated content. Throw document versioning, approvals and workflow and business data on the pile and while SharePoint isn't as sexy looking as WP is, it gets the job done.
I don't think there's a right or wrong choice here but pick your tools as you see fit. As always, choose, but choose wisely.
-
Setting up a Local Mail Server for a SharePoint Virtual Machine on Server 2008
The only way to do software development for SharePoint is really a Virtual Machine. Yes, with SharePoint 2010 you can install it on Windows 7 and Vista and with some hacking you can get SharePoint 2007 to run on Vista. However I’m talking about real development for real men (and women!). For that we setup virtual machines (VMs) and usually run the whole SharePoint stack on it (SharePoint, SQL Server, Visual Studio, SharePoint Designer, Office, etc.).
One of the key advantages of running in a VM is the ability to run your SharePoint server as a domain controller (or at least connected to one) where you have ultimate control over it. This allows you to practice safe installs, spin up an environment with exactly the same OUs as your production environment, use the same account names, etc. all without having to peeve off your friendly neighbourhood domain admin.
The last piece of the isolated puzzle is getting mail working. SharePoint supports both mail out (alerts, etc.) and mail in (email enabled document libraries). However for this trick you need a mail server, or an incredible simulation of one. Very often people go to the trouble of installing a copy of Microsoft Exchange which falls into the bazooka-to-swat-a-fly realm. Exchange is big and heavy and a bugger to configure and run, all for what? A few emails that trickle into your VM and to an administrators mailbox?
Here are two options that will prevent you from setting up an Exchange server, which should only be left for those with a desire to hurt themselves.
Server 2008 SMTP Server
First up is the Windows Server 2008 SMTP services. If you’ve installed Server 2003 you know that it came with a SMTP server and it was pretty easy to setup (here’s a great walkthrough). With Windows Server 2008, there’s no longer a Mail Server role but you can still install the SMTP services.
SMTP services are now a “Feature” (not to be confused with SharePoint Features). Open up Server Manager and under Features select Add Feature. Select the SMTP Server option, click Install and go have a short siesta.
Now what can you do with it? Not much but if you want to do anything, you have to install the IIS 6.0 Management tools (a disadvantage of one tool requiring legacy features, just one of the many with the SMTP service). Once you have the IIS 6.0 tools installed, you can cry a little. I did. Then launch the IIS 6.0 Manager, cry again, and you’ll see the SMTP services in the tree. Right click on the menu to bring up the SMTP properties.
Select Relay under the Access tab:
Select “Only the list below” and click Add:
Enter 127.0.0.1 for your local address:
So now you have a local SMTP service that will relay messages from the local system. Splendid. However this is only for SMTP. What about POP3? That’s where it gets tricky and frankly, this blog is not going to go to that bad place. I did manage to find a POP3 “extender” for Windows Server 2008 so you can explore that here and give it a shot. However that gets you part of the way there and there’s still the issue of adding domains, only having unauthenticated users, and IMAP… well. All of these add up to a big headache to configure and while SMTP services is a far cry from the bloat that is Exchange, there are other sane options.
Sidebar: You might be wondering why I walked you through the setup of SMTP services only to direct you somewhere else. Hey, I’m all about free choice so if you’re happy and you know it then clap your hands and stick with SMTP. If you want to live like the rest of us do, read on.
So Exchange is out (unless you really enjoy chewing up 4GB of your precious VM just to deliver mail) and SMTP services have left a bit of a bad taste in our mouths. What else is there?
I stumbled across this server tool accidently sometime in 2005 or something. I can’t remember exactly but it was a pre-beta that worked well. It’s a complete mail server for Windows and can run on XP, Server 2003, Server 2008, Vista and Windows 7. It supports all the basic protocols (IMAP, SMTP, POP3) and does what it should. Deliver email.
On top of delivering mail it supports mapping to domain accounts, having your own accounts (username/password), security, auto out-of-office messages, mailbox limits, customization out the ying-yang, and all sorts of options and gadgets. The brilliant part of the system is that it’s easy to setup and get running (add your domain and you’re done) but you can have your cake and eat it too. Run it stripped down and simple or load up all options to make it that much more filling.
Best of all, it’s totally free (as in beer). And hey, if you want the source code is available up to version 4.x (the current version is 5.x and closed source).
You just download and run the installer. Takes about 1 minute (literally) and it’s up and running. It comes with it’s own embedded database (used to be an embedded version of MySQL but later versions now ship with SQL Server Compact Edition which is just a single DLL) to store the configuration and emails.
Don’t get too choked up in all the options. There are many but it’s the simplicity of this tool that makes it shine and since it supports POP3 and SMTP (along with IMAP) it’s almost like having Exchange running. If you do decide to turn on logging, add multiple domains and security, forwarding, etc. it’s all built in. Nothing to download or add-on. All the nice additional wrappers sent by SharePoint to Outlook are intact so you can still interact with your SharePoint system from your email client. The only drawback is there’s no calendaring element so that’s out, but otherwise it’s all good to go for any budding SharePoint developer (or anyone that wants to debug emails going through a system).
So really. This is one of those things I have in my toolbelt when it comes to SharePoint and I don’t setup a server without it. It’s a breeze to setup, free, and does everything you need it to for your virtual environment except feed the cat and impregnate your daughters (or is that the other way around?). Check out hMailServer and give it a whirl.
Full disclosure: It’s a free product and nobody coaxed me to write this. I get no kickback from the download of the product other than the credit card number you may accidently send me as you decide to fill me with praises and remarks, but I’m good with that.
-
Sandboxed Solutions and SharePoint 2010
One of the most interesting new feature of SharePoint 2010 is something called Sandboxed Solutions.
Think of it this way. In 2007 we have solution packages, WSP files that are packaged up with all kinds of goodness (Master Pages, InfoPath Forms, Web Parts, Custom Actions, etc.). Whenever we want to deploy these, we need to hunt down our IT guy and hand him over the package to run on the server and deploy, using the farm account. Only then can we activate the feature on our site or site collection. And then there’s the hassle of retracting, redeploying, etc. for upgrades.
In 2010 the game has changed. You can still upload WSP files on the server to the solution store but there’s a new kid in town called Sandboxed Solutions. From a development perspective, they’re pretty much the same as building a solution today. You can create web part, write event receivers, create InfoPath forms, etc. You’re allowed a subset of the full SharePoint API (what’s allowed is documented in the SDK). Some of the major restrictions to Sandboxed Solutions are accessing the web.config file or farm file system (the 12 hive), central administration, and going outside the site collection. Sandboxed Solutions are uploaded to a single site collection (although there’s nothing stopping you from uploading it to multiple site collections) and basically can access any data within that site collection, if you want to.
The main advantage of Sandbox Solutions is two-fold. For the developer, he just needs to be a site collection admin (rather than a farm admin) so it’s simple to give him or her their own site collection and let them go to town. For the SharePoint admin, you can monitor a sandbox solution, throttle memory and CPU usage, and even shut down solutions that have gone rogue without taking down the entire farm.
Here’s a few Sandboxed Solutions that have hit the interwebs to show you some cool things you can do with this new feature of SharePoint 2010.
Currently I use Jan Tielens SmartTools jQuery to blast a copy of jQuery onto every page in my site collection. It works great because it’s just a site collection feature and doesn’t require me to muck with whatever Master Page I’m using at the time. It even shows up on application pages in the _layouts folder because it uses the AdditionalPageHead DelegateControl. Problem is this isn’t an option in 2010 as a Sandboxed Solutions (DelegateControls are not permitted in the Sandbox) but Daniel McPherson came up with a pretty slick solution over at zevenseas that does just this. Check it out here.
Another Sandboxed Solution from Mr. McPherson gives us a “go” service for SharePoint. Basically you create pathways (keywords that lead to a fully qualified URL) and mange it through a simple SharePoint list. Whenever a user goes to the link site with that keyword (http://yoursite/go.aspx?LinkId=HelpDesk) they’ll be whisked away to whatever site the pathway is configured for. This is great for important sites that might move around as a result of needing to restructure your site collection or servers that bounce around or whatever reason you might have. Users can always rely on the original link to be valid. The community version (free) of the Link Conductor only supports 15 pathways but it’s enough to get started to see if this is worth it to you. Check it out here.
For SharePoint 2007, Scot Hillier put together an excellent collection of solutions to help get things done. You can still see his 2007 collection here. Now he’s putting together the same thing but for Sandboxed Solutions! So far there are only a few in the collection so it’ll grow. Definately a CodePlex project to keep an eye on. Check out the Sandboxed Solutions collection here.
This is one of my favorite projects, not just because it’s an Agile planning tool but it’s built in SharePoint and… a Sandboxed Solution! Andrew Woodward and company have put together a very slick solution that allows you to have a Mingle like interface in SharePoint, driven by a simple SharePoint backlog list. It’s very cool and you must try this out, even if you’re not into Agile planning and tracking tools. Check out 21SCRUM here.
Search AutoComplete for SharePoint 2010 Lists
There are a few “autocomplete” solutions for SharePoint 2007 but here comes another one, and a Sandboxed Solution. Very slick and quick and easy to get up and running in your environment. Oh yeah, also free as in beer. Check it out here.
All in all, a very powerful feature. As always, with great power comes great responsibility so sit down and think long and hard before you allow or disallow this type of practice in your environment. With any development methodology you should inform your developers of what the boundaries are, help them getting going with their solutions, and make it a win-win scenario for everyone. Maybe sandboxed solutions are not for you, but give them consideration and maybe they’ll be a new tool in your SharePoint toolbelt!
BTW, just to be fair Doug Ware wrote up an alternate piece to Sandboxed Solutions basically saying they had a lot of restrictions (which they do). You can check out his excellent article here over at End User SharePoint and judge for yourself if you want to use them.
Resources
- Developing, Deploying, and Monitoring Sandboxed Solutions in SharePoint 2010
- SharePoint 2010 Sandbox solutions: Architecture and Restrictions
- Introducing Sandboxed Solutions (15 minute video by Andrew Connell)
Got more Sandboxed Solutions you want to add? Post them in the comments below!
-
Content Query Web Part and the Yes/No Field
The Content Query Web Part (CQWP) is a pretty powerful beast. It allows you to do multiple site queries and aggregate the results. This is great for rolling up content and doing some summary type reporting. Here’s a trick to remember about Yes/No fields and using the CQWP.
If you’re building a news style site and want to aggregate say all the announcements that people tag a certain way, up onto the home page this might be a solution.
First we need to allow a way for users of all our sites to mark an announcement for inclusion on our Intranet Home Page. We’ll do this by just modifying the Announcement Content type and adding a Yes/No field to it. There are alternate ways of doing this like building a new Announcement type or stapling a feature to all sites to add our column but this is pretty low impact and only affects our current site collection so let’s go with it for now, okay? You can berate me in the comments about the proper way I should have done this part.
Go to the Site Settings for the Site Collection and click on Site Content Types under the Galleries.
This takes you to the gallery for this site and all subsites. Scroll down until you see the List Content Types and click on Announcements.
Now we’re modifying the Announcement content type which affects all those announcement lists that are created by default if you’re building sites using the Team Site template (or creating a new Announcements list on any site for that matter).
Click on Add from new site column under the Column list. This will allow us to create a new Yes/No field that users will see in Announcement items. This field will allow the user to flag the announcement for inclusion on the home page. Feel free to modify the fields as you see fit for your environment, this is just an example.
Now that we’ve added the column to our Announcements Content type we can go into any site that has an announcement list, modify that announcement and flag it to be included on our home page.
See the new Featured column? That was the result of modifying our Announcements Content Type on this site collection.
Now we can move onto the dirty part, displaying it in a CQWP on the home page. And here is where the fun begins (and the head scratching should end).
On our home page we want to drop a Content Query Web Part and aggregate any Announcement that’s been flagged as Featured by the users (we could also add the filter to handle Expires so we don’t show old content so go ahead and do that if you want).
First add a CQWP to the page then modify the settings for the web part. In the first section, Query, we want the List Type to be set to Announcements and the Content type to be Announcement so set your options like this:
Click Apply and you’ll see the results display all Announcements from any site in the site collection.
I have five team sites created each with a unique announcement added to them.
Now comes the filtering. We don’t want to include every announcement, only ones users flag using that Featured column we added.
At first blush you might scroll down to the Additional Filters part of the Query options and set the Featured column to be equal to Yes:
This seems correct doesn’t it? After all, the column is a Yes/No column and looking at an announcement in the site, it displays the field as Yes or No:
However after applying the filter you get this result:
(I have the announcements from Team Site 1 and Team Site 4 flagged as Featured)
Huh?
It’s BACKWARDS!
Let’s confirm that. Go back in and change the Additional Filters section from Yes to No and hit Apply and you get this:
Wait a minute? Shouldn’t I see Team Site 1 and 4 if the logic is backwards? Why am I seeing the same thing as before. What gives…
For whatever reason, unknown to me, a Yes/No field (even though it displays as such) really uses 1 and 0 behind the scenes. Yeah, someone was stuck on using integer values for booleans when they wrote SharePoint (probably after a long night of white boarding ways to mess with developers heads) and came up with this.
The solution is pretty simple but not very discoverable. Set the filter to include your flagged items like so:
And it will filter the items marked as Featured correctly giving you this result:
This kind of solution could also be extended and enhanced. Here are a few suggestions and ideas:
- Modify the ItemStyle.xsl file to add a new style for this aggregation which would include the first few paragraphs of the body (or perhaps add another field to the Content type called Excerpt or Summary and display that instead)
- Add an Image column to the Announcement Content type to include a Picture field and display it in the summary
- Add a Category choice field (Employee News, Current Events, Headlines, etc.) and add multiple CQWPs to the home page filtering each one on a different category
I know some may find this topic old and dusty but I didn’t see a lot out there specifically on filtering the Yes/No fields and the whole 1/0 trick was a little wonky, so I figured a few pictures would help walk through overcoming yet another SharePoint weirdness.
With a little work and some creative juices you can easily us the power of aggregation and the CQWP to build a news site from content on your team sites.
-
SharePoint – The Most Important Feature
Watching twitter and doing a search for SharePoint and you see a lot (almost one every few minutes) of tweets about the top 10 new features in SharePoint. What answer do you get when you ask the question, “What’s the most important feature in SharePoint?”. Chances are the answer will vary. Some will say it’s the collaboration aspect, others might say it’s the new ribbon interface, multi-item editing, external content types, faceted search, large list support, document versioning, Silverlight, etc. The list goes on. However I think most people might be missing the most important feature that’s sitting right under their noses all this time.
The most important feature of SharePoint? It’s called User Empowerment.
Huh? What? Is that something I find in the Site Actions menu?
Nope. It’s something that’s always been there in SharePoint, you just need to get the word out and support it.
How many times have you had a team ask you for a team site (assuming you had SharePoint up and running). Or to create them a contact list. Or how long have you employed that guy in the corner who’s been copying and pasting content from Corporate Communications into the web from a Word document.
Let’s stop the insanity. It doesn’t have to be this way.
SharePoint’s strongest feature isn’t anything you can find in the Site Settings screen or Central Admin. It’s all about empowering your users and letting them take control of their content. After all, SharePoint really is a bunch of tools to allow users to collaborate on content isn’t it? So why are you stepping in as IT and helping the user every moment along the way. It’s like having to ask users to fill out a help desk ticket or call up the Windows team to create a folder on their desktop or rearrange their Start menu. This isn’t something IT should be spending their time doing nor is it something the users should be burdened with having to wait until their friendly neighborhood tech-guy (or gal) shows up to help them sort the icons on their desktop.
SharePoint IS all about empowerment. Site owners can create whatever lists and libraries they need for their team, and if the template isn’t there they can always turn to my friend and yours, the Custom List. From that can spew forth approval tracking systems, new hire checklists, and server inventory. You’re only limited by your imagination and needs. Users should be able to create new sites as they need. Want a blog to let everyone know what your team is up to? Go create one, here’s how. What’s a blog you ask? Here’s what it is and why you would use one.
SharePoint is the shift in the balance of power and you need, and an IT group, let go of certain responsibilities and let your users run with the tools. A power user who knows how to create sites and what features are available to them can help a team go from the forming stage to the storming stage overnight. Again, this all hinges on you as an IT organization and what you can and empower your users with as far as features go. Running with tools is great if you know how to use them, running with scissors not recommended unless you enjoy trips to the hospital.
With Great Power comes Great Responsibility so don’t go out on Monday and send out a memo to the organization saying “This Bil guy says you peeps can do anything so here it is, knock yourself out” (for one, they’ll have *no* idea who this Bil guy is). This advice comes with the task of getting your users ready for empowerment. Whether it’s through some kind of internal training sessions, in-house documentation; videos; blog posts; on how to accomplish things in SharePoint, or full blown one-on-one sit downs with teams or individuals to help them through their problems. The work is up to you. Helping them along also should be part of your governance (you do have one don’t you?). Just because you have InfoPath client deployed with your Office suite, doesn’t mean users should just start publishing forms all over your SharePoint farm. There should be some governance behind that in what you’ll support and what is possible.
The other caveat to all this is that SharePoint is not everything for everyone. It can’t cook you breakfast and impregnate your cat or solve world hunger. It also isn’t suited for every IT solution out there. It’s a horrible source control system (even though some people try to use it as such) and really can’t do financials worth a darn. Again, governance is key here and part of that governance and your responsibility in setting up and unleashing SharePoint into your organization is to provide users guidance on what should be in SharePoint and (more importantly) what should not be in SharePoint. There are boundaries you have to set where you don’t want your end users going as they might be treading into trouble. Again, this is up to you to set these constraints and help users understand why these pylons are there. If someone understands why they can’t do something they might have a better understanding and respect for those that put them there in the first place. Of course you’ll always have the power-users who want to go skiing down dead mans curve so this doesn’t work for everyone, but you can catch the majority of the newbs who don’t wander aimlessly off the beaten path.
At the end of the day when all things are going swimmingly your end users should be empowered to solve the needs they have on a day to day basis and not having to keep bugging the IT department to help them create a view to show only approved documents. I wouldn’t go as far as business users building out full blown solutions and handing the keys to SharePoint Designer or (worse) Visual Studio to power-users might not be a path you want to go down but you also don’t have to lock up the SharePoint system in a tight box where users can’t use what’s there.
So stop focusing on the shiny things in SharePoint and maybe consider making a shift to what’s really important. Making your day job easier and letting users get the most our of your technology investment.
-
What is SharePoint Out of the Box?
It’s always fun in the blog-o-sphere and SharePoint bloggers always keep the pot boiling. Bjorn Furuknap recently posted a blog entry titled Why Out-of-the-Box Makes No Sense in SharePoint, quickly followed up by a rebuttal by Marc Anderson on his blog. Okay, now that we have all the players and the stage what’s the big deal?
Bjorn started his post saying that you don’t use “out-of-the-box” (OOTB) SharePoint because it makes no sense. I have to disagree with his premise because what he calls OOTB is basically installing SharePoint and admiring it, but not using it. In his post he lays claim that modifying say the OOTB contacts list by removing (or I suppose adding) a column, now puts you in a situation where you’re no longer using the OOTB functionality. Really?
Side note. Dear Internet, please stop comparing building software to building houses. Or comparing software architecture to building architecture. Or comparing web sites to making dinner. Are you trying to dumb down something so the general masses understand it? Comparing a technical skill to a construction operation isn’t the way to do this. Last time I checked, most people don’t know how to build houses and last time I checked people reading technical SharePoint blogs are generally technical people that understand the terms you use. Putting metaphors around software development to make it easy to understand is detrimental to the goal. </rant>
Okay, where were we? Right, adding columns to lists means you are no longer using the OOTB functionality. Yeah, I still don’t get it.
Another statement Bjorn makes is that using the OOTB functionality kills the flexibility SharePoint has in creating exactly what you want. IMHO this really flies in the absolute face of *where* SharePoint *really* shines.
For the past year or so I’ve been leaning more and more towards OOTB solutions over custom development for the simple reason that its expensive to maintain systems and code and assets. SharePoint has enabled me to do this simply by providing the tools where I can give users what they need without cracking open up Visual Studio. This might be the fact that my day job is with a regulated company and there’s more scrutiny with spending money on anything new, but frankly that should be the position of any responsible developer, architect, manager, or PM. Do you really want to throw money away because some developer tells you that you need a custom web part when perhaps with some creative thinking or expectation setting with customers you can meet the need with what you already have.
The way I read Bjorn’s terminology of “out-of-the-box” is install the software and tell people to go to a website and admire the OOTB system, but don’t change it! For those that know things like WordPress, DotNetNuke, SubText, Drupal or any of those content management/blogging systems, its akin to installing the software and setting up the “Hello World” blog post or page, then staring at it like it’s useful. “Yes, we are using WordPress!”. Then not adding a new post, creating a new category, or adding an About page. Perhaps I’m wrong in my interpretation.
This leads us to what is OOTB SharePoint? To many people I’ve talked to the last few hours on twitter, email, etc. it is *not* just installing software but actually using it as it was fit for purpose. What’s the purpose of SharePoint then? It has many purposes, but using the OOTB templates Microsoft has given you the ability to collaborate on projects, author/share/publish documents, create pages, track items/contacts/tasks/etc. in a multi-user web based interface, and so on.
Microsoft has pretty clear definitions of these different levels of SharePoint we’re talking about and I think it’s important for everyone to know what they are and what they mean.
Personalization and Administration
To me, this is the OOTB experience. You install the product and then are able to do things like create new lists, sites, edit and personalize pages, create new views, etc. Basically use the platform services available to you with Windows SharePoint Services (or SharePoint Foundation in 2010) to your full advantage. No code, no special tools needed, and very little user training required. Could you take someone who has never done anything in a website or piece of software and unleash them onto a site? Probably not. However I would argue that anyone who’s configured the Outlook reading layout or applied styles to a Word document probably won’t have too much difficulty in using SharePoint OUT OF THE BOX.
Customization
Here’s where things might get a bit murky but to me this is where you start looking at HTML/ASPX page code through SharePoint Designer, using jQuery scripts and plugging them into Web Part Pages via a Content Editor Web Part, and generally enhancing the site. The JavaScript debate might kick in here claiming it’s no different than C#, and frankly you can totally screw a site up with jQuery on a CEWP just as easily as you can with a C# delegate control deployed to the server file system. However (again, my blog, my opinion) the customization label comes in when I need to access the server (for example creating a custom theme) or have some kind of net-new element I add to the system that wasn’t there OOTB. It’s not content (like a new list or site), it’s code and does something functional.
Development
Here’s were the propeller hats come on and we’re talking algorithms and unit tests and compilers oh my. Software is deployed to the server, people are writing solutions after some kind of training (perhaps), there might be some specialized tools they use to craft and deploy the solutions, there’s the possibility of exceptions being thrown, etc. There are a lot of definitions here and just like customization it might get murky (do you let non-developers build solutions using development, i.e. jQuery/C#?).
In my experience, it’s much more cost effective keeping solutions under the first two umbrellas than leaping into the third one. Arguably you could say that you can’t build useful solutions without *some* kind of code (even just some simple jQuery). I think you can get a *lot* of value just from using the OOTB experience and I don’t think you’re constraining your users that much.
I’m not saying Marc or Bjorn are wrong. Like Obi-Wan stated, they’re both correct “from a certain point of view”. To me, SharePoint Out of the Box makes total sense and should not be dismissed. I just don’t agree with the premise that Bjorn is basing his statements on but that’s just my opinion and his is different and never the twain shall meet.
