Unused generated password clutter
I have a user story that happens over and over, and it's subliminally annoying. I haven't thought carefully about what behavior I want to see or would expect to see; I only note that the current behavior is not ideal.
It goes like this: I want to change my password on some site. It has unique password requirements. Perhaps I don't know what these are at first, and the first password I generate doesn't fit the requirements — it's too long. I shorten it and try again — oops, the @ character is disallowed. I generate a few more — some have a ) and others have a ( — both disallowed. Finally I generate a password that is accepted, and I update the login item. But now I also have six never-used generated passwords to delete. If I'm using the Safari browser extension, I think I even have to edit-delete-confirm them one-by-one. This is tedious to remember to do and tedious to execute when I remember to do it.
I'd like this workflow to work more smoothly, but I'm unsure what that would look like.
Comments
-
I'd like this workflow to work more smoothly, but I'm unsure what that would look like.
Welcome to our world! ;)
Seriously, though, this is a little peek at some of the issues we wrestle with. I agree with you that the Password Generator experience could be better...but we're still looking at ways to improve it that work for most users and don't have unintended negative consequences elsewhere, or for other users. Sometimes, there's no good answer to those questions -- at least none that presents itself immediately.
One of my longstanding pet peeves is sites that don't disclose their password restrictions to you until AFTER you've "violated" them. I put "violated" in quotes because how can you know if you've violated them if you don't know what they ARE? We could solve this by not recording generated passwords each time the Password Generator is used to fill on a page...but that runs the risk of you generating a password, saving it in the login item and (for whatever reason) 1Password failing to offer to save it, and you being locked out of your data since there's no available record of the password anywhere. Not a good solution. Other ideas we've had for this are either far too cumbersome (require a lot of coding or additional UI clutter/user input) or cause other potential problems. We'll keep looking for ways to improve it, but (unfortunately), I don't have anything to share on this issue just now. Thanks for bringing it up, though! :)
0
