NMR SharePoint Team Blog

Learn how to use SharePoint Designer to declaratively develop advanced customizations.

SharePoint Designer is your friend

Now that you are generally familiar with SharePoint from a user’s perspective, it’s time for advanced customizations with SharePoint Designer.  This tool is for customizing specific SharePoint sites and adds a lot of functionality over the Web UI (workflows, form customizations, Business Connectivity Services, etc.).  It is a powerful and useful tool, even if buggy, prone to crashes, and slow.

The goal of any SharePoint project is to leverage the use of the platform, deliver value rapidly, and enhance the user’s capabilities to serve their business needs.  Depending on the type of project you are working on, Designer can be your destination or your vehicle.  If this is a single-site customization project, for example, try to stop at the web UI and Designer.  If this is a professional solution with complex implementation, deployment, or maintenance requirements, you will still use Designer regularly.  Oftentimes, it is the only way to learn how something works, or at least the best way to get started.  You will then import your customizations into a Visual Studio solution to package them up, and deploy them, and likely add code (web parts, workflow activities, event receivers, etc.).

Customizing list views and forms

One of the most common and likely customizations you will come across is customizing list views and forms.  In the web UI, you can customize a view by showing or hiding columns, adding filters, sorting, grouping, and that sort of thing.  You cannot, however, touch how the list data are rendered.  Each field will display the same way every time depending on its type.  The headers, the hover effects, and all the elements of that list are predetermined.  SharePoint Designer gives you the tools to go deeper.

SharePoint uses an XSLT rendering method that applies the XSL Transformations to the results of a query to render a list view or form (display, edit, or new).  The actual transformation happens early in the page lifecycle during page initialization, allowing the use of ASP.NET server control declarations in the XSL.  You will see the <SharePoint:FormField ... /> control in new and edit forms, for example, that renders the complex controls for editing data depending on the field type.  Also, SharePoint provides added functionality by importing some xml namespaces for use in your XSL markup.  So, when customizing a view or form, you have the power of XSLT to work with, plus the SharePoint ddwrt namespace, plus the use of ASP.NET and SharePoint server controls.

To get started, check out this great SharePoint Designer resource from Microsoft.  The Data Views and Forms link has a wealth of information on how to use the tool to customize views and forms using Designer.  Each article has a See Also section near the top of the right margin with related articles.  Some notable examples:

• Example 1:  Create a custom list view
  Just to give you an idea, here is an example from a recent sample project I worked on.  Here I used HTML (added div elements and the like to the XSL), jQueryUI and CSS to translate numeric or text values into meaningful visualizations:
  
  Before:
  
  
  After:
  
  
  
• Example 2:  Create a custom list form
  Once again, example screenshots to spur the imagination.  Here I formatted the fields as Text Boxes instead of SharePoint FormField using the Design view.  I then switched to Source view and added jQueryUI sliders and synced them with the textbox.  To add more sizzle, I swapped out CSS classes for the slider depending on ranges I chose.  Green for 0 – 0.35, etc.
  
  Before:
  
  
  After:
  

Before we move on, I have to mention Marc Anderson, one of the most active members of the SharePoint community serving “the middle tier”.  Call it what you will, this advanced customization, declarative programming, or middle tier development that I described above is very powerful.  Check out his blog, and the SPServices jQuery library.

Designer workflows

You can create workflows to help automate business processes using the many OOTB workflow actions and pre-canned workflows, like approval and signature collection.  Workflows open the door to processing data that you don't have in the web UI.  A workflow is just code that runs on the server with inputs, outputs, access to variables, etc. This is Workflow Foundation under the covers.  So using the existing workflow actions, you can process data in new ways.  For example, since some fields aren't accessible in a Calculated column (like ID or lookup fields), you can use a workflow as a replacement.  The workflow is scheduled to run asynchronously in a timer job after the list item is created with no guarantee of when it will run, so it may not be ideal in all situations.  Any workflow-modified fields will not be immediately available to the user and could take a few minutes to update.

You cannot create new actions or write new workflow code in Designer, but you can augment your toolbox.  Here is a great opportunity to gradually scale up your project.  If you find you cannot accomplish something with a Designer workflow, you can find open source components (check codeplex.com) and third party products (from activities to advanced workflow design software).  Failing that, as a developer, you will certainly be able to write your own as well.  It goes against our instinct as developers, doesn’t it?  If Designer workflows are too limited, we want to pull it into Visual Studio and use the full power of Workflow Foundation.  We don't want to use some contrived designer to perform actions that would take only a line or two of crisp, clean code.  Remember... the point is to deliver low-cost, low-complexity solutions.  Purchasing a workflow action is cheaper, more reusable, and easier than custom code.  Of course, when warranted, there is nothing better than custom code, but think reusability.  Write a custom action to get over a hump before writing a completely custom Visual Studio workflow.

What else?

A few other important capabilities to be aware of are:

• InfoPath:  If you are using SharePoint Server, you also have access to InfoPath forms for form customization. InfoPath includes a rules engine, validation, more form layouts, and controls, and the ability to write code within the form.
  
• Business Connectivity Services:  Business Connectivity Services allow you to integrate external data and functionality into your SharePoint 2010 environment. This great article by Kirk Evans describes what BCS is, how to use it, and even proper scenarios for custom development beyond Designer.
  
• Honorable Mention:  Well, as this post fizzles out, I'll mention that Designer has other capabilities that you can explore on your own.  Editing pages, editing master pages, and site/sub-site creation all get an honorable mention.

In conclusion, I hope you see that an awful lot can be done in SharePoint using the web UI and Designer.  Even if you remain strictly a custom coder, there is a place for you in this ecosystem.  Everything we have covered so far can be extended with custom components.  It is important to understand how this all works, what the capabilities are, and where your hooks are to develop most efficiently.  But for the developers who are interested in building complete business solutions on SharePoint, you have to have an open mind.  Even if you are working in Visual Studio, you will author many of your customizations in the web and Designer before importing them into your project.  You will play a sort of dual role as a power user and developer, but that comes with the greatest combination of capabilities.

Thanks for Reading,
Lou Estrada

In order to better understand SharePoint, its capabilities, and its limitations, use the product as an end-user.  This will give you valuable perspective when you start designing your own solutions.

Not So Fast!

If you are truly new to SharePoint, and you want to be a SharePoint developer, it is going to take time and you will have to start small.  You cannot – or should not – develop for SharePoint without understanding the platform from the user’s point of view.  The platform is for them, after all.  You are only going to be needed when users need help, or when a professionally developed and maintained application is warranted.  Also, as you develop components, you should understand how your users will interact with them and use them in a normal user scenario.

So, before you start reading development books, spend a couple of days playing around in the environment.  Learn how to create site collections, sites, pages, custom fields, content types, lists, views, etc.  Do this only from the web UI and avoid SharePoint Designer or Visual Studio for now.  It is important to know where the lines are so you start to get a picture of the user’s capabilities.  There are plenty of resources available to get you started.

Start Creating in the Web UI

When you create a site, notice the different site templates available to you.  Go into site settings and learn about site features.  Notice that a Team Site deploys with the “Wiki Page Home Page” feature enabled, for example, while the Blank site does not.  Create a list and notice the many field types available.  Create another list and add a lookup field to the first list.  Explore or take a guided tour, but do spend some time experiencing SharePoint from a user’s perspective.

If you think about a custom application, it would mainly consist of data, data access, processing, and UI.   SharePoint lists are a robust data store with indexing and referential integrity.  They can handle millions of records (although there are caveats with large lists).  SharePoint’s data access comes in a variety of flavors, including Server API, cross-platform Client APIs, and Web Services.  With event receivers, workflows, web parts, controls, http modules, timer jobs, custom actions, xsl, and client script, you have all the necessary means to implement your processing.  Finally, SharePoint is a web framework and has OOTB default rendering, although you could create your own pages, views, web parts, HTML, etc.  You can also utilize any of the applicable data access methods listed above from other platforms, like a native smartphone app, for example.

How’d They Do That?

By looking at the platform from a user’s point of view, you are engaging in some sort of reverse engineering.  You are looking at what is possible before getting bogged down with how to do it.  It is a useful exercise, and I suggest everybody take a minute to go to the web UI, find something really cool, and then figure out how you can do the same thing in your code.

While I was learning the SharePoint 2010 web UI, there were many things that caught my eye; the ribbon, the dialogs, the rich client experience.  As you will find out, you get some of this for free when you start developing your own solutions, and some you have to work for.  When I was building a web part, for example, I wanted to pop open a dialog to collect input like the Silverlight Web Part does.  After a couple failed attempts, I put it off for another time.  My colleague, Rob Cronin, sent me to a blog post by Wictor Wilén that explained the undocumented feature.  Having had experience with the web UI, I knew it was possible.

Another colleague, Rob Johnson, told me about his experience exploring SharePoint 2010.  He experimented with service applications like Excel Services.  He learned how to reference a cell, chart, or pretty much anything in an Excel document via a URL (using RESTful services).  “Think of the possibilities,” he said.  Well, as a developer exploring SharePoint through a user’s eyes, I say think of the opportunities.

When you hit a wall, DON’T crack SharePoint Designer just yet.  Search for third party tools, open source projects, and crafty solutions from the SharePoint community (and your colleagues!).  Think like a user and don’t try to develop your way out of every problem.  Is there a fix you can purchase, install, or configure?  How far can a user go without leaving the web UI and without calling you?

Learn SharePoint Permissions

Learning SharePoint permissions is important for a few reasons.  First, the users will have different experiences based on their permission levels.  If a user hits a wall, is it because they don’t have the permission to accomplish their task?  Or is it truly a limitation of the platform that you may have to develop around?  The user may not know which it is and call you.  Will you know?

Second, you may work with organizations that have different approaches towards user empowerment.  Consider how working with an organization that embraces user empowerment might differ from one that is more locked down.  Developing in an environment where users can develop for themselves makes for an interesting dynamic.  You may step on each other’s toes, be met with unrealistic expectations, and, if the culture doesn’t truly support it, you may begin to feel a lot of tension between the two groups.  On the other hand, if users are so locked down that they need a developer to do anything, then that defeats the purpose of SharePoint.  Costly developers will spend too much time creating pages and configuring web parts for the underprivileged rather than developing innovative solutions.

Understanding these dynamics, possibilities, and limitations will pay dividends later.

Thanks for Reading,
Lou Estrada

SharePoint is for end-users…

SharePoint was designed for end-users.  Whatever accommodations have been made for developers have been slowly introduced and improved over the last decade.  SharePoint 2010 is the first version that can pass as a development platform, in my opinion.  While it pales in comparison to other development platforms in some respects, it far surpasses them in others.

Point is, end-users are front and center.  They are supposed to be able to help themselves without us.  As it turns out, sometimes they can help themselves, and sometimes they can't.  Sometimes they are able to compose a solution by creating a list, customizing a view, creating a page, adding some web parts, etc.  Sometimes, users need a little extra push to get over a hump.  Even then, developers may not be necessary.  A power user can train up on SharePoint Designer and InfoPath, customize a form, add a workflow, and even surface external data through Business Connectivity Services.

…but there is room for Developers, too

Developers, on the other hand, can utilize Visual Studio to package their solution into a WSP file for reuse in any SharePoint environment.  The developer packages the WSP, it is deployed to staging, and if the tests pass, the same exact package gets deployed to production, potentially multiple times in multiple environments.

Each has their own strengths

Developers have other advantages, too, like the tools that allow us to do more (features, controls, web parts, etc.) and the technical know-how that allows us to do it better (better architecture, performance, testing, quality, stability, reusability, maintenance).  Not to mention we have decades of IT lessons learned in our pockets, such as development methodologies, frameworks (ITIL, CMMi), best practices, and more, to help our projects succeed.

Users have an advantage with quick turnarounds (composing their solutions directly on production for instant gratification) and intimate domain knowledge (smarter about their business processes and their requirements, leading to more accurate process representations in their work).  They work faster and nimbler, with fewer layers of interpretation from problem to solution, and less ceremony getting in the way of immediate results.  Not every business problem warrants a six-figure (or more) price tag, and the results users and power users can put together often are compelling. 

Getting the best of both worlds

So how can an organization get the best of both worlds; the flexibility, speed, and accuracy of a user-created solution, and the stability, professionalism, and performance of a developer-created one?  Well, this is where politics and egos get involved.  In order to avoid problems down the road, an organization ought to put together guidelines ahead of time.  What are users free to do? When should developers get involved?  How should they work together?  There is no black and white answer here.  Navigating these politics come with the job.  Some guidelines to consider...

• Look to invest in more professional solutions on mission-critical projects, projects that need to be maintained for years to come, or that need to be shared among departments/sites/workspaces.  Keep it simple on others.
• Leverage the strengths of all team members, utilizing whatever assets are appropriate for the task at hand.
• Find ways to work together... Consider pairing a developer with a power user to design solutions or perform solution reviews.  Or have shared meetings (perhaps Lessons Learned meetings) where knowledge, ideas, and status can be shared among everybody.  Each would be surprised what the other is capable of.
• Document best practices for common situations... a knowledge base (a wiki is great for this).
• Look for reuse opportunities.  If a developer sees a common problem, is there a creative solution that can be deployed as a feature?

These are all common sense measures here.  No matter what the makeup of your team, with a little thought, a bit of experience, and a lot of patience, you can find a way to get the best of both worlds.

Thanks for reading,
Lou Estrada