Experiment #4 – New interface in 1Password.com’s vault view

1P_Rob

In my testing, when switching between the new and the old, it takes about 2 seconds to load the old version and about 3 seconds to load the new version. We will continue optimizing, but there are a couple things working against us that might be useful context:

The new version is a separate app that doesn't load until you click into it. The old version is part of the same app as the sign-in screen, home page, profile page, etc., so navigating within that app is snappier, but switching between old and new gives a clearer picture of total load time.

I just did some more testing on a couple different machines, both with fairly high-spec and very modern hardware, and I think I may have found why you're seeing faster speeds than I am: switching directly back and forth between the old and new versions, they old version loads in about 3 seconds, and the new one loads in around 4, so slightly slower than your machine but still but still pretty close together. However, that's not how I actually use 1Password normally. Most often, my method of launching the 1Password web app is by either creating or editing an item from the browser extension. Doing that a few times in a row starting from an empty browser window with the old UI takes right around 3.5 seconds every time, while the new UI took 6~10 seconds on one machine, and 5~8 on another. Looking more closely at the "switching back and forth" approach, another difference is that the old UI automatically loads the first item in the list, and the new one doesn't load anything, saving it a bunch of extra work. I'm curious if you see the same slowdowns as I am if you ask it to load a more complex view right off the bat.

In general, 1Password is different from many web apps because there's an awful lot that has to be done in your browser rather than on a server. We can't do much of anything until your data is decrypted, and that can only happen in the browser.
I can appreciate that on its face, but when you've already established a baseline of what's possible with the old version, your cold-boot times shouldn't be getting worse.

We believe it's already better from a perspective of functionality and stability, though, and not everything requires more clicks than before.
Like I said, updates over the last year or two in the browser extension are a much stronger example of this (like burying even "Edit" of all things in a menu), and I'm only starting to see the same early warning signs over here. For example, looking at a non-editing view of a saved login: the item's creation date, something I'm rarely specifically looking for but is often helpful context to see, is no longer shown by default, and the add to favorites button has also been moved under a 3-dot menu along with sharing history. None of those are exactly world-ending, but I certainly don't like the direction. I've got a ton of screen space and I'd like less of the pixels to be white.

Other than revealing a password or displaying in large type, what actions are you frequently trying to do that take longer now than before?
Honestly, the performance is the really big one. Everything else is less about doing any one specific task, and more like someone's moved all my furniture around by a few inches so I keep stubbing my toe on things I didn't expect to be there. I know right where everything should be, and suddenly it's not there.

Even if the new version may have some new functionality, I don't like things changing on me if I didn't purposely install an update. If and when I want to optimize my existing workflow any further, that should be my decision.

This whole thing was almost as big of a mental hurdle for me to get over when initially considering a SaaS password manager as was the concept of handing over total control of all my credentials to a third party and storing them on their servers instead of safely on my local machine. In general, I much prefer local software under my complete control, and strongly prefer to keep most updates strictly to security and stability.

Finally, this isn't something I expect any explicit support for, but I do a fair bit of customization of various sites and webapps with extensions like Stylus and ViolentMonkey. Any major changes are going to mean I have to redo all that work, and as has been the trend with a lot of the popular frontend frameworks lately, the new version has more opaque markup that makes it more difficult to find elements on the page, including random characters at the end of every class name that typically mean I can't trust them to stay stable (although thank you for at least not using Tailwind). I fortunately haven't been doing too much of that stuff with 1Password, mostly because I can't easily do the same inside the extension popup which is what really needs it, but the couple cosmetic tweaks I've gotten used to are still one more thing that makes the new UI feel even more foreign, and will also take up more of my time (just once, not repeatedly) if I decide to take a stab at re-implementing them.

we now have a keyboard shortcut for revealing passwords too: Ctrl-R.
That's hardly ever a thing I personally, do, but... we're talking about the web UI, right? Ctrl+R is a fairly universal shortcut in every browser I'm aware of for reloading the page. I'm not sure what browser you're using, but I know I don't let webpages override core browser controls, so Ctrl+R would do sort of the opposite of revealing a password. I certainly wouldn't want to rely on that override being possible, since it seems like the sort of behavior that could get patched out of any browser that currently allows it at any time.

However, most importantly:

The new version is, well, new, and just hasn't had all the wrinkles ironed out yet. There are a few specific areas we're planning to tune in the coming months.

We're still polishing up a few things, but we're getting close to replacing the old experience with the new one permanently.
"replacing the old experience with the new one permanently" sounds an awful lot like "disabling the old experience" to me, and given all the things that are still under active development, I really hope that's not the case. I can't believe I have to say this, but shipping a half-baked redesign is not a good thing. The older version works fine (I would even argue "much better" given the performance difference), so this isn't some emergency situation where a "good-enough" rewrite is needed ASAP. There's a difference between having a public beta period and outright developing in production, and while making the beta version the default is a bit of a gray area, turning off the stable version definitely crosses that line. And even if you don't like calling an unfinished codebase that runs consistently slower than its predecessor "beta," there's nothing wrong with keeping a "classic" version around until its replacement can manage to go at least a month or so without needing any big changes.