Let me explain.<\/p>\n
Suppose your company’s revenue drops off. You learn that over the past quarter, revenue coming from mobile app has declined significantly.<\/p>\n
<\/p>\n
You dig further. App downloads<\/a> are unchanged. App performance<\/a>\u00a0is\u00a0unchanged. App crash rates<\/a> are\u00a0unchanged and low.<\/p>\n In fact, the only change is in the UI. You’ve released several new versions over the past few months. So, some of these UI changes must be causing the revenue dropoff, you guess.<\/p>\n You decide to do some user research. Show them old and new versions of the UI and ask which they prefer.<\/p>\n But no one has a record of what the old UI looked like. Those designs are lost, washed away by the passing of time like a sand castle in surf.<\/p>\n It’s crazy that, in 2018, we have accounting systems to track our company finances, CRM to manage sales process — heck, we even have apps to manage our houseplants<\/a>!<\/p>\n But there’s nothing to manage the application user interfaces that drive revenue for modern businesses.<\/p>\n Like I said: crazy.<\/p>\n So how do we fix this?<\/p>\n We were amazed that, with so many businesses driving the bulk of their revenue through web and mobile apps, there wasn\u2019t a way for product teams to track the visual evolution of their apps. So we built one.<\/span><\/p>\n We call this UI Version Control. It’s like a wayback machine<\/a> for your apps.<\/p>\n UI Version Control lets\u00a0you build software smarter by capturing the entire visual history of your apps, so you have a record of what\u2019s been changed, by whom, and when — and what should be rolled back if the need arises.<\/span><\/p>\n Most important, UI Version Control directly links changes in the UI to underlying code changes<\/a> in your GitHub code repository. This clarifies what code commits need to be undone in order to fix a user interface change that has hurt the user experience or revenue generation.<\/p>\n This helps your company on a number of levels.<\/p>\n They can release more frequently, secure in the knowledge that they know what code changes to make to roll back a feature that didn’t pan out.<\/p>\n They can begin to view application features as experiments — some of which\u00a0will work, and some won’t — and iterate their way to an optimal UI.<\/p>\n They can de-risk the user-facing aspects of their Digital Transformation projects — many of which are at risk<\/a>, due in part to lack of a system of record for digital transformation<\/a> — because they have a way to back out of digital dead ends.<\/p>\n So how do you derisk Digital Transformation?<\/p>\n Before UI Version Control, Applitools showed only baselines in the context of test results from the test results manager, and you weren’t able to view the history of a test baseline.<\/p>\n That’s all changed.<\/p>\n With UI Version Control,\u00a0you can see the history of all your test baselines in each branch, compare them to prior versions of your baselines<\/a>, and revert to an earlier version if necessary. You can do this by selecting \u2018Save as latest\u2019 from the baseline options menu. So, if you accidentally accepted a baseline that you shouldn\u2019t have, you can undo your mistake.<\/p>\n UI Version Control works just like source code version control<\/a> that you, or your developers, are already familiar with. Visual baseline branches can be merged in the same way that code changes are merged. <\/span><\/p>\nIntroducing UI Version Control<\/h2>\n
Move Fast and Fix Things<\/h2>\n
With a UI System of Record<\/h2>\n
![\"Applitools](\"https:\/\/applitools.com\/wp-content\/uploads\/2018\/04\/Baseline_History_Screenshot-3.png\")
![\"User](\"https:\/\/applitools.com\/wp-content\/uploads\/2018\/09\/tm-merge-with-conflict.png\")
![\"Applitools](\"https:\/\/applitools.com\/wp-content\/uploads\/2018\/04\/Applitools-Baseline-Comparison-NEW.png\")