New Office 365 Admin UI Preview

On the November edition of CollabTalk, I did a short demo of the new Office 365 Admin Center. This new UI is available as a functional preview to folks who have opted into First Release in their tenant as well as some of the small business licenses.

If you’d like to take a look at the new UI and you’ve got First Release enabled, you should see a couple of links at the top of the screen when you visit the main page of your tenant Admin link from the App Launcher, a.k.a. “the waffle”. From these links, you can either take a sneak peek at the new UI or watch a video.


All of this is changing swiftly, so think of these screenshots as indicators of where the admin UI is going – it’s not final. The great thing about it, though, is that what is there actually works. You can use it to get some of the more common activities done.

Here’s a view of the new page as it stands. You can see that it isn’t – by any means – everything you can do in the current Admin Center. To me, that’s a great thing. The full UI can be overwhelming, anyway.


If you start taking the tour, it will highlight the important parts othe new UI in an order that makes a lot of sense to me. I love the fact that Microsoft is starting to build these in-application tours into the newer UIs. We shouldn’t need to read the manual before we know what to do anymore!


What are the most important things we do in the Admin Center? Well, I’d argue it’s managing users, billing, and checking system heath. The next three steps in the tour show us exactly where we’d do each of those important activities, as well as showing us how we can navigate to each activity. Plus – a ninja cat riding a fire-breathing unicorn!


Managing users is front and foremost. Users are at the core of Office 365 – of course, right?


Taking care of licensing and billing is a central activity on Office 365, because there’s no concept of server licenses here. In the new Admin Center, it’s easy to buy additional licenses and assign them.


We all care about service heath, and the new Office 365 Admin Center gives us a one-glance view of what is having problems, rather than a long list of things that are fine, as in the current Admin Center, but with the option to drill into the details.


If you try out the new Admin Center and can’t accomplish something, it’s easy to switch back to the old UI.


What do you think is missing? Well, there’s a feedback link built right into all of the pages so that you can send feedback to the team behind it. And because this is the new Microsoft, they are really listening.


Finally, there are links to helpful videos and articles that can help you get up to speed if all this is new to us – and we’re all new to this at some point.


So what’s not so great yet? Well, the UI isn’t fully responsive. It’s housed inside the newer semi-responsive Suite Bar but the Admin Center itself isn’t responsive enough to work on a phone. (For that form factor, we have the Office 365 Admin app at the links below.)

The functional map between the old Admin Center and the new one is pretty sparse. But like I pointed out already, managing users, billing, and service health are some of the most important aspects of admin, especially for smaller organizations. More will come, and I expect we’ll see it come quickly.

Right now it’s a little stormy in the cloud. But Microsoft is clearly “Working on it…”


This article was also published on IT Unity on 11/19/2015. Visit the post there to read additional comments.

The ‘MVP Thoughts’ Series – Live from Sharegate World Headquarters

2015-11-18_17-30-46Last month a handful of SharePoint and Office 365 MVPs (now Office Servers and Services MVPs, but who’s counting?) gathered at Sharegate‘s offices in Montreal to help them with their next series of Damn Simple videos. Stay tuned for those.

After all the silliness – I mean serious cinematography – Jennifer Roth (@jennifermason), Corey Roth (@coreyroth), Fabian Williams (@fabianwilliams), and I sat down with the great Benjamin Niaulin (@bniaulin) to talk about Office 365 and SharePoint. You know – the usual. Each time a bunch of us gets together, though, the conversations tend to go in different directions. It’s even interesting for me to watch these, as our opinions often change over time.

I’m not sure how many segments we ended up with, but I’ll keep adding them here as they come out. If you’d like to read the transcripts instead, follow the title links.

MVP Thoughts: What to Expect From SharePoint 2016

MVP Thoughts: SharePoint Workflows & Forms in Today’s Environment

MVP Thoughts: What Should SharePoint Developers Focus On?

SharePoint and Office 365 in the Modern Workplace

Office Graph API & Groups Seen By Developers

Coming soon:

Today’s SharePoint Developers’ Challenges

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.

Recent Changes to Task Management Conventions on Office 365

2015-11-13_14-20-24If you’ve been using Task Lists in SharePoint as long as I have, you will notice even the tiniest changes. Task Lists have never worked exactly the way people want them to – why doesn’t marking a task %100 complete also mark it as Completed? – but by adding a few extra columns to each list to customize them for your organization, they have always gotten the job done.

I wrote about how I generally use Tasks Lists years ago in my post Simple Best Practices for Using SharePoint Task Lists. I’m no longer a huge fan of the “best practice” term – there can be many different “better practices”; rarely is a “best practice” the best for everyone – but I’ve been following that model for Task List usage since I wrote the post in 2009. That’s through SharePoint 2007, SharePoint 2010, SharePoint 2013, and SharePoint Online.

Well, sometime in the last few weeks or months, the way Task Lists work in Office 365 seems to have changed, and my model doesn’t work so well any more. These changes seem to apply only to Task Lists that have been created since the changes, as my older Task Lists still work the same way they always have.

I don’t see anything in the Office 365 roadmap to explain the changes (I admit I didn’t pore through every item, but the prose there is difficult to follow, IMO), so I figured I’d capture what I’m seeing. Here’s what’s different:

  • If you change the Task Status from Not Started to In Progress, the % Complete column is set to 50% on save
  • When you change the % Complete column to 100%, the task is marked as complete on save

These two little changes can make a big difference. I think that they are actually an improvement, but for anyone who is used to the old way, it’ll be frustrating. This will be the case especially if you have some older Tasks Lists and newer Tasks Lists in the same site!

My new suggested model will change a bit:

  • When you start working on a task assigned to you, set the Task Status to In Progress, then immediately change the % Complete from 0% to whatever is appropriate. SharePoint seems to respect the % Complete you set rather than updating it to 50% on save.
  • When you’ve completed a task, leave the Task Status in the In Progress state, as we have before. Now, however, mark the % Complete to 99%. This will prevent SharePoint from marking the task as Completed when you save it.
  • When the person who originally made the request decides you have completed the task appropriately, they can change the % Complete to 100% or just tick the Completed box, which is generally to the left of the task, at least in the default view.

One of the main goals I’ve always had in my model is to make it an exception – rather than the norm – for people to mark tasks complete which they work on. We don’t need to enforce it strictly, but by convention. These tweaks under the new Task Lists behavior still supports the goal.

Plus ça change, plus c’est la même chose

Moving from SPServices to Rest, Part 5: Using Promises with SOAP and REST

Wouldn’t it be great if we could drive flying cars like the DeLorean in Back to the Future? Unfortunately, even though October 21, 2015 has passed us by, that’s not a reality yet. The science fiction writer Arthur C. Clarke famously said,Any sufficiently advanced technology is indistinguishable from magic.” Sometimes JavaScript promises can feel a little bit like magic – at least until you get good at working with them.

Paul Nigh's '' Back to the Future DeLorean Time Machine - Image source:

Paul Nigh’s ‘’ Back to the Future DeLorean Time Machine
Image source:

What are promises?

Both SOAP calls using SPServices and REST calls return promises. This is the case primarily because we are usually using a similar transport mechanism: maybe jQuery’s .ajax() function, which sends HTTP requests. (We don’t have to use jQuery, but it’s one of the more commonly used libraries to do this sort of thing. If you’re using one of the alternatives, you’ll need to do a little translation here.)

Promises are very cool mechanisms that work something like this. I think of it as a bit of magic, maybe like an act on America’s Got Talent.

When you make a call to SPServices or REST, you can assign the result of that call to a variable. That variable is a promise, which is sort of like an empty envelope. There’s no data in it when you first get it, but the call you just made promises to fill up the envelope for you. When the data is available and any conversion is finished, the original call sort of taps you on the shoulder and says, “You’ve got data!” (Say that in your best AOL voice.) At that point, you can start to do whatever work you want to do with the data.

Pretty neat, right? But, why does it matter? Well, when you are making AJAX calls, it can take a while for the server to respond. Servers are usually very powerful but they can get busy, or you may have asked for something complicated, or you may have asked for a lot of data, or the server may simply be tuned very badly. In any of those cases there will be a delay between the time you make the request and the time the response is available to you. The delay may be a few milliseconds or even a minute or two (though that probably indicates a poorly thought out request or a badly tuned server). During the time that delay occurs, you don’t want your JavaScript code to sit there waiting. Instead, you want to handle the call asynchronously meaning you don’t wait for it to finish; you elect to be notified when it finishes. That’s where promises come in.

Each browser reacts slightly differently to synchronous calls. Internet Explorer is probably the worst of the bunch, as it really hangs up until the request is complete. This makes for an unpleasant user experience, which ought never to be our goal. Because of this, using a promises pattern is important to ensure that your application feels responsive and peppy to your users.

What does converting to the promises pattern get us?

If you’ve been using SPServices for a long time, you may be setting async: false in many or all of your calls. This means you are making the calls synchronously, hanging up the browser. By moving to the promises pattern while still using SPServices, you’ll be setting yourself up for making REST calls efficiently down the road.

Let’s look at a simple example where we are just retrieving some items from a Custom List.

  operation: "GetListItems",
  async: false,
  listName: "MyCustomList",
  completefunc: function(xData,status) {

    $(xData.responseXML).SPFilterNode("z:row").each(function() {
      // Process the data


In this example, a SOAP payload will be sent to the server, and our code will sit and wait until the response comes back because we have specified async: false. If we’re only making this one call on page load and there isn’t a lot of data coming back, that might be fine, as the response will come back quickly, so the user may not even notice.

But if the server is busy or we’ve asked for a lot of data, our user will be wondering why the browser is locked up. To avoid this, let’s switch to using a promise.

var p = $().SPServices({
  operation: "GetListItems",
  listName: "MyCustomList"

p.done(function() {

    $(p.responseXML).SPFilterNode("z:row").each(function() {
      // Process the data


Here we’ve switched things around. We make the call to get the data, obtain the promise from the call and put it in variable p and then move on. Below the call, we have p.done(…), which means “When the response is here and ready to process…” Our JavaScript keeps executing from there and the browser is available to the user in the meantime. They might leave the page, click on some other actions, whatever.

When the promise is fulfilled, our code in the p.done(…) block executes. Now this will feel pretty weird to you until you get the hang of it. In the interim since you made the call, the DOM may have changed and the user may have done other things. You need to take those possibilities into account as you process the data you’ve received in the response.

Why convert now?

Converting to the promises pattern while you still are using SPServices to make SOAP calls has some advantages.

First, you already know how your code works. It may have taken you a while to get it up and running. As you’re thinking about how to move from SOAP to REST, you may not want to change too many things at once.

Find a simple call using SPServices and convert it to the promises model so that you understand how it works. Your user experience will improve even if you don’t move to REST yet. Even better, you can make this change in SharePoint 2007 or 2010 without having to switch to REST at all.

By the way, the call above in REST would look something like:

  url: _spPageContextInfo.webAbsoluteUrl +
  method: "GET",
  headers: {
    "Accept": "application/json; odata=verbose"
  success: function(data) {
    success(data); // If the call is successful, process the response
  error: function(data) {
    failure(data); // Do something with the error

The success and failure functions will only be called once the promise from the $.ajax function is resolved, so it’s somewhat equivalent to the promise-based call using SPServices above.


Since one of my goals in this series is to make moving from SOAP to REST less painful, I want to give you smaller steps you can take to get there without hurting yourself. Moving to the promises pattern now – whether you decide to go fully to REST or not – will put you in a better place when you do decide to take the plunge. Even better, it will prepare you for more “modern” Web development down the road, where you may be consuming data from multiple services. Those services may all be within SharePoint Online or Office 365 or they may be from separate sources altogether. Many of those services will be exposed via REST and the promises pattern will enable you to manage all of that data flying around more effectively.

This article was also published on IT Unity on 11/6/2015. Visit the post there to read additional comments.