Color Codes in SharePoint SPColor Files MUST Be All Caps

With the new world of branding a tenant on Office 365, styling the suite bar and using a theme (aka Composed Look) can take you pretty far toward improving the user experience.

A Composed Look is made up of (potentially):

  • A master page – generally either Seattle or Oslo
  • Theme URL – the spcolor file to use for common classes in a SharePoint page
  • Image URL – an image to use as the background for pages
  • Font Scheme URL – spfont file to use for common classes in a SharePoint page
  • Display order – simply where in the list of Composed Looks yours is displayed

Composed Look Settings

I won’t go into all the details about how this works, but each setting above is somewhat optional: you can use an existing spcolor file, for example, but create your own spfont file. If you want to understand all the mechanics, check out Benjamin Niaulin’s article Step by Step: Create a SharePoint 2013 Composed Look

 

Change the look

Here’s a quick tip about spcolor files. I was tearing my hair out over the last few weeks trying to figure out why sometimes my iterations of an spcolor file were working and other times they weren’t. By not working, I mean that the Composed Look would simply disappear from the Change the look page. I’d revert to my last working version and slowly inch forward again.

It turned out to be something silly and obvious – once you know it!

All of the color codes in the spcolor file MUST be all capitals. So, for instance, this:

<s:color name="ContentAccent1" value="0057b8" />

would not work, but this:

<s:color name="ContentAccent1" value="0057B8" />

would. That was *not* easy to spot, but spot it I did.

Don’t let this one bite you; I hope that your Binglage has led you here for a solution and this helps…

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!

SharePoint Saturday Boston 2016 Follow Up

Thanks to everyone who attended my session at SharePoint Saturday Boston on ‘Best Practices for Small-Scale Client-Side Development in SharePoint’. I’ve posted my slides on SlideShare for everyone’s enjoyment.

Be sure to follow my series on Sympraxis Client Side Development Pipeline for more details on some of the approaches and methods I demonstrated in the session.

Thanks to Heather Newman for the photo!

Thanks to Heather Newman for the photo!

Retrieving the Content Type in a REST Call in SharePoint 2013 On Premises

Content Type

I’m working in a SharePoint 2013 on premises installation, and I needed to get the ContentType back from a REST call. Content Type is often the most important piece of metadata in a list or library, with the detailed metadata for the Content Type coming in as secondary. It certainly matters which Content Type you have if you’re building custom UIs like I am.

On SharePoint Online, this works:

/_api/web/lists/getbytitle('MyList')/items?
$select=ContentType/Name&$expand=ContentType

But on premises, it doesn’t. Nothing comes back for the ContentType at all.

I found this great little tip from eko buried in a StackExchange comment – with no up votes. Up votes matter, people, so make sure you use them.

Simply add ContentTypeId to the $select and you’re in business:

/_api/web/lists/getbytitle('MyList')/items?
$select=ContentTypeId,ContentType/Name&$expand=ContentType

We shouldn’t need to do this sort of workaround, but it’s great when we can!

Sympraxis’ SharePoint Client Side Development Pipeline – Where Should We Put Our Stuff?

This entry is part 2 of 2 in the series Sympraxis Client Side Development Pipeline

As I mentioned in my previous post, when Julie Turner (@jfj1997) joined Sympraxis, we quickly realized we needed to get smarter about managing our code and our overall development process.

One of the first things Julie and I discussed was where we should store our code. Even way back before SharePoint entered my life, I’ve thought of code as content. It’s just a different type of content that has different content management requirements. For this reason, I’ve never fretted too much about storing my code in a SharePoint Document Library or in the Master Page Gallery.

Code as Content

That works fine when you’re a development team of one. But as Julie and I started working on a project together, we knew we needed to do better. Plus, angst and all that. One thing that is key here – and is key in many conversations about stuff like this – is there is no one-size-fits-all answer. Managing code is like managing any other content in that there should be some governance around it. But the governance doesn’t have to be – nor should it be – the same in every instance.

So we thought about what we wanted to be able to accomplish. Basically, what our requirements were to get rolling.

  • We needed an offsite (meaning not just on our machines) repository. This would make us worry less about disaster recovery. We were both doing backups to the cloud (me with Crashplan and Julie with Acronis), but we wanted a repository that belonged to the company, not to either of us personally.
  • We wanted to improve our code reuse. It’s not that we build the same thing over and over, but like the functionality in SPServices, there are some things we do fairly often. In other words, our tricks of the trade. By storing all of our code in one place, we hoped we would make reuse easier.
  • We work with clients on project-based work. Sometimes we work with a client for a while, then they take over for a while, and we reengage with them when a new need arises. We wanted to make it easier for ourselves when that re-engagement happened: basically improve our speed-to-useful again.

As Julie mentioned in her post, she had used Team Foundation Server (TFS) Online at a previous job. I had touched TFS at a previous gig, but like many Microsoft tools it seemed way overblown for our needs. Plus, it’s really tuned for Visual Studio, which I never use.

Julie decided to set up a private Github repository, figuring it would be more palatable to me. I’m always a fan of using things that are simple (Github confused me for years, so I’m not sure it qualifies as simple!) and I liked the fact that we would be using something the wider tech community had stamped with a seal of approval.

GitHub_Logo

We went with an Organization Bronze Plan – which now seems to be obsolete. (Here’s a link to the old plans courtesy of the Internet Archive Wayback Machine.) This gave us up to 10 repos and unlimited users for USD$25/month. Not much money, really, and we figured 10 repos was plenty.

Once we had the repo, we thought about how to organize it. We started with three repos for our organization: clients, admin, and samples. Our thought was that we would put all of the client work artifacts into that one clients repo. It certainly addressed our requirements to work that way. The admin and samples repos would be for Sympraxis administrative stuff and demos or samples we used for speaking sessions, respectively.

This got us up and running. We were both storing our code in a central repository and we could use whatever code editor (or IDE, depending on what terminology you find acceptable) we wanted. I’m using WebStorm a lot these days, but I also use Sublime Text and SharePoint Designer, and… Yeah, whatever works. Julie came from using Visual Studio, but these days she’s mainly using Visual Studio Code.

One of the greatest things about this Brave New World is that what we use to edit code really doesn’t matter that much. I really started liking WebStorm when I realized that its tooling for Github actually made Github make sense to me. I love the ecosystem of plugins for Sublime Text. And no IDE understands SharePoint as well as SharePoint Designer does. So I get to use whatever I need for the task at hand, and so does Julie. We’re just putting the results of that work into the same place.

As we moved forward with this setup, we started to see a few flaws in our thinking. The great thing about being a learning organization (the learning group is YUGE at Sympraxis) is that we comfortably revisit our decisions whenever it makes sense. The clients repo quickly became unwieldy. (Some of you would say “Duh!” here, but we’re fine with the way this went.) We were still manually copying code into our clients’ environments or editing in place and taking copies to dump into Github. We were very happy with Github, but not the mechanics of how we were using it.  So all wasn’t rosy yet.

In my next post, I’ll talk about the next steps we took to tune things…