View all projects Lingoport Command Center
Command Center is a project/product that I have been creating over the last 2 years during my employment at Lingoport. Command Center is Lingoport’s all-in-one continuous internationalization (i18n) and continuous localization platform. It has been my primary focus at Lingoport, and it’s the company’s most important product right now.
Lingoport has two main product lines. Globalyzer is a static application scanner, and accompanying tools, to help development and i18n teams find and fix i18n issues, such as embedded strings, or currency formatting issues. And Localyzer is a family of localization products that connects, integrates, and automates the interactions between large complex codebases and virtually any translation management service. Command Center is a singular platform for all configuration, running, and reporting of both Globalyzer and Localyzer projects.
Before I started the Command Center project, the user experience for all Lingoport customers was quite fragmented, and it had a negative impact on the overall usability of the product. Users would do all of their project configuration and running on one system that ran Jenkins, an open-source CI/CD platform, alongside a Jenkins plugin that we developed. In order to read the reports and take actions on the projects that they just configured and ran, they then would have to switch over to an entirely different system, which we called “Lingoport Dashboard” that ran a custom-forked version of Sonarqube, an open-source static application security testing platform. It was clear there was a lot of room for improvement, but also a lot of work to do to get there.
I started out the Command Center project by finding out what aspects of the existing platforms our existing customers did actually like and want to keep. But also searching for their biggest pain points and ways I could improve the experience. One of the biggest takeaways from those interviews was that the process of creating/onboarding a new Localyzer project was very confusing, and taking way too long. The user was just bombarded with fields to fill out without any meaningful organization; there was so much to configure and many people didn’t know where to even start.
Before even designing the user interface, there was still so much planning to do: the user stories, the flow of the pages and how they relate to each other, and more. I made sure to dive deep into the details of the old onboarding process, and figured out the most elegant way to group relevant information together and break it down into a guided multiple step process.
After many iterations of UX research and planning, I started using Figma to create UI prototypes for Command Center. As a developer first, and (admittedly) a designer second, I was able to design everything with development in mind, avoiding dreaming up wild ideas that would be too hard to implement in code, while also doing just a few *slightly* wild things that I knew for sure I could code. Despite that however, I knew I wasn’t going to be the only developer on this project once it passed the design phase, so I was constantly collaborating with the rest of the development team, getting their feedback and making sure we would be developing the product that we all wanted to create together.
For the last almost two years now, we’ve been developing Command Center as a team of 3 developers. While I have done plenty of full-stack web application development for this project, I have also been leading all front-end development efforts, as a bit of a carry-over from my starting role as lead designer. Through these front-end projects that I’ve been leading, I’ve been prioritizing developing an accessible, usable, and (importantly to our company) easily internationalizable user interface. Leading the front-end UI to a brighter future has also resulted in me doing some quite intense back-end tasks.
One such project has been introducing React.js into our old-school stack. Adding yet another library and tool to a complicated stack was not a decision we took lightly, but our original stack consisted (mostly) of just Groovy/Grails, a traditional MVC framework for the JVM, and it was exclusively a server-side-rendered stack. But we were developing our own highly specialized continuous integration platform, the kind of platform that has statuses of things changing all the time, lists that are growing and shrinking, multiple users online at the same time taking, all taking actions that affect the other users. Trying to use an exclusively server-side-rendered stack for this resulted in UI performance that was sometimes fine, sometimes a little embarrassing, but sometimes downright unusable in certain situations. For that reason I was able to convince the rest of the team to adopt React.js and to start replacing server-rendered views with client-rendered views, starting with the ones where UI performance was the most important. But adding a new technology to an old web stack is like trying to teach an old dog new tricks, it just isn’t that easy. From setting up Gradle build tasks such that my teammates didn’t even need to install Node.js on their system, to creating a pipeline such that the client/React.js views could access the same i18n messages as the server could, I needed to set up everything. There was a significant multiple week investment in back-end engineering before I could even get to the front-end React.js work! But once I did, it definitely paid off. Later on in this post, you’ll find a demo video of Command Center, and it shows off much of the work that spawned out of this project.
Localyzer String Manager
The most recent project that I’ve worked on for the Command Center product has been a new feature under the Localyzer product family called String Manager. String Manager provides localization managers and developers with important visibility into the externalized strings of a project, giving them crucial information about the string keys, values, source files and line numbers, translation status (whether the string will be sent in the next translation kit, etc.), and even provides a review and review recommendation system so that quality of the source strings can be ensured before they are ever even sent to translation. It’s an incredibly powerful tool. And the video below shows just how easy it is to get so much information. But it was also a wonderful project for me to work on too. It was my first opportunity since the original Command Center ideation to revisit the whole process of planning, designing, iterating, and repeating all over again - and I really enjoyed it. After creating the Figma design and UI prototype, there was plenty of full-stack development to do, but I had teammates to help with that, and so I really got to focus most of my efforts towards creating a front-end that is really functional as a tool, easy to understand and learn, and also quite nice to look at too!
Iconography and Logo Design
One of my favorite side quests that I have gone on at Lingoport has been Logo design. It started out pretty innocent, but eventually it turned into me redesigning every logo the company has… oops.
I have plenty of graphic design experience from both my graduate and undergraduate degrees at ATLAS, and something I opted in for when designing Command Center was to create every icon within the application from scratch. This was mostly done for fun, and to keep myself engaged and entertained (sometimes worker happiness is more important than efficiency), but it also had the added benefit of thematic consistency within the application. I personally think it looks pretty nice because of that. This *naturally* led to me designing the logo for Command Center as well, after all, it was a new product, so it needed a new logo. And *naturally* enough those two tasks combined together into creating new logos for the existing Globalyzer and Localyzer products. After all, these were products of their own that existed before Command Center, but now Command Center was to “house” these products, and therefore referenced them constantly, and to be honest their old logos really stuck out like a sore thumb amongst the rest of Command Center’s consistent iconography. But Localyzer isn’t just one product, it’s a whole family of products, so I *naturally* I had to redesign the logo for Localyzer Express and Localyzer QA as well. And then when presenting my new logos to the CEO, he liked them so much that *naturally* he asked me to redesign the company logo itself. And… wait… how did I get here?
All jokes aside, I’m super grateful to both my manager, and the CEO of Lingoport for giving me the creative freedom to redesign every single logo that existed within the company. It’s an opportunity that I’m honored to have been given, and the results are something that I’m really quite proud of too! I kept everything within existing brand colors, so this was really just a logo overhaul, not a brand overhaul. And the changes to the company logo itself were more evolutionary than revolutionary; the only really noticeable change is that I capitalized the first letter, not only to match all the product logos, but also because I feel it projects a much more professional image of the company.
