This article discusses the differences between ServiceNow’s “Studio” (the legacy application development environment) and “ServiceNow Studio,” its successor. Because of the fun naming of these two products, I’ll refer to them as Old Studio and New Studio. This article’s written in the ServiceNow Yokohama-era.
After years of living in Studio day in and day out, it’s grown on me. I appreciate that I have to flip in and out of different browser tabs — some things are just faster to do in UI16. It feels home, i have my cadence down, it’s comfortable. But, since the release of a few new features in Yokohama, I’ve realized that it is time for me to make the switch.
Here’s the biggest features that made me a fan
- Supporting working in multiple scopes without ‘switching’ over. For many of my more complex client applications, I’m frequently flipping between scopes. I’m regularly reminding developers and staff which scope a feature should be build in. It’s easy to forget in Studio because your scope itself isn’t front and center — it’s easy to miss in the bottom-corner of the page.
- There’s just more types of objects available to build at your fingertips. The Create File menu is packed with features that aren’t represented in Studio at all. Everything else aside, this is a major reason — if you’re still building applications without these features, you’re missing out. Or, you’re spending a lot of extra time flipping over to UI16 or elsewhere.
- The full app settings menu is now available. For me this is helpful at the start of every new application. I like to set the default menu and roles — call it habit, but I still prefer to set these right away, lest some other developer on my team lets the Old Studio autocreate new roles and menus that I have to cleanup. Lack of this feature pre-Yokohama still had me starting every new scope in Old Studio — this isn’t necessary anymore with Yokohama.
- Built in Workspace Designer. I can quickly now create a new workspace from the same environment. This is something that I used to have to bounce over to AES or UI Builder to get a new workspace started.
- I know my whole scope. This is a pro and a con (also listed below). When my dev teams are getting ready to publish something, we can quickly see everything that is included in the scope. Even if this list is quite long, an App Repo packages everything — so we should have visiblity into everything.
Why I still sometimes go back to Studio
It’s faster. For simpler tasks, such as making a table where I already know my desired data model, the old view is just faster. Fewer page loads, quicker data entry, and fewer pretty prompts and graphics to slow things down. To be fair to the ServiceNow team, I could just power-up and use the IDE, if I wanted to be even faster, but I’m not that crazy yet.
It hides the things I don’t use very often. For example, I don’t typically care about the Number record that gets created when I create a new table. Complex apps can get really bogged down in the leftmost navigation panel with a lot of object classes that I don’t often care about. This might be addressed sometime in the future with increased developer preferences.
Closing thoughts
These new features in Yokohama sealed the deal for me. It’s bigger, covers more, gives me more detail on the entirety of the app, lets me work across scopes, and more. I can’t say I won’t still open Old Studio once in a while just for memories and pure browser speed for some tasks, but I can now see that this will be fewer and far between.
Have you made the switch?
This article was originally published here: https://adamhutton.medium.com/a-curmudgeons-guide-to-switching-to-servicenow-studio-de685b0f8933?sou...
1 Comment
