6/28/2009
As SharePoint 2010 looms in to view, it's not a bad idea to look back at the incredible distance we have come in the SharePoint world. I'm not talking about the platform, I'm talking about us.
For example, back in 2003 almost no one had a staging server -- development was frequently done directly in production in a site collection named /sites/test or something similar. Today, three-stage development is standard practice: development > staging > production. Some shops add a fourth or fifth level to the deployment process.
Virtuallzation is another area that we've kind of figured out. Only a year ago, doing a production MOSS deployment on a virtual platform was bleeding edge. Now, some of us consider it a best practice.
Finally, the tools and add-ons are much better now. I know that seems like a platform issue, but from my perspective it is more of an evolution of developers: we are more experienced, better at our jobs, and there are more of us now.
All that said, I think we are still evolving in the areas of workflow, user education, and applying social networking for business goals. It's nice to have room to grow! 6/9/2009I have extended the ESP Content Editor web part to include JavaScript variables for key information formerly only availble within server-side code. The .zip and more information is available here:
To see the web part at work, go here:
I'd like to hear what other variables designers need on the client side. If you have ideas, please post them here:
Thanks! 4/12/2009
This came up the other day: what is the worst idea you've seen done in SharePoint? We developed a list of five, which were too specific to describe here. However, I think they represent five general traps that enterprises can fall into when deploying SharePoint.
In order, our top pitfalls were:
1) Not enough site collections.
Increasingly, I look at site collections as a security mechanism. They keep permissions completely separate and allow you to delegate administration. Every huge site collection I've seen in production has been a nest of confusing SharePoint groups that is difficult to untangle. This is a more serious problem because it hits late in the game, once everyone is relying on SharePoint.
2) Ignore training.
SharePoint is easy, but not intuitive. All users need some training. I generally figure one half-day class to teach how to use their specific collaboration site; and one half-day class for site owners (again, using their sites). General training is less effective, since users really want examples that apply to their work, and that's hard to do in the abstract.
3) Go custom early.
SharePoint can deliver 90% of immediate needs using out-of-the-box features. Not maxing that out before attacking the very real remaining 10% delays immediate results and can result in a team that doesn't fully understand the core features very well. That's a huge on-going cost.
4) Ignore change control.
Maintaining a log of configuration changes, versioning templates, themes, master pages, and all custom components is old-hat to most software developers, but it's new ground for some SharePoint teams. If you aren't familar with these concepts, you will learn why they are important down the road, trust me...
5) Stay too long in planning.
The best solutions are adaptive, not predictive. It's impossible to know exactly how SharePoint should be implemented in an enterprise before actually doing it. Planning is important, but if it goes on for more than 30 days, cut scope and deliver something, then learn from that experience.
Bonus! Here are a three that just missed the top-five:
6) Bad branding.
It is better to do minimal branding than branding that hides or breaks features. Branding can be difficult in SharePoint, but it possible to deliver it incrementally by versioning the pieces.
7) Prohibit My Sites.
My Sites are a great training tool, leverage employee intellegence, and can easily fit in to existing email/Internet use policies. Gee Jeff, how do you really feel?
8) Move your farm.
Part of the planning process should be choosing the hardware to install on. Don't accept "We can move it later." That's a real pain in production and 100% avoidable. 2/15/2009
More notes from the field: this came up the other day -- how does one decide whether a request for a new site should be created as a sub site or as a new site collection?
First, it helps to remember that site collections and sub sites are primary levels of scope in SharePoint. A site collection is a hard boundary that has it's own set of galleries, quotas, storage, navigation, and security groups. Sub sites share all of those things within their containing site collection.
In addition, site collections are stored in a structure that is flat -- usually they are all found under the /sites or /personal managed paths. Sub sites are usually organized heirarchically within a site collection, for example: /sites/hr/benefits.
Once you understand those things, you can infer a decision matrix to help you determine whether or not a request should spawn a new site collection or a sub site within an existing site collection.
Here's a list of possible questions for such a decision matrix. Yes answers imply you should create a new site collection, No answers imply you should use an existing site collection:
Does this site request...
...potentially contain more than 5 GB of data (5 GB is my default site quota size)?
...potentially require more than 20 SharePoint security groups (or contain > 200 unique users or AD groups).
...have an owner who is capable of becoming a site administrator but does not already own other sites?
...exist as part of a business structure that might get re-organized in the forseeable future?
...require custom workflows, web parts, content types, list or site definitions, or other deployed features that are not part of your standard site package? (exclude SharePoint Designer workflows since they are no-code)
...represent a function that crosses organization boundaries?
...not logically fit into an existing site collection?
Scoring: Tally your yes/no/maybe's from above. If there are more yes's than no's the request probably belongs in a site collection, if not, then it probably should be a sub site in an existing site collection.
Feel free to add questions or submit them to me so I an append them here -- I just submit this as a starting point.
Thanks,
Jeff 1/24/2009A client was interested in the Business Data Catalog, so I finally had a chance to explore it in depth, and I came away impressed. Once it's set up correctly, it is amazingly easy to integrate data from your SQL databases in to SharePoint lists, libraries, and search without duplication.
I've spent a lot of time and effort doing similar things for clients who are not running the Enterprise edition, and so can't use the BDC or Forms Services, and I now know the BDC is definitely the way to go.
A couple observations:
For phase 1 of a BDC implementation, focus on using Views from the database rather than trying to set up complex associations in the application definition (XML). That's much easier and you get 90% of the value quickly (in days, literally).
Configure search with a scope for Business Data as part of phase 1. Make this feature very visible to users (shout from the mountain top -- this is cool).
Buy a copy of Meta Man for phase 2. It solves the association problem.
Implement your custom actions in SharePoint using the Shared Services pages, then export the definition if you need to add entities with Meta Man or some other tool. You can export/import as much as you like as long as you increment the version of the application definition.
Add actions to run the business apps that are the source of the BDC data. This is easy and it adds a lot of value.
1/13/2009In the web world, we try to promote using subdomains for discrete audiences: www.company.com for the public, mycompany.company.com for employees, partners.company.com for customers and vendors, you get the idea.
You can see the idea applied a craigslist.com -- they use subdomains for each region they serve. The cool twist they add is that their subdomains are sticky. If you go to spacecoast.craigslist.com on Monday, you'll return there on Tuesday if you simply type craigslist.com in the address bar.
I think that's a pretty good idea, and probably worth implementing... Let me get back to you on that. 12/23/2008So it's nearly year end and a time to reflect on 2008 and project / speculate on 2009. First:
2008 has been a busy year in the SharePoint sphere. There were a lot of new third-party tools, as well as big improvements to existing tools. Microsoft has been busy readying Office 14 (skipping lucky 13, showing that even software developers are superstitious).
My favorites from 2008:
WssOnVista - allows you to install SharePoint on a Vista box for development/prototyping.
Upload Wizard - OK, I did this one, but it's a useful utility and a popular download. It's one of the few end-user tools for SharePoint.
VS 2008 Extensions - a quantum leap over the extensions for VS 2005. These really accelerate SharePoint development with Visual Studio 2008 Professional or better.
Sample Master Pages - another one from Microsoft, targeting SharePoint Designer. I think this is a growth area.
OK, on to the tough stuff. The look ahead:
Geez, who knows? I think it's going to be tough sleddig economically so my bet is on providing new value with existing resources.
All of my customers are planning zero growth for 2009, and some of them have excess IT infastructure: stuff like ESX servers waiting to be deployed.
That may be OK news for us SharePoint folks. Maybe we won't do as many new deployments, but migration to virtualized servers, training of existing users, and improving efficiency through workflows could keep us busy.
I also think there's a case for "creative destuction". Some businesses will fail in 2009, and thus make room for more agile startups which is good for enabling technologies like SharePoint...eventually.
But that is probably 2010, and I'm only going to wish you one Happy New Year at a time.
Good luck, good health, and have some fun. -- Jeff 12/14/2008I just got back doing a series of training courses across the South and met a lot of excellent people dealing with SharePoint as a new technology. Here are some notes:
- Folks like "fer-instances". Fer instance: you need to create a way for users to sign up for a class with limited seating. To do that in SharePoint...
- No one knows what they don't know. Course titles don't always map to the audience who signs up. We try to deal with that using prerequisites, but those are way down in the course materials that not everyone reads.
- "Development" != "programming"
Therefore, a "developing" course in SharePoint sometimes focuses on using the browser, sometimes on SharePoint Designer, and sometimes on Visual Studio. I think the key to the class's success is whether or not the students walked away with enough fer-instances that they can apply their next day on the job.
That level of flexibility makes the job of trainer challenging, so a complete knowledge of the SharePoint topography is important. I'm fly fishing in the Keys this week and that's what I look for in a guide: local knowledge and patience to help me "develop" my skill. 11/22/2008I just got back from a week training some good folks on using SharePoint Designer (SPD) to customize their sites. It was an interesting experience, and here are a few quick observations:
- Create in browser -> customize in SPD is the correct model.
- SPD requires .NET 2.0, but does not check for it. It will run without .NET 2.0, but it can't render web pages.
- Folks like SPD data views. Heck, I do too.
- It's hard to separate core SharePoint concepts from SPD training.
- The SPD Contributor Mode security settings are confusing to most people (why have a separate security model?)
- Branding should be easier.
- Jimmy G's in Houston has amazing seafood.
Perhaps Microsoft can work on their install program to check for .NET 2.0. That they missed that makes me feel a little better about my own installation routines! 11/7/2008
I'm pretty sure this does not reflect well on me, but I'll share it in case someone else can benefit from my own shortcomings:
I developed a workflow that tested fine in development, deployed to staging fine and worked there, then completed died in production.
The error: "Failed on start (retrying)" .
If you've written workflows in Visual Studio you know how frustrating that error is -- it never really retries, and the workflow doesn't usually get far enough to tell you what went wrong in the History log.
I flailed around on that one until COB yesterday. The problem: I accidentally included.NET 3.5 references in the project and .NET 3.5 was not deployed to production.
I removed the references (and associated using statements), rebuilt, and everything is fine!
Note that new projects in VS 2008 include references to Linq and new data objects by default. If you set the project compatability to .NET 3.0, VS will flag the things you need to pull out.
Of course this is not an issue if your dev, staging, and production environments are in sync! |
|