Created attachment 394514 [details] The application picker dialog. The application picker lists a list of known applications (by what method it finds these I'm not sure of). The obvious (to me) method of single-clicking an application name - then clicking 'choose an application' instead launces a file find dialog. Perhaps 'Add an unlisted application' would be more appropriate text? Or should simply single-clicking the application name work? (en-uk)
Unfortunately, looks the width of this space is not enough at the current situation.
Severity: normal → minor
OS: Linux → All
Hardware: x86 → All
Whiteboard: [good first bug]
To fix it then, apart from replacing the text, it would need to resize the dialog, right?
Sorry, but I don't remember why I said the that time. Looks like the space is adequate, and the window can be resized.
Created attachment 8503807 [details] [diff] [review] Changed action text of Application Picker
Attachment #8503807 - Flags: review?(mak77)
Comment on attachment 8503807 [details] [diff] [review] Changed action text of Application Picker Hi Gavin, could you please review the submitted patch or recommend someone better to do so? Thanks!
Attachment #8503807 - Flags: review?(mak77) → review?(gavin.sharp)
Comment on attachment 8503807 [details] [diff] [review] Changed action text of Application Picker Thanks for the patch, Bruno! A technical nit: when we change strings, we need to also change the string references, so that the change is visible to localizers. So in addition to this change, we'd also need to change "ChooseApp.description" itself to something else - perhaps "chooseAnApp.description", and then also update the reference to it in dialog.xul (http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/handling/content/dialog.xul#37). This patch looks good with that change. That aside, I'm not sure I understand the motivation for the suggested change here. I don't quite understand the concern being described in comment 0, and I don't understand what's unclear about "Choose an Application" (seems even clearer to me than "add an unlisted application", because the meaning of "unlisted" isn't necessarily obvious in this context). Ian reported the bug over 5 years ago, so I'm not sure whether he's still available to clarify, but perhaps YF has an idea? I think the next steps here are to answer the "do we want to do this" question first - and if so, then submit a new patch taking into account my feedback above. If not, then let's call this WONTFIX, and perhaps we can find you another bug to tackle :)
Attachment #8503807 - Flags: review?(gavin.sharp) → review-
My understanding for this bug: the "Choose an Application" may be understood as an instruction, and the "Choose…" button may be understood as an operating premise. It may be too paranoid, but maybe really it happens. This is like a UX problem. No misunderstand: "Want to add an unlisted application?", but it seem slightly longer. I think the "Want to add an Application?" is a good choice.
I think I understand better now. Let's see if we can get some thoughts from our UX team.
The choose button is an expected navigation pattern for this action, used any time browsing your applications is necessary. Using a Choose button tells you that you are going to open the file chooser to pick software not already listed. You are choosing to add it to your list so the action is true. You still have the option to choose another after you add it to the list but the action still applies.
The vocabulary and phrasing (at least in english) is something we could easily test with users. The research questions to ask: Why is there misunderstanding among some users about the instructions of this dialog? How do those users misunderstand it? If there is misunderstanding, how can we alter the vocabulary to increase comprehension of the options provided and possible outcomes from actions taken?
Unless we have lots of spare research cycles, I don't think this bug is where our research resources are best spent (given how seldom users should encounter this dialog). That being said, I think there are some things we could do to improve the wording of this dialog: - Change »Choose an Application« to »Choose other Application« - Change »OK« to »Open in selected Application« (if that's too long we can also use »Open in Application« or just »Open link«)
What about changing "Choose an Application" to "Other Application" and "OK" with "Launch", so that it can be in consistency with the dialog title?
Created attachment 8738821 [details] [diff] [review] Bug 510516 - Changed text in application picker Hi, this is the first time I'm submitting a patch so I hope I'm doing it right. I'm not sure if this bug is still being considered for a fix, but I included the suggested changes from the comments. Could you please review this patch please? Thanks.
Comment on attachment 8738821 [details] [diff] [review] Bug 510516 - Changed text in application picker Review of attachment 8738821 [details] [diff] [review]: ----------------------------------------------------------------- Wayne, many apologies for taking so long to review this. It looks good, there's just one problem. I can fix it for you if you'd like, or you can post a new patch, let me know. ::: toolkit/mozapps/handling/content/dialog.xul @@ +44,4 @@ > <checkbox id="remember" aria-describedby="remember-text" oncommand="dialog.onCheck();"/> > <description id="remember-text"/> > > + <hbox class="dialog-button-box" align="right"> right (and left) should normally not be used since it assumes that all users use a left-to-right language. Instead you should use "end" (or "start"). But actually in this case what we want is the pack attribute, not align. So this should be pack="end". The reason is that for hboxes, align specifies how children will be aligned vertically; pack specifies how children will be aligned horizontally, which is what we want in this case.
Sorry for the late reply. I'm currently on exam week and I wouldn't mind it if you fixed it for me. Otherwise, I will post a new patch when my exams are over. Thanks!
Created attachment 8746684 [details] [diff] [review] patch v2
Assignee: nobody → zsw007
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox49: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 49
You need to log in before you can comment on or make changes to this bug.