Posts

Showing posts from July, 2010

Training Users after deploying SharePoint 2007/2010

When deploying a SharePoint solution, the business often place most of their budget and allocated time to SharePoint Features, configuration and that strong look and feel and forget about end user training.


They understand that the assigned administrators require training to help manage and update the features available, and that type of training is usually included in the project planning – but they forget that the general, every day users may also require training, and they usually try to throw in a quick fix just before launch.

I planned to talk about the “SharePoint Learning Kit”, available from CodePlex, it’s a SharePoint e-learning site with tracking created by Microsoft that you install in your existing SharePoint farm, but there were a few things I didn’t like about this solution, mainly:

It’s not open source, meaning that I cannot edit this solution

Its uses a separate database, so I don’t see it as a true sharepoint sub-site anyways, and installation was difficult.

It…

Minimum requirements for a good on site working environment

In the past, when a software solution needs to be developed, my team build the solution in the office, tested it in the office and only when everything is built and ready, we would go to the clients offices to install and configure the final solution.



These days, it’s more common to deploy the entire team onsite (clients’ offices) right from the start of the project, and while on site they do all the development, testing and configuring directly on the clients servers.


This results in easy accessibility of the team, better focus, commitment and dedication from the team which ultimately means faster more accurate delivery of the solution.


But the team is moving away from an environment they are comfortable with to the clients’ environment which may not be designed for this purpose, and if a few basic requirements are not in place, delivery of the solution is compromised.


So if you are looking at getting an outsourced team to work in your office to deliver a solution, make sure these minim…

Auto Provisioning, the next step in SharePoint

The thing that makes SharePoint great is the way it was built (yes – that narrows it down!). It was built for the business users (not developers), to have sufficient control and power to create their own web space, that will assist them in achieving their business goal.



Before SharePoint, we had two extremes when providing a business user with an application or web space to achieve their business goals.


On one side we have business users requesting an application from the IT department, resources were eventually allocation and the SDLC begins, a solution is provided about a month or so later.  This application had its own database, little to no integration with other systems, its own security component, meaning another set of usernames and passwords the business users need to remember, and its own unique look and feel.


On the other side, the business user will create an application themselves via Excel or Microsoft Access.  The solution will be available quickly but the solution will be …

Please don’t pimp your SharePoint site

Image
Look at this picture, someone spent allot of money on a Benz, but decided that they wanted to make the car look like a sports car instead, so with a little extra time and money, they added design elements that made the car look different, the new look gets a great deal of attention and everyone wants to drive it, but later people notice that the car cannot drive faster than 30km/h or drive up an incline without breaking something, the lights didn’t work as well as they use to, you can only enter the car a certain way, sharp turns has not been tested but is not recommended and only people with special training or knowledge on how this new look was implemented will be able to wash, repair, drive or fuel up the car.

Sounds crazy doesn’t it, well, that’s what you are asking us to do when you ask for a SharePoint site that does not look like a SharePoint site.

Sticking with my Benz example, the Benz comes from the factory in silver, black, white and red, and a special colour can even be c…

Search - Now an essential feature for websites.

Image
When I use to create website’s, my focus use to be on what the client asked for, its usually the home page, the content, and a good user experience. Search functionality was never something a client puts a strong focus on, and thus, it was never something I put allot of time towards.

Why should I? whatever you want you can find from the home page or the navigation menu's, right? The search feature is something that people hardly use, and when we do use it, we not really expected to find what we want anyways.

That was my attitude up until last year. in all my project planning, I place about one day on adding a search feature to a website, that’s one day for everything search related from start to finish.

It would involve creating a simple textbox on a header, usually expecting one keyword, and a search button, it would have a search results page that run a simple query that will return a bland list of titles and links that will reference a page that was lucky enough to have the keywor…

ajax/silverlight and application.master page dont mix in MOSS 2007!!

If you want to give sharepoint 2007 a strong look and feel (in other words - make it look nothing like sharepoint). It involves digging under the hood and changing files SharePoint did not expect you to change, on of these files is the application.master page.

If you want to mess around with the application.master page, I say mess around, because Microsoft does not recommend this, (and I am sure this is one of the resons why), make sure the application.master page contains no ajax controls or silverlight controls.

Ajax use the preRender event to load whatever it needs to load in order for ajax to work, some SharePoint admin pages overwrite this preRender event, meaning that the ajax bit of code never run, and there is no way to stop this from happening.

We know that the following pages give errors if ajax exist in the application.master page.

_layouts/people.aspx
_layouts/groups.aspx
_layouts/spnewdashboard.aspx

I am assuming they did this because MOSS 2007 was out BEFORE ajax was big, so it…