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:
- 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.
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.
Marc,
I agree that it’s time to start thinking about the options. My current vision is that it is a story about Microsoft Visual Studio. I created a couple hello world apps from Windows 8 connected to Office 365 Preview on Sunday and it is looks like it could have broad appeal. One barrier to SharePoint Developement in the past was the 1:1 need for a SharePoint Server installation per developer. The App Model may finally be the way to overcome that. In the end, maybe it will be better than DVWPs.
Tom
Tom:
Which still leads to the “hire more developers” conclusion, unfortunately. Smaller shops that have avoided “code” will have no recourse but to take on a larger development budget.
M.
Marc,
If you think developers are bad, you’re talking to the wrong person. In my mind, broadening the developer base for a product is exactly in line with Microsoft’s past successes. Think Basic in DOS, VB in Windows. Designing apps for Windows in Visual Studio is easier for many than adding and configuring a data view web part in SharePoint Designer. More SharePoint Developers is a step forward, not a step back.
Tom
Tom
Your rationale is good, not just because it forces companies to be more serious about their development work, but also because it is a clear message to developers who have been too lazy to properly learn what they do. I’m not trying to undermine anyone, but I think that forcing developers away from the “Look, here’s how easily I can drag-and-drop a critical business solution into production” paradigm can’t be bad.
It will cause some tears and bruised egos, but as essentially its parents, Microsoft needs to take steps to protect its SharePoint child. Jeff Teper calls it the “Myspace problem” which I think perfectly illustrates the problem with making development too easy.
On the other hand, Microsoft is also adding Apps that speak to a new generation of “look, ma, no hands!” developers. It certainly isn’t any safer neither to SharePoint nor is users and it certainly isn’t more efficient. Instead of one server rendering code once, 10,000 clients will do so every time they hit the page. I can hear Greenpeace screaming already.
The new Apps model has the added consequence that existing SharePoint developers will be as green as anyone else so the code base will likely be horrible for a long time. It’s not that 9 years of Visual Studio coding has produced any reasonable patterns or uniform practices. Throwing another paradigm won’t help with producing more stable SharePoint code, it’s quite the opposite.
So, I don’t think we have a bright future ahead of us, whether we’re existing developers, aspiring developers, users, or environmentalists.
.b
Tom:
I don’t think developers are bad at all. (Remember that I’m a developer, even if some people don’t think I’m a “real” one.)
My point is more that SharePoint is one of the first platforms I’ve ever seen that truly has enabled the citizen developers out there to solve their own problems. They’ve taken their needs into their own hands and built solutions that have worked to solve their business problems. This is often behind IT’s back or with IT’s explicit knowledge because IT doesn’t have the resources to support them well. If we disable those citizen developers, then IT has it thrust back on them with no more resources. They will have to staff up to just stay afloat.
In other words, removing SharePoint Designer as a viable development tool breaks something that fundamentally works.
M.
I’ll miss SharePoint Designer. And, there is no doubt in my mind you’re a developer despite what even you may say at times. ;)
However, with disappointment also comes new opportunity – for me, my clients, my online SharePoint buddies and occasional log ride companions like you.
I brought up Visual Studio because it’s long been a best of breed solution. SharePoint Designer was never in that league. Maybe more citizen developers will be empowered by a move to Visual Studio and Napa. Maybe not, but they will go somewhere and we’ll be watching.
You didn’t list the main move to the client side: in SharePoint 2013, all list views are rendered via JavaScript. In SP 2010 it was only the case for special views like calendars and Gantt, and in SP 2007 everything was server side (remember these big table calendars?).
The “Data View Web Part” actually has two different roles: 1/ the connection to a data source and 2/ the conversion of xml into html via XSLT. You advertise “using a DVWP to do the heavy lifting of getting the initial load of data onto the page”, and I think this makes sense. But this is related to the data source role, it has nothing to do with a “design” view. For example you could simply use the DVWP to serve JSON, as demonstrated in a recent article on NothingButSharePoint.com.
I think today everybody pretty much agrees that XSLT is obsolete and should be replaced with JavaScript. LinkedIn for example has an interesting series on their blog about the move to the client side and the use of templating. Viewed from today, the XSL List View Web Part was clearly a step in the wrong direction.
Christophe:
I see what you are getting at, but I think there are a few flaws in your reasoning.
First of all, no Design View means no way to maintain the existing XSL-based functionality. Even if we all agree that XSL is going the way of the dodo, that problem persists. It’s either maintenance with Code View only or a total rearchitecting and rewrite.
Secondly, without the Design View, adding those DVWPs which can serve up JSON is going to be a real PITA. Try adding a DVWP with SharePoint Designer 2013, and you’ll see that without the Design View, you’re stuck. There’s no way to connect a DataSource without writing the code yourself. You also can’t see the results of what you are building as you do it. I’m assuming you mean that you’d hand roll the XSL to emit the test-based JSON. Have fun with that with no surface where errors can be exposed.
Moving to JavaScipt and client-side processing is great for people like you and me; we’ve been working that way for a while now. A lot of other people are going to be in trouble. Deprecating the Design View in this version but still including it or providing some way to work in an improved way would have been the right move here.
M.
Although I have been reluctant to comment too often on this decision by Microsoft, I agree that it is the wrong thing to do, and I finally see the road they should have taken in your last comment. “Deprecating the Design View…” would have been (perhaps will be…hint hint Microsoft) a better approach. If I was looking at that option, I could gradually get comfortable with the new mode of working, still maintain the solutions we have built and roll forward with a nice mix of, as you would say, middle-tier products.
Deprecation would be a kinder-gentler way of saying XSL is dead, or “we would prefer that you not touch what we gave you in the box.” The mix of development conduits in SP2007-2010 let me spread our development workload across a wider group of individuals. The people comfortable with Visual Studio are working on desktop and server side solutions. The people less comfortable in that realm are working in SP Designer. The half-code half-visual world worked well, and let someone more heavily bent toward design than development actually delivers a solution. Microsoft needs to provide a means for these people to continue their good work, and “become a programmer” isn’t the answer.
As it is, I fear we will simply delay our move to SharePoint 2013 until there is a better answer, or until some geek comes up with a hack or add-on that lets us work the “old” way or perhaps even the new way in something like Dreamweaver. This won’t hurt Microsoft, or even send a message to them since everything we own is under Software Assurance; it’s not like they’re losing a sale. On the other hand, every time you disappoint a major portion of your community, you hurt growth.
Marc, I was just commenting specific points in your post, I agree that there are other issues.
I am afraid Microsoft can’t just deprecate the design view. If they do that, they’ll get even more complaints that the new Web Parts offer no interaction in design mode. I think the only path forward is an upgrade, and this is a big endeavor.
As for adding new Web Parts, I’ll argue that there’s an interface for that. How do people add Content Query and Chart Web Parts to a page? Why is the DVWP not in the list? Just because the design view has been the only way to add DVWPs in the past doesn’t mean it’s the right way to do it. For the record my User Toolkit includes DVWPs that you can simply add to the Web Part gallery (of course the scope is very limited, but I’m sure Microsoft could do much better).
I am not sure what you mean by “hand roll the xsl” (and I assume you mean xml), but the idea would be to have a standard XMLToJSON routine… just like what you have in SPServices or what was published in the NothingButSharePoint.com article. Then you’d work with the DVWP the same way you work with the output of SPServices.
Maybe the transition is not easy, but people will have to do it because this is the way the new Web Parts work anyway (cf. the first part of my first comment). I wouldn’t be surprised to see in the next few months somebody publish an XSLT that generates SP 2013 JSON output (and this person could very well be you or me).
Marc,
I agree with you and for developers this is a water shed event; however, the main selling point of SharePoint for the places I worked for was the ability of users of varying degrees to be able to go in and (like you said) do what they needed to do. The move here is totally the opposite direction. With budgets already tight I can’t see the clients I work with that still have 2007 installed going to 2013 knowing that they will have to increase there developer pool. For me its a great thing but for any company considering it’s personnel and budget the best some may do is 2010.
Christophe – I have to disagree at the point where you say “but people will have to do it because…” This particular change pushes some people out of their comfort zone. The response isn’t going to always be “oh, ok I’ll do it that way now.” The response will be split between people moving more to the development side and people gravitating to tools and products that offer the ability to “easily” build the stuff we were “easily” building before. But, because not everyone is comfortable as a developer, and not every company can afford a lot of expensive tools, a third group will also emerge – the people who stop using SharePoint for these kinds of applications.
Depending on the availability and price of the tools, my group will land between the “tool using” and “not using” bands on the spectrum. The appeal of SharePoint was how easy it was to put information in front of my customers (coworkers and outside collaborators). I have lots of other options in that space, and I am going to go with what is easy to build and easy to use. SharePoint doesn’t have a lock on those applications. BTW, I still think tool vendors will save the day, but I worry about the cost of those tools.
Dan, significant changes push people out of their comfort zone, that’s the norm. You have certainly witnessed it yourself if your group moved from network shares to SharePoint.
Of course you can look at other applications, but… they’ll rely on JavaScript too, so you’ll have to make the move anyway. My point (cf. my first comment) is that it’s the whole world that is moving away from xslt. Microsoft made some unfortunate choices a couple years ago and drove some of us in a dead end.
When you talk about stuff you were “easily building before”, I hope you are not referring to editing xslt in SharePoint Designer? Half of Marc’s blog is about fixes for SharePoint xslt, while the other half is about bypassing it and using Web services ;-)
I hate Microsoft – so frustrated