Overview of User Experience Approaches

If you've worked with previous releases of SharePoint products and technologies, you're probably familiar with the traditional server-side controls approach to building a web-based user experience. Typically, your server-side toolbox would include master pages, application pages, themes, cascading style sheets (CSS), Web Parts, delegate controls, navigation controls and providers, and so on. SharePoint uses these resources to construct an ASP.NET page dynamically. This is then converted into HTML, packaged into an HTTP response, and sent to the web browser on the client.

When you use this approach, all the logic in your application executes on the server. In order to update any of the content on the web page—to apply a filter or view the details associated with a list item, for example—the browser must send an HTTP GET request to the server. The server processes the request, regenerates the HTML, and sends a new HTTP response to the web browser on the client, which must render the entire page from scratch. This is known as a full-page postback. The process is illustrated by the following diagram.

Web page with server-side controls

While this approach provides a robust, functional approach to web application development, it can lead to a frustrating user experience. Interactivity is limited, as users must wait for the page to reload in response to any changes they make on the user interface. As a result, web developers increasingly rely on RIA technologies, such as Ajax, Silverlight, and Flash, to provide a more engaging user experience. These technologies allow you to execute some logic on the browser, rather than relying entirely on server-side execution.

RIA technologies typically use asynchronous communication to send and receive data from the server without reloading the entire page. With an asynchronous programming model, the request communication is disconnected from the response mechanism. This results in more responsive applications and an increased ability to perform work in the background or in parallel. The result is web pages with multiple, relatively isolated regions that can be updated independently, and user interfaces that continue to respond to the user while data is being retrieved from the server.

RIA technologies are not mutually exclusive. It's common to see SharePoint web pages that contain a mixture of server-side controls, Ajax-enabled regions, and Silverlight applications. In the remainder of this topic we provide an overview of the key approaches to building a client-side user experience for SharePoint applications.

Note

There is some debate within the technical community as to whether or not Ajax qualifies as an RIA technology. However, in this documentation we view Ajax as an RIA technology, as you can use it to provide a more interactive user experience through client-side logic.

Ajax User Interface

In the broadest sense of the term, Ajax refers to a set of technologies that allow you to retrieve data asynchronously from the server, and manipulate that data in the client browser, without disrupting the display or behavior of the current web page. Ajax was originally an acronym for Asynchronous JavaScript and XML, as Ajax applications would traditionally rely on the JavaScript XMLHttpRequest API to send asynchronous requests to a web server and to return the response to the calling script. The script could then use the response to alter the document object model (DOM) of the current page—for example, by updating the values in a table—without refreshing the entire page. However, Ajax has evolved to encompass a broader set of technologies in which scripts running in a browser window can use a variety of asynchronous communication channels to retrieve and manipulate data from a server. Today, the term Ajax has become synonymous with a web application style in which user interactions are managed predominantly by the browser, rather than the web server.

The use of Ajax-style technologies in a web page is rarely an all-or-nothing approach. At one end of the scale, you might use a little bit of JavaScript to display dialog boxes, concatenate strings, or validate user input. You might add Ajax-enabled regions, which make use of partial postbacks to provide users with access to constantly changing data without reloading the entire page. Depending on your requirements and your target audience, you might move to a pure Ajax approach, in which the page is loaded once, all further interactivity takes place on the client, and all further client-server communication takes place asynchronously in the background. However, you will still need to design a server-side page to host your Ajax components, you'll typically still require Web Parts to host the Ajax-enabled content, and the browser will still need to retrieve your page from the server at least once. Your web page will typically use a combination of full-page postbacks and asynchronous communication to communicate with the server, depending on the extent to which you implement Ajax features of your user interface. This is illustrated by the following diagram.

Web page with Ajax components

Note

Client-side data access mechanisms include the client-side object model (CSOM), the REST interface, and the ASP.NET (ASMX) web services. These are described in Data Access for Client Applications.

Ajax functionality is supported by virtually all web browsers, with some minor differences in how scripting functionality is interpreted. Popular JavaScript frameworks such as jQuery help to manage the complexity of variations between browsers, and improved debugging support for JavaScript has made Ajax more accessible. The Ajax approach delivers a more responsive user experience for several reasons:

It only loads part of the page at a time. This reduces the amount of data that is passed between the client and server, and largely eliminates entire page refreshes. Only data is sent between the server and the client on asynchronous requests; no HTML markup is included.

It handles more events on the client without requiring a postback to the server.

It caches information on the client between user interactions. This is more efficient than the full-page postback approach in which state information is typically passed between the client and the server on every request.

SharePoint 2010 makes extensive use of Ajax principles in the out-of-the-box user interface, and client-side APIs in the 2010 release make it easier for you to use Ajax approaches when you develop SharePoint applications.

Silverlight User Interface

Silverlight is a development platform that enables you to create rich, engaging applications that run in web browsers and on other devices. Silverlight developers use a specialized, lightweight version of the Microsoft .NET Framework to create applications. Alongside the benefits of a familiar .NET development experience, Silverlight offers capabilities in areas such as graphics, animation, and multimedia that go well beyond what you can achieve with Ajax.

Silverlight applications can run on a variety of platforms—in fact the latest release, Silverlight 4.0, allows you to build applications that can be taken offline and started from the desktop. However, in this documentation we focus on the use of Silverlight as an RIA technology. In the case of web pages, compiled Silverlight applications (XAP files) are hosted within HTML object elements, which can either be embedded in the page or generated dynamically through JavaScript. In the case of a SharePoint web page, Silverlight applications are typically hosted within a Web Part. SharePoint 2010 includes a Silverlight Web Part that is specifically designed for hosting XAPs within a SharePoint page. Just like web pages that contain Ajax-enabled components, the browser must use a traditional synchronous page load at least once in order to render the page and download associated resources, such as the Silverlight XAP and any JavaScript files. The Silverlight application can then use a variety of data access mechanisms to communicate asynchronously with the SharePoint server. This is illustrated by the following diagram.

Web page with Silverlight components*

Silverlight applications can also interact directly with Ajax elements on a page. It's increasingly common to use a combination of Silverlight applications, Ajax elements, and traditional server-side controls together to provide a full range of functionality for SharePoint users.

Note

SharePoint 2010 includes a new SilverlightWebPart class. This provides a Web Part that you can use to host Silverlight applications within SharePoint web pages.

Office Clients and Managed Code Clients

Managed code clients are typically stand-alone applications that use the full capabilities of the .NET Framework. Managed code clients include Office clients, rich stand-alone clients built on Windows Presentation Foundation (WPF) and Windows Forms applications, and administrative applications built as console applications or Windows PowerShell extensions. A Silverlight application in offline mode could also be considered a rich client application. Rich clients usually provide a full UI and often integrate data and functionality from multiple sources into one composite application. These applications can use the SharePoint client APIs synchronously or asynchronously, in order to access and manipulate data on the SharePoint server. This is illustrated by the following diagram.

Rich client application

Office client applications, such as Microsoft Word, Microsoft Excel®, Microsoft Access®, and SharePoint Workspace, have their own development framework in Visual Studio Tools for Office (VSTO) as well as more advanced out-of-the-box integration with SharePoint. Office client applications can also use the Business Connectivity Services (BCS) client object model, which installs with Office and is licensed with SharePoint Enterprise.

This capability enables Office clients to connect directly to external services through a Business Data Connectivity (BDC) model defined on the SharePoint server. Portions of the BDC model can be deployed to the client as part of an application, and the client application uses the model to connect directly to external services through the client BCS runtime. The client application can also use the Secure Store Service on the SharePoint server to authenticate to the external services that it accesses. The BCS client includes offline caching capabilities and an API for developers. The API is accessible outside of Office when the Office client is installed. However, its use is not supported outside the context of an Office client.

Development for Office clients is a specialized area that differs substantially from other approaches to client-side development for SharePoint. For this reason, this documentation does not cover Office client development in any detail.

Note

For more information on working with the BCS, see External Data in SharePoint 2010.