Since we're in deployment phase of SPS 2003 to the whole company, one thing of course we need to do is brand it for ourselves. I mean, who wants an out-of-the-box portal?
Matt McDermott, a consultant we brought in to do a lot of the heavy lifting (who just started blogging at Mindsharp) was an immense help. He has a great checklist and brought some great tips [below].
I also have to say that Daniel McPherson's article on branding was a fantastic resource.
Idea #1: use transparent .gif as logo
One of Matt's ideas I *really* liked was using a transparent .gif as the logo, but then having the logo embedded in the background. So imagine this header:
If you notice the upper left hand corner, you see our logo. Well, that logo is actually part of the background image, not the logo image. The actual logo that's a place holder right there is a transparent gif that just happens to be the exact height.
So assume your banner is 2000x65 pixels. You want 2000 pixels wide so that if they have a big screen it won't disappear. Then you make a transparent gif that's , oh, as wide as your logo and 65 pixels high.
That way when the users mouse over the logo, it's clickable and brings you home. But then you don't have to worry about making one logo overlap the other, or synchronizing the background image with your logo image. If you don't have a semi-professional graphics artist working for you, this can really help save time getting a good look and feel on the brand.
btw, you'd put your background image in a custom directory... I'd recommend
[drive]:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\LAYOUTS\1033\Styles
and create your own directory, then put your images and css files in there. You can create your own .css file, put it in there, and then point the portal to your css file. You specify the background image to use in the css file, and you can specify this transparent gif by going to Site Settings > Change Portal Site Properties. Point the custom CSS to your file by using /_layouts/1033/styles/mega/mega.sps.css ( you would use your own directory and names of course). And you can also point to your own transparent gif here as well by putting that in like /_layouts/1033/styles/mega/images/sitelogo_trans.gif (again, assuming your own directory and names, and notice I created an “images“ directory under “mega“ under “styles“.)
The code used in the custom css file looks something like this:
.ms-bannerframe, .ms-GRHeaderBackground, .ms-storMeFree
{
background-color: #FFFFFF;
background-image: url('./images/sitelogobg.jpg');
background-repeat: no-repeat;
}
Idea #2: Changing the Watermark on the left hand side
You may also notice the change of the watermark on the left-hand side (see the graphic above). This can be done by editing
[drive]:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033\SPS\default.aspx
(note the location may not be C: but it probably is. Also, do I really need to remind you to always save a copy of files like this so if you shnork your file and bring down your portal, you can easily bring it back? And.... the “1033“ assumes English, so if you're localized to something else, use your specific language directory)
In that file, look for the text that says “Sharepoint Portal Server” in the watermark section. Change it to what you want. Note that I haven't figured out all this stuff and how to more accurately define ways of making the watermark better, but I can see how to change the font and stuff.
Idea #3: Enhanced Search Web Part
Another great thing Matt supplied was an enhanced search web part for the WSS portion of things. He based it on Anthony Petro's article entitled Creating a Site Context Search Box that Uses SharePoint Portal Server Search Results on the MSDN site.
You know how SPS and WSS are really separate beings when it comes to searching? SPS uses MSSearch and WSS uses the SQL Full Text Indexing engine. That's just plain annoying! I'd rather give my users a consistent look and feel whether they search from the portal or from their team sites.
Matt's enhanced search web part replaces (or enhances) the built-in WSS search part.
Twist #1 - launch portal search instead of wss search
Here's the first thing it does.
Imagine I have a site collection called “STS“ and it has some sub sites and they have some workspaces, sites or whatever. When on a site collection or top level site, This enhanced search part gives the following choices:
(you can kind of tell that it's a top level site because it has a portal connection saying “Up to Megapath Intranet“, which is our portal)
But here's the twist -- when you initiate a search, it actually launches a Portal search, not a WSS search, and just returns results from this site collection and everything underneath it. Isn't that the coolest? Before this web part, your loser WSS search would just search that site, and not sites below it (I think this is correct... would hate to call it loser-ific if I was wrong).
So you can still do All Sources search, or you can search this site collection and all of it's subsites. [or google (see below)].
Twist #2 - search your site collection, not just this + subs
Well, there's another really cool twist. If you're on a subweb, it gives the following choices instead:
(notice that the portal-level connection now says “Up to STS” which was the top level site we were on before)
So now it has an “All Sources” and “This Site” which is the same as before, meaning it can search this site and all subwebs, but now it has a “Site collection” which means it will now search STS (the top level site that contains this site) and all subwebs.
So imagine if the top level site collection was “Human Resources”, then any subweb or team site underneath it would automatically give the user the ability to search all of HR instead of just the site they're on, and they don't have to try to navigate to the portal to do so.
I've been bugging him to modify the web part to actually put the top level connection name in the drop-down... maybe if I wait long enough I'll end up doing it myself :) That way, if you're in http://portal/sites/HR/policies/expenses/ sites, and you want to search HR, the drop down would actually give you “All Sources,“, “HR“ and “This site“ as options.
Twist #3 - Integrate with google
I know he's worked on a google dropdown too... we'll see if he blogs about that someday. I think it's basically that the last dropdown selection lets you specify google. I've tested it and it seems to work but I'll let him do the blogging on that one.
it looks like this when deployed:
Hope this helps!
Our WSS server, which was a beta staging ground for at least a year before the deployment of Sharepoint Portal Server 2003, has pretty much had no problems. It's about 4GB in size and tons of users use it either for testing or even production use. About the only problem we've ever had was when a user clicked “Delete this document library” and actually thought it meant something else.
Recently, I created a list to track cell phones and blackberries. It tracks the phone number, assigned user, PIN, model type, status of the device, and the monthly phone and data plans on the devices (we're trying to go to corporate pool of minutes to save $$).
One of the data types was “Phone Plan Monthly” and it was just a single line of text. Then I had changed it to a Choice type and had choices like $49.99, $59.99, $79.99, etc. Then I realized later that really I wanted it to be of type currency because I would want to add up, average, and calculate things on this field.
When I went in to change this type to “Currency” I received the typical pop-up that said “Changing the type of this column may result in a loss of data. Are you sure you want to change this field from Choice to Currency?”
I said “ok” or “yes” and received the title error:
Now... you know what I'm thinking. “Oh crap, my server's out of disk space” or “What's wrong with SQL server?” or “now I have to go test out that restore procedure I've been working on”. Well, I checked disk space and SQL and everything seemed ok. Sure, maybe I was a little low, but I still had plenty of room.
So I checked around the site and everything else was working fine. I could even change the same field type from Choice to Single Line of text without a problem. So I started searching on the error.
Most of the results had to do with STS, not WSS. Plus, they seemed to imply that SQL was in read-only mode or something was preventing a write to the database. However, when I went around the site, I could add content in tons of places, so that wasn't it.
btw, the url that was passed to the server was
/server/site/_vti_bin/owssvr.dll?CS=109&Cmd=UpdateField&List=[somelongstring]
So then I got to thinking -- maybe it's because the field has some data in it. I checked, and yes, this field had been used by some line items and contained entries like “$79.99”. Hmm, maybe the dollar sign is throwing it off or something?
I cleared out the entries in that field and tried again.
SUCCESS!
So evidently, when you change a data type from one type to another, and [I'm assuming here] SQL Server has a hard time converting the data, sometimes it throws an error instead of doing what it *should* do, which is throw out the data but give you a little log of what was thrown out.
So now I can continue on with tracking cell and blackberry costs without any nasty SQL server error messages.
Ever just live with something and think that's just the way it is, and you just have to deal with it? Well, that's me in a nutshell when it came to Sharepoint's Explorer View.
Every single time, from every box in our network, using Explorer View was just a dog to use. Regular views were just fine, but accessing a document library through the Explorer View on the side or using UNC filepaths to access documents (\\server\sitecollection\site\DocumentLibrary for example) was just too slow to be usable, and I just thought... that's the way things are.
Then we had a consultant come in and help speed us up on our deployment. He immediately commented... “Wayne, that's just too darn slow”. We had him access explorer view from his laptop and voila! it was super speedy.
So I unloaded OfficeScan on my machine and re-accessed it, and voila! it was also super speedy.
In the meantime, we've opened up a ticket with Trend to ask how to either
- configure it to “ignore“ our SPS server
- get an update that's more sharepoint friendly
- configure tweaks to speed performance in a sharepoint environment.