SharePoint Designer 2013′s Missing Design View – It’s Official

Well, Keenan Newton did a post on the Microsoft SharePoint Team Blog entitle Changes to the Design View in SharePoint Designer 2013 yesterday that makes it official: the Design View in SharePoint Designer 2013 is not just missing, it’s not coming back. I’m reproducing Keenan’s post below, but you should also read it in situ, as the comments are already piling up, and they aren’t positive.

Hi, I’m Keenan Newton, a senior product marketing manager on the SharePoint team.

We’re making some changes to the Design View in SharePoint Designer 2013, and I wanted to talk about the reasoning behind the changes.

With SharePoint Server 2013 embracing new web standards for client side rendering of pages such as JavaScript, JSON, and OData, there is no longer a need to support a visual web page editor within SharePoint Designer. With that in mind, we removed the ability to visually edit pages in SharePoint Designer 2013 because its page editor is designed to only understand the unique features of a SharePoint web page. With our support of new web standards, any web page designer can now be used for editing web pages in SharePoint Server 2013. This includes form customization, conditional formatting of page content, layout, theming and branding. To simplify the process of integrating customized SharePoint pages, SharePoint Server 2013 includes a new feature called the SharePoint Design Manager. This feature enables a web designer to export a web page from SharePoint, customize it, and then import it back into SharePoint, all right from the SharePoint site.

SharePoint Designer 2013 will continue to support site, workflow, list, library, and external data customization and configuration. However, we will look for opportunities to leverage SharePoint itself as the primary tool for customization and configuration tasks.

I’m not going to be politic about it: this is going to hurt Microsoft and it’s a horrible decision. The things you may be able to use Design Manager to do and workflows are not what the majority of people use SharePoint Designer for. Code View will do those same people virtually zero good, and there’s no replacement strategy.

Here are some of my specific beefs with the “official” stance that Keenan puts forth.

…we removed the ability to visually edit pages in SharePoint Designer 2013 because its page editor is designed to only understand the unique features of a SharePoint web page.

Exactly! The reason we choose to use SharePoint Designer is *because* it understands “the unique features of a SharePoint web page”. Nothing else does. For better or worse, SharePoint 2013’s forms, for example, are the same as they have been in 2007 and 2010, based on the List Form Web Part. No other editor knows what that is. SharePoint Designer does.

…any web page designer can now be used for editing web pages in SharePoint Server 2013.

This has always been the case, but who has decided to use Notepad or anything else in the past? We’ve always had the option to copy aspx page content out into some other editor to work on it, and that seems to be what Microsoft is recommending now. SharePoint Designer was and is the only IDE that understands SharePoint’s page structures, controls, and Data Sources. With any other tool, we have to know ourselves how to set up a Data Source in a DVWP or which controls to add to take advantage of SharePoint-specific functionality. In the newly neutered SharePoint Designer, many of the ribbon buttons actually serve no purpose anymore. Things like Conditional Formatting, DVWP formatting options, etc. don’t function unless we write our own code first. On top of that, there is no longer a surface where SharePoint Designer can show us errors in that code. Errors, cryptic or not, have always been shown in the Design (or Split) View. Now we will be flying blind.

To simplify the process of integrating customized SharePoint pages, SharePoint Server 2013 includes a new feature called the SharePoint Design Manager…

Maybe Microsoft believes that the Designer word in SharePoint Designer means that people only use it for design. As you and I know, design is only one small piece of how we use SharePoint Designer. Design Manager also is only useful if you want to apply a design via a master page or page layout to an entire Site Collection that has publishing features enabled. It doesn’t do us any good on individual pages where we want to make small customizations in the design or structure for single-location functionality.

All in all, I’m very disappointed in Microsoft’s decision on this one. As I’ve been telling people, I’ll be fine. As a consultant, I can keep working with SharePoint 2007 and 2010 for a long time and make a decent living at it. I can even learn to work in the Code View exclusively in SharePoint Designer 2013. I’m worried about all of the unsung heroes out there in SharePointland who have been using SharePoint Designer to build solutions that their organizations actually use, rather than what IT typically jams down their throats. Those of us who believe in user empowerment and citizen development have lost a battle this day.

[important]For another great slant on all of this, check out Michal Pisarek’s (@michalpisarek) great post from yesterday SharePoint 2013 Design View Changes and Change Management 101. In it, he makes some excellent points about how the change management around all of this has been abysmal.[/important]


SharePoint Designer 2013′s Missing Design View – More Thoughts

I’ve written previously about SharePoint Designer 2013′s Missing Design View here on my blog as well as on the Microsoft forums and elsewhere.. My goal in writing about this and making a lot of noise about it is not to simply complain. (We have way more complaining about everything out here on the InterWebz than we already need.) People need to understand what not having the Design or Split View in SharePoint Designer means if they upgrade to 2013 so that they can make good decisions.

At this point, I’m going to be going with the assumption that the net-net  answer is “hire more developers”. (Note: Assumption)

If the Code View is the only available view in SharePoint Designer, and existing functionality has been implemented with XSL-driven Web Parts, such as Content Query Web Parts (CQWPs) and Data View Web Parts (DVWPs), then there are two main options:

  1. Maintain the DVWP in Code View, which requires an XSL able developer. This is not at all easy. The XSL that SharePoint Designer generates – it is essentially playing a code generator role here – is horrible. There are some reasons for this that are legitimate: in order to be prepared for that next button you click on to change what you want to display in a DVWP, SharePoint Designer includes all sorts of stubs in its XSL For years, I’ve simply thrown away most of the SharePoint Designer -generated XSL and written my own because of this. However, altering existing DVWPs that have been implemented by power users become a development task going forward with 2013 even if a developer wasn’t needed before. It’ll have to be direct customization of the XSL in the Code View.
  2. Rearchitect the solution to use client-side processing. This is where Microsoft is clearly heading. The client-side push that started in SharePoint 2010 continues in 2013. Microsoft has expanded the Client Side Object Model (CSOM) and the REST Services. In many cases, the exact same functionality we have used DVWPs to build can be built with this new paradigm, but there will, of course, be cases where we have to make some trade-offs. Regardless, it becomes a developer task, as I can’t see many power users choosing to learn scripting.

If you follow me at all, you know that I love using client-side processing.with SharePoint to greatly improve the user experience (UX). The tools of the trade here are CSS, JavaScript and the many things that people have built to provide extended functionality, like jQuery, SPServices, and so many libraries, plugins, and add-ons it’s impossible to count. This is a great thing for SharePoint. As I’ve been saying for years now, it opens up SharePoint development to herds of new people who already have those Web development skills

But I also see a huge downside to this rush to client-siide development. The reason I coined the term “SharePoint’s Middle Tier” (OK, OK, I know most people hate the name – I can’t say it without the disclaimer) is that we do processing on the server *and* the client. We choose what makes the most sense in load distribution and put each chunk in the right place. Using a DVWP to do the heavy lifting of getting the initial load of data onto the page often covers a high percentage of use cases. Then we layer script (the other code) onto the page to provide behaviors and interactivity with the data without postbacks. By pushing for client-side processing exclusively, we lose that capability to architect well-balanced solutions (without cracking open Visual Studio – which Microsoft has started to discourage).

The biggest issue here is that we go from minimal error assistance – which is only shown in the Design or Split Views – to zero error assistance. Even a well-trained XSL developer or an XSL monkee like me will get zero error messages other than the essentially useless

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator.

error message in the browser and have to figure out what error we’ve introduced by feel.

Design and Split View for most of us who do this kind of work has nothing to do with “design”. The argument that SharePoint 2013’s new Design Manager allows us to design with something like Dreamweaver is somewhat specious. Instead, we use SharePoint Designer to develop real solutions using markup, DVWPs, script, etc. The Design View is where SharePoint Designer shows us what is going on. When I intentionally created a error in a DVWP to get the text for the error above, SharePoint Designer was telling me “This Web Part does not have a valid XSLT stylesheet: Error: A name was started with an invalid character. <<< “. That’s useful – I had added a couple extra < signs and it told me that I had. We totally lose that with no Design or Split View. The upshot of this is that there will be no reasonable way to build this type of solution or maintain existing ones. QED

Thus, we end up at option 2, which is a rearchitecting all the existing solutions which rely on development using the Design or Split Views. IT shops have used these methods as much as power users, at least at my clients, so it is my firm belief that this issue is going to be big and pervasive.

So, what’s the upshot of all of this? Well, if you plan to upgrade to SharePoint 2013 and have used the development methods I talk about here, then keep your eyes open to the level of effort it may require. Do a very careful inventory of solutions that you already have in place that were built using SharePoint Designer and think about what you will do with them in 2013. It’s not hopeless, but it’s going to be a lot of work.

The Content Query Web Part (CQWP) and the ddwrt Namespace

I’m positive I’ve run into this little issue before, but since I don’t seem to have done a post on it, I stymied myself again.

A client of mine spotted a nice post from Ben Tedder (@bentedder) showing how to Create a Classifieds Listing using SharePoint 2010. It uses a bunch of Content Query Web Part (CQWPs) to build up a sort of virtual bulletin board where people can post things they have for sale, help they need, upcoming community events, etc. Ben has been doing a lot of really cool stuff with SPServices, so I’m familiar with his stuff and know that the quality level is high.

Ben’s post gives a nice outline of how to create this type of solution, and we decided I’d implement it. Normally I’d jump straight to the Data View Web Part (DVWP) for something like this, but there’s some appeal to the CQWP in this case. It’s not unlikely that they will want to change both how the categories are laid out on the page and what categories are available, and there’s no reason to involve a developer at that point; the CQWP is pretty easily adjusted by a reasonably sophisticated user.

When I first dropped Ben’s template into the ItemStyles.xsl file, saved it, and refreshed my page, I got an error. No worries, I figured, I must have missed a closing tag or comma or something. About an hour and a half later, I’d tried every version of paring the XSL down that I could think of and had pretty much isolated the issue to where I was displaying the Created date. But I couldn’t for the life of me figure out why it wouldn’t work.

Time for a drive to get some lunch, and within five minutes the answer had occurred to me. (I’m a big proponent of separating myself from the physical location where something has me stumped – I find it lets my mind wander into different territory.)

The problem was that the ddwrt namespace wasn’t registered in ItemStyles.xsl. What that means is that where I was using the ddwrt:FormatDateTIme function, SharePoint had no idea what I was talking about, and it threw an error. When I displayed the Created date without using the ddwrt function, it worked just fine.

[important]If you’re not familiar with the ddwrt namespace, you should be if you write any XSL at all for SharePoint. The only article I’ve ever found which explains it is one on MSDN from Serge van den Oever
which he wrote way back in 2005 called SharePoint Data View Web Part Extension Functions in the ddwrt Namespace. It’s such an important namespace, it always amazes me that this is the only article which explains it on Microsoft’s site.[/important]

Once back in the saddle, I looked at one of my trusty DVWPs and figured out where the references need to be. Here’s the top of the ItemStyles.xsl file before I edited it:


and after I added the reference to the ddwrt namespace.


It’s a simple little change, but absolutely necessary if you want to use the ddwrt namespace functions in your CQWPs.

Now, with this post, I’m happy that I won’t paint myself into this corner again, and hopefully it’ll help a few of you to stay out of that corner as well.

When Would I Use a CQWP Over a DVWP?

Anyone who follows this blog or hears me speak at conferences knows that I am a *huge* fan of the Data View Web Part (DVWP).

A good friend sent me this quick question in an email today:

Content query webpart vs data view wp? When would you use content query over data view?

Here was the quick response I typed on my iPhone while waiting for a seat for dinner:

CQWPs are good if your users may need to reconfigure them over time because they can change the filtering and such in the Tool Pane. The drawback is that unless you get someone to write you new XSL to give you the styles you want, you’re stuck with what SharePoint gives you OOB. CQWPs also often deploy from environment to environment better because there’s more OOB to them.

DVWPs let you do basically anything you want by modifying them in SharePoint Designer. However, your users can’t do any reconfiguring on their own (unless they are SPD jocks). If DVWPs aren’t written intelligently, deployment *can* be a problem, but doesn’t have to be.

Because I find the DVWP so much more flexible, I usually choose it over a CQWP, but i do implement CQWPs from time to time as well.

What do you think?

Displaying Links Lists’ URLs in a Content Query Web Part (CQWP) in SharePoint 2010

I was trying to use a Content Query Web Part in SharePoint 2010 today and display the URL column from a Links list. Oddly, there’s no out of the box style for this. A little Binging, an #SPHelp tweet, and I came to the conclusion that I needed to add a new style to ItemStyles.xsl in /Style Library/XSL Style Sheets.

This seems counter-intuitive; a Links list would seem to be a common type of list to use with CQWPs. But I guess not. This sort of thing with the CQWP is why I almost always just jump straight to the Data View Web Part (DVWP). I can build my own XSL libraries faster than trying to sort out the CQWP ones, but we’re aiming for as fully out of the box as possible in this project. So I needed to write some XSL. You know, out of the box.

Luckily, I found a post on the MSDN Forums with a nice XSL template to accomplish exactly what I wanted. Yay, InterWebs. I could have written this, but why, when it’s already been done?

   <xsl:template name="LinkList" match="Row[@Style='LinkList']" mode="itemstyle">
        <xsl:variable name="SafeLinkUrl">
            <xsl:call-template name="OuterTemplate.GetSafeLink">
                <xsl:with-param name="UrlColumnName" select="@URL"/>
        <xsl:variable name="DisplayTitle">
            <xsl:call-template name="OuterTemplate.GetTitle">
                <xsl:with-param name="Title" select="@URL"/>
                <xsl:with-param name="UrlColumnName" select="'LinkUrl'"/>
        <xsl:variable name="TheLink">
   <xsl:value-of select="substring-before($DisplayTitle,',')"/>
        <div id="linkitem">
            <xsl:call-template name="OuterTemplate.CallPresenceStatusIconTemplate"/>
            <a href="{$TheLink}" target="_blank" title="This link opens in a new window">
            <xsl:value-of select="substring-after($DisplayTitle,',')"/>

BTW, this works the same way in SharePoint 2007. I just get more hits if I say SharePoint 2010 these days. ;+)