Easier filtering of logins/forms per site

I can literally have 40 forms or logins saved for a single site. This becomes a bad UX with how 1password mini currently works. The two problems are:

1. Favorites don't list at the top

2. The "search" searches entire database instead of just filtering the list for that current site.

Can you improve the UX here? When we are at a website, calling 1password mini from browser extension, why in the world would we want to search the entire 1password database? I say when at about:blank you can search whole database (even though i never use that feature). When you are at a website, the "search" should be just filtering the list of forms saved FOR that website.

AND whats the point of favorites if all they get is a tiny yellow blob on the icon? They should be at the top.

QUESTION: What is your ordering logic for the list anyway? My lists seem completely random, sometimes seems alphasorted but then not. This adds to the frustration as the list is just completely random from a user perspective.

Thanks for the great software! I'm a critical person who develops UI/UX, and this is my only gripe, which means you are doing a FANTASTIC job!!! :love:


1Password Version: 6.8.2
Extension Version: Not Provided
OS Version: 10.13
Sync Type: WLAN

Comments

  • littlebobbytables
    littlebobbytables
    1Password Alumni

    Hi @flyingman,

    So favourites should be at the top of any matching Login items. By matching I mean the ones instantly listed by 1Password right below the search field based on the FQDN (Fully Qualified Domain Name) of the open site. If favourites aren't at the top it suggests we're looking at a subdomain of the registered domain and either you have a mix of FQDNs through your Login items or a potentially an option is enabled in your preferences, one that I'm leaning towards suggesting we remove as I fail to see the good it does. The option I speak of is in the Browsers tab of 1Password's preferences and it's titled Allow filling on pages that closely match saved websites. This causes confusion because it treats all URLs as if they have no subdomain for matching and can mess up the expected ordering if you use multiple subdomains on a single site.

    So questions I have include:

    1. Do these 40 Login items span multiple subdomains on this site?
    2. Is the option I mentioned enabled?
    3. Are the various Login items set up for specific subdomains or do some only contain a generic entry for the registered domain even if they are only used on a particular subdomain?

    The normal ordering with default settings is to first filter based on the registered domain. We then split this into groups of those that match the FQDN and everything else. We then split each of these into groups based on their favourite state. We then order each of these four subgroups alphabetically based on title and then they are listed in order of FQDN (favourites), FQDN (non-favourites), non-FQDN (favourites), non-FQDN (non-favorites).

    The search is global because a primary use is to find a unrelated Login item and instruct 1Password to initiate open and fill. I don't think we ever envisaged it required for filtering matching Login items when it was designed. Filtering only the matching Login items would tend to only benefit a very small number of people for just a few sites. I'm sure you would agree that 40 Login items for a single site is an outlier rather than the norm. For the vast majority they are likely to see one or two items at most for any given domain and they are used to search being global. I'm not a UI developer but I imagine creating a UI that addresses both groups while not offering any confusion or clutter wouldn't be a sleepwalk. I could be wrong of course but something we do try to avoid doing is simply throwing more options into 1Password to try as each option does bring its own set of considerations.

    I'm wondering if we get the ordering addressed though whether the search becomes less of an issue.

  • flyingman
    flyingman
    Community Member
    1. No, for that example, it was actually a google login page that had over 40 logins
    2. The option is not enabled
    3. Sometimes I specifically setup a login without schema or subdomain so that it'll match what I need, but in this case, being google, i think you already know your software matches the many domains/subdomains google uses for its barrage of services. So some of the logins are just for https:///adwords.google.com while others for accounts subdomain and so on.

    If you split ordering to ensure matches appear, then consider adding some UI to show the groupings - you dont have to name the groupings, just like a horizontal rule or something to show a "new section" of matches.

    I can understand your power users get the shaft because they are the minority, but good UX likes to consider minority and majority as one and think more in terms of what "makes sense". Changing your UI behavior now could and probably would cause confusion, so I call it an unfortunate early mistake, since it makes MORE sense that it filters matches for currently visited website. When using MINI from system toolbar or when using it from about:blank, then search entire database. So while that definitely makes more sense, it wasn't done, and changing it now is probably not a good way to go. But, easy way to solve it is to simply add an option to preferences:

    "Search filters matched entries if any"

    And there you've solved the issue and have built a UX that caters to all your users instead of just the majority of them.

  • littlebobbytables
    littlebobbytables
    1Password Alumni
    edited October 2017

    Hi @flyingman,

    So if you have 40 or so Login items relating to different Google accounts and they all only contain a generic https://www.google.com or https://google.com then 1Password should be treating the all equally no matter what subdomain you are currently visiting. In that scenario favourites should always be at the top and then a simple alphabetical ordering of the favourites and then the non-favourites. If you're seeing something else that would deviate from the behaviour as I understand it.

    If you however have a number set to say https://accounts.google.com they would be favoured over any set to just https://www.google.com or https://google.com regardless of whether they are marked as favourites when specifically on the accounts.google.com subdomain.

    The suggestion of visually flagging the different groups seems pretty reasonable. I know the menu is a weird object but we use horizontal lines elsewhere there so I can't imagine there's a technical impediment.

    I understand that it doesn't seem unreasonable to add another option but first it's this, then it's another equally reasonable request and if you're not careful you end up with a mass of options. We are very conservative when it comes to adding new options and our developers would like to prune if at all possible. It isn't that we intend to ignore power users and we are willing to consider and reconsider any aspect in the bid to improve 1Password so even if I'm saying it's unlikely that doesn't mean 1Password will always behave as it currently does and maybe one day will better care for your preferences. We would look for demand for any such change though so this post is a start and others are free to indicate this is also something they wish to have seen but never told us about. It's one of the reasons I am glad we have these public support forums.

This discussion has been closed.