Hello,
I find there is a lot of useless strings, most can very easily replaced by icons and tooltips. After few minutes of use, what might have been confusing is now known with the tooltip (or manual/help).
Here is a quickly made ascii-layout, don’t pay attention to spacing/alignments.
All tabs are visible, no need of second level tabs.
In this capture, we are on the password tab.
History on the right clock-in-round-arrow icon
Password field on 2 lines, regenerate and copy icons on its left.
It can be also manually edited, so you can for example remove unwanted char or add some kind of small mnemonic chars.
Its width can be very small, minimum would be something like the LlIi10Oo ambiguous characters option. All tab icons become a single burger-menu icon.
Everything can be set/unset via keyboard without having to use the mouse at all.
New forbidden characters field at bottom right.
On this matter, it would be far simpler to have only 1 checkbox with authorized special characters:
[ & ( ) $ * -+*/ ]
Here is a second version.
Must enhance the tabs area as it is not color-blind friendly, should be the usual tab style… Quickly made with html-css & fontawesome.
To make further comparison, this is like comparing Asus’ bloated Armoury Crate with seerge’s incredible GHelper. (niche mention i know, but i’m certain all asus laptop users will resonate with me.
I would agree, but I think one of the big reasons is it looks like the color choices were what I would choose. (I am not a graphic designer so they’re gonna be ugly.)
Note: I updated the title: 1. adding the recently and mostly used term “compact mode” and 2. referencing all apps in the title (the tag was already set to app:all before).
Even though the tag was set to app:all, a functional Compact Mode UI makes most sense for the apps that have viewports of limited size (browser extension & mobile). I believe that the OP was proposing a design for the browser extension, since they mention using a keyboard or mouse to interact with the UI.
However, although Bitwarden does seem to adhere to a design philosophy of making UIs match (as much as possible) for different apps (and especially for the browser extension & mobile UIs, which have very similar size and aspect ratio), I feel that this is a flawed approach.
To most effectively use the browser extension, frequently used actions should be near the top (to speed up access by mouse or by keyboard tabbing). In contrast, a mobile app UI benefits from having key actions docked at the bottom of the screen, where they can be accessed by thumb presses.
In mobile apps, there is also a limit on how compact one can make a “Compact Mode” before it becomes too difficult to interact with UI elements using a finger. In contrast, for the browser extension, a much greater level of compactness is possible (and desirable, to maximize information density). Another important factor is that scrolling is more painful in a browser extension than on a phone screen, so it is much more important to minimize scrolling when designing for a browser extension.
For these reasons, I believe that it would be better to have separate feature request threads for compact UIs in the mobile app vs. in the browser extensions. Although there may be some commonality in the fact that increased compactness may be desirable for both cases, if the detailed discussion in the thread is going to include specific design proposals (like the ideas shared by the OP above), then suggestions for the browser extension UI will not be relevant to the mobile app UI and vice versa.
Of course. On the other hand, if you have a preference for “compact views”, you can also feel that desire while using the desktop app or web vault.
Probably. But the desktop app and web vault also are better usable with a keyboard or mouse. (unless you have a touchscreen)
Well, I think I agree that “as much as possible” can be (or is) problematic. - I think we agree that the UI should be somewhat consistent across devices/apps, but the properties of those devices/apps have to be considered as well.
Hm. Definitely agreed for mobile. – For desktop/browser, I’m not so sure (only think of the taskbars usually being at the bottom of the screen – but I have not done extensive research here…).
Generally agreed. But don’t forget, that the mobile app can also be used on tablets, which are at least somewhat larger than phones.
I can understand your points, I think. And also, that the technical side / codebase etc. behind the apps, and also the usage differs between the apps (e.g. no autofill for the web vault, but the browser extensions, mobile app, and the desktop apps… the latter of course only announced right now ). But I would see it differently here.
First, I still think, that there may be a “need” (or request) for a compact mode in all BW apps. Maybe especially with the new UI, that is 1. “spacier” and 2. sooner or later applied to all apps, that “need” is larger than before. (e.g. I think the dialog boxes we have in the browser extension now, will also look the same on the desktop app and the web vault… the latter may already be somewhat adapted → you could want those dialog boxes to also be more compact in those apps…)
(and I think, as you also acknowledged, as BW tries to keep the UI consistent, it could even be argued, that a compact mode should also be available for every app)
Then, if we had four/five feature requests for all four/five apps (browser extension, desktop app, web vault, mobile app, authenticator app), one would need 4-5 votes if it was very important for someone. That’s a bit impractical, IMO.
And, maybe suggestions for a specific app are irrelevant for all other apps. But maybe they aren’t. – It may even be the case, that a suggestion for a certain app turns out to be impractical for that app, but is surprisingly a good idea for another one of the apps.
One idea I just go - but certainly burdensome for the designers and developers - would be to define levels of “compactness” (that would be apt for the properties of the respective app)… like “a bit” / “medium” / “very”.
So, I think I generally prefer more “centralized” feature requests (as I wrote before, also because of the limited number of 20 votes, but also to reduce “duplicate” requests that only differ in the targeted app - and to keep the discussion a bit more “centralized”…).
But, you are the “senior” here and you decide what to do now.
). But I would see it differently here.