Apple’s 10.4.3 update includes a nice surprise: the search field for the Keychain Access application is now case-insensitive! How many times I’ve fumed and fussed about this shortcoming. At last I can search for “etrade” and find a note called “ETrade info.”<\/p>\n
\nThough vastly improved, by no means is the Keychain Access application perfect. In fact, this application and associated technologies are one of those “treasure troves” of undesirable behaviour. Often while looking more carefully at an unfortunate behavior, with the intention of reporting a bug, my attention ends up snowballing into a series of observations of how an application could be better designed.<\/p>\n
\nWith Keychain Access, a major area it is still lags in is the keyboard navigation department. Now that I can easily search my keychain items, it would be nice to be able to do so without ever reaching for the mouse. At this point I have a keyboard shortcut set up to open Keychain Access, and from within the application I can press Cmd-F to start a new search. But when I see the beautiful shining result in the filtered list, there’s no way to navigate back to it! Pressing Tab from the search field does exit the search field, but it switches focus to the “Keychains” sidebar table. Who wants to navigate to that? Pressing Tab again switches focus to the “Category” table. Arrow-keying through the various items in this table causes a live update of the main table, but no amount of tabbing will get you there. It’s a “next responder dead end!” (Radar 4327828<\/a>).\n<\/p>\n \nOnce I’m focused on the main table, there are other hiccups. It took me a while to figure out that I can in fact bring up the secure item’s “info dialog” by pressing Cmd-I. This shortcut is attached to little “i” button at the bottom of the screen, and unfortunately is not available from any menu item. The friendliest way to handle this would be to have the tableview interpret “return key” as a signal to “open the selection.” The return key is often interpreted as a request to either open or edit a selected item. In this case, by opening the Info dialog, it would do both. (Radar 4327871<\/a>).\n<\/p>\n \nBut anyway, at least I can get info! The fun stops there, however. I am looking at the info window, but the thing I want to see: the secure note, web password, whatever, is hidden from me. I can see the checkbox that needs to be clicked to reveal the secrets, but I soooo don’t want to reach for the mouse. There should be a “Show Secrets” keyboard shortcut for any secure item that has such a checkbox. (Radar 4327842<\/a>).\n<\/p>\n \nIn the process of trying to figure out whether there was a convenient shortcut for “show secrets” in the info dialog, I managed to stumble into accidentally editing the item. When I closed the item, a dialog came up asking me if I’d like to save the changes. I tried the typical “Don’t Save” shortcut: cmd-D. No such luck. The “Save” button is throbbing blue so its keyboard shortcut is taken care of, but the “No” button seems to require a manual mouse click. As a long-shot try, I press “Cmd-N” to match the “No” of the button’s text. At first this seems to work, but instead something very fishy happens. Pressing Cmd-N, even while being faced with a modal sheet in the Info dialog, invokes the application’s higher-level “New Keychain Item” functionality. The Info window and its pending sheet disappear and a sheet appears on the main window asking for details about my new item. I thought the window had been dismissed, but later I found it hiding behind the main keychain window. It had simply been ordered backward. The “Save Changes” dialog should support a keyboard shortcut for “Don’t Save.” (Radar 4327889<\/a>).\n<\/p>\n \nLet’s assume all the above bugs get fixed, and I’m sitting pretty in Keychain Access land. I hit my Keychain Access keyboard shortcut, press cmd-F, search for “etrade,” navigate to the main table, press return to open the item, press a keyboard shortcut to reveal the secret password, and am faced with the “Keychain Access wants permission” dialog. First of all, isn’t this the Keychain<\/strong> Access application? I’ve just unlocked my whole keychain. We’re staring at my repository of goodies. Can’t you work out a deal or something? You seem to be “in good” with the Keychain. Once you show the secure text for an item, you can choose to “Always Allow,” but that only gives permission for that specific item! So you’ve got to enter the password and click “Always Allow” at least once for every freaking item in your keychain. There should at least be a preference for easily saying “Always give Keychain Access access to secure items.” (Radar 4327935<\/a>).\n<\/p>\n \nI thought maybe I could do something spiffy like go in and manually set all of the items to allow Keychain Access to access them. Since you can “preload” this setting in the “Access Control” pane of an item’s info window, I thought maybe I could select all of my items and add the same access privilege for Keychain Access to them. Oops! I selected all 500+ items and hit Cmd-I. Now I’ve got 500+ Info windows cascading across my screen. To add insult to injury, Keychain Access doesn’t support a “Close All Windows” option, though quitting and relaunching did the trick. (Radar 4327956<\/a>).\n<\/p>\n \nHaving to give individual authorization to each and every item wouldn’t be so bad if the authorization dialog itself wasn’t so poorly keyboard-navigable. The dialog pops up, asks you to give authorization (by typing of course… at the keyboard!) and then you have to go over to the mouse to click either the “Deny,””Allow Once,” or “Allow Always” items. Gah! Presumably this is done to prevent somebody accidentally giving permission to a malicious application, but you’ve got to enter the password before doing so<\/em>! That gives me plenty of opportunity to think twice before allowing or denying the action. At least the “Allow Once” button should be default and automatically clicked upon hitting return from the password dialog. The “Always Allow” button should ideally also have some keyboard shortcut. (Radar 4327981<\/a>).<\/p>\n","protected":false},"excerpt":{"rendered":" Apple’s 10.4.3 update includes a nice surprise: the search field for the Keychain Access application is now case-insensitive! How many times I’ve fumed and fussed about this shortcoming. At last I can search for “etrade” and find a note called “ETrade info.” Though vastly improved, by no means is the Keychain Access application perfect. In […]<\/p>\n","protected":false},"author":10,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,12],"tags":[],"class_list":["post-51","post","type-post","status-publish","format-standard","hentry","category-applebugfriday","category-usability"],"_links":{"self":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts\/51","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/comments?post=51"}],"version-history":[{"count":0,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts\/51\/revisions"}],"wp:attachment":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/media?parent=51"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/categories?post=51"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/tags?post=51"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}