75.85 KB, image/png
4.85 KB, patch
|Details | Diff | Splinter Review|
3.07 KB, patch
|Details | Diff | Splinter Review|
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.
Created attachment 607527 [details] 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.
Yes, that should be just fine. Jenzed, can you come up with some feature documentation to populate the popup window ?
Andreas: Do we have a stick question mark, or "help" icon that we can use here? -Mike
Created attachment 608816 [details] [diff] [review] 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.
So, who is going to create the Filelink "Learn more" page, and what URL will it be at?
I can provide a text. As for the URL, I have no idea: can Sancus or Mark propose something ?
I'm sure we can find somewhere on our vast web server to put a page, given content.
Though, on second thought, isn't this really a good use of a knowledge base article?
(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
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.
Created attachment 610125 [details] [diff] [review] Patch for comm-aurora Sorry Blake, more for the review queue. I'll try to steal a few more from you today. :)
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.
Created attachment 610131 [details] [diff] [review] Patch for comm-central This patch introduces a new "Learn More..." string for the compose window.
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 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.
Created attachment 610879 [details] [diff] [review] Patch v2 for comm-central (carrying over r+/ui-r+ from bwinton) Thanks! Fixed those issues.
Attachment #610131 - Attachment is obsolete: true
Attachment #610879 - Attachment description: Patch v2 (carrying over r+/ui-r+ from bwinton) → Patch v2 for comm-central (carrying over r+/ui-r+ from bwinton)
Created attachment 610886 [details] [diff] [review] 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.
Landed in comm-central as http://hg.mozilla.org/comm-central/rev/ccb4559ce25b
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 14.0
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.
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
Attachment #610886 - Flags: approval-comm-aurora? → approval-comm-aurora+
Committed to comm-aurora as http://hg.mozilla.org/releases/comm-aurora/rev/a183704a5449
status-thunderbird13: --- → fixed
(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
The article title and contents are fixed.
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).
(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
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..."
(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.
(In reply to Mike Conley (:mconley) from comment #26) What about the popup iso a tab ?
(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?
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.
(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.
You need to log in before you can comment on or make changes to this bug.