Intro To Developer Blog Series
This Developer Blog Series is going to get extremely technical. Most people are not going to get value out of this, but our hope is that those who do get value out of this will get more than they even hoped for. It will not be loaded with any sort of sales or marketing jargon. This is our way of trying to give back to the ServiceNow developer community who have helped us to through the years get to this point. This first post will be our least technical post and will only go deeper from here. This is meant for developers.
As we’ve been researching and exploring using the Now Experience Framework (it goes by many names including Seismic, UI Framework, and UXF) we have been learning a lot and internally documenting thoroughly. With UXF being in its infancy from an adoption standpoint, we realize that a blog series like this would have helped us out tremendously and we want to share some of the knowledge we’ve gained the hard way with other developers in the ServiceNow ecosystem.
For a little bit of background of how we got to this point, VividCharts is a ServiceNow Technology Partner and we develop a data-visualization platform that lives entirely on top of ServiceNow (read more on our philosophy here). We have always put a lot of focus on visual and aesthetic control of ServiceNow data. So we have been heavily leveraging the Service Portal to date (more on this in a bit). Just by the nature of our product, we’ve always had to push the limits of how some of the ServiceNow tech was intended to be used and that will continue to be the case. We have begun the process of rebuilding our platform from the ground up in ServiceNow and have taken this as an opportunity to reevaluate our entire tech stack including our UI stack.
As part of our re-platforming, we have decided to use UXF instead of the Service Portal going forward. We are going to share what we learn along the way, including the hurdles we face and how we overcame or worked around them. We want to build this in public, so you can learn UXF more efficiently than we are.
How We’ve Been Using Service Portal
When we first started building our product in the beginning of 2018, Service Portal was the best and most flexible available framework for us to use. For those of you who can remember using UI Pages all the time, or heaven forbid CMS, you know what we’re talking about. We wanted to give users a way to get their data and dashboards into something that was presentation-quality with the least amount of time spent preparing and formatting the data. Service Portal has allowed us to do this. It might not be perfect, and there are certainly some quirks, but it has allowed us to accomplish our goals. A large majority of our application files today are Service Portal widgets.
Unfortunately, while Service Portal is a decent piece of technology, there are certainly issues (as I’m sure you are all aware). None of these issues were deal-breaking, but there is a big difference between “it works” and “it works well”. As our application expanded in scope and complexity, the organization of the Service Portal widgets, as well as aging tech (Angular 2) made things significantly harder than they needed to be. It was time for something better!
Our Investigation Into UXF
We began looking into UXF hoping it would be able to replace our Service Portal implementation with something much cleaner, faster, well organized and with performance that could really wow people. We set out with a goal in mind but we had to make sure UXF could work for our organization. We couldn’t just have it ‘work’, it needed to not only be able to replicate the functionality of Service Portal but offer some serious improvements to justify the cost of switching tech stacks.
When we began our exploration, UXF had been released for around a year. This was an ideal time for us as we figured the technology has had some time to mature. Unfortunately, we did suffer some initial setbacks. UXF is a big, big framework. Not only does it have its own quirks and intricacies, but it was built very similarly to the React framework, which comes with many of its own complications. If you haven’t figured out what I’m going towards, there is just a LOT to consider with UXF. ServiceNow has done their best to document and explain how UXF works, but at times the documentation can be hard to find, or done in varying quality. It was often enough to get something very, very basic up and running, but to do anything meaningful was largely uncharted territory.
All this meant we were faced with a simple problem. We had to roll up our sleeves and get to work picking apart the framework and just trying things out until it clicked. Thankfully, we were not alone on this journey as several others were instrumental in helping us to better understand what we were getting into. As such, before we go any farther I’d like to thank Brad Tilton who’s blogs and guides on the subject were amazing and really helped kickstart our exploration (seriously, I’d probably still be trying to figure out HTTPEffect without his excellent guidance). Another big shoutout is to Ashley Snyder (ashleysn) whose ‘working through now experience components’ blog was an absolutely amazing starter and is still something we recommend every new employee working on UXF to read. Her exploration into the CLI probably shaved weeks off our exploration and we are forever grateful. We also just want to say a quick thank you to the entire ServiceNow community. Whenever we would get stuck on something, we would always go to the community and it was truly amazing seeing so many developers come together to solve the many challenges UXF gave us all.
Despite all of the guidance we were still left with the challenge of actually figuring it out. Unfortunately, to some extent, there is no magic guide or video that just explains everything (well, maybe someday this series we hope!). When push comes to shove we just had to get in the weeds with the framework and just start building stuff. We initially just started small and didn’t even really integrate with ServiceNow instances. One of our earliest projects was just getting a button to display information on the screen. Then we started refining. Now that we have everything jumbled into one file, let’s split it up, make different components, make them modular and really push the limits of this super simple concept. After that it just became us layering on the complications. Maybe instead of the button creating things on the screen, what if we pull that data in from ServiceNow, and make the button trigger the collection? What if we used that information and made a basic pie chart out of it? Oh, that requires external libraries? Guess we are learning how to interact with external libraries.
I don’t want to give the impression that this was an easy process. Roadblocks happened early and often and there was almost never a quick or easy resolution. We used ServiceNow’s tutorials extensively, but sometimes they did not cover or even discuss the particular problems we were trying to solve. And with the framework still largely in the early days, there wasn’t much in the way of community answers. One thing that helped out immensely was that many of ServiceNow's own components are available for download from npm. By downloading their components, we could in essence reverse engineer them and figure out how ServiceNow engineers are solving the same problems that we were. This also led us to really digging into what seemed to be best practice in UXF.
Slowly but surely however, with great efforts come great rewards. The deeper we dug, the more surprised we were with the power and versatility of UXF. Things that would take considerable time in Service Portal were accomplished in mere minutes. The blazing speed and ease of use (once you figure it out at least) was seriously impressive. One by one, we solved all the problems we would have considered blockers. At the end of the day, it was clear to us, UXF was a truly incredible framework, it just had a very unfriendly shell.
How We Made Our Decision
There were many factors that went into our decision to use UXF as part of our re-platforming, but the 2 biggest were: 1. Strategic and 2. Technical Feasibility. Strategically, did we believe that UXF would become widely adopted throughout the ServiceNow ecosystem? Technically, did we believe that we could deliver on our ambitious roadmap with a new and maturing framework?
We have become extremely confident that UXF is the way forward. We’ve had countless conversations with our great partners at ServiceNow both on the product side and engineering side and the message was consistent: UXF is the future. You will see more and more usage of UXF by ServiceNow in the coming releases. You may have heard of the UI in San Diego project which is essentially changing every screen you see in ServiceNow to leverage UXF. We believe that this will be the first wave that is going to start pulling adoption very quickly. From there, we predict a lot of developer functionality and documentation surrounding UXF to start being released rapidly.
Technically, we realized that far from holding us back or restricting us, UXF has opened the doors to possibility wide open! It allowed us to not only solve any problem we encountered, but solve it in a way that we felt was vastly superior to Service Portal implementations. The underlying tech powering UXF (React) is an amazing technology that enables selective rendering greatly improving performance. Not only that, but the significantly decreased overhead means much faster performance. With queries potentially taking a considerable amount of time to perform, any performance increase that can achieve shaving off overhead is not only a welcome bonus for VividCharts, but passes down that impressive time savings to the user as well, creating a significantly improved experience.
I also greatly appreciate the organizational ability of UXF. By having full control over the structure of a component, we are able to organize our code in a way that is much more efficient to read and consume. This means that our work-speed is greatly increased and we can produce higher quality components much faster than we could struggling through large Service Portal implementations.
The speed of development by someone trained in UXF was not only much more impressive, but UXF provided a path forward towards solving the talent shortage so prevalent in ServiceNow. Unlike Service Portal, UXF is very similar to most front end frameworks in use by web developers. The usage of common front end design patterns and REST APIs are immediately familiar concepts for any web developer and onboarding one is significantly quicker and easier than trying to train someone on Service Portal. As a web developer myself, the paradigm of a React-like framework on the front end and REST APIs on the back end was something that was significantly more fun to work with and my team appreciated the move. All in all, it’s just something that is much more exciting for all involved!
Let’s also not forget that UXF is just one piece of the puzzle. With UI Builder growing by leaps and bounds, we can’t just look at UXF by itself. By integrating with UI Builder, the true power of UXF is unleashed and so many things that once would have been a struggle are now able to be done effortlessly. Linking components together in fun and interesting ways, using page parameters to customize the experience and many other really cool new features prove it’s hard not to feel as though the sky is the limit!
Summary
We are all in on UXF as part of our re-platforming. We might be just a little bit early for this move, but we think the timing is very close for us. In the coming weeks and months, we will be releasing more pointed blog posts in this series to address things as simple as getting the UXF CLI set up to more advanced topics such as creating full-stack multi-component applications. We hope that you find our journey helpful in some capacity. If you have any suggested topics that you would like for us to cover, please let us know. If you see us doing anything incorrectly or inefficiently, we would absolutely love the feedback. Thanks for reading!
Our next blog in this series will be about Getting CLI setup and the overview of architecture (linked here when available).
