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]
I’m with you Marc. Losing the Design/Split view has taken the *ease* of use out of SPD (SharePoint Designer). If the real reason Microsoft pulled this from SPD is because of a “MySpace” problem, then their resolution is atrocious. It’s never been easy and I mean *pea-brain easy* to have granular security controls over SPD. Building something like a SPD Management Interface would have been a more effective approach. Currently locking down SPD with granularity sucks, at best.
If pulling Design/Split view is due to technical challenges or Microsoft’s way of embracing more up to date standards, ( *ahem* JS or any other client side tech ) then I completely understand.
Pretty sure it’s due to the latter… I asked you a while back how Microsoft would upgrade from XSLT 1.0 to XSLT 2.0 and still maintain backwards compatibility. I didn’t think it was possible and maybe this is the result of the technical challenges that Microsoft had to create an answer for.
All in all, I feel you’ve done a bang up job documenting the necessary XSL(T) to create DVWP’s. So I would expect your blog to have a lot more hits in the future as developers move their solutions away from DVWP’s. :-)
Cheers,
Matthew
If Microsoft isn’t going to listen to their MVPs then they aren’t going to listen to anyone unfortunately. Myself, I’ve been moving farther and farther away from the DVWP but it’s unfortunate it had to be this way. Clearly client-side is the future, and we all understand that, but it’s ridiculous that we as implementors and creators don’t get the choice of how to develop our solutions, especially considering the large base of people that already use the DVWP every………….single…………… day.
What this really has done is make SharePoint designer almost useless. For many, now it’s a Visual Studio world and that’s just the reality. Since the 2013 preview came out, I haven’t opened SPDesigner more than a handful of times and I guess that’s the way Microsoft wants it.
Clint:
Unfortunately, moving the type of development we have been doing in SharePoint Designer into Visual Studio simply isn’t feasible for many shops. Either the prohibitive cost of Visual Studio seats or the existing governance (which often prohibits server-deployed code) will get in the way. Large Microsoft customers – who Microsoft tends to service to the detriment of everyone else – will be able to absorb the costs and their governance probably won’t get in the way. Many, many medium to small organizations, however, have been relying on SharePoint Designer-based development for *all* their enhancements.
M.
Why would anyone expect a continuous positive slope of enhancement??? We all have seen it countless times in the past.
Capability (A) is enhanced, now Capability (B) no longer works, UNLESS, it’s Tuesday with a full moon. Analogously , it’s like trying to pull a string at both ends through a tube, but the string is the same length as the tube. You get one side out but now the other has dissappeared.
So maybe Microsoft is trying to steer us away from XSLT. It’s a nice language but really confusing at times because of the “add-in” functions, namespaces to employ those, and just the recursive nature of the syntax. If we move toward a js/jquery friendly world and those webparts speak that — that would be better. So someone just needs to write a translator for existing DVWP, DQWP, CQWP, and LVWPs to this js/jquery syntax using HTML5 and then have a visual editor with SPD like features to write out the new constructs. I recommend using MVVM with knockout and jquery and CSOM.
Could that be done? Lightning Tools, Bamboo, etc you’re up at bat :)
Brian:
Whether or not you like XSL, it’s been a stock tool for SharePoint for all of its incarnations to date. Moving from XSL to something better is an admirable goal, of course, but we have to have a migration strategy for it. That’s what’s missing here.
If some third party can come up with a magical translation machine that turns XSL into client side script, that would be grand on the one hand. Who knows how long it’ll take before something like that is avialble, though. It’s not clear to me that there’s a revenue model there that will drive one of the vendors to build it, as it will be a tough one to get right. I expect that Microsoft has its collective fingers crossed in hopes of just that, though.
I’ll stick to my opinion that this wholesale move to client side processing is a mistake. We should be able to balance the processing in some way, like the DVWP enables us to do now.
M.
@tigertoy
In my opinion, most of this work is already finished by Dustin Miller:
http://blog.sharepointexperience.com/2012/03/06/introducing-the-magic-data-view-builder/
It still emits XSL, but *someone* should be able to take his work and build upon it. Maybe turn it into a jsfiddle or jsbin of sorts.
This may end up being the defacto way of building your JS templates in the future.
Well there you go. Dustin solved the issue. You don’t need Design View if you use his MDVB tool. I always thought Designer created way too complicated XSL. I remember when I wanted to make a certain column sortable. I had to tear apart the template just figure out where to inject my code. We just need to advertise and publicize this MDVB like we do SPServices.
Does the ‘Magic’ builder support site aggregation?
Not to my knowledge, but neither did SP2010 for the most part. That little beloved hyperlink was clipped in SPD 2010. You *could* always dive into the code it produces and tweak accordingly though…
Thanks for sharing the Magic Dataview Builder. That really helps.
Time to get working on that magic data-view webpart builder v3!
VS 2012 with Blend is an awesome duo and great for previewing design. While I haven’t tried using it for Sharepoint 2013 (yet), maybe the team removed the preview for that reason?
Christine:
If that’s the new paradigm, it would be nice if someone from Microsoft made it clear that was the path forward. However, I don’t think that helps us with the non-design aspects of SharePoint Designer work. It also means an expense for two products over one free one. Hmm.
M.
Yeah, the design view has bring forward the people that uses SharePoint to start building no code applications or starting of with branding. So far I can not see any equivalent option for these people. I will really miss the design view, but let’s hope for new opportunities with new technologies ahead.
Great post Marc,
I had the same jaw dropping experience when I first started working with Designer 2013. I’m right there with you on all points. I’ll deal with the code view in 2013, I’ve spent years entrenched in it anyway since 2007. But I have so many clients that would refuse to upgrade to 2013 strictly because of the loss of user-empowerment.
I’m glad ‘m not the only one that sees the contradictions here… The design manager is a joke to people like us.
I’ve known for years that SPD filled a very large niche that MS seemed to overlook this whole time. Now we get to deal with the repercussions.
Interesting that I just read this post today. Like many others, I fall in the ‘power user’ range when it comes to development with SharePoint. I have experience developing solutions in managed code, developing solutions using XSL and DVWP’s as well as solutions which leverage SPServices, knockout.js and other frameworks.
In my company, I can’t touch managed code right now and will never be allowed to get anywhere near developing a solution. The closest I got was developing a solution on my local dev environment then sending the code to my internal IT who then used the code in their solution.
There are different options available for any given need. XSL and SPD Design view just happens to make getting some solutions off the ground a bit easier. Like Marc mentioned, setting up the data source, parameters, web part connections, filters, conditional formatting and more are all made easier by SPD. Does this mean I don’t know EXACTLY what code SPD is including? No, I could write the code myself and there are cases where the design view does not even provide the options I need. But then there are days like today. I have to develop a very complex form for a list which I could have done one of two ways. I could either use XSL and formfields. One thing I needed, was the fields themselves. While I know XSL well, I am not to keen on manually figuring out something like:
With design view, I can get all of those fields quickly and easily. Without it, I am left with option 2, build up the form using knockout.js and hook it up to SharePoint using COM or SPServices. I can do a lot that XSL allows (there are still some things that only XSL can do because it is server side) but it will take me a lot longer to build. That or I need to use infopath.
This is just one example. I know how to code XSL by hand, but the assistance that SPD provided helped speed up the process. This is like going back to the old days when all of the WYSIWYG HTML editors created horrible code so notepad was the best option. With the new SP2010 XSLTLVWP I already find myself coding xsl by hand for XSL overrides.
People like to call us ‘power users’. We are developers, just in different languages.
It still makes me wonder, why ADD SPD features like ‘edit view in designer’ in 2010 then strip them for 2013.
And one day later, I think I am going to change my solution previously mentioned back to a pure Javascript html solution using SPServices. There are plenty of benefits of using XSL but one huge drawback is some of the horrible html tables and CSS classes which are pushed onto my code. It makes it a huge pain to develop a nice looking form.
I am the same…I am just trying top update some workflows and pages and it plan doesnt work. I am fuming