Today the SharePoint Mobile App Comes to iOS

One of the big May 4th announcements comes true today, with the release of the Microsoft SharePoint app on iOS. (Yes, we iPhone folks get to have most of the fun!) Read all the details about the release on the Office Blogs.

In case you missed the details, the Microsoft SharePoint app for iOS puts “your Intranet in your pocket” – though it’s probably more useful in your hand. Here are a few views of the app from the Office Blogs post. 
SharePoint appThe version they’ve release today looks a little bit different than the May 4 screenshots, but the basics are all there: Sites, Links, and People. I expect we’ll see continuous and rapid improvement on the app going forward, so keep an eye on it!

Learn more about the new SharePoint mobile app in this video, which was released for the May 4 event:

Dear Microsoft: Please Listen to Us About the New Document Library “Experience”

One of the latest hubbubs in the Office 365 world is around the new Document Library “experience”. (I refuse to use the word “experience” in this sort of context without a little sarcasm and some air quotes.)

There’s a new “experience” coming to Office 365 that makes Document Libraries look a lot like the OneDrive browser UI that some of you must use. (I prefer to use a synced folder on my devices to interact with OneDrive – when syncing actually works.)

In case you haven’t see the new “experience” yet, here’s how it goes. Here’s a very simple Document Library in our Sympraxis tenant.

2016-06-16_10-12-36

When you go to a Document Library for the first time after the functionality hits your tenant, you can choose to walk through a Motherhood and apple pie set of intro screens that show why the new experience is swell.

New Document Library "Experience" Prompt

2016-06-16_10-08-59

2016-06-16_10-09-15

2016-06-16_10-09-30

2016-06-16_10-09-43

And after clicking on “Let’s get started”, you see the new “experience”…

2016-06-16_10-11-58

 

Note the small link at the bottom left that lets you switch back to the “classic” view – for now.

The issue isn’t so much the new “experience”. I do think since people hate change, it’ll cause a lot of discomfort in many organizations, especially since it’s roaring into all tenants. In fact, the new capabilities are indeed swell. The issues are around existing customizations to the branding of functionality of Document Library views.

If you’d like to see what’s got people upset about it, you can check out the UserVoice item Allow Javascript customization and CSS branding/theming in the new Document Library Experience. There’s also a very long thread at the Office 365 Network in Yammer about it.

I do think the “Working on it” message in the UserVoice entry should give some hope. Microsoft knows there are issues. If they can’t address them and others like them, the flow to Office 365 will reverse back to on premises. What I think sows a lot of Fear, Uncertainty, and Doubt about this is it feels – yet again – like it could be a slippery slope.

Document Library default views are often built into what amounts to applications, or at least launch pads into application. It can be anything from simply adding some explanatory text in a CEWP at the top of the page (which is, after all, a Web Part Page) to full fledged functionality provided by additions of JavaScript using jsLink, DVWPs, JavaScript, CSS, etc. In many cases, the view page ends up looking little like what it started out as.

There simply has to be a way to keep these view pages in the mix, as considerable investment of time and money have gone into them. One would hope “telemetry” will show many people *choosing* to stick with “classic” (in this case meaning “functional” and “useful”) mode pages, even if all the “Working on it” stuff happens.

What I’m asking for in this post (Are these Dear Microsoft posts of mine merely rhetorical? I hope not.) is for a sincere attempt to hear what the concerns are. There are many times where people are feeling like a change to something new risks removing some of the exact reasons why the SharePoint platform has been successful in the past. Running Office 365 as a service can indeed be at odds to the successful methods used in Document Libraries, but understanding how to continue the exact patterns of enhancement that were encouraged in the past – by Microsoft- is critical.  Change can be good, but not if it undoes past investment and successful implementation.

I like the image that Brent Ellis (@Brentless) posted in the Yammer thread:

Do No Harm

Software development isn’t medicine, but still…

SPC Adriatics 2016 Follow Up

One of the best parts about my job is that I get to travel to exotic locales to talk about SharePoint. My most recent jaunt was to the fine country of Croatia to attend SPC Adriatics. Every conference has its own personality, and SPC Adriatics is know for being fun and filled with meat. Who wouldn’t go?

20160530_191516407_iOS

The triumvirate of organizers – Toni Frankola (@ToniFrankola), Adis Jugo (@adisjugo), and Nenad Trajkovski (@ntrajkovski) sure know how to put on an event. They were ably helped this year by the talented Branka Obuljen Štritof.

SPC Adriatics Speakers

Unfortunately, I was sick in bed for Day One of the conference and still off my game for Day Two when I did my two sessions. I apologize to everyone who attended my sessions for not turning in a better performance. I hope I’ll get another chance to visit Croatia and do a better job.

Regardless, here are links to the two slide decks I presented.

Dear Microsoft: Remove the 5000 Item Limit for SharePoint List Views

It’s 2016. In 1993, I used Microsoft Access to process over 1,000,000 records of data to implement a product profitability model at Staples – on an IBM 486 machine.

SharePoint-List-View-ThresholdWe’ve been saddled with a 5000 item limit for views since SharePoint 2010 launched. Oddly, in SharePoint 2007, there was no such limit. When 2010 came out, with its requirements for heavier and beefier hardware, the limit showed up.

I’ve read (well, skimmed) the white papers about why this needs to be. I’ve had long conversations with people in the SharePoint Product Group about the technical debt involved and why it is a “hard” thing to fix. I’ve read the highly visited KB articles about it, like “The number of items in this list exceeds the list view threshold, which is 5000 items” error when you view a SharePoint Online list in Office 365 Enterprise.

Bill Baer (@williambaer) has posted some promising messaging about the thresholds (See: Navigating List View Thresholds in SharePoint Server 2016 IT Preview), but I still don’t see any outward evidence that the limit is going away anytime in the foreseeable future.

I think there have been mixed messages and misinterpreted messages (no blame to Bill). The auto indexing idea which was recently added to Office 365 and comes in SharePoint 2016 (I believe – but I’m not positive) was misconstrued as lifting the 5000 item limit, which it definitely doesn’t.

The 5000 item limit in the UI for lists and libraries is arguably a good thing. There is absolutely NO reason to show more than 5000 items on a view page. Ever. No one can digest that amount of data or make use of it. Views should show just enough information for people to make good decisions about what to do next. (This is a very common mistake in SharePoint information architecture.) There are times when we simply need to have a view which derives from 5000+ items, though. Remember what year it is; 5000 items is a speck, a mote, an iota of data in this Big Data era.

No 5000 item limit

When it comes to calling SharePoint’s APIs, the 5000 item limit simply has to go. It’s a crazy limit in this day and age. I don’t care about all the technical debt talk about it. The SharePoint Product Group should be able to slide a solution underneath, at least on Office 365 – but ideally in on premises versions of SharePoint as well.

That’s the whole point of APIs: you can fix stuff under the hood without breaking any “contracts”. As more and more processing moves off-SharePoint, the 5000 limit is stifling. It’s been a problem for me for years because I live on the client side. I don’t always need all 5000+ items, but I need to know stuff about them: how many items match some criteria, what the sales total is for 12,834 items, how many items fall into a set of groupings, etc.

Whatever approach the Product Group takes shouldn’t matter, as long as they uphold the API contracts. For years they have told us – very rightly – that touching the underlying SQL tables puts us in an unsupported state. As long as we’re calling the APIs, what happens under the covers doesn’t matter. In fact, most of us should care less; that’s Microsoft’s domain and we should leave it to them.

With the new SharePoint Framework (SPX?) coming along – which I think is a TREMENDOUSLY good thing – the 5000 item limit is going to be on the minds of every developer who works with SharePoint. There will be no more server side tricks to haul out to cheat your way around this stuff. Those tricks have been reduced in degrees anyway. If SharePoint is to truly be treated as a service (as I firmly believe it should) then it needs to behave like a service in 2016+, not a service in the 1990s – or earlier.

I’ve heard many people – my fellow MVPs included – say that Microsoft will never fix this. There’s no cool Marketing moment in it, no splash they can make at a conference, little to show in the UI for it. But think of the consequences if they DON’T fix it. How long can we continue to believe that we can pump millions of items into a list (which is the true capacity) only to be told that we can only retrieve fewer than 5000 of them from the client side?

Unfortunately, if we assume they won’t fix it or can’t do it right, then the SPX may be doomed, IMO. I’d prefer to believe that they know it has to be fixed and are working on it. As my friend Jeff Shuey (@shuey) is always saying “I want to believe!”


If you want Microsoft to hear your vote on this idea, check out any or all of the feedback below ion the SharePoint UserVoice site:

  1. Remove 5000 item limit
  2. Provide a list limit over 5000
  3. Remove the list view threshold (5000 by default)
  4. Default notification for lists and library’s hitting the 5000 items limit
  5. Remove the limit of 5000 items as result in a view
  6. Allow new library look for libraries over 5000 items (provided the structure in managed correctly)<

Making Your REST Calls Simpler by Changing the Metadata Setting

When you talk to SharePoint using REST, you have some options about what the data you get or send looks like. Early on, when REST first arrived on the scene for SharePoint, we HAD to specify odata=verbose. This meant that we had to be very specific about what our data was going to look like, especially when it came to updates.

If you don’t use odata=verbose, then you’re telling the server to accept something different. You’re basically telling the server what “dialect” of odata you are choosing to speak for the current transaction.

If you look at this post, you’ll see the options:

JSON Light support in REST SharePoint API released

Just to recap, the options are:

accept: application/json; odata=verbose

This is probably what you’re used to, and requires the heaviest payload. Using this option, you’ll get the maximum amount of information about the data coming your way, and you’ll also have to send more as well.

accept: application/json; odata=minimalmetadata

This is the middle ground. You’ll get some metdata, and you’ll also need to send some, but it’s less.

accept: application/json; odata=nometadata

This option means we won’t get any metadata and we also don’t have to send any.

accept: application/json

If you don’t specify the odata setting at all, it will default to odata=minimalmetadata.

You can use these settings both on the inbound and outbound part of your REST calls.

Content-Type: "accept: application/json; odata=minimalmetadata"

means that you are sending data that contains minimal metadata.

Likewise,

Accept: "accept: application/json; odata=verbose"

means that you want to receive data with full metadata information.

In many cases, you’ll want to use odata=verbose as you’re debugging and switch to odata=nometadata once you move into production. The metadata tells you a lot about the data coming and going and can be helpful as you build up your calls. If you don’t make that switch, there will be more data going down the wire, though in many cases that doesn’t matter too much. Since I learned to code back when nibbles were expensive storage, I tend to want to reduce data size as much as I can, though.

Unfortunately, I don’t think many SharePoint developers realize what all this can do for you. I hear people say all the time that REST calls are too “chatty”. In many cases, that’s simply not true; you developers are making things too chatty!

This allows you to switch from something like:

var data = {
  "__metadata": {
    "type": "SP.Data.FC_x0020_RunsListItem"
  },
  "Title": run.RunID,
  "RunDate": run.RunDate,
  "OperatorId": run.Operator.Id,
  "DataIDs": dataIds.join(","),
  "FCData": angular.toJson(run.samples)
};

var request = {
  method: 'POST',
  url: url,
  data: JSON.stringify(data),
  headers: {
    "Accept": "application/json; odata=verbose",
    "content-type": "application/json;odata=verbose",
    "X-RequestDigest": document.getElementById("__REQUESTDIGEST").value,
    "X-HTTP-Method": method,
    "IF-MATCH": "*"
  }
};

to:

var data = {
  "Title": run.RunID,
  "RunDate": run.RunDate,
  "OperatorId": run.Operator.Id,
  "DataIDs": dataIds.join(","),
  "FCData": angular.toJson(run.samples)
};

var request = {
  method: 'POST',
  url: url,
  data: JSON.stringify(data),
  headers: {
    "Accept": "application/json",
    "content-type": "application/json;odata=nometadata",
    "X-RequestDigest": document.getElementById("__REQUESTDIGEST").value,
    "X-HTTP-Method": method,
    "IF-MATCH": "*"
  }
};

This is a real example from some of my code in a client project. It may not look like a huge savings, but if you are passing a lot of data either way, it can make a difference.


UPDATE on 3 May: Tip from Mikael Svenson (@mikaelsvenson) – If you’re running on premises SharePoint 2013, you may need to enable the multiple metadata formats for JSON. See: