MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

Site customization guidelines

  Asked By: Deandre    Date: Aug 11    Category: MOSS    Views: 740

My experiences focus primarily on the administration
side, so please forgive me if I phrase this
incorrectly. I'm looking for some best practices for
site customization and design using Sharepoint
Designer 2007. I'm familiar with the concept of
master pages and I know about Heather's base pages and
that's a great start. Any other tips that I can
provide to our zealous developers? Generally, the
feel at our company is that if they they dont
understand something, they just rip it out of the
page. Now we're feeling the pain of that mindset with
our MOSS upgrade. Any best guidelines I can provide
so that we can avoid this situation in the future?



5 Answers Found

Answer #1    Answered By: Lester Casey     Answered On: Aug 11

First, Make sure that developers understand the difference between SharePoint
Designer and Visual Studio. Unless you are building a site  Collection which
employs the Publishing Feature SharePoint Designer changes are limited to an
individual site. With some planning you can make much more maintainable and
global changes using Visual Studio and XML (CAML). Using VS I can deploy a
custom master page that can be changed at will which will affect every site
built from a specific site definition no matter what Site Collection it is in.
I can do the same with Styles and JavaScripts. SharePoint Designer was
originally envisioned by Microsoft as more of a Power User's tool rather than
an IT Developer's tool.

Answer #2    Answered By: Rudy Francis     Answered On: Aug 11

I understand the conceptual aspect of
SPD vs. VS, but do you know of anything that indicates
the design  limits of the two tools? Not being a
developer, I don't have a clear idea of SPD's

Answer #3    Answered By: James Miller     Answered On: Aug 11

The Publishing Feature clouds this up a bit because it implements inheritance of
page layouts and Master pages from a top level site  through a hierarchy. But if
we put that aside. Making changes with SPD is limited to changing a single Site
in a Site collection. It’s the publishing feature that allows me to roll some
of those changes throughout a Site Collection. Since Visual Studio can be used
to make changes to the Site Definitions themselves I can position certain things
like MasterPages that can be ghosted when a Site or Site Collection is
provisioned. A change to the original file will then affect every Site created
using that Site Definition. (Please Note: Changing a site definition is like
changing a blueprint. It won’t change the site after the fact. But if I
build a modular design  into the blueprint it can be changed). SPD changes
ALWAYS results in a file that is customized (unghosted) from the original 12
hive. That prohibits any future changes to the ghosted original.

VS can also be used to write programs that make broad sweeping changes to a
site, a site collection or a whole farm. SPD is easier and faster, but much
more limited in scope. VS is harder and slower, but can make changes that
affect the entire enterprise.

Answer #4    Answered By: Collin Griffith     Answered On: Aug 11

That's a great definition. I'll be sure to use that
comparison. That being said, any general pointers on
successful site  design? The only thing I'm aware of
would be to ensure that all page controls are
preserved even if they're not being used. Anything
else I should be aware of?

Answer #5    Answered By: Scott Nelson     Answered On: Aug 11

The only other real suggestion would be to plan before acting. The ability to
make global changes later is dependent on building in Features and capabilities

Didn't find what you were looking for? Find more on Site customization guidelines Or get search suggestion and latest updates.