Why I abandoned the best mobile operating system

This is a story about how I abandoned my old mobile phone last year, even though it had the best mobile user experience available. Or actually, it’s a story about the digital workplace. Because let’s face it: considering the amount of time we spend on our phones, the smartphone is an important part of that digital workplace.

So what phone did I have you ask? It was a Windows Phone (yes, you can stop snickering now), the Lumia 830 if you want specifics; the last one branded as Nokia. It runs the Windows Phone mobile client OS that was originally released in 2010, as follow-up to Windows Mobile (formerly PocketPC). While Windows Mobile was very Microsoft-oriented in terms of connections and user interface, the new Windows Phone OS was developed from the ground up with the capabilities of modern smartphones in mind and a more universal (think cross-platform) look onto the world. This new OS arrived very late in the game, because competitors Android and iOS already had well developed operating systems for modern smartphones at the time. The advantage of arriving late though, was that Microsoft had a chance to take all lessons learned from existing mobile operating systems, and develop a whole new user interface taking all this into account.

I have always found the iOS user interface to be cluttered, with a plethora of different looking icons on your start screen. The Android interface has the same issue and was still rather clumsy around 2010 (although much improved since then). In comparison, the Windows Phone’s interface of tiles is clean, structured, intuitive, and you can get to any setting or application really fast. Also the so-called live-tiles are far superior to any widget I’ve seen on an Android phone, because of the way they fit and blend into the overall appearance. Add to that the flawless Exchange, OneDrive and Skype integration, and you get an almost unbeatable mobile digital workplace in terms of productivity.

mylumia830

Why abandon my phone then? That had everything to do with available apps and app support. So how did this happen? Well, do you remember the VHS vs. Betamax format war in the 80s? Or more recently HD-DVD vs. Blu-ray? SD-card vs. Memory Stick? Super Audio CD vs. regular CD? My point is: the best platform doesn’t always win. If another product gets better marketing, a better image, better distribution channels, more resellers, then an objective comparison of features and usability doesn’t have to be all-decisive. And at some point if you drop below a certain market share, the battle is lost. This is exactly what happened with the Windows Phone – for a large part I should say because Microsoft was so late in the game, and the competition had already cornered the market.

As a result nearly every company or event organizer that was building a new mobile app, made the decision to only create a version for Android and iOS, because the limited Windows Phone user base didn’t justify the cost of an additional version. There still were many Windows Phone apps of course for key applications (mobile banking, Facebook, Twitter), sometimes sponsored or even created by Microsoft, but often these were updated less frequently and had less capabilities than their (better looking) Android/iOS versions. And then over the last few years, when Microsoft basically stopped investing in phones and the Windows Phone OS altogether, focusing more on Windows 10 and the Universal Windows Platform Apps, many companies even dropped support for their existing Windows Phone apps. It was a hopeless downward spiral.

So what does this tell us about digital customer experience in general? Most of all, although user experience is important, it’s not the whole story. You may have an app or a site with a slick look & feel and the best usability around, but that’s just the storefront. Important as that is, if you don’t back it up with proper marketing, image-building, good distribution channels and continuous updates, you are unlikely to succeed. In a market that is becoming more and more digital and global, keeping both the storefront and all surrounding processes in shape takes considerable effort and attention.
And as the Windows Phone example shows us, you also need to act in time. A great digital user experience is important, but that by itself is not the killer feature that will lure customers away from one of your competitors. Gaining market share (or preventing market share loss) if you arrive late in the digital game is going to be tough.

This post was originally published on the Capgemini ‘Capping IT Off’ blog.

Permissions required to start a SharePoint Designer workflow

I’ve read in multiple blog posts that you need Contribute permission to start a SharePoint Designer workflow on a List item. That makes sense, because the workflow also generates a workflow status field on the List. And starting the workflow on an item typically alters the value of that field, which automatically means you need permission to change that item.

What I’ve found is that Contribute permission on the List itself is not enough. There are two other permissions required:

  • Contribute permission on the hidden Workflow History list
    The actions taken by a workflow are recorded in a workflow history list. By default this is the hidden List ‘Workflow History’ (URL: {site}/Lists/Workflow%20History) which is always present.
    If the user account that started the workflow cannot write anything to this history list, then the workflow will fail rightaway.
    By default the Workflow History list inherits its permissions from the site root. What typically happens is: someone needs to start a workflow from a Document Library but has only Read permission on the site root. The Workflow History list inherits that Read permission, which is not enough for a workflow to start/run properly.
    If your users who start workflows are already regular Members of the site and therefore have Contribute permission from the root, then you will not notice this problem since you automatically have the correct permission on the Workflow History list.
  • Contribute permission on the Tasks list
    Almost the exact same logic applies to the Tasks list. If (and only if) you have a workflow that creates Tasks, then obviously the user needs Contribute permission on the Tasks list configured for that workflow as well.
  • Read permission on the site root
    Please note: I am less certain about this one, but I found that the permissions on the site root also play a role. My theory is this: you need Read permission on the site root so the user can ‘see’ the available workflows and the lists (Tasks and History) attached to those workflows. Somehow that information is stored at site level, which is why you need Read permission there.

Note that the above permission requirements also apply to workflows at site level, not just for List workflows.
Get these permissions in place, and your users should have no trouble starting SharePoint Designer workflows (either manually, or automatically OnCreate/OnChange).

Limitations for external users in SharePoint Online

You can share a SharePoint Online site (or a list or document, etc.) with external users, if your global setting for the site collection allows this. Although you need to select a specific permission group for these external users (from the list of available permission groups in that site), those external user do not have the same capabilities as a ‘normal’ user of the site.

The reason for this is that external users do not have an Office 365 license linked to them, at least not unless you choose to assign that to them.
As a result there are a number of things you cannot do as an external user. Microsoft has some documentation on those limitations:

Manage external sharing for your SharePoint Online environment

I recently found that there is at least one other thing that external users cannot do, which is not documented: An external user cannot share something with another external user by inviting them.

On the one hand that makes sense, because that could potentially allow an endless string of external users in the site. On the other hand it is strange: if I am allowed into the site as an important user with broad permissions, then why can’t I share anything with another (new) external user?

What I haven’t tried yet is to see if an external user can share with new external users once an Office 365 / SharePoint Online license is assigned to his account. Will update this post if I find out.

 

Versioning in SharePoint when editing in Word compared to Word Online

While I was developing a workflow to be triggered on a changed Document Library item in SharePoint Online (this was a Word document), I noticed something interesting about the versioning.
In the workflow I was checking if the version number had already increased, thinking that in this way I could determine if the user was done editing.

As it turns out, it depends if you are using Word or Word Online. What happens is this:
If you are using your local MS Word installation, then you are basically working offline. You only connect to SharePoint Online when you take an explicit action like saving or checking-in a document. SharePoint will not create a new version in the version history until you click Save in Word. So even if you type lots of new text and update some properties, but close the document without saving, nothing is changed in the version history.

This is very different in Word Online. As you probably know, there is no Save button in Word Online, because any change is automatically saved for you. So that made me wonder: if I edit a document in Word Online for half an hour, making many changes, then that document is going to be saved automatically dozens of times. So does that create dozens of new versions in the history? Well, that would be awkward and luckily the answer is no.

What happens is that Word Online creates a new version in the version history (in SharePoint Online) when the first change is being saved in Word Online. So as long as you don’t touch anything in Word Online and just read the document, you get no new version. Then, on every next change in the document that is saved in Word Online, that same new version is *updated*. You can see the Modified time change in the version history.
That is actually the same behavior that we are used to in (local) Word: as long as you do not close the document, subsequent saves will be considered as an update to the same version. This is true if you use both minor and major versions, but also if you only use major versions.

So coming back to my workflow, the downside here is that a new version in the history does not always mean that the user explicitly saved his work. That depends if Word Online or (local) Word was used. Your new version will in any case appear in your version history more quickly when using Word Online.

 

Accessing your Audit Reports in SharePoint Online

I was used to my SharePoint audit reports index being available as a link in Site Settings > Site Collection settings.
In SharePoint Online however, that link appears to be gone. I can still edit the Audit Settings, but there is no link to open the actual reports.

I’ve seen different reasons mentioned for this. This might be done on purpose, because the Office 365 Protection portal has become the access point for audit/compliance reports.
This doesn’t help me, because in this particular case I did not have access to the Protection portal of the customer. But if I need to check something for SharePoint Online, then obviously I would like to have access to at least the reports for SharePoint Online. That seems reasonable if you are a Site Collection administrator, doesn’t it?

Luckily there is a workaround: the URL for the audit reports is accessible, you just need to know it.
After the URL to the root of your site, append the following:

/_layouts/15/Reporting.aspx?Category=Auditing

and voilà, you’re there!

auditreports

You cannot delete a DropOffLibrary in SharePoint Online

If you enable the Content Organizer feature in SharePoint, a library with the name DropOffLibrary is automatically created for you. This is the place where you drop off your documents, after which the content organizer rules kick in and move your documents to the appropriate target location.

I was doing some testing with this feature in a test site in SharePoint Online and wanted to clean up afterwards. So what I did was disable the Content Organizer feature. Result: no more content organizer rules, but the DropOffLibrary was still there. So of course I went into the library settings, expecting to delete it from there. Surprise: the link to delete the library is missing for the DropOffLibrary.

As it turns out, there is a property called AllowDeletion which is set to False for this library, probably because it is so tightly linked to the Content Organizer feature. What you would hope for is that feature deactivation causes this property to be set to True, but that’s not the case.
I tried a few other options, like deleting it through SharePoint Designer but you can’t delete it from there either.

Several blogs mention that you need to set the property AllowDeletion to True using PowerShell:

$list.AllowDeletion = $true
$list.Update()

But unfortunately, that only works in SharePoint (2010, 2013) On-Premises. The property is a member of the Microsoft.SharePoint.SPList class, but not available as a member of the Microsoft.SharePoint.Client.List class, so not part of the CSOM (yet) and therefore deletion of this list cannot be set to allowed.

In other words, once you activate the Content Organizer in SharePoint Online, there is no way to get rid of the DropOffLibrary. What you can do of course is hide it as much as possible, but that’s not really cleaning up. So if you are considering the Content Organizer for a SharePoint Online site, make sure you want this because there is no complete way back.

 

Search results not showing duplicates

Recently I ran into the issue that the SharePoint Online search was not returning all expected search results – or so it seemed.

To do a test on a site with many items, I uploaded around 7000 documents, all with a different file name but the contents were identical.
As it turns out, SharePoint by default hides the duplicates -and doesn’t show you the ‘Show Duplicates’ link, which is hidden in the popup window for a search result anyway.
The effect was that while I was expecting 7000 results from a search, I only got 1 hit.

If you want to see all your results, you would ideally want to switch off some option on the results web part, to tell it to stop hiding duplicates. Unfortunately that option is not available on the web part UI (something Microsoft should really have put in there IMHO).

Luckily there are some workaround, and you can also enable the ‘Show Duplicates’ link, although I think that solution is far from ideal.
You can either change the TrimDuplicates setting in the web part code (by exporting the web part, changing the setting and re-uploading it), or change the query in the web part settings to make it GroupBy the property DocumentSignature.

Here are the relevant blog posts describing all this in more detail: