Code, just the code ma’am – The role of SharePoint Designer

The systems development paradigm has changed and like the frog sitting in steadily warming water I am not sure developers have noticed the temperature is going up.

I wrote a SharePoint Designer course and I continue to be surprised with developer’s comments expecting to see more code for application development when dealing with SharePoint Designer. I think there may be a misunderstanding of what the role of SharePoint Designer is and what can be done with it. So first, let me explain the purpose of SharePoint Designer, where and what type code there is, and I’ll tie it back to the bigger picture of application development.

SharePoint Designer is a tool for customizing SharePoint web sites. As I see it, it has three major types of customizations.

  1. Branding – Changing the look and feel of the web site by modifying the Cascading Style Sheets (CSS),  HTML, java script etc.
  2. Linking and connecting to lists, libraries, xml data sources, and databases using a wizard (no code) approach to build a  “dashboard” style web page that links multiple data sources on a single page. Straight forward CRUD (Create, Read, Update, Delete) database functionality.
  3. Building custom, no code, very powerful workflows.

Branding requires an intimate knowledge of the SharePoint page construction, of Master Pages, Content Pages, how CSS and HTML is used and integration in the in the page. This technology is ASPX master page technology, but implemented in SharePoint. You will see code here, but only client side code and have the ability to add new master pages.

Linking to various data sources is all done via properties and wizards. There is no server side code at all. We have VS.NET type grids and controls available to us and we set properties to get the controls to do what we want them to do. It is surprising how much can be done with no code.

Building workflows is almost like building a Visio diagram that executes. As a matter of fact SharePoint Designer 2010 workflows will be built in Visio!

Now back to development big picture.

If you are a developer I can hear you chuckling, I’ve used those types of controls in Visual Studio previously and they don’t give me the type of control I want. Before I agree or disagree with you, I need to ask; what type of application are you trying to build? Check your water temperature.

I am going argue that many applications can build built now with no code, a smaller percentage require coded solutions.

SharePoint has 3 levels of application development.

  1. Web site
  2. SharePoint Designer
  3. VS.NET code development

The first two, don’t require code and you can build very robust applications.

20 years ago we were promised that there will be no need for coders, we laughed. 20 years ago the tools were not as mature or had as much functionality as today. What kind of application are you working one, does it really need a custom code solution?  Before you emphatically say YES! Really ask yourself what kind of application you are building?

System development can be grouped into two large categories

  1. Mission critical
  2. Office automation / project management / business intelligence / basic CRUD

Mission Critical applications require complex logic and finite control. These should be written with code.

Office automation etc. – Users have been using home grown LAN and email solutions (not great but workable solutions and I’ve seen very large companies run on these). SharePoint and SharePoint Designer can provide a fast solution for these types of applications that are 1000 times better than home grown LAN and email solutions. Development is fast with no code.

SharePoint has changed the development landscape and I am not sure that all developers have noticed. What kind of systems are you working on?

Here is an another view from Joel Spolsky on a similar topic-

Gord Maric

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.