SharePoint Designer 2013’s Missing Design View – Still

Here is a question that came in from my blog today.

My company is starting to plan to migrate to SP 2013 and I just found out that the design and split view is not included in SP Designer. This is going to be absolutely devasting for us as this is really the only way we do development. We have so many items created with XSL that I can’t imagine what we are going to do when we migrate. Can you update me on if MS has reconsidered adding that back and if not, where do I go to post my comments and to add my voice to those that are not happy?

Unfortunately, questions about the missing Design View in SharePoint Designer 2013 are fairly commonplace and sadly I have no good news. Those views are gone and as far as I know are not coming back. Any uproar that occurred due to my earlier posts like SharePoint Designer 2013′s Missing Design View – It’s Official fell on deaf ears.

I tend to write my own XSL, and one can certainly continue to do so using SharePoint Designer 2013. The Design View was always inexact, but since it was where we saw any error messages, I find that is why I miss it the most.

Display Templates – which are built of markup and script – are worth looking at, as are frameworks like Knockout or AngularJS. Yes, new things to learn, but more the way Web development is headed.

I also don’t know of anywhere to go to register complaints about this. I find that the MSDN Forums may make you feel better, but are rarely monitored by Microsoft people who can push for changes. Microsoft Connect is supposed to be the place to report bugs and give feedback, but things seem to languish there as well.

None of this is much solace for people who need to maintain existing XSL-based solutions. Bottom line: we all need to learn new tricks and/or rewrite our older XSL-based solutions.


SharePoint Designer 2013 Crashing on Open Site: The Fix

The Problem

My Office365 tenant has become half-upgraded from SharePoint 2010 to SharePoint 2013. (If you want to read more of my whinging about this, checkout this thread on SPYam.)

This leaves me in the unenviable position of having to use SharePoint Designer 2013 (SPD2013) with my SharePoint 2010 Office 365 tenant. Unenviable because, as anyone who follows me even occasionally knows, the Design and Split Views are not available in SharePoint Designer 2013. That thread that I started on TechNet has over 28,000 views, so I don’t think that I’m the only one upset by this.

When I installed SPD2013 on my laptop, all went well. However, every time I tried to use the Open Site dialog, it would crash. SharePoint Designer 2010 (SPD2010) was still working fine when I accessed other 2010-based installations, but not SPD2013.

I found a fix that worked for me in the Technet forums. You may or may not want to trawl through the thread, as it is quite long. Instead, here’s the Cliff Notes version of what worked for me.

Sungmin Kim from Microsoft offered up this check.

You can repair your SPD 2010 to restore the regkey for SPD2010.

The issue might happen in case the ClientGUID of the Open Site dialog in SPD14 is the same as the one of the open site dialog in SPD 15 in a certain Side by Side environment.

(this repro’s only in a specific environment, but I couldn’t find the enviroment yet and when the GUIDs could be the same)

so I have couple of questions. Sorry to bother you, :(

1. Could you please check if ClientGUID value under HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Open Find\Microsoft SharePoint Designer\Settings\Open Site is the same as the ClientGUID value under HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Open Find\Microsoft SharePoint Designer\Settings\Open Site?

2. If the values are the same, could you please check if the crash still happens after removing both registry keys?

3. Have you ever installed any other version of SPD15 on your machine? (e.g. beta version) or any other version of SPD14?

4. if the issue still happens at #2, how about removing the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDLg32\LastVisitedPidlMRU ?

Points 1 and 2 did the trick for me. Apparently both SPD2010 and SPD2013 had the same GUID for the ClientGUID value in the registry. I had not installed any betas of SPD2013 on my laptop because I was concerned about exactly this sort of incompatibility. (I’d limited my use of SPD2013 to launching it inside virtual machines.)

The Fix

If you have this problem and want to fix it, here are the steps.

Open the Registry Editor. You can do this by going to the Start menu (I’m still a Windows 7 stalwart, so I can’t vouch for how this might work on Windows 8), choosing “Run”, and typing “regedit” in the Open: box.

Look for the keys:

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Open Find\Microsoft SharePoint Designer\Settings\Open Site


HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Open Find\Microsoft SharePoint Designer\Settings\Open Site

In my case, they were identical, as shown below.

SharePoint Designer 2010 (14.0)


SharePoint Designer 2013 (15.0)


Delete both of the ClientGUID keys. You can do this by highlighting the key and hitting the Delete key or right clicking and choosing Delete.

Once I had deleted these two registry keys, I was able to open sites in both versions of SharePoint Designer with no problems.

Unfortunately, the two versions of SharePoint Designer seem to use the same recent sites list, so I see the same Recent Sites in both versions. This is going to make it confusing when I am trying to figure out which site to open. Now I’m a three SharePoint Designer version guy, as I’m still using SPD2007 and SPD2010 for client work in addition to SPD2013. Yeesh.

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.