If you’ve been watching the social space around SharePoint or Office 365 lately, you may have noticed that Office 365 has been surfacing a few regression issues that are breaking people’s client-side solutions. Let me give you three examples I’ve seen in the last week:
Issue #1: Changing the Title Field
The first one I saw was highlighted by Marc Anderson’s blog: Office 365 Update Changes ‘Display Name’ on Required Fields . In this issue, Microsoft added the string “Required Field” to the Title field on a form. This broke a reference people were using with a jQuery selector to get access to that field because now instead of a specific lookup, they need to do a fuzzy lookup.
A Marc mentioned in the update on the post & in the comments, it appears this was an intentional change and was done to improve accessibility using screen readers..
Issue #2: Changing Protocol-less Library & Style References
The second one I’m hearing is that some (or all?) customers who have added protocol-less references to CSS or JS libraries are being rewritten. For example, if you reference the jQuery library on Google’s CDN like this:
//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
is being rewritten like this:
//tenant.SharePoint.com/ajax/libs/jquery/1.10.2/jquery.min.js
This doesn’t look so much like a SharePoint change, rather it smells a bit more like a reverse proxy or some networking change because from what I hear, the modified date on the affected files hasn’t been changed. But the point is that OUR code shouldn’t be changing. Are the libraries the exact same? Technically they should be, but these recent changes aren’t exactly instilling confidence with customers that they can rely on Office 365 not making arbitrary changes.
Issue #3: Changing the DOM ID’s
Frankly this is the biggest one to me. Today I saw a question pop up in the
SharePoint StackExchange Forum
:
Did Microsoft just update SharePoint online?
. In this instance, it appears an element ID in the DOM changed from Suite_MainLink_ShellDocuments to O365_MainLink_ShellDocuments.
Apparently the rule developers have lived by where ID’s are supposed to be unique and unchanged so you can reference them at a later date does not apply in the Office 365 dimension.
My Thoughts
Some changes like this likely have very valid and justified reasons, others are done for unknown reasons and even worse, some seem to be (and sorry MSFT for saying this), but seemingly out of ignorance. I’ve searched far and wide and can find no announcement or change log where things like this are documented by Microsoft or, better yet, customers have been given a heads up. It’s just a “hey we’ll change it when we feel like it and you’ll just have to find them on your own and deal with it.”
In mid-2012 Microsoft started pushing the whole “get off the server, SharePoint solutions are dead and apps are the way” when they started talking about SharePoint 2013. While that messaging was toned down a bit and solutions are just not recommended, the message is clear: developer should not be building things on the server and should be focusing on working in the client or off the SharePoint server. Let’e me clear… I’m all good with that. But if you want me to work in the client, you need to treat all your client-side interfaces as an API… the CSOM, JSOM, REST/OData and the user experience (UX).
I’ve already heard one of my very big Fortune 100 customers affected by this say the following
That is most certainly not the message customer should be walking away with… but can you blame them?
The Office 365 team has had their fair share of bumps in the last few years. Most of them seem to revolve around process and understanding what it means to build and provide a service to customers. So far they haven’t shown they’ve gotten this right… and customers are now starting to get fed up. I sure hope things start to change for the better… and soon. Maybe we’ll see some of this addressed at the SharePoint Conference in just over a month… I sure hope we see it.