Inconvenient SharePoint Solution Generator

While working with the SharePoint Solution Generator (a utility which ships with Visual Studio 2005 extensions for Windows SharePoint Services 3.0) I have stumbled upon an interesting by-design feature which affects the way you develop Features - at least if you're using or planning to use the SharePoint Solution Generator (SPSolGen).

Configuring SSL in SharePoint 2007 development environment

A SharePoint 2007 development can get quite complex depending on the business case and requirements of your customer. Last year I have worked on a few SharePoint 2007 solutions. During the development I have noticed that it is extremely helpful if you know how the customer's infrastructure will look like. It will help you even more if you will configure your development environment to resemble the customer's infrastructure as much as possible.

Which Doctype to use with SharePoint 2007?

Designing and developing accessible web sites on top of SharePoint 2007 gets more and more attention in the community. But the more developers try to reach the required accessibility or standards compliancy level, the more challenges they face and the more questions pop up. One of such questions is which doctype should be used for standards compliant and accessible web sites.

SharePoint 2007 redirect solved: using 301 instead of 302 redirects

Each time you request a Site Collection (http://domain/) or a Site (http://domain/foo/) of your Publishing Site you get redirected to the http://domain/Pages/<WelcomePage>.aspx. SharePoint 2007 uses the 302 header (location temporarily moved) for this purpose. Surprisingly even WSS uses the 302 header to redirect a root url to the default.aspx. In comparison ASP.NET uses an internal redirect to render the default page when the root url requested: there is no redirect in this situation.

The impact of developing an accessible web site in SharePoint 2007

The development process of a typical Web Content Management solution based on Microsoft Office SharePoint Server 2007 consists of three main areas: User Experience, Functionality and Deployment. The development process begins mostly with designing the total User Experience. Based on the business requirements the designers determine the particular areas on the web site and the corresponding functionality. The typical products of this stage are the User Interface (UI) design and the Interaction design – the way the UI responds to the user input. The next stage is translating the User Interface into code: HTML, Cascade Style Sheets (CSS) and JavaScript (if any client-side interaction required). As the products of this cycle form the baseline for the solution to be delivered it is crucial to name all the requirements of the total product and in particular the accessibility aspects. During the last stage of the User Experience phase the translated User Interface is being incorporated into SharePoint 2007. At this moment the Master Pages and Page Layouts are being formed and the content areas and the Web Part Zones are being determined and placed within the Page Layouts. In many cases the User Interface incorporated in SharePoint 2007 is being hand over to the developers who are going to fill it with the dynamic controls they are going to build. Using the original User Experience translations the developers start their work. First of all basing on the original User Experience they design the look & feel and the behavior of the dynamic control and Web Parts. Then they take the pieces of the User Interface translation and incorporate them within the custom controls. As soon as the development stage is finished and the whole solution has been tested, it is being prepared to be deployed on various environments such as test or production. The decision of developing an accessible WCM solution based on SharePoint 2007 has a major impact on the development process. The affected areas have been marked orange (product independent) and green (requires product specific knowledge) on the figure below. First of all the designers have to take accessibility into consideration while designing the User Interface. Drop down menu’s dependant on JavaScript and mouse centered interface for example can lead to a totally inaccessible web site. Choices like these can have major impact on the overall accessibility of the web site and the presented information therefore they need to made very carefully and according to best practices for developing accessible web sites. The products made during the translation stage form the baseline for the whole web site. The accessibility of the information depends on the quality of the delivered code. That is why it is crucial to be sure that the right patterns and practices have been chosen to translate the drawing into code. The translation can also have impact on the total performance of the web site therefore it definitely shouldn’t be underestimated. During the incorporation of the translated User Interface into SharePoint the designers are very likely to face many of the undocumented features of SharePoint 2007. Originally SharePoint’s interface is table-based and my experience shows that even a little alteration can have impact on the SharePoint engine. If made carefully the decisions taken at this point can make the development stage easier and can guarantee very high level of accessibility. The developers are responsible for designing and developing custom controls which in many cases present dynamic content. Many of these developers are .NET developers with some SharePoint experience and very little to none accessibility knowledge. At this stage the web site has the biggest risk of getting inaccessible. Because of the little accessibility knowledge the most developers have, they are not able to estimate the impact of their choices on the accessibility aspects of a web site.