I expect this to be possible and will be prioritising it providing that the user feedback for the new main menu interface is positive enough.
@hellcry I’ve merged your topic into this one since it appears to be essentially about the same subject. @pasbec, I think your concerns are most closely aligned with the issues @hellcry raised.
Regarding changing the URLs as a solution. It’s common that websites have more than one way to access a login page, even if just by appending different query string or hash fragment information to them. It probably doesn’t work for a small percentage of websites but I don’t think it’s even close to being an unworkable solution.
For the 2nd potential solution, it’s impossible to say how many modifications would need to be made - it will depend upon how many entries you have and what their current configurations are like. In a lot of cases you might be able to simply add the correct ID to a single entry and have it all work from then onwards but you’ll know the setup of your entries better than I do - I’m only talking about the general case so I’m sorry if this doesn’t apply exactly to your situation.
I do appreciate that it will be a bit of effort to reconfigure things suitably in order to retain the “auto-fill of a single preferred entry” behaviour, and that in rare cases it may not be possible at all. Unfortunately, this use case for the old Priority override feature was not previously known to us.
Regarding the use-case of wanting to override the order of entries in the matched entries list, which appears to be the most common aim among those complaining about this change in v3.5, I’ll address a variety of the questions posed below.
The order you see now is the correct order in all situations - this is ordered by the quality of the match between the entry and the form on the web page. Previously, the Priority override could mess up the order because the override was associated with a specific entry and not with a specific web page / sign-in form.
The feature was introduced to Kee early on so that incorrect ordering could be manually overridden. Such instances of incorrect ordering now happen so rarely, if ever, that the feature no longer serves this purpose. I appreciate that for some people the override feature had the unintended side-effect of allowing you to define a preferred visual order for the entries and that some of you may have used it this way without being aware of the long-term support status for the feature.
I appreciate that for some people the consistency of this visual ordering was important and apologise for the stress involved due that ordering now being different and no longer controllable through the same method. I did think of the impact of this change many times over many years and can broadly summarise the conclusions again here:
- For users with a small number of matching entries, the order is not a hugely important factor because all entries are easily reachable in the list of matched entries - the only drawback here is a case of the one-off unexpected change in position.
- For users with a high number of matching entries, the order is already far less useful than an effective search feature because it takes so long to scan down the list to find a specific entry. Thus, with the release of the new matched entry filtering feature, the marginal benefits in this situation are also less important than with earlier versions of Kee. There is still the additional drawback of the one-off unexpected change in position of course, but this is unavoidable unless the feature was left exactly as it always was - something that was never going to be a realistic option.
Why is it not realistic? During user testing, no users found the priority override feature understandable. It does not behave in a predictable way in all circumstances and can be especially poor for those users who have multiple databases to maintain or have entries that provide access to more than one website. It overrides the correct accuracy score in a way that impacts which is the “top match” - while @hellcry has shown that this quirk can be used in a positive way once understood, most people do not achieve this level of understanding so the more likely outcome is unexpected form filling or submission of entries - something that can have far more serious consequences than the visual ordering of matched entries.
I appreciate that some of the problems with the old feature might not seem relevant or important to you, but they are facts and many users will benefit from the removal of the old feature so I’m not prepared to get into a discussion about the reasons or motivations for the change.
As for whether we can “implement it again” or “undo the change”. Essentially the answer to the latter is a definite “no” but for the subtly different former question, “maybe”. If we can design a suitable replacement feature that does not suffer from the complications of the old Priority override feature, I’d be happy to incorporate it, although I cannot commit to being able to dedicate much time to the feature myself so it may require a code contribution from someone else - we can decide this if we get to a point where there is a workable solution planned out.
Again, I am sorry that I did not have enough time in recent weeks to pull all this information into one place as part of the release notes for v3.5. In future, please note that these sorts of changes are generally released to the beta channel first - we don’t know how things would have worked out if any of you that are upset by this change had engaged in discussion about it before the release of v3.5 but obviously the more time that we have to talk about the issue, the more likely we could reach a viable solution before a change gets released to all users.
You have probably now understood that I consider the original implementation of the priority feature a mistake. I understand that if you have found a way to use that mistake to your advantage, you will be upset that I have now removed it. I am not against the idea of allowing matched entries to be reordered through some mechanism but the previous priority override feature was not the correct way to go about implementing that feature.
I am happy to work with anyone who wishes to engage in a positive way on new features to support your preferred way of working with Kee.
