When the beta extension is has been installed, the Ctrl+Shift+Y shortcut for activating the extension does not work (even though it is defined). It does not start working until after the user has deleted and redefined the keyboard shortcut for activating the extension.
If the browser extension is locked when pressing the Ctrl+Shift+L autofill shortcut or when a relying party prompts for a passkey, then the unlock screen appears in a popped-out floating window, instead of in the extension pop-up. I notice that the same (unexpected) behavior is also present in the stable version of the browser extension (2024.10.1).
This is especially problematic when a single login item stores multiple URLs (e.g., because SSO requires the same credentials for multiple unrelated websites). Even if the item does not have any associated collection or folder, at best, a single URL is visible without scrolling:
@jawp Thank you for your feedback. We will be releasing a new build to the Extension Preview listing on the Chromes store in the coming weeks that should include several of the improvements we’ve discussed in this thread.
Another information density example (in addition to the ones pointed out in previous comments here, here and here):
The new unlock screen (and presumably also the new login screen, yet to be unveiled) can now only display 26 characters of a master password — this is down from 40 characters in the current UI. As shown in the screenshots below, this is caused by the gratuitous margins in the new UI (“so modern!”), as well as the larger font size.
For Bitwarden users who follow best practices of using a master password that consists of a randomly generated passphrase, the average length of the password would be 31–47 characters (for passphrases containing 4–6 EFF words).
Therefore, when one needs to fix a typo in the entered master password (it happens — and not infrequently for those of us who are not skilled touch-typists), there is now a 15%–45% likelihood that scrolling will be required before the password typo can be found and corrected. This will increase the time that the master password must be visible on the unlock/login screen, which could create a security vulnerability.
Fonts used for displaying passwords should be able to make characters like O, 0, I, l, and 1 visually distinguishable. The current UI handles this very well (even color-coding numerals and special characters); in contrast, the new UI fails completely in this regard, as shown in the screenshot below:
FTFY. I sort of get why there’s a problem: any run-of-the-mill UI design person can put together something that has a look-and-feel comparable to what is currently trendy (e.g., round corners, vast expanses of empty space, sliding switches, etc.), but it is a completely different beast altogether to design for function. And most likely, whoever is currently working on the design doesn’t have as much experience with the core functionality of the product as do the long-time customers.
One thing that could help is for Bitwarden to engage the services of some experts to conduct rigorous usability testing studies. I would even be open to participating in a beta release that includes telemetry to measure what parts of the UI are accessed most frequently, how many clicks and scrolls are required to accomplish basic tasks, etc. The decisions made thus far are most definitely not data-driven or evidence-based, as they should be.
As this is a feedback thread on UI design (and in the spirit of the approaching Halloween festivities), does anyone else find the color palette … well, a little bit garish?
Although I should perhaps adhere to the dictum “de gustibus non est disputandum”, to me, these five shades of blue/green do not play well together, and some of the colors are just jolting in dark mode.
Did anyone already mention, that the Drag & Drop feature is no longer there? I couldn’t believe my eyes just now… such a great feature (especially when auto-fill is not possible), as it “circumvents” the clipboard (security) and avoids unnecessary clicks. - Really??
The only problem I’ve had thus far is with the password generator. I saw someone else in the thread mention an issue close to mine, but not exactly.
The issues I have are:
In the old plugin, it would remember the last “Length” setting. The new plugin reverts to 14 every time you flip away from it. I have a length of password I like to use (longer than 14), so it’s inconvenient to have to reset it every time.
Related to the above, the new plugin seems to have a 5-character minimum for the “Length” field. That’s not my issue, per se, but when I try to type in a number - say “26”, or “32” - the first number reverts to “5” every time. So, instead of getting “26” or “32”, I end up with “56” or “52”. Super irritating.
Other than that, no major problems. Again, love the new look.
Yes, I did notice that field values are no longer draggable (but I already made two comments in a row, and the Discourse platform has evidently been configured to not let you post a 3rd consecutive comment).
It’s a very unfortunate regression! Hopefully, this is under the category of “items still being worked on” (even though it was not mentioned in @kspearrin’s top post). @dflinn, any comment? @patrickhlauke, any insight/thoughs — are you able to re-do your work from PR 3321?
hmm, i admittedly wasn’t looking closely at any of this. seems it would be useful for me to go through this early preview from an accessibility point of view at least…
@grb@patrickhlauke Interesting (the PR)… If I understand it correctly, the situation is now even “worse” than it was at the time of this PR, since then at least username, password and TOTP were draggable. As far as I see it, not a single field is draggable in the current version of the Beta extension (seems to be indeed an “unfortunate regression”…).
That sounds very promising, but could you allow us power-users to provide feedback on what you had in mind? “Compactness” is in the eye of the beholder, and I’m hoping that your idea of “compact” is not reducing the password field height from 83px to, say 70px, which would barely make a dent in the problem.
A true compact mode design should aim for doubling the information density (in both the vertical and horizontal dimensions) compared to what you currently have in the “refreshed” UI, while also minimizing unnecessary mouse-clicks or taps.
And if you don’t intend to reverse the decision to put text labels in buttons (by using icons instead) for the default UI, then please at least use icons instead of text in the Compact Mode.
