Closed Bug 929903 Opened 8 years ago Closed 7 years ago
place cursor in Address Book search field upon open, instead of focus on first contact in address book
User Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release) Build ID: 20130910160258 Steps to reproduce: Opened address book. Actual results: The cursor (insertion point) was not in the Search box. Expected results: The cursor (insertion point) should be in the Search box when you open the Address Book. This would make things much faster, since when you open the Address Book, you usually use the search function.
I don't find a duplicate of this request. And users with muscle memory may expect this behavior to not change. ctrl+K gets you there quickly. But I'm sympathetic to the idea because 99% of time I go to address book to search and I do ctrl+K. I don't go there to start typing the first characters of someone's name and have it take me to some name. Blake, what are the generally accepted rules of focus with regard to focusing search fields in windows.
Severity: normal → minor
Summary: Address Book Suggestion - place cursor in the search box upon open → place cursor in Address Book search field upon open, instead of focus on first contact in address book
When you go to www.google.com or www.bing.com, the cursor is automatically in the search box, which makes things much faster. I don't see why to have the same in the Address Book.
(In reply to shmuelw1 from comment #0) shmuelw1, thank you for this nice and well-formed RFE. > Expected results: > The cursor (insertion point) should be in the Search box when you open the > Address Book. This would make things much faster, since when you open the > Address Book, you usually use the search function. I tend to agree that using AB quick search is the most likely / most frequent scenario after opening AB. (In reply to Wayne Mery (:wsmwk) from comment #1) > I don't find a duplicate of this request. And users with muscle memory may > expect this behavior to not change. ctrl+K gets you there quickly. Inital focus in AB quick search box, as proposed by this RFE, would be even quicker ;) We would not break muscle memory of those who use Ctrl+K to get into the search box now (because cursor would just be and stay where they want it anyway). I can't imagine reliable other muscle memory scenarios which this RFE could break, on the contrary, this RFE would certainly assist people with muscle memory as the search is much more efficient and versatile in finding contacts than using the list, as Wayne describes below. It's also much easier to find the right contact using search because all irrelevant entries will be filtered away, so there's a visual feedback where it's easier to verify if user found what he was looking for (vs. one selected contact in the middle of many others). Compare typing a name in contacts list, vs. typing the same name in AB quick search box, which is better? However, I'd suggest that we make the tab-cycle consistent with main window, so tab-ing out of AB quick search should first go down into results list (as when you tab out of main 3pane qfb, you first get to the message list). That's also more logical because shift+tab from AB quick search would then take you to list of ABs, which makes sense because it's "get out of this AB and go one level up to the list of ABs". > But I'm sympathetic to the idea because 99% of time I go to address book to > search and I do ctrl+K. I don't go there to start typing the first > characters of someone's name and have it take me to some name [in the message list]. +1 (so Wayne and I in support of this idea).
Severity: minor → enhancement
Blake, another potential 1 minute ui-r :) STR 1 Open AB 2 Look for certain contacts (most likely / most practically using AB quick search, by typing a search word) Actual Result - after opening AB, focus is on first contact of contacts' list - need to manually shift focus into AB quick search box before searching - mouse click into AB QS, or - 2x Shift+Tab (not very intuitive), or - Ctrl+K (undocumented in UI, needs new Bug) Expected Result - after opening AB, focus should be in AB quick search box, to allow immediate searching (and if you want focus in msg list, it's only single click or 2x TAB to get there). I'd agree with reporter that it's a reasonable assumption to make that the most frequent scenario after opening AB is to search for contacts using AB quick search. That scenario will be more efficient if we have the initial focus on the search box. Benefits of this RFE: - make the most useful/frequent scenario after opening AB more efficient by sparing users from having to shift focus manually into search box - typing a name in search box is much better UX compared to typing a name with focus in list of contacts: - immediate filter removes irrelevant contacts and let you focus on reduced result set - if you mistype your search word, easy to correct (not possible by typing names directly in contact list) - quick filter is more versatile/successful to find matches because it searches more fields with "contains" logic (contacts list can only find contacts based on name matches exactly as they happen to occur in current setup of contacts list). As explained in my previous comment, I don't see any relevant disadvantages with this RFE.
So, since typing the first letter of a contact would bring you to that contact in either mode, I think we can probably make this switch without too many complaints. (We also don't let you do _that_ much from the address book with the keyboard, so it's not like many people are going to complain that their keybindings don't work anymore. I hope. ;)
Comment on attachment 821017 [details] Screenshot1: AB with initial focus (cursor) in AB quick search box (per this RFE) (I don't think that a screenshot is a meaningful way to get my feedback on this issue, so I'm cancelling the ui-r? But as you can hopefully tell from my previous comment, I'm in favour of this idea. ;) Thanks!
Blake, thanks for rapid response :) To reduce the potential for complaints after this change, can we also streamline the tab cycle to become ux-consistent with the clockwise tab-cycle already found in main 3pane window? The main benenfit here that after searching, you'll just need to press TAB *once* to get into results list (currently requires 2x TAB, which feels clumsy and unnecessary). Current tab cycle (top-down, left-right): 1 Contacts list > 2 Contact details > 3 AB quick search > 4 List of ABs Proposed tab cycle (clockwise; swap 3 and 4): 1 AB quick search > 2 Contacts list (quick search results) > 3 Contact details > 4 List of ABs (In reply to Thomas D. (away till 23rd Oct) from comment #3) > However, I'd suggest that we make the tab-cycle consistent with main window, > so tab-ing out of AB quick search should first go down into results list (as > when you tab out of main 3pane qfb, you first get to the message list). > That's also more logical because shift+tab from AB quick search would then > take you to list of ABs, which makes sense because it's "get out of this AB > and go one level up to the list of ABs". Imo it would be very inviting and helpful for volunteers who might want to fix this to see at least your feedback+ on the screenshot. A screenshot says more than 1000 words... ;) (in this case, even a screenshot with annotation inside the image, plus comment explaining the new behaviour and its benefits). Imo it's also VERY encouraging to find [has ui-review+] in whiteboard, so that if I'm a volunteer and I'm looking for something to fix, I'll know there won't be any big UI discussions when I pick this up, and it won't get rejected after I've already spent a lot of my precious time on writing up a patch without knowing if the UI is acceptable. That's notwithstanding the need and benefit of ui-reviewing the final patch. :)
shmuelw1 (reporter), would you like to try and fix this yourself? We depend on volunteers doing this... (and we'll assist as required)
Status: UNCONFIRMED → NEW
Ever confirmed: true
That's a pretty screwed up tab cycle IMO. But I think it should be a separate bug. And changing cycle has potentially more impact for the small but important accessibility community. Indeed they might have some thoughts of how it should change for them. Blake, thanks for the quick comments. I agree with Thomas that some form of (pre)approval status would be helpful, because NEW status on enhancement bugs means nothing. My work is done here. :) Thanks all.
@Thomas: Thanks for having confidence in me to allow me to fix it myself, but I'm just I'm not a programmer, just a user :)
Wanted in Seamonkey too.
Version: 24 → Trunk
Fix contains also the Seamonkey version, but untested.
Comment on attachment 8503491 [details] [diff] [review] patch Personally I'm not interested in taking this for SeaMonkey, the search input is only a shortcut key away.
Comment on attachment 8503491 [details] [diff] [review] patch Review of attachment 8503491 [details] [diff] [review]: ----------------------------------------------------------------- I like it! r=mkmelin
Attachment #8503491 - Flags: review?(mkmelin+mozilla) → review+
OK, dropped the Seamonkey part. Carrying over reviews for TB.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 36.0
Backed out for orange - https://hg.mozilla.org/comm-central/rev/21b318bbe902 https://tbpl.mozilla.org/php/getParsedLog.php?id=52171545&tree=Thunderbird-Trunk&full=1#error4
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This should do it. Aryx, please push to try server.
Attachment #8511678 - Attachment is obsolete: true
Comment on attachment 8519491 [details] [diff] [review] patch v2.2 Thanks, seems to have worked.
Attachment #8519491 - Flags: review?(mkmelin+mozilla)
Comment on attachment 8519491 [details] [diff] [review] patch v2.2 Review of attachment 8519491 [details] [diff] [review]: ----------------------------------------------------------------- Looks good thx! I'll try to land it in a moment
Attachment #8519491 - Flags: review?(mkmelin+mozilla) → review+
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.