216169 - Inconsistent naming sendpage/sendlink Send Page / Send Link

Status: RESOLVED WONTFIX

(Firefox :: Menus, defect)

Description

[Aaron Kaluszka]

This line in the patch to bug 173954 seems to be in error (the id should be
menu_sendPage to be consistent):
+                <menuitem id="menu_sendLink"  label="&sendPageCmd.label;" 
accesskey="&sendPageCmd.accesskey;"  command="Browser:SendLink"/>

Comment 1

[Michael Newton]

It seems the bug is referring to inconsistent naming within the code, but I
wondered why the context menu says "Send Link..." and the File menu says "Send
Page..."
I found some comments on it in bug 173954 but they didn't seem to go anywhere. 
To my way of thinking, "send page" means sending the page, not a link.  Should I
bother opening a bug, or would that just be petty (and WONTFIX)?
If it were changed, it would just be a further modification to the line in the
patch mentioned above.

Comment 2

[Aaron Kaluszka]

The context menu says "Send Page..." if you right click on the page but "Send
Link..." if you right click on a link.

Comment 3

[Michael Lefevre]

Calling it "send page" and then sending a URL is inconsistent with both Mozilla
and IE, where send page means sending the whole document in an email, and
sending just the URL is called "send link".

The command in the file menu and on the page's context menu should be labelled
"send link".

Comment 4

[Jon Henry]

I agree with comment #3, the menu item cleary does not send the entire page,
merely a link to it.

Comment 5

[Jon Henry]

I have a small patch for this, but before I go ahead and attach it, which
wording would people prefer? I initially tried "Send Page As Link", but I think
"Send Link To Page" sounds a little less clunky. Any thoughts or other suggestions?

Comment 6

[Jon Henry]

Attachment: Proposed patch

Since no one weighed in with an opinion, here's the patch I prefer. It changes
instances of "Send Page" to "Send Link To Page" (in the File menu and when
right-clicking in the content area), and "Send Link" remains unchanged (for
when right-clicking a link). I think "Send Page" should be brought back when/if
the ability to send the entire page as an attachment is implemented, since
that's the effect that wording implies to me.

Comment 7

[Peter Lairo]

I think "Send Link To Page" would be a *bad* choice. It sounds like your sending
a link to a page (e.g., What page are you sending that link to?). Usually, users
will be sending a link of the page they are *currently loking at*.

Better might be:

  For a Page: "Send Link" (i.e., keep it as it is)

  For a Link: "Send Selected Link", or 
              "Send this Link", or 
              "Send Link under Cursor"

PS. Sorry for not responding sooner - been a "biiit" busy lately. :-\

Comment 8

[Jon Henry]

Attachment: Patch v1.1

Peter's suggestions make sense to me, here's an updated patch. The File menu
option, as well as right clicking in the content area, both result in "Send
Link" being displayed. Right clicking on an actual link will display "Send This
Link". It also addresses the mismatched/conflicting entity names in the code
itself, I hope.

Comment 9

[Jon Henry]

Comment on attachment 138309 [details] [diff] [review]
Patch v1.1

Could you please take a look at this when you have time, Ben?

Comment 10

[Aaron Kaluszka]

Hmm, on top of this, we now have a File menu item called Send Page, but a Mail
toolbar button dropdown called Send Link yet they do the same thing...

Comment 11

[Bill Mason]

*** Bug 250451 has been marked as a duplicate of this bug. ***

Comment 12

[PikeUK]

It's getting worse, now we have two entries in the main menu hierarchy which
both do the same thing (bad enough) but which have different names, Send Page in
the File menu and Send Link in "Tools->Mail & News". Perhaps Send Page should
just be removed from the File menu now that Mail has it's own sub-menu in Tools?

Comment 13

[:Gavin Sharp [email: [e-mail]]]

These options have changed/been removed since this bug was filed, is this still an issue?

Comment 14

[Jon Henry]

Gavin: Yes, I think this is still an issue. The main problem:

Open the file menu: it has an option for "Send Link"
Right-click on a link: it has an option for "Send Link"

Despite identical names, they do not do the same thing. The first one creates an email with a link to the current page, while the second one creates an email containing the link you right-clicked.

It can be partially fixed by changing the context menu option to "Send This Link". Which is what my patch does. But now I think the File menu's "Send Link" is nonsensical. Send what link? And send it how? To who? Throughout the UI, nothing else refers to the current page or its URL as a "link", as far as I can tell. Unfortunately, I can't think of anything better.

Ideally, there would be "Email this page..." and "Email this page (as an attachment)" or something, which would provide better functionality and resolve the ambiguity. But in any case, I think changing the context menu item to "Send This Link" is a good start.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 138309 [details] [diff] [review]
Patch v1.1

This patch no longer applies.

Comment 16

[Jon Henry]

Attachment: Updated to trunk

After 3 years, my motivation to keep updating this patch has waned, but here's one last version.

Comment 17

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 242784 [details] [diff] [review]
Updated to trunk

(In reply to comment #16)
> After 3 years, my motivation to keep updating this patch has waned, but here's
> one last version.

That's understandable :). I can't do much about that other than tell you I won't take 4 years to review it, and I can check it in for you once I grant +. A couple minor things:

>Index: mozilla/browser/base/content/browser-context.inc
>-                <menuitem id="menu_sendLink"  label="&sendPageCmd.label;"  accesskey="&sendPageCmd.accesskey;"  command="Browser:SendLink"/>
>+                <menuitem id="menu_sendLink"  label="&sendLinkCmd.label;"  accesskey="&sendLinkCmd.accesskey;"  command="Browser:SendLink"/> command="Browser:SendLink"/>

copy-paste error?

You also forgot to remove sendPageCmd.label and sendPageCmd.accesskey which are now unused as far as I can tell.

Comment 18

[Jon Henry]

(In reply to comment #17)
> (From update of attachment 242784 [details] [diff] [review] [edit])
> (In reply to comment #16)

> >Index: mozilla/browser/base/content/browser-context.inc
> >-                <menuitem id="menu_sendLink"  label="&sendPageCmd.label;"  accesskey="&sendPageCmd.accesskey;"  command="Browser:SendLink"/>
> >+                <menuitem id="menu_sendLink"  label="&sendLinkCmd.label;"  accesskey="&sendLinkCmd.accesskey;"  command="Browser:SendLink"/> command="Browser:SendLink"/>
> 
> copy-paste error?

Yup!

> You also forgot to remove sendPageCmd.label and sendPageCmd.accesskey which are
> now unused as far as I can tell.

You're right.

Attaching a revised patch, thanks for getting back to me on this.

Comment 19

[Jon Henry]

Attachment: Revised

Comment 20

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 242801 [details] [diff] [review]
Revised

r=me, but I think it would be a good idea to not re-use the "context-sendlink" ID for the context menu item (in case extensions rely on it for positioning), so please change it to something else, like "context-sendpagelink".

Comment 21

[:Gavin Sharp [email: [e-mail]]]

Beltzner: the only UI effect that this patch has is changing "Send Link..." in link context menus to "Send This Link...".

Comment 22

[Jon Henry]

Attachment: Updated to comments

Thanks, Gavin. I changed the name of that id. Carrying forward your r+, if that's alright.

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 242887 [details] [diff] [review]
Updated to comments

>-<!ENTITY sendLinkCmd.label            "Send Link..."> 
>+<!ENTITY sendLinkCmd.label            "Send Link...">

I wonder if "Send Page Link..." might be better, but Jon's thought about this a lot longer than I have.

>+<!ENTITY sendThisLinkCmd.label        "Send This Link...">
>+<!ENTITY sendThisLinkCmd.accesskey    "d">

This is obviously better.

Comment 24

[Wayne Mery (:wsmwk)]

Jon, look like this never checked in. Will you be requesting that?

Comment 25

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I believe this will be bitrotted. Jon, would you mind to check that? Thanks!

Comment 26

[Jon Henry]

I'm sure it has bitrotted sometime in the last 2.5 years :) I no longer have a Mozilla build environment and don't plan to do any work on it.

Comment 27

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks Jon. So lets remove you as assignee.

Alex, could you give an update how the ux team is seeing this?

Comment 28

[Alex Faaborg [:faaborg] (Firefox UX)]

>Open the file menu: it has an option for "Send Link"
>Right-click on a link: it has an option for "Send Link"
>
>Despite identical names, they do not do the same thing. The first one creates
>an email with a link to the current page, while the second one creates an email
>containing the link you right-clicked.

While the names in isolation are ambiguous, the interface as a whole works ok.  Menus are usually meant to be read as a full command, like "file print" or "view source" so in this case the command is "file send link" where "send link" acts on the "file."  In the case of the context menu, we draw a focus ring around the item that the user clicked on, giving them a visual indication of what the commands are going to operate on.

>It can be partially fixed by changing the context menu option to "Send This
>Link"

Reverting to the use of "this" to try to disambiguate would result in adding it to nearly all of our contextual commands (print this, email this, bookmark this, copy this email address).  And the word "this" by itself is still ambiguous, so I don't see why that would help.  Also, in terms of human interface guidelines, as far as I know none of the platforms recommend the term "this" to set context.

Comment 29

[Alex Limi (:limi) — Firefox UX Team]

Resolving based on Faaborg's comments.