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:
- 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.
- 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.
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.