Holy Smokes! That's a long time between blog posts!
Things have gotten a might busy between taking masters classes, teaching a Software Engineering class, and this @#$%! move to MOSS 2007 at work. While I have not forgotten the module at hand, I haven't had a free hand to touch it in over a week, bleh!
Anyhow, any Sharepoint Gurus out there know how to ease my pain? Y'know, let a guy get back to his beloved NWN2 module by answering the questions that keep him up at night?
Requirements:
Public Facing MOSS2007 Internet Site for Content Management (with Publishing/WorkFlow) w/o Deployment (no Staging Server). Just want to make sure we begin on the right path before we delve too deeply into content deployment. We will eventually work with the Document Management as well for online forms and such.
Questions:
1.) a.) Which Site Definition should we use to begin with? Collaboration Portal, Team Site, etc.
b.) Should we create a custom Site Definition and if so, which do we base it upon?
c.) Since there will be sites below the top level site (homepage), should their Site Definitions differ from the top?
(IE Collaboration Portal for top level, Team Sites below that).
2.) Since there will be significant CSS changes, as well as multiple MasterPages per site level, should we override the CORE.CSS and what is the preferred method for doing so (Inline, Override Textbox in Site Settings, Custom Function, etc).
3.) Editing Custom MasterPages, there is a place for PlaceHolderMain, yet no breakdown of the Web Part Zones contained within this area. What defines the Web Part Zones and their placement on a given MasterPage?
4.) Calendar and Announcement WebParts only seem to be options in a Team Site. Is there a way to enable these for use in other definitions? Is that done on the MasterPage, the ONET.XML, etc. Basically, how do we select from the Smorgasbord if they are prepackaged into Value Meals?
5.) Assuming that we will eventually be writing custom Web Parts, should we contain the entire Sharepoint Solution on VS2008 as a deployable package, or keep the Web Parts separate within Visual Studio and rely on Sharepoint Designer for the inner workings of Sharepoint.
Episode 83: Alpha Testing (Stage One)
1 week ago
4 comments:
First of all, please forgive my rudeness.
I have the impression that you have been handed over a task you are not qualified for. The questions you're asking unveil a severe lack of project management and SharePoint skills.
For example, answers to questions (1) are directly related to the project's requirements which you should know, shouldn't you?
Yes, you want to override core.css, read about it at MSDN.
Master pages do not contain web part zones, you define them in pages which are loaded into PlaceHolderMain.
The calendar web part is available in team sites because a calendar is provisioned by default. Create a new calendar and you will find your calendar web part for this instance. See what I mean by lack of knowledge?
There is plenty of information on MSDN available to get you started. You know MSDN?
You complain about SharePoint but you obviously have no idea what it is all about. Do yourself a favor and take a course on SharePoint basics.
Wow Steve, you should write a book. You know, one where you generally belittle the reader in your 'Nick Burn-esque' way of educating. I suppose your disclaimer is the equivalent of one saying "I'm about to be an a-hole", so no harm done.
Let me give you a disclaimer, regardless of what I'm about to type, thanks for the info (seriously).
Perhaps your feathers are ruffled because you feel that I am looking/talking/typing down to MOSS. That is not the case, as it was primarily my decision to go with such. I'm fully aware that a MOSS 2007 rollout is supposed to involve the entire department/organization and take months of preplanning. I can't really afford that luxury at my current organization/position. My frustration is not stemmed from Sharepoint itself (I'm a Microsoft sellout myself), it is from the lack of buy-in and the 'make it so' attitude of those pulling the strings.
As to the 'task you are not qualified for', I personally find tasks that I am qualified for a bit dull, and enjoy a challenge. Forgive my sense of adventure. If it wasn't for a dose of BS, I would never have gotten to where I am today. Set the bar higher than you can currently reach, and reach harder. As to the lack of Project Management skills, let's just say I am still in the project planning phase, but unfortunately the key elements such as deadlines/milestones/deliverables are out of my hands. Would you not agree that these are valid concerns to get hammered out before breaking ground and slapping content in all willy-nilly? When time is a factor, and an unmovable one, wouldn't it be best to establish a plan before charging in guns blazing?
Taking a class in Sharepoint, ahh yes in a perfect world with budget dollars and ample time, that would be the ideal. Time and money can do anything; remove those two factors and now you get to see just how good you really are. Thus I will likely do what I have always done. Reverse Engineer, Read eBooks, Look online for examples, check community resources (complete with snarky comments ala comic book guy in the Simpsons), and generally do what I am not qualified to do. About the time I become qualified to do something, I start to look one more level up. That, my friend, is how a guy whose good at Photoshop ends up teaching Software Engineering. Had I never looked up, I guess I'd be retouching pictures.
MSDN...is that some sort of muscular disorder? I kid.
Actually looked at it quite a bit and there seems to be plenty of conflicting information and various approaches to things. Such as overriding the CORE.CSS, Creating Custom Site Definitions, etc. I was more concerned about 'Best Practice' then 'How To', as in what is the recommended method when there are several avenues to pursue. I have rarely found MSDN to be the all encompassing codex of knowledge in the years that I have used it. Many Microsoft MVPs, I'm sure, feel the same.
As there are many varied opinions and methods to approaching a Sharepoint roll-out contingent on which of the pillars you wish to expose and how, I like to put as much thought into it ahead of time. Anyhow, I am actually pretty appreciative that you took some time to type a response. Although not exactly what I'd call bringing your A-Game to the ole communication table. Then again, I am quite comfortable with German efficiency and bluntness (fortunate enough to work with a few myself), so let me conclude by thanking you for your frankness.
Raith, please accept my apologies. Now that dust has settled I would not use the same wording again.
What dust? Well, today, only a couple of ours before I came across this post, I had a conversation with a "consultant" who was extremely unhappy about the companies move to deploy SharePoint in favor of some OSS solution. He just could not stop complaining about things he obviously never had heard about. Later, he admitted that he never took a course or read about SharePoint at all before. And now, he was in place to oversight the deployment but completely reluctant to gain knowledge about this beast. (Yes, it's a beast. If you know how to feed it, you'll probably become friends some day) The problem is that he will report to his management about problems, schedules and strategies. Thus, due to his biased perception of things he might risk a successful roll-out. It's not the first time that I have observed projects failing due to lack of knowledge and perspective.
The point is that installing WSS/MOSS and trying to figure out how things work might be OK with Mac OS X (which I use at home, btw, and it really worked because it's so easy) but it is definitely not the right approach for learning how SharePoint works. You just have to read, code, read and code, again and again and again to get familiar with it. It is by far flawless, and, not making things any easier, heavily over-engineered in some areas. You see, I have an ambivalent attitude towards this thingy myself, yet I mastered it (as many other bright people did before) and ignorance certainly did not help. (Still talking about the "consultant", not you, Raith)
To your points. OK, ok, you're qualified! Really, no doubt about it. Yet, experience has taught me that planning is half the bet. [did I put it right? English can be quite cumbersome sometimes.] Make a business case and talk to stakeholders about their requirements. Do it more than once since users and managers tend to think about the important matters after you talked to them initially. Plan for a staging environment! Please, do that for your own good. You know how often I have completely messed up my SharePoint environment in the past? Sometimes took me a while until I figured out what was wrong. Luckily no one took notice since I did not work in the productive farm (which is a huge no-no anyway as you already know).
SharePoint development can be quite a pain sometimes and, as I read from your comment you are ready for adventure, be prepared to experiment with some new techniques. Many aspects are not well documented yet, though our key account manager at MS keeps promising the situation will improve. Just try some of the undocumented methods, classes and properties. Just last week I did exactly that and accidentally discovered a solution for a problem I faced months ago.
To summarize: SharePoint is a huge framework and not an application. (Just mentioning that because many people think that you can it install, run at it will manage itself.) You will soon have to develop custom solutions to cover user requirements since the OOB capabilities aren't enough even for small deployments. Knowing the object model is the key to successful SharePoint development. Get yourself one or two books: Inside Windows SharePoint Services 3.0, Pattison et al and Inside SharePoint 2007, Tissegem (both Microsoft Press) are pretty good ones and not very expensive.
Again, sorry for the harsh comment in the first place but I came across your post just at the wrong time. Thank you for your kind words. Feel free to get in touch with me on any subject regarding SharePoint if you still like to.
No Harm, No Foul; I appreciate that. You give some great advice that I will definiately heed. I was also a bit of an ass in my response back to you, so please accept my apologies as well.
I definately respect MOSS for the entire shift in information that it represents, not an install and go application. That is why I am being so careful. Facing quite a bit of anti-Microsoft bias here as well from the designers (it's in their genes), so it has been a hard sell.
One of the biggest challenges is the change in terminology as well as the mindset one must get in to truly understand how Sharepoint handles things. I think much of the naysaying about it is bred from ignorance, and those who would rather have a WordPress linked to a MySQL database, which just doesn't cut it in the real world as far as I am concerned.
I actually have those books, as well as a few others, but I will pay particular attention to those if you recommend their practices. I normally go for Wrox or O'Reilly, but I think Microsoft Press may just have a better handle on it this time around.
Thanks again for the advice, it will not be ignored.
Post a Comment