3 minute read
[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?