Dear Microsoft: Confusing Failures in “Modern” SharePoint Libraries

Moving documents around in the “modern” Document Libraries in SharePoint Online (Office 365) has certainly gotten easier. Instead of opening libraries in File Explorer, downloading the files, and then uploading them into the new location, we have nice options like Move to, Copy To, and Rename right in the toolbar. That’s a big upside.

Sadly, there are downsides. While the new capabilities are awesome, I’m finding that the UI is often confusing – both to me and my clients.

When you use one of these new file manipulation capabilities, you get a little feedback message ion the right side of the toolbar telling you how it went. Unfortunately, the message location isn’t all that obvious, and it usually feels as though the operation succeeded even when it didn’t.

Here’s and example of a Move to operation that failed for me. Note that the message says “1 item wasn’t moved”.

There’s no other feedback, and on my wide monitor, the message is way over to the right side. I don’t usually notice it.

In the case above, I did see the message, so I clicked on the message to see what was up. The reason I saw it was that I was looking for something wrong. A client of mine told me that a Move to wasn’t working. Every time she went back to the library, the documents were still in the same place, no matter how many times she moved them.

As you can see from the expanded message below, there was indeed an issue: there was a file with the same name in the destination location. I have two logical options, either to Keep both files or Replace the original.

 

The message really isn’t obvious enough, and I’ve been caught many times because I didn’t see that something I did failed. Even worse, to my client “SharePoint is broken”. I’m hoping the Product Group can come up with a more informative way to provide the feedback that something has gone wrong – which happens surprisingly often!

There is yet another “unfortunately” here, though. In my client’s case, even when there is no error in a Move to operation, the files are boomeranging right back into the original position after a few screen refreshes.

I also tried the Content and Structure page to see if moving the document that way would help, but still no dice. I checked to see if perhaps there was a workflow in play here causing issues, but that’s not the case. The only other thing I see which MIGHT be a problem is that the library has 4988 documents in it, which is pretty close to the 5000 list view threshold. I hate that threshold with a steaming passion (have I mentioned that here and here and  here and here and here and probably tens of dozens of other places?), but I can’t think why it would matter in this case.

So we’re at an impasse. The error messages aren’t so great, and the Move to operations are failing when when there aren’t errors. Maybe SharePoint really is broken.

Anybody? Anybody?

Advertisements

Dear Microsoft: Please Fix Retrieving SharePoint Lookup Columns with REST When the Lookup List is in Another Web

I love SharePoint. I really do. I especially love writing client side code to build awesome applications for my clients.

Today’s annoyance, though, comes while I am in the process of rewriting an application I built on SharePoint 2007, porting it to SharePoint Online in Office 365. This ought to feel like a huge leap forward technologically, and in some ways it does. I’m changing all my SOAP calls with SPServices to REST calls. I’m switching from KnockoutJS to AngularJS, which will simply perform better given the profile of the applications. (KnockoutJS was the right choice years ago when I first built the applications, but the data and feature requirements have outgrown it.)

Unfortunately, I’m running into a simple constraint that makes my life a lot harder. When I first started building these applications five years ago, I created what I’ve got to say is a very solid information architecture. It’s withstood shifting needs and requirements in the interim, and I stand by it. One of the aspects of this good information architecture is storing commonly used reference lists in the root site of the Site Collection. By creating a Site Column which is a lookup into each reference list, I can reuse those common reference values throughout my subsites.

This works great in SharePoint 2007 with SOAP calls. When I retrieve items with one of these lookup Site Columns from a list in a subsite, I simply get the ID and Title values, separated by a “;#”. However, when I try to do the same thing with “modern” REST calls, I get an error like this:

I’ve been a good team player, and I’ve suggested they fix this on the SharePoint User Voice in my suggestion Enable support for lookup columns in other webs in the REST API. The votes are up, and it’s been a while.

There’s a workaround, but it’s not very pleasant. (The easiest workaround is to simply stick with SOAP calls and SPServices – I’ve done that in several cases in other projects. But SOAP is officially “deprecated”, so…)

Here’s a specific example. The client I’m working with is in financial services, and they issue recommendations on securities. Those recommendations are very standard, and predictable: Hold, Buy, Sell, etc. In other words, perfect to store in a list in the root site called Recommendations. Why not a Managed Metadata column, you might ask? Well, I also wanted to store several other columns in the Recommendations list, like Description (e.g., “The analyst expects the security to outperform their coverage universe.”), a SortOrder value so I could rearrange the values in dropdowns using SPArrangeChoices, and several other fields which drive configuration of some reports. In other words: great information architecture. The values are all consistent across the various subsites, I store them once, etc. Nice setup.

I created a Site Column back in the beginning called Recommendation, which is a lookup into the title column of the Recommendations list (Hold, Buy, Sell, etc.). I used that Site Column in many Content Types defined on the subsite level. Those Content Types are mainly used in a list I’ll call Notes.

In SOAP with SPServices, I can make this [simplified] call:

This retrieves the items and returns nice JSON for me. Because Recommendation is a lookup column, it comes back as something like “1;#Buy” and that’s easy to turn into a JSON object like:

Easy, peasy.

However, when I try the analogous call in REST:

I get the error:

In other words, there’s no way to $expand the Recommendation column because it comes from an other Web, even though that is ideal information architecture!

The workaround, which André Lage (@aaclage) pointed out in my UserVoice suggestion (but I clearly didn’t get at the time), is to simply ask for the Recommendation column’s ID instead. This isn’t obvious at all:

This doesn’t follow the syntax we’d expect: we need to append “Id” to the end of the lookup column’s InternalName. Of course, this just gets us the ID of the item in the Recommendations list; it doesn’t fetch us the Title value, which is what we really want. Because of this, I need to do a *separate* REST call to get the items from the Recommendations list and merge the values in my client side code.

Now, one could argue that this is more efficient. I don’t ask the server to $expand the values across thousands of notes (yes, there are way more than 5000; I’ve written enough about that lately – I may have mentioned it here and here and here and here), so it gets a break. Retrieving the 5-10 values in the reference list (in this case) is no big deal.

But I have a half dozen or so of these lookup columns to deal with in this application, which means a half dozen extra REST calls, plus the code to merge the values. More work for me, but more importantly a longer wait for the application user when they load the page. I believe that poor UX is what has doomed many a SharePoint roll out, and I loathe creating a poor UX myself. In this case, I’ll make it work, but I’d really like to see this change.

Customizing the Suite Bar Theme in your Office 365 Tenant

Part of a good user experience with software is feeling that it is our own. When it comes to SharePoint, which for many people is their Intranet or at least an important work environment, we almost always do some level of branding.

It’s hard to keep up with how we are supposed to brand our Office 365 tenants these days. We have “guidance” from Microsoft that we shouldn’t customize the master pages in our tenants now, and in fact the “modern” “experiences” that are rolling out don’t even use master pages to put together the rendering of the UI.

There are some simple things we can do starting with a vanilla Office 365 tenant to make it feel more like home, though, and they aren’t all that complicated. One of the easiest things to do – and with the widest reach – is to change the theme of the Office 365 suite bar.

By default, the suite bar looks like this:

Suite Bar Default
Making the suite bar your own isn’t that complicated, and this article from Microsoft explains it: Customize your theme in the Office 365 admin center. But I often need to explain these settings to clients, so I figured I’d write up what I tell them.

Here’s what our Sympraxis suite bar looks like:

Sympraxis Suite BarIt’s not fancy or anything, and we don’t mess with any of the components of the suite bar with CSS or JavaScript tricks. We know how to do these things, but it just isn’t worth it. It’s all done by making changes in the Office 365 Admin center.

tip
Note that you need to be a Tenant Administrator to work on these settings. Being a SharePoint Administrator is not enough: you’re changing the suite bar for the entire tenant: SharePoint, Exchange (Mail), OneDrive, even Yammer. I’ve found that the “stickiness” of these changes sometimes varies across these services, but they get there in most cases.

Step by Step Instructions

Navigate to https://portal.office.com/AdminPortal/Home. This is the home page for the admin functions in Office 365. The UI here has been changing frequently, so these screenshots are current in our Sympraxis First Release Tenant as of today. Your “experience” may vary, but hopefully the basic steps will look the same.

Settings / Organization Profile

At the top of the page, you’ll see the information about your organization, such as the name, address, technical contact, etc.

Organization Profile

There is also a section to Manage custom themes for your organization.

Manage themes

Click on the Edit button.

There are a number of things you can change here. I’ll run through them in a little detail.

Select custom logo image

Custom logo imageIf you upload an image here, it will show up in the suite bar in the center.

Custom logo image

You’ll want to make sure the image fits well into the space allotted. The recommended size is “200 x 30 pixels in JPG, PNG, or GIF format, and no larger than 10 KB”. Since this image will load on every page in your Office 365 tenant, you’ll want to make sure the image is the right size and resolution to make it look good and load fast.

If you’d like the image to be a clickable link to something, you can add that in the next field. Since most people use their Office 365 tenant for internal collaboration or as their Intranet, I usually see this link going to the public-facing Internet site for the organization.

Select Background image

Background imageIf you’d like a background image across the entire suite bar, you can upload one here. As above, the image requirements are specific: “1366 x 50 pixels or less in JPG, PNG, or GIF format, and no larger than 15 KB”.

Earlier iterations of this capability came with a set of selectable images. One of the images I’ve seen most often is one with LEGO® tiles. It’s sort of cool, but that sort of image might not be your thing.

Prevent users from overriding custom theming with their own theme

Prevent users

This effectively locks the theme so that no one can override it. Frankly, I’m not sure what this prevents, as we can drop custom CSS into any page which overrides the theme, but here it is…

Set custom colors

Custom colors

Finally, we have a section where we can set custom colors for the suite bar. This is probably the change which will have the biggest impact for your users.

You can change the color from the default Office 365 / Microsoft blue and black to something which is more aligned with your organization’s identity. Even making a little switch like these colors can make your Office 365 tenant feel much more like it belongs to the organization; don’t underestimate the importance of this for the user experience.

You can change three colors here. For Sympraxis, we’ve used our logo’s purple for the Accent color (332F81), white for the Nav bar background color (ffffff), and our logo’s green for the Text and icons (A3A437).

Sympraxis colors

Save your changes

Save changesFinally, save your changes. It will take a few minutes for the changes to take effect across Office 365, but you’ll see them in every application in the suite soon enough.

Note that it’s easy to go back and change these settings or remove them entirely.

Making these changes immediately makes your users feel like the Office 365 belongs to them. They may not even notice the specific changes, but they will feel more at home. Try it out and see!

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 applications. 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…

News Flash: Wandering Office 365 Waffle, Or “Who Moved My Waffle?”

Call it the waffle or the App Launcher or whatever you want (internally it has the CSS class ms-Icon–waffle2, so I think Randy Drisgill [@drisgill] is right, as usual), but if you use Office 365 or the soon to be available SharePoint 2016, you probably click on it dozens of times a day.

Recent changes to the Suite Bar (CSS classes start with suiteBar) have made it more responsive for different sized screens. This is a good thing, as the Suite Bar can now scale from a wide-screen desktop monitors down to a phone screen. How modern.

The implementation may confuse, though, so be prepared for some quizzical looks from your users.

Desktop Mode

Desktop Mode

Tablet Mode

Tablet Mode

Phone Mode

Phone Mode

As you can see, the waffle is where you’d expect it in desktop mode, and I get to see my Sympraxis Consulting logo as well.

The phone mode also seems to make sense. The logo is gone – there’s not really any room for it – and the icons are all hidden, albeit behind the dread ellipses rather than the hamburger most people are used to.

It’s the tablet mode that will probably throw your users. “Where my waffle?”, you might ask? Well, it hops over to the right, jumping over the Suite Bar title (“Sites”, “Outlook”, etc.) to hang out by the notifications icon (at least for now – the Suite Bar changes frequently).

It looks like the media query kicks in at 1024px, which may be the width of some of your users’ regular desktop screens, even in this day and age. Even if they have higher resolution monitors, they may not use their browser in full screen mode. (I’m a full screen guy myself.)

All in all, it’s no harm – but some of your users may cry foul. Be prepared for it. I’m seeing it in my own First Release tenant as well as in several non-First Release tenants as well.

Thanks for Stefan Bauer (@StfBauer) for the heads up on why this is happening.