Bringing the Update Set Picker back from the UI14 Gear Menu

Bringing the Update Set Picker back from the UI14 Gear Menu

T

he ServiceNow Eureka release contains many new features and changes. Among these are some significant changes to the look and feel that are generally a very nice (and needed) improvement over previous versions of ServiceNow. I have heard a few complaints about the way that the Banner Frame has been reorganized though. Instead of having the update set, language, and application pickers, etc. available directly, they’ve been moved into a separate menu which is now accessed by clicking a gear icon in the header. While I understand ServiceNow’s reasoning for this – the old header bar was starting to look very dated and cluttered – the update set picker in particular is something that I believe really needs to be visible to admins and developers at all times. In this post I’ll show you a quick workaround you can apply to your system to bring the update set picker back where it belongs!

The Solution…

There’s no way to get at the back-end code that controls the gear menu popup so our only option is to manipulate the UI using client scripting. Since this is a global issue independent of any specific table or form, we can use a UI script to target the Update Set picker element and move it to a different location on the page. The following script does just that, just make sure to remember to check the ‘Global’ checkbox on the UI script record. Enjoy!

$$('.btn-icon').each(function(d){
d.style.lineHeight='inherit';});}if($('update_set_picker').select('legend')[0]){
$('update_set_picker').select('legend')[0].remove();}//Move the update set picker from under the gear icon to the header
$('nav_header_stripe_decorations').insert({
top: $('update_set_picker')});//Make sure that UI14 doesn't change styling
$('update_set_picker').id='update_set_picker_new';}}catch(e){}}

Moving the Home icon…

I’ve had a few people ask about moving the home icon back as well. This one is a bit more difficult because of the lack of a decent ID to target, not to mention the old-style icon. In this case, I think it’s probably easier just to create a new icon in the header. The following code could be placed inside of the ‘if’ statement in the update set picker code above to also add a ‘home’ icon in the header.

I really have some difficulties to understand why ServiceNow decided to go for such a radical change. Yes, the banner was getting crowded, and I believe it makes perfect sense to have the Language or Theme pickers in a sub-menu (you will not modify those settings every minute, but, as Mark very rightly mentions it, the Update Set picker is something you will work with all the time as an administrator.
Moreover, the banner now looks… totally empty. How useful is that?

Overall, the feedback I get from customers is that they really like the new features included in Eureka, but they are more skeptical about the new UI (modern-looking for sure, but too flat, too white and more difficult to read)…

It is, but I’ve found such little use for the application picker that I didn’t think it warranted a mention. You can move the application picker at the same time by placing the following code within the ‘try’ statement in my code above…

//Move the application picker from under the gear icon to the header
$('nav_header_stripe_decorations').insert({
top: $('application_picker')});//Make sure that UI14 doesn't change styling
$('application_picker').id='application_picker_new';
$('application_picker_select_title').id='application_picker_select_title_new';

How can you make sure a script like this only runs when the UI is UI14? When I use IE8 in Eureka, the UI falls back to UI11 automatically, and the UI script still runs. Although it only moves the update set to the left on UI11, it begs the question of selectively running client side code based on the active UI version. I can’t find any documentation on this, as I am trying to run a few additional command on ui14 sessions only.

Also, is there an advantage to running this as a global UI script instead of global client script? It looks to be doing the same thing, but if there is a performance advantage then it would be good to know.

Good questions. The basic idea behind only running on a specific version is to test for something that’s only present in that version. This can be a system property or something in the UI. In this case, simply checking for the gear icon should be enough to do the trick. I’ve added this up above in the sample script. One thing to note is that the global UI script will ALWAYS run, all we can do is construct conditions within the script itself so that it doesn’t take any unnecessary actions.

Regarding global UI scripts versus global client scripts, there’s not really any inherent performance advantage, it really just comes down to when the scripts run. Client scripts are always tied to a table or catalog form being rendered. This means that they don’t run when lists, reports, homepages, CMS sites, etc. run. Global UI scripts are the only way to run client-side code throughout the entire instance. That’s good in this case, but can also be very bad if you haven’t developed and scoped your code correctly as it can often be the source of serious performance issues.

Do you know if it is possible to move the domain picker back to the header as well? I tried the obvious name ‘domain_picker’ but that didn’t work. Looking at the UI Macro for the domain picker indicates that the id for it is dynamically generated. It is not a simple static string like ‘update_set_picker’ or ‘application_picker’.

It’s not perfect, and only works for the select version, but this code should do pretty much what you want for the domain picker in Fuji. Just create a new UI script separate from the update set picker one.

Thanks so much, that is better than nothing at least we know what domain we are in all the time! Only issue I had was that it made the text in my select box on the header white (not sure if that would be an issue specific to us or not) so I just added $(elID).style.color=”black”; and that fixed it.

I do have one more question on that fix you provided for domain picker in Fuji, do you know why with the update set picker update it removes the Title and the lines above and below the select box in the system menu but those don’t get removed with this domain picker update? I don’t see a different in the code that would remove that header and those lines?

My guess would be that the script you reference is causing an error because it’s targeting elements that don’t exist at the time it runs. This would cause all subsequent client/UI scripts to fail. I’d check your console log in your browser to see if you have any errors.

I’ve added the Create home icon in the header script to the Move update set picker script I was already using. If I mouse over the new home page icon in the header and select any of the available home pages from the fly out, it works fine for any page I select. But if I just click the home page icon itself, it says “The page you are looking for could not be found”. Under that is a text field with “home_splash.do?sysparm_direct=true” in it and “Go” button to the right of that. Have you run acorss this issue before? Thoughts on what the problem could be?

The only problem I’ve seen with this is that homepages don’t render correctly sometimes if you don’t have all of the code inside of a ‘try’ block in the UI script. If that doesn’t work, then check out what I’ve got set up at https://demo003.service-now.com/side_door.do and compare it to yours. If you can reproduce the error there I can take a look.

Mark,
I took the same UI Script from our QA environment that was having the issue and created a global UI Script called Move Update Set Picker in demo003 and it works fine there, so I’m unsure what the problem is. Feel free to view my script and provide any feedback.

You should be able to move pretty much anything using this same script while adding the specific element ID that you want to move. You can use a standard DOM inspector to identify the correct element ID. ‘timezone_changer’ is the ID you’re after in this case.

Hey Mark,
This is not related to the discussion which is going on here. Actually I need to display a macro in front of one Reference field. But the problem is that, that reference field is read only. Because of this I am not able to put any Macro in ref_contributions of that field, even if I try to put, it is not getting shown on the form just because that field is Read Only. Can I do this without DOM manipulation? Is there any way to overcome such situations?
Any solution is appreciated!

What is the “$(‘update_set_picker_select_title’).id = ‘update_set_picker_select_title_new’;” line supposed to be doing? It’s throwing an error in Fuji – it cannot find the “update_set_picker_select_title” element.

Nice work on the Update Set for Fuji , it works.
I tried to do a similar thing with the Timezone Changer, but it does look a bit crooked – makes the header bar tall and shows the list white, unless you point to a choice option. Has anyone modified this one successfully for Fuji?

Hi Mark,
why are you actually moving the item in a client script? I would recommend to make the respective UI macro (or a downsized copy of it) available via decorate_welcome_header_stripe_left. This seems less error prone also to upgrades.
Daniel

Aside from being the quickest way to accomplish it, the main reason is that I want to avoid ownership (and the potential for breakage) of the entire welcome header bar and the code for the update set picker. Frankly, I’d rather not have to deal with any of it breaking at all and the best solution would be if there weren’t any need for the fix. I wish that ServiceNow would give us an option to move the update set picker to a location where it is actually visible to those who need to see it, or at a minimum, offer some explanation for burying it in the gear menu.

I do agree with your last statement very much and have raised this internally as much as I could.
Anyway, I rather go with the owning of the UI macro as this seems more update safe than mocking around with jQuery to move things on UI level. Guess this is a bit to personal preference….

Hi Mark,
I have added the new update set to my dev instance which is on Fuji Patch 1 but with the homepage button I no longer get an overview when I hover like I did in Eureka. This hover feature was fantastic and saved time.
Can you please advise what I am doing wrong?
regard.
Gareth

Welcome to the wonderful world of Fuji :). The issue here is that they’ve changed the way the button works in Fuji and have removed the hover capability. Unfortunately there’s not a simple fix for that unless ServiceNow decides to change it.

If we can’t make any additions/changes to the Settings cog in the top right, is there any way to create our own version (i.e. an icon on the banner bar that gives a set of options when clicked)? There’s a few options we’d like to have displayed here, but my current UI script basically floods the bar with multiple options. A second Settings cog like this would allow us to clean it up.

Update set picker and home button works very well in Fuji and from all browsers (IE, FF and Chrome). Thanks a lot.

Is there a way to show the “Switch to old UI” link. There is a property glide.ui.doctype set to true in Fuji, when we change it to false it changes the UI15 to UI11 globally, I would like to provide an option to the user who wants to switch to UI 11. There is an other option sysparm_device=desktop we can use but it is a manual and only active for the current session.

I can’t seem to get this to work on Fuji. I;ve tried several of the different code versions on this blog entry. The only error I can find is a “‘setPreferred FontSize’ is undefined” error, but I can’t find where I set my preferred font size, either.

Hi Mark. First, thank you very much for this post — I’ve used it several times and I love it. Second, I’ve just upgraded my personal dev instance to Geneva and turned on UI16. I’m sure you’ve seen that, out of box, you have the option to move the update set picker into the header. However, you must go through the gear–>developer section to easily get to the update set, or list of update sets. Obviously, there are other ways to accomplish this (like using a bookmark on the Edge), but is there a way to get that functionality back in the header bar…similar to what you’ve done with this post?

I don’t have a way to do that currently and I’m not sure it’s a good idea for us to continue to modify it anyway. If I were you, I would complain very loudly to ServiceNow via a hi ticket so that they’ll fix it. The sizing on the update set picker is messed up as well. It doesn’t even resize large enough to clearly display the name of the default picker. They think they’re fixing it for everybody but it’s still a pretty terrible job of fixing it. If enough people contact them and request it there may still be hope for getting it really fixed in Geneva.

Do you know why companies like Amazon, Zappos, Southwest Airlines, or the plumber in the next town keep getting more business from consumers like us? The answer is quite simple. It’s because they provide exceptional customer service every chance possible. Their entire brand is built on the promise of great service. Sounds easy, right? On […]

We are excited to announce the official release of our new book, 10 Pillars of ServiceNow Success for CIOs. The book is an educational resource to guide CIOs and their teams on their journey to transforming their organizations using ServiceNow. The 75-page book discusses best practices derived from more than 500 ServiceNow implementations—all aimed at […]

Famous leaders on the world stage have struggled to articulate a vision to gain the kind of mass support that changes history. Without a clear and consistently communicated vision, momentum for the cause...

Welcome to Part X of Crossfuze’s 10 Pillars of ServiceNow Success for CIOs blog series! First, a story to illustrate the challenge of fully integrating your ServiceNow ecosystem: Kyle is an experienced CIO...

Welcome to Part IX of Crossfuze’s 10 Pillars of ServiceNow Success for CIOs blog series! First, a story about the universal, pervasive challenge of demand management: Jason is a veteran CIO who has made many friends and allies within his company by being a “yes man.” He bends over backward to fulfill everyone’s IT service […]

Since 2009, ServiceNow Guru has been THE go-to source of ServiceNow technical content and knowledge for all ServiceNow professionals. Whether you're a new admin or a seasoned consultant, you're guaranteed to find quality solutions that will aid you in your ServiceNow journey!