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?



SPTechCon Boston 2012 Follow Up

SPTechCon Boston 2012The SharePoint Technology Conference (SPTechCon) has always been one of my favorite SharePoint conferences. It was the first big conference I ever spoke at, and the folks at BZMedia(where’s Katie’s photo???) who put it on are all aces, every single one of them.

I only did one session at the latest iteration in Boston because I totally forgot to submit anything before the deadline. On the day of the deadline, I begged a little bit and David Rubinstein relented and slid me in. Since it was almost literally in my backyard, I didn’t want to miss out! Next time in San Francisco, I hope to do a workshop or two as well as some “regular sessions”.

My session in Boston was one that I’ve been doing different versions of over the last year or so called Flying in the Cloud: New Ways to Develop for SharePoint. It’s different every time because I am always adding new examples based on the client work I’ve been doing.

In the session, I talked about some of the ways I’ve been building things in SharePoint way back to the early SharePoint 2007 days, when I worked for what I call Jornata I (ask Scott Jamison or Mauro Cardarelli about those heady days). To me it’s not a new way of working, but with SharePoint 2013 coming along with its new app model, it’s becoming almost fashionable to use things like jQuery, Web Services, DVWPs, XSL, and CSS. You know, that “no code” stuff.

If you’re interested in the demos I showed, I’ve packaged them into a couple of WSPs which you can download and instantiate in your own environment if you’d like. Additionally, for each of the examples, I’ve done other blog posts which describe what I did and how they work, along with the code. If you can’t find the posts, feel free to ping me via the contact for or on Twitter (@sympmarc) and I can shoot you a link for what you’re looking for.

The SharePoint 2010 “List View Lookup Threshold” and Why We Don’t Change It

I’m a huge fan of Lookup columns in SharePoint. Choice columns just don’t give me enough oomph, and Managed Metadata Columns give me plenty of oomph, but not all that I need.

With Lookup columns, I can lookup into the Title of a reference list, but also store additional information in that list which is associated with the values. SharePoint 2010 gave us the ability to “drag across” additional columns from the reference along with the “key” column (usually the Title if you have good data normalization).

So I can build reference lists that have additional columns that I want the user to see (like perhaps the client’s location in addition to just their name) and columns I don’t need them to see (like a SortOrder column I can use when I build displays in a DVWP).

However, there’s a limit on the number of Lookup columns you can have on a list. That limit is 8, and those in the know, like my pal Bjørn Furuknap (@furuknap), say that even that many lookups can be a bad idea due to the performance impact. To me, this is a ridiculously low limit, but it is what it is.

Today I went scrounging for information on how I might bump up the limit and I convinced myself that I should never touch the setting based on what I read in a white paper from our pals at Microsoft.

If you look at the section with the heading “Lookup columns and list views” (reproduced below), you’ll see that bumping up the 8 lookup column limit is a Very Bad Idea.

Should you choose to bump it up anyway, it’s a Web Application setting you can get to in Central Administration: Central Administration > Application Management > Manage Web Application > Your Web Application > General Settings > Resource Throttling.

In my particular case today, I’m relegated to using some combination of Lookup columns, Choice columns, and Managed Metadata columns. The trick will be to decide for each lookup value which causes me to give up the least in terms of flexibility.

Here’s my take on the benefits and drawbacks of each:

  • Choice columns are best for lookup values that change very infrequently and for which we have no need to store any additional data. Choice columns usually can’t be managed by end users, since they are stored in the list settings. Choice columns cannot be shared across Site Collections unless they are a part of a Content Type in the Content Type Hub.
  • Lookup columns are best for values we want to reference, but where we also want to store additional data, like Client City on the Clients list. Lookup columns are also nice since we store the items in a list and that allows them to be changed easily by end users. This can also be a drawback if you don’t lock them down well enough. Lookup columns cannot be shared across Site Collections unless they are a part of a Content Type in the Content Type Hub.
  • Managed metadata columns are best for hierarchically arranged data that doesn’t have to have any additional data associated with it. Managed metadata can be shared across Site Collections. I’ve always found the managed metadata implementation to bit a bit too obtuse, and have hoped that vNext will make it work much better from an information architecture perspective.

Tradeoffs stink.


Lookup columns and list views

Each lookup column in a list view causes a join with another table. Each additional lookup column in a view increases the complexity of metadata navigation and list view queries. In addition to standard lookup columns, single-value managed metadata, multiple-value managed metadata, single-value people and group columns, and multiple-value people and group columns count as lookup columns. Adding lookup columns to a view does not cause a gradual or linear decrease in performance, rather performance is somewhat stable until after eight columns when it rapidly degrades.

The following graph shows the change in throughput as the number of lookup columns in a view increases. As you can see, the change in performance from zero to eight is rather stable, but at 10 lookup columns throughput greatly decreases. This test was performed with the list by using only one row. If a list is row wrapping, then performance degrades faster.

Chart showing lookup columns in a view throughput

The following graph shows SQL Server CPU utilization as the number of lookup columns in a view increases. As you can see, there is a significant change at 10 lookup columns. For a list that has a large number of queries, having views that contain more than eight lookup columns causes the queries to use a disproportionately large amount of SQL Server resources. We recommend that you do not change this limit to be more than eight.

Chart showing SQL CPU utilization - lookup columns

Although this decrease in performance is not for the total number of lookup columns on a list, only for the number of lookup columns in a view or query, SharePoint Workspace cannot synchronize any list that has more than eight lookup columns. This is regardless of whether the columns are used in a view or not.

List view lookup threshold

Default: 8

Existed in 2007: No

Configurable: Yes

Configuration location: Central Administration, per Web application

Software Development Literacy – Wave of the Future or Doomsday Device?

A few months ago, I read a newspaper article – which unfortunately I can’t find – about the idea that software development literacy may someday seem as normal as reading literacy is today. I didn’t think it was far-fetched at all. In today’s world *everyone* touches a computer in some way, even if it’s only the chip that runs the fare collector on public transportation. (This isn’t a discussion about rich and poor – I tried to come up with the most benign example I could. Admittedly, it’s more a first world example.)

Today there was an article in the Boston Globe about a company called FreeCause here in Boston that is doing something unique. The story explained that…

…29-year-old company chief executive Michael Jaconi told all 60 of his employees that they had to learn the programming language JavaScript. The idea is not to turn everyone into an engineer, but to give employees — from accountants to designers to salespeople — a better understanding of what goes into developing the company’s software.

Jaconi’s initiative is a recognition that technology has inserted itself into almost every aspect of modern life, and it’s a subject people increasingly need to know. In many companies, technology often creates barriers that separate technical from nontechnical workers.   “There’s a pretty big divide between engineers and nonengineers, and what I wanted to do was bring those two camps closer together,” said Jaconi, a serial entrepreneur and former political campaign worker who is learning to code along with his employees. “I thought that this would facilitate more efficiency, bring teams closer together, and ultimately make our company perform better.”

Oddly, unless I’m really out of it, there’s a bug in the example the article showed in one of the accompanying pictures. Bonus points if you spot it.

Learning JavaScript

Image from the Boston Globe Web site

I tweeted a link. (Through the wonders of HootSuite – the awesome social media tool I prefer over all the others – I also posted it to Facebook and LinkedIn at the same time.)

The fastest response I got on Twitter was from my friend Dan Antion (@DAntion):

I expected I’d hear something similar from a good number of the developers who follow me on Twitter, and eventually I did hear from quite a few with what amounted to disparaging comments about the idea. At best they were, like Dan’s, a sort of “uh-oh”.

I think it’s more complex than that initial reaction and also more important. Let me explain my thoughts.

As a consultant, I am paid to be an expert in some things. What many of my clients don’t realize, though, is that because I don’t specialize in any particular industry and I’ve been in consulting a very long time, I also have to know at least something about a lot of things: car manufacturing, stock trading, theme parks, higher education, pharmaceutical discovery, and the list goes on. (Those are all examples of real projects I’ve worked on over the years.) I have enough humility to know that I’m not an expert in fields out of my chosen one, but I have to know *something* about others in order to advise in a useful way and to write useful solutions.

Think about your major in college. Do you “do” that thing now as your everyday activity? I majored in Mathematics, and it’s pretty rare that I “do” math. I studied all kinds of things in college: psychology, chemistry, film making, rocks for jocks [geology], etc. I don’t “do” any of those things on a daily or even yearly basis. But I’ll argue with anyone who says that a liberal arts education – wherein one studies a wide range of things – doesn’t add up to a well-rounded, multi-talented individual. (Full disclosure: my major was actually called “Computer Mathematics”. The last time I came up with an interesting, computer-based  way to factor primes was in college, though.)

Another thing I’ve seen over my years of consulting is that, generally speaking, the teams that I’ve seen be most effective share some traits. They are usually cross-functional, highly motivated, and inquisitive about each other’s knowledge. I’d take a team with those traits over specific, homogeneous knowledge any day. Note that I mentioned “inquisitive about each other’s knowledge”. That means that they want to learn a little something about what the others know. This helps them to work together more effectively.

As software development becomes more and more pervasive, what’s wrong with everyone having basic literacy in it?

We might be able to interact with technical customer support better. We may be able to understand what to do or not do to avoid infecting our computers with viruses. We may be able to save unending time by not doing things that cause our work to be lost, requiring us to recreate it. We might understand what we’re asking each other for just a little bit better, making us more able to collaborate on the important parts of the task at hand rather than level setting every time.

Simple programming knowledge (I almost said “basic programming knowledge”, but that would be too specific) is an excellent idea. To apply knowledge management principles to “using a computer”, if we can identify what the key things the high performers know that make them good at it and can teach the low performers just a scintilla of that knowledge, everyone’s competency rises. By knowing something about what’s going on under the hood, I posit we all become better digital denizens.

Also note that nothing in the article said that the accountant or the salesperson has to become a software developer. They just have to learn the basics – enough for “every FreeCause employee develop a product such as a Web page or toolbar component that could potentially be integrated into the company’s loyalty rewards software.” That’s potentially. Not definitely, and not absolutely.

I’m going to go with Jaconi’s idea as a wave of the future, and one I welcome. There’s plenty of other stuff to worry about in the doomsday category, and this isn’t one of them.

Enhanced by Zemanta

Refreshing a Web Part Without a Postback Using jQuery’s AJAX Function

I’ve been working on several projects with good old SharePoint 2007 (MOSS). jQuery and jQueryUI sure can spice it up nicely. Recently, I decided I wanted to refresh the contents of a Data View Web Part (DVWP) based on a user selection – a simple click on one of a big set of links – but I wanted to avoid that clunky postback.

SharePoint 2010 has the ManualRefresh capability baked right into DVWPs, but not SharePoint 2007. Besides, I wanted both the trigger for the refresh and the UX to work differently than the rather utilitarian (and never used in my experience) out of the box feel that 2010 gives you.

This is the script I came up with. In this case, I decided to show a nice message in a modal dialog using jQueryUI while I waited for the .ajax() call to complete, as I’m using an AggregateDataSource that is querying several pretty large lists. This means it takes a few seconds to come back, and the dialog saying what’s going on – not just a spinner – makes the UX more palatable.

Refreshes an element's contents on a user action, showing a modal dialog during the refresh
elementId  The id of the container element
qs         The Query String to append to the current URL
title      The title to show for the dialog
msg        The message to show in the dialog

function refreshElement(elementId, qs, title, msg) {

  var elementObj = $("#" + elementId);
  var infoDialog = $("<div><div>" + msg + "</div><div class='aaa-please-wait'></div></div>").dialog({
    open: function(event, ui) {
      $(".ui-dialog-titlebar-close").hide();  // Hide the close X
      $(this).css("overflow-y", "visible");   // Fix for the scrollbar in IE
    autoOpen: false,
    title: title,
    modal: true

  elementObj.fadeOut("slow", function() {
      async: false,
      url: window.location.pathname + qs,
      complete: function (xData) {
        newHtml = $(xData.responseText).find("#" + elementId).html();
  }).fadeIn("slow", function() {

I made the function pretty generic so that I could pass in the four arguments and use it in multiple locations if I needed to. You could really pass in the id of any element in the page. In the instance I built it for, I was passing a new value on the Query String based on what link the user clicked on, but fetching the same page with AJAX. The DVWP was set up to return different data based on the Query String parameter value.

Keep in mind that both jQuery and jQueryUI must be loaded for this to work.

The CSS for the body of the dialog is pretty simple, but here it is. The sizing worked well for me based on the image I decided to display.

.aaa-please-wait {
  background-position:center center;

What do you think? Would this make a good addition to SPServices? If so, what other options would you like me to include? If I did add it to SPServices, I’d remove the dependency on jQueryUI, as I don’t want any outside dependencies other than jQuery itself.

Enhanced by Zemanta