SharePoint Designer 2013’s Missing Design View
[important]If you’re interested in this topic, also see my follow up post.[/important]
Yesterday I posted in Microsoft’s SharePoint 2013 Preview for IT Professionals forum about my concern that that the Design View (and by extension, the Split View in case you were wondering) is no longer available in SharePoint Designer 2013. There are a lot of potential repercussions of this, but to me the most significant is that we won’t have any good way to debug the Data View Web Part (DVWP). As cryptic as the error message may be in SharePoint Designer’s Design View, they sure beat something like this in the browser:
If you use the DVWP or any other SharePoint Designer capabilities where you rely on the Design View, please read my post (duplicated below), the comments, and add comments of your own. The list of people who have already commented is impressive, including quite a few MVPs who don’t even use SharePoint Designer, but understand its importance in empowering the SharePoint end user.
It may be a vain attempt, but I’m trying to get Microsoft to understand the importance of what they have removed before it’s too late. Please add your voice.
In SharePoint Designer 2013, the Design View is no longer available.
Some of us MVPs have been talking about this since the beta release, most recently at SPTechCon for me. The general response from the real people we talk to about this – after a stunned silence – is “You’ve got to be kidding me!” I’m of the belief that this is going to cut a lot of people off at the knees.
This will be a *huge* problem for many of my clients, who are very used to using SharePoint Designer as the tool to build full scale applications. Here are some scenarios which will no longer be possible, which we see real users doing all the time:
- Creating full-featured Data view Web Parts (DVWPs) to display list-based content in unique and required ways. Given that the DVWP is XSL-driven, the possibilities are virtually limitless in how users can manipulate the XSL to emit the markup around the data that they choose. Having control over that markup also ensures that client side script laid onto the pages at load time can add needed behaviors.
- In SPD 2013 workflows, the initiation/association forms are built as ASPX pages and not InfoPath pages. If this was SPD 2010, we could then use the SPD’s Design View to amend and add other ASP controls using the Toolbox tool pane, setting the properties of the ASP controls using the Tag Properties tool pane to enhance these pages. Without the Design View, we will have to tell our clients to open Visual Studio. This will affect the adoption of SP 2013 workflows because advanced IW users will think any solution that involves VS is too difficult for them and they also will probably not have access to VS. This will push this IW-based work back to IT.
- Existing DVWP-driven functionality will no longer be easily maintainable in 2013. This means that the investment that these power users have made in this SharePoint development technology may be seen as a poor architecture choice, which can cast a shadow on the new functionality that SP 2013 is giving us.
- Simple page formatting changes will become much harder. Oftentimes, power users simply want to add conditional formatting or widen a column in an existing List View. Without the Design View, these simple tasks become “blind”. Rather than being able to see the results of their changes in SPD before saving the file (thus potentially avoiding broken pages), they will have to save, refresh in the browser, repeat. This process is more onerous than using the Design View at best, and prohibitive at worst.
These are just a few of the scenarios that come to mind based on my conversations and thinking about it myself. These scenarios reflect my client work, and others will have additional perspectives.
What is the Microsoft guidance for all of this? What can we tell our clients the alternatives are? How can we continue to support their existing applications if they decide to migrate to SP 2013?
Thanks,
M.
We run our entire Construction and Development company using Sharepoint Online. All the reporting is done in-house using Sharepoint Designer. I can’t even begin to imagine the impact of losing the Design View. If so, we would be forced to leave Office 365 and go to a provider who would keep the Sharepoint 2010 in place for us. Please do not do this!
Marc: I couldn’t agree more. I use Design and especially split view extensively. I am not a developer and without split view I would never be able to find the code that needs “fixing” or modifying. All of your above points are right on … I use ASP.net controls, DVWPs, combined content sources w/DVWP, conditional formatting, and workflows extensively. I am sure I am missing a ton of detail re: how I use this powerful tool. It will literally render me useless or much more ineffective in my job if I don’t have that and I will have to throw the work “over the fence” to developers much more regularly. In my opinion the very name “SharePoint Designer” to me implies that this is a tool for power users, not a tool for developers. Removing design and split view will make this an essentially useless tool … frankly, I am horrified what this might mean to the job I do …
Inge:
I know you’ve already commented in the thread on the Microsoft forum, but the more people who do with cohesive arguments like yours, the better. Please encourage others to do the same. I’m not sure if this is going to go the right way, but it’s worth a try.
M.
This is a really strange move by Microsoft. Although capable of designing solutions in VS, I usually use Designer instead – the idea being that a DVWP solution can be more easily transitioned to a co-worker or replacement without extensive training. The fact that changes can be seen and tested in real-time is a huge bonus as well.
For this and a couple of other reasons, I have to recommend against moving to SP2013 for the time being. Hopefully MS will come to their senses and shore up some of these bad decisions on the product.
Marc, I use SPD design view all the time for debugging, optimzing and “fixing” all the stuff that SPD occasionally messes up. If this is true, I will see very little reason to suggest any of my clients move to 2013 (since many of them are still struggling to move to 2010). It’s even worse than the functionality they removed from SPD 2007…and I still find myself using 2007 on occasion, since you can point it to anything, SharePoint or otherwise.
Personally, I wish they’d fix the underlying workflow foundation issues that we still encounter when creating SPD workflows, such as actions firing out of order, and make it more robust while retaining the current features.
Are MS getting too much flak from developers concerned with power users taking away some of their job? ;)
Hi,
I am a humble all-rounder who relies on SPD design view extensively. I am certain that there will be many folks around the world who, similar to me, have been given the responsibility of creating / modifying and maintaing SharePoint sites without having formal programmer training or extensive XSL etc. skills. This is one of the great benefits of SharePoint – that enterprises of all sizes and budgets can leverage some benefit using the talent available to them.
If there is no design view in SPD 2013 then I will basically be looking for a job and the not for profit organisation I help with their SharePoint environment is going to have to find some money to employ “experts”.
Seems like a pretty dumb move by Microsoft to me.
Mark
I agree with Marc Anderson, we can sway the product team at Microsoft to reconsider this decision. Below, please find an
open Letter to Microsoft that MVPs and other influential customer decision-makers can sign-off and hand to the SharePoint Team in Redmond,WA.
————————————————————————————-
An Open Letter to Microsoft to Restore the Design View Functionality in SharePoint Designer 2013.
We the undersigned categorically agree that removing the Design View in SharePoint 2013, while it may have limited merit, is an overall terrible decision that will have devastating consequences for organizations heavily invested in the SharePoint product and will greatly reduce continued adoption of the SharePoint product. While there are many impassioned reasons why we have come to this conclusion, we have narrowed it down to the one main “critical deal-breaker” item that must addressed:
Long-Term Legacy Maintenance and Administration is now extremely difficult or even impossible for SharePoint power users: If organizations who have heavy SharePoint Designer 2007/2010 “power-user designed customization’s” seek to migrate to SharePoint 2013, then customization’s created by power users can no longer be maintained by the very same power users who owned, maintained, and created said customization’s. From any CIO’s perspective, this scenario is totally unacceptable as it negates year over year investment in SharePoint.
Darrell:
Oh, if only a petition would sway those folks in Redmond. They have heard loud and clear from many people how the community feels about this (read through the TechNet forum thread in my post), and I don’t think they are going to change anything based on that input.
M.
A few of our SharePoint developers have a couple of workarounds that they use to deal with the loss of the missing design view in SharePoint 2013. Take a look and see if they can help.
http://www.theunbounded.com/sharepoint-designer-2013-where-did-split-design-view-go/
Why on earth did Microsoft leave Conditional formatting controls in SPD 2013 if they have no intent of allowing us to use them? I understand they want to push SPD into Studio as they have done with InfoPath, and that’s fine if they tell me how to get the same results as I achieve in SPD 2010. Our company passed down to use SharePoint with as much out of the box functionality as possible and move away from custom code. Now I have to go tell them that this is no longer possible as eventually everything will be in Studio. They are already looking at alternatives.