737348 - Filelink notifification should display a 'What's this ?' link to a Filelink feature description

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Jb Piacentino]

The current Filelink notification bar can appear impromptu without the user ever heard of Filelink. In this context, a link should point to the feature description, shown in a popup window. 
The help content is TBD but needs to be localized.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Attachment: Wireframe

Blake and I discussed this change before string freeze, and I believe the solution we came up with was to use a question mark icon within a button.  See attached screenshot.

Comment 2

[Jb Piacentino]

Yes, that should be just fine.
Jenzed, can you come up with some feature documentation to populate the popup window ?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Andreas:

Do we have a stick question mark, or "help" icon that we can use here?

-Mike

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Attachment: Patch v1 (for Aurora)

This patch is specifically for comm-aurora, because it hard-codes in a "?" string for the new button I've added (this is the compromise that bwinton and I came up with, since we obviously don't want to add any new strings).

For comm-central, I will prepare a separate patch that will include a "Learn more" string instead of the hard-coded question mark.

When clicking the "?", notice that the URL loads in a contentTab. Currently, I'm pointing it at https://support.mozillamessaging.com/, but clearly we need to find a real URL for it.

As soon as someone lets me know what the real URL will be, I'll update the patch.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

So, who is going to create the Filelink "Learn more" page, and what URL will it be at?

Comment 6

[Jb Piacentino]

I can provide a text.
As for the URL, I have no idea: can Sancus or Mark propose something ?

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Bump

Comment 8

[Andrei Hajdukewycz [:sancus]]

I'm sure we can find somewhere on our vast web server to put a page, given content.

Comment 9

[Andrei Hajdukewycz [:sancus]]

Though, on second thought, isn't this really a good use of a knowledge base article?

Comment 10

[Mike Conley (:mconley) (:⚙️)]

(In reply to Andrei Hajdukewycz [:sancus] from comment #9)
> Though, on second thought, isn't this really a good use of a knowledge base
> article?

Yeah, actually, I think you're totally right.

Roland / Jen: what would be the best way for Jb to set up a "Filelink" page on support.mozillamessaging.com?

-Mike

Comment 11

[jenzed]

In general, you can create a new KB page through this link: https://support.mozillamessaging.com/en-US/kb/new (after creating an account). However I'm glad to do it for you. 

Stub page (use this URL as the link from the icon): http://support.mozillamessaging.com/kb/file-link

Jb: you can edit that page, or send me the content you'd like to see, or just wait until I start doing the docs for the related release.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Attachment: Patch for comm-aurora

Sorry Blake, more for the review queue.

I'll try to steal a few more from you today. :)

Comment 13

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 610125 [details] [diff] [review]
Patch for comm-aurora

I may have found a "Learn More..." string we can re-use in comm-aurora.

Once I get the OK to use it, I'll pump out a new patch.

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Attachment: Patch for comm-central

This patch introduces a new "Learn More..." string for the compose window.

Comment 15

[Jb Piacentino]

Suggested text is here: https://support.mozillamessaging.com/en-US/kb/file-link/discuss/516

jenzed: can you please proof and make sure this is understandable ?
And of course, comment !

Comment 16

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 610131 [details] [diff] [review]
Patch for comm-central

The UI seems fine, so ui-r=me.

>+++ b/mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties
>@@ -457,8 +457,10 @@ cloudAttachmentListFooter=%1$S makes it 
> 
> ## LOCALIZATION NOTE(cloudAttachmentListItem): A line of text describing a cloud
> ## attachment, to be inserted into the message body. Do not translate the words
> ## %1$S, %2$S, %3$S, or %4$S. %1$S is the attachment name, %2$S is its size,
> ## %3$S is the name of the cloud storage service, and %4$S is the link to the
> ## attachment.
> cloudAttachmentListItem=* %1$S (%2$S) hosted on %3$S: %4$S
> 
>+learnMore.label=Learn Moreâ¦
>+learnMore.accesskey=L

So, I think these lines should go up before the bigFileShare.label lines.
And, it looks like "bigFileShare.accesskey=l", so I worry about using "L" for Learn More…
How about "m" instead?

r=me with those changes.

Later,
Blake.

Comment 17

[Mike Conley (:mconley) (:⚙️)]

Attachment: Patch v2 for comm-central (carrying over r+/ui-r+ from bwinton)

Thanks!  Fixed those issues.

Comment 18

[Mike Conley (:mconley) (:⚙️)]

Attachment: Patch v2 for comm-aurora (r+ / ui-r+ from bwinton over irc)

This patch is nearly identical to the patch for comm-central, but has two important caveats:

1)  We borrow a string from messenger.properties
2)  We don't have an access key to the "Learn More..." button.

But of those issues are dealt with in the comm-central patch.

Comment 19

[Mike Conley (:mconley) (:⚙️)]

Landed in comm-central as http://hg.mozilla.org/comm-central/rev/ccb4559ce25b

Comment 20

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 610886 [details] [diff] [review]
Patch v2 for comm-aurora (r+ / ui-r+ from bwinton over irc)

bwinton gave me the ol' thumbs up over IRC.

Comment 21

[Jb Piacentino]

The feature name is Filelink and should be referred as Thunderbird Filelink in external communications. 
The support article title should therefore be 'Thunderbird Filelink' and not 'File Link' (2 words) 
https://support.mozillamessaging.com/en-US/kb/file-link

Comment 22

[Mike Conley (:mconley) (:⚙️)]

Committed to comm-aurora as http://hg.mozilla.org/releases/comm-aurora/rev/a183704a5449

Comment 23

[Mike Conley (:mconley) (:⚙️)]

(In reply to Jb Piacentino from comment #21)
> The feature name is Filelink and should be referred as Thunderbird Filelink
> in external communications. 
> The support article title should therefore be 'Thunderbird Filelink' and not
> 'File Link' (2 words) 
> https://support.mozillamessaging.com/en-US/kb/file-link

Jen:

Are you able to update the support page to reflect this?

-Mike

Comment 24

[jenzed]

The article title and contents are fixed.

Comment 25

[Jb Piacentino]

Two more comments on this:
- I think it would be nicer if we could have a 'popup' window, instead of a tab: the user can read the information, close the window, while still having the compose window visible in the background
- Is the SUMO article the best place to display this help text ? This page is full of navigation items that can be confusing to users. Can we locate this somewhere else and format is in a way that better correspond to a help text? 

Finally, the feature name is Thunderbird Filelink. The current page should be renamed or a new one created with the right title (and the old one deleted).

Comment 26

[Mike Conley (:mconley) (:⚙️)]

(In reply to Jb Piacentino from comment #25)
> - Is the SUMO article the best place to display this help text ? This page
> is full of navigation items that can be confusing to users. Can we locate
> this somewhere else and format is in a way that better correspond to a help
> text? 

There are other instances where we directly link to the knowledge base from within Thunderbird.  For example, when a plug-in crashes in a content tab, a support link appears in the "broken plugin" content frame.  That support link is a knowledge base article that opens up in a new content tab.

Another case is when the user goes to Help > Help Contents - we open up the knowledge base in the default browser.

I would argue that having the page be hosted on the knowledge base makes sense for two reasons:

1)  It's internally consistent with the other two cases I listed above
2)  It might allow for an easier on-ramp for contribution, since (I believe) we already have a fairly active community working on the knowledge base.

I'm, however, always open to argument. :)

-Mike

Comment 27

[jenzed]

I think adopting another platform / mechanism for deploying documentation is a big project and can't be approached on a one-off basis. If we wanted to do this, we would have to scrape content from the knowledge base so that we don't have to manually update two versions. 

Regarding "Thunderbird Filelink" - sorry, I added an erroneous capital - I'll fix. Do you really mean you want all instances where we refer to "Filelink" to be changed to "Thunderbird Filelink"? As in, "Thunderbird Filelink enables you to .... With Thunderbird Filelink ... To access Thunderbird Filelink..."

Comment 28

[Jb Piacentino]

(In reply to jenzed from comment #27)
> I think adopting another platform / mechanism for deploying documentation is
> a big project and can't be approached on a one-off basis. If we wanted to do
> this, we would have to scrape content from the knowledge base so that we
> don't have to manually update two versions. 
Fair enough.
> 
> Regarding "Thunderbird Filelink" - sorry, I added an erroneous capital -
> I'll fix. Do you really mean you want all instances where we refer to
> "Filelink" to be changed to "Thunderbird Filelink"? As in, "Thunderbird
> Filelink enables you to .... With Thunderbird Filelink ... To access
> Thunderbird Filelink..."
Yes. "Thunderbird Filelink" is the feature name. It might be shortened to Filelink if the context is not ambiguous or has previously been defined. No other spelling should be used, IMO.

Comment 29

[Jb Piacentino]

(In reply to Mike Conley (:mconley) from comment #26)
What about the popup iso a tab ?

Comment 30

[Mike Conley (:mconley) (:⚙️)]

(In reply to Jb Piacentino from comment #29)
> (In reply to Mike Conley (:mconley) from comment #26)
> What about the popup iso a tab ?

Blake - thoughts?  Should I file a bug to open the link in the browser instead?

Comment 31

[Blake Winton (:bwinton) (:☕️)]

A popup that came out of the "Learn more" button?  I'm not a fan of that, and we don't do that sort of UI anywhere else as far as I know…

The Account Provisioner stuff all opens in the browser, but that's mostly because it's a modal dialog, and you wouldn't be able to read the page if we tried to open it in a tab.

Further, I don't think hosting a full, editable, SuMo page in a popup would work out well, since it could change length at any time.

So I think the current solution is the one we want to go with, even though it will work out better once we get compose-in-a-tab.  Perhaps focusing the newly-opened content tab would help address JB's concerns?

Thanks,
Blake.

Comment 32

[Mike Conley (:mconley) (:⚙️)]

(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #31)
> So I think the current solution is the one we want to go with, even though
> it will work out better once we get compose-in-a-tab.  Perhaps focusing the
> newly-opened content tab would help address JB's concerns?

Just a note that we already focus the new content tab after spawning it.