Closed Bug 723761 Opened 13 years ago Closed 12 years ago

Implement small library to show FB/Twitter share buttons on click only

Categories

(mozilla.org Graveyard :: Webdev, task)

Product:
mozilla.org Graveyard
Component:
Webdev
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: wenzel, Assigned: pmac)

References

(
URL
)

Details

Attachments

(2 files)

Social Media Button Assets
17.44 KB, application/zip
Details
Facebook social text cut off
22.72 KB, image/png
Details
cmore points at a prototype for this in bug 701759 comment 26. The idea is to not *load* a regular Twitter or Facebook button until the user clicks on "share", so that we don't leak user data by default.
Assignee: nobody → ocoutts
I talked to CB and the designs are nearly complete and thus will be able to move forward with the development of this shortly. As soon as the PSDs are available, I will update this bug with a link to them.
Assignee: ocoutts → nobody
High-fidelity mock ups: * default - http://cl.ly/0v1M0q3u263o2a1Z3G07/o * open - http://cl.ly/0L2c1w3e3q2U3C1z0X15/o PSDs are coming soon.
Is it possible to design a version that encompasses the heart icon, share link and arrow into one button? It makes the perceived clickable area more obvious.
(In reply to Bram Pitoyo [:bram] from comment #3) > Is it possible to design a version that encompasses the heart icon, share > link and arrow into one button? It makes the perceived clickable area more > obvious. Bram, interesting feedback. I believe this works exactly as you've mentioned. The heart, share, and arrow are one action v. many. The arrow is included in the design to help set the expectation that the area will expand, an interaction that is very useful on smaller mobile screens. In the ux-phase, I did a lot of playing around with the concept, and we're pleased with this first pass for production. I'm sure in the coming months Ty and I will iterate on this. Thanks!
Just making sure that everything looks, feels, and is actually clickable, and we’re good to go!
Owen: The PNG and PSDs are in bug 725759. Let me know when you have the first pass working even if it is a bit rough. Thanks!
Owen, please ping me with questions about the user interaction.
Assignee: nobody → owen
Hey Owen. Just wanted to see if I could get an estimate on when you will have a working model that we can test? We have some sites that could benefit from this soon and wanted to get an estimate from you.
Attached file Social Media Button Assets —
Owen: Here you go!
Margin around social media buttons is 12px on all sides.
Additional hex colors: arrow bg: fcfcfc popup box bg: ffffff popup box shadow: e5ddcf arrow box shadow: e0e0e0 arrow box border: d2c7b8 red: af3232 black: 484848
Blocks: 724107
Hi everyone, I have some beginnings that I was hoping to get some feedback on from everybody. I have two sizes right now. Small: http://people.mozilla.org/~ocoutts/SocialShare/small.html Large: http://people.mozilla.org/~ocoutts/SocialShare/large.html I'd like to get some feedback before I finalize things so I thought I'd put it up here for the group to see. Two things to note: 1) I haven't put in the arrow. In the box. Its coming, I just haven't been happy with the way it looks when its been cut out of an image. 2) On the large view, g+ is a few pixels shorter than the other icons. There isn't much I can do about that without violating TOS.
Owen, I think this looks great! My main comment is about the user experience. For both the small and large versions, clicking the 'Share' button opens a blank sharing container for me while the individual share buttons load. The first time I clicked the 'share' button, the container was 1) initially empty 2) then had a plain text link to 'Tweet' and 3) then the buttons loaded individually. I'll also note that this wasn't much of an issue when refreshing the page - the buttons loaded almost instantly. Do we know if this delay is caused by loading the buttons from the individual social networks? Ideally, we'd want to have the buttons appear at the same time. One possible workaround is to having a loading placeholder animation appear in the container until the buttons have loaded. Not sure if this is worth looking into but wanted to mention it. Everything else is great. I think the g+ sharing box is good as is.
Hey hey, Looking good so far. My initial thoughts (and I know this is just the beginnings but want to outline the details) based comparison to the mockup: http://cl.ly/3t0q0W2u2b1i1j0h2F1N - align the boxes similar to the mockup (centered under dropdown in small, centered under full module cta in large) - would be good to see it with the proper clickable button styles to get a better feel - are we adding the side arrows in the small version? that isn't in the mockup. - would be good to tighten up the "Share this" text with a bit of letter-spacing - can we use the heart glyph from the mockup instead? that one looks horizontally stretched. - with Ghostery installed, nothing shows up, so I was a bit confused at first! :)
A few more things to add: - The link color needs to be changed to match the global link color on the site which will change depending on which site style is active - The white container box is missing a 1px dropshadow - There also needs to be a 24px spacing between the images and container box edge
> Do we know if this delay is caused by loading the buttons from the > individual social networks? Ideally, we'd want to have the buttons appear at > the same time. One possible workaround is to having a loading placeholder > animation appear in the container until the buttons have loaded. Not sure if > this is worth looking into but wanted to mention it. Hi William. It appears the time delay from the user input of a click to the time that all of the buttons loaded is something outside of our control. Normally those are items that happen onLoad of a page thus the delay is isn't that a problem. Since we are executing that code on user click, the delay is very obvious and there is all sorts of externally hosted JavaScript that is executed. I have discussed this already with Owen and he is going to investigate showing an animation while everything is loading and then finally displaying the buttons. The only "grey" area with this is that to accomplish this animation, we will need to obscure the buttons for a second or two while everything loads. Obscuring is against the TOS of each of the providers thus that implementation has some problems. I think it is small issue as the obscuring is only happening for a brief period of time and it is solely to improve UX and not to do anything negative with the external services. If we can do it technically, we should confirm with legal that they are willing to take this additional small risk. Owen: comments?
(In reply to Chris More [:cmore] from comment #16) > I have discussed this already with Owen and he is going to investigate > showing an animation while everything is loading and then finally displaying > the buttons. The only "grey" area with this is that to accomplish this > animation, we will need to obscure the buttons for a second or two while > everything loads. Obscuring is against the TOS of each of the providers thus > that implementation has some problems. I think it is small issue as the > obscuring is only happening for a brief period of time and it is solely to > improve UX and not to do anything negative with the external services. If we > can do it technically, we should confirm with legal that they are willing to > take this additional small risk. Thanks Chris - this approach sounds good to me.
I think Chris summed this issue up pretty well. I will remove the tweet placeholder text.
William: Just to make sure we are on the same page. Is your vote to have the loader animation onClick until all the buttons are loaded even though it violates the TOS for a brief few seconds?
(In reply to Chris More [:cmore] from comment #19) > William: Just to make sure we are on the same page. Is your vote to have the > loader animation onClick until all the buttons are loaded even though it > violates the TOS for a brief few seconds? Yes, exactly.
To clarify comment 20, I'm alright using this approach as long as our privacy team is okay with the risk. It's also a gray area as to whether or not this violates the Facebook TOS - we don't know for sure. cmore, can you confirm this risk is okay with privacy before we move forward? Thanks!
(In reply to William Reynolds [:williamr] from comment #21) > To clarify comment 20, I'm alright using this approach as long as our > privacy team is okay with the risk. It's also a gray area as to whether or > not this violates the Facebook TOS - we don't know for sure. > > cmore, can you confirm this risk is okay with privacy before we move > forward? Thanks! I have reached out to Jishnu for his recommendation. I will update everyone as soon as I hear from him.
I've made some updates: Small: http://people.mozilla.org/~ocoutts/SocialShare/small.html Large: http://people.mozilla.org/~ocoutts/SocialShare/large.html Ty, can you let me know what you mean by the link colour matching the global link color? Which link are you talking about? Can somebody let me know if I am doing the red colour properly? Should it be going on and off as a hover state or does it become red only when the box is open?
Going red on hover is good. I think that the link should remain red when the box is open, to indicate the changed state.
@bram thanks for sharing your thoughts. @owen Ty and Sean are guiding the design, so please follow their direction on link colors.
Attached image Facebook social text cut off —
Owen: When you click the share button a second time on the small example, the share count gets cut off. It is fine on the first time and then gets cut off the second. Also, will the drop down boxes (large and small) increase in width the large the buttons are for each service? For example, as the share count increases, does FB/Twitter/Google increase the width of the box or do they keep it the same and add K or M or thousands or millions?
(In reply to Chris More [:cmore] from comment #26) > Also, will the drop down boxes (large and small) increase in width the large > the buttons are for each service? For example, as the share count increases, > does FB/Twitter/Google increase the width of the box or do they keep it the > same and add K or M or thousands or millions? They are supposed to stay within a maximum width.
Owen, the widget is looking good. Sorry I just realized how confusing that comment regarding the link color was. What I meant was that the color of the link should match what the site template dictates. In this instance its red, for the FFx pages it should be blue, etc. Not sure how to tie it directly to the main CSS style sheet :s For the pressed/down state of the widget, lets keep the link red versus changing it to grey upon mouse-off. Few more things: GLOBAL: - Make the border-radius 3px vs 2px OFF STATE: - The arrow needs to be moved up by 2px. Since the inset shadow is 2px, we need to compensate for the spacing above and below the arrow - Please change the border color to rgba (0,0,0,0.12) instead of the tan color. This will be easier then to implement within the other templates and require less changes to the CSS. PRESSED/DOWN STATE: - move the arrow down 1px (from current position) - background color to rgba(74,74,74,0.1) - drop shadow 1px rgba(255,255,255,0.4) - inner shadow 2px 1px rgba(0,0,0,0.3) - inner glow 5px rgba(170,170,170,0.2) Thanks for your hard work!
Hey Everyone, Ty and I have worked through the last tweaks in the design. You can see the updated version at the same website: Small: http://people.mozilla.org/~ocoutts/SocialShare/small.html Large: http://people.mozilla.org/~ocoutts/SocialShare/large.html Unfortunately we can't dynamically change the colour of the images so that will need to be prepackaged. Perhaps we can make that a configuration option?
Owen, shaping up really nicely! Works well in Firefox, but still needs tweaks to work in Chrome, Safari, etc.
Just checked out various browsers, and actually looks good on those. We had to force-reload the page to make sure we had the latest version. Owen will wrap it up like this for code review, and for further requests and iterations, we can open enhancement bugs (or, probably, as it's a standalone library, github issues). (I expect this to happen, for example, to localize the words, or add more colors, etc.)
@fred Sounds good, before wrapping it up, can it be staged on a page like: http://www-dev.allizom.org/en-US/collusion/ This way we can verify its interaction with real content, especially how and what copy it takes from the page. Currently, we see: -Facebook: "You like social share" (pulling page title) -Twitter: Social Share link via @mozilla (pulling page title, link, @mozilla) -G+: You +1'd this (but, it blinks in FX Beta & I can't verify on my Google+ what content is is capturing) Questions: -On Facebook, can we use an H1 or H2 v. the page title? What level of control does the site owner have without having to go through a future secreview? -On Twitter, can we use an H1 or H2 v. the page title? Can the @mozilla be @firefox instead? (are they interchangable for the various properties by a site owner without secreview?) -On G+ can we see what the share looks like on a live G+ page before this goes for final code review and secreview?
I'm not sure about whats going on for you with g+, however I'm able to see it on my own page without seeing any blinking in Aurora. (https://plus.google.com/108085811575904624683/posts) Re tweeting from @mozilla vs @firefox: Yes we can change that to @firefox for the short term. In future versions we can make this an option. Re share text: Some of the buttons allow us to manual configure the share text. At first glance it looks like that includes twitter and potentially facebook. In future versions we can add an option to configure the text where we can.
@Chrissie: Yeah, those all would be great options to include as attributes so that sites owners can customize the implementation of the social share without having to dig into the JavaScript that was created. For now, let's get the 1.0 version past code and infrasec review and iterate on future versions. There are a number of sites that need this code now and like One Mozilla assets, they will continue to get more robust over time. @owen: Nice work on the development! Looks much prettier than my example: http://people.mozilla.org/~cmore/share-example.html @Fred: Can you give us an estimate on when code review should be complete? I'm going to create an Infrasec and WebQA review bugs now. Nice job everyone on making this a near reality! Can't wait to see this live on our sites.
@cmore: In this case, getting the assets to pull the right copy is a 1.0 requirement. Engagement can't use a social asset that's not pulling the right copy into the experience. Further customization is great for a V2. @owen @fred As a next step, let's move the social button unit over to http://www-dev.allizom.org/en-US/collusion/ per Ty's layout (upper right and footer/lower left). Please reach out to Ty directly if anything is unclear about the placements. Social buttons in closed state in upper right corner & lower footer: http://cl.ly/0v1M0q3u263o2a1Z3G07/o Social buttons in opened state (post-click) in upper right corner & lower footer: http://cl.ly/0L2c1w3e3q2U3C1z0X15/o Then repost to the bug, for Jane/William/CB review. This way we can verify its interaction with real content, especially how and what copy it takes from the page. Please update unit to pull the following: -On Facebook, use H1 v. the page title. -Q. What level of control over the content published does the site owner have without having to go through a future secreview? By universal, is this behavior not able to be modified per campaign? -On Twitter,use H1 v. the page title. -Change @mozilla to @firefox instead -Q. What level of control over changing the Twitter account does the site owner have without having to go through a future secreview? By universal, is this behavior not able to be modified per campaign? (e.g. Firefox Flicks, Firefox, Mozilla sites would ideally like to use their unique twitter handles) -On G+, use H1 v. page title/header
Depends on: 734931
(In reply to Chris More [:cmore] from comment #34) > @Fred: Can you give us an estimate on when code review should be complete? Yeah should be done today. There's nothing much left. We'll land this initial code, then have Owen file pull requests for the changes noted below. > I'm going to create an Infrasec and WebQA review bugs now. Nice job everyone > on making this a near reality! Can't wait to see this live on our sites. Woot, thanks for filing those bugs. (In reply to mcbmoz from comment #35) > @cmore: In this case, getting the assets to pull the right copy is a 1.0 > requirement. Engagement can't use a social asset that's not pulling the > right copy into the experience. Yeah using the first available h1, and in case there is none, the page title, sounds like a reasonable default. > As a next step, let's move the social button unit over to > http://www-dev.allizom.org/en-US/collusion/ per Ty's layout (upper right and > footer/lower left). Please reach out to Ty directly if anything is unclear > about the placements. Owen can make a static copy of that page and place the share buttons in it to see what it looks like, yup. > -On Facebook, use H1 v. the page title. Yeah, we'll use that for all three services for now. > -Q. What level of control over the content published does the site owner > have without having to go through a future secreview? By universal, is this > behavior not able to be modified per campaign? Like cmore said, editing the text is possible and a goal for the second version. We're working closely with Infrasec to ensure secure coding standards. While the initial version needs Sec review to ensure the functionality / architecture / etc. matches security standards, not every new line of code needs to spawn a new review. > -On Twitter,use H1 v. the page title. > -Change @mozilla to @firefox instead Works. > -Q. What level of control over changing the Twitter account does the site > owner have without having to go through a future secreview? By universal, is > this behavior not able to be modified per campaign? (e.g. Firefox Flicks, > Firefox, Mozilla sites would ideally like to use their unique twitter > handles) > > -On G+, use H1 v. page title/header Same answer here as for Facebook.
Here is the documentation for each service G+: https://developers.google.com/+/plugins/+1button/#plus-snippet Default text priority: Schema.org microdata > FB OG > Meta title/description > best guess. Twitter: https://dev.twitter.com/docs/tweet-button Default text priority: Share query string > data- tags > title tag. Facebook: https://developers.facebook.com/docs/opengraphprotocol/ Default text priority: FB OG > best guess --- With everything mentioned above, we can proceed with the following to ensure that the share text matches the page/site in question. 1) Ensure that every One Mozilla site is using FB's OpenGraph meta data tags. 2) For Twitter: Dynamically create the data- meta tags based off of FB OG tags and then default back to H1s if FB OG is not implemented on the site. The first point above is a site-by-site and page-by-page implementation and does not require changing of anything with the JS library. The second point will be development on our side to make sure that the Twitter-specific implementation pulls the correct meta data from the site. Owen: Please let us know when the Twitter data- meta tags are dynamically created based off of FB OG tags and if they don't exist, default to the first H1. If an H1 doesn't exist, fall back to the <title> tag. Owen: After you have these changes done. Please implement this within the Collusion page. Thanks!
@fred per comments about shipping v1, the social assets referenced for Twitter & Facebook should be Firefox-specific, since the site owners can't customize them (they are @mozilla in the demo). This means that we won't add this unit to mozilla.org until v2 allows for customization, though I can't speak for other site owners, I imagine that this will be true for programs like Firefox Flicks as well. https://twitter.com/#!/firefox http://www.facebook.com/Firefox
@fred @cmore Once we can view this asset on a page from Firefox Flicks or maybe even a post from Blogzilla, Engagement can confirm that it works. We realized today though, talking through what copy would be pulled and how the demo is currently working that this implementation is specific to content sharing v. acquisition. Works well for: Firefox Flicks, Blogzilla, product interaction like "I just downloaded Aurora! Here's a link where you can download it too" (that's just a hypothetical. Does not work well for: mozilla.org, mozilla.org product subsites (foundation, b2g, apps, persona), mozilla.org/firefox (GA, Beta, Aurora all have separate social acquisition assets) Examples: -the Facebook like seems specific to liking that particular page v. the overall Firefox page. -Twitter tweet reposts a link to a particular page v. enabling the user to follow the account Next steps: We'll address acquisition separately over on mozilla.org and mozilla.org/mozilla and leverage the prevailing design established here. We just won't be able to use this particular implementation for launch. Speaking with @cmore, we'll carve off the product page/site approach and solve for mozilla.org and mozilla.org firefox within the website team.
@Chrissie: Can you define "acquisition" so we are on the same page with terminology? There is a myth in the Facebook and Twitter "like buttons" that they actually make you "like" or "follow" a specific page/account. It was never possible to acquire more follows on Facebook and Twitter simply from click a like button on a website. I believe what you are looking for is the "like box", which is completely different and would allow the "acquisition" that I believe you are referring too. Like box: http://developers.facebook.com/docs/reference/plugins/like-box/ The "like button" as created in the designs from the creative group can only be used to share content and cannot be used to "like" a page or other social media asset. The code that Owen created for the "like button" could be changed to also allow a "like box" all from the same library. A website implementing this sharing library could specify simple sharing of content of acquisition of of followers/likes on a specific page/account. For example, on HuffPost, they have a "like button" for liking specific content on their website (which also shares that page with others) and a "like box" on the right under "social news" for to acquire more followers of their main social media accounts. Example: http://www.huffingtonpost.com/peter-s-goodman/ed-demarco-fannie-freddie-principal-reduction_b_1336190.html Thanks!
@cmore I sent you a meeting invite earlier today, would be great to discuss in person. Importantly, share solves an immediate need for Firefox Flicks. Over at HuffPost, we implemented every option imaginable in that little social hub purpose :-) By design and research, we wanted bloggers to self-promote, readers to share, as well as try to capture opportunities for 1:1. It's a lot of bling, and it doesn't serve users privacy or experience very well. ----- Share = sharing links with snippets of copy from particular web pages Acquisition = total number of Twitter Followers, Facebook Likes, and eventually Google+ brand page +1s ----- Campaigns like Flicks need share functionality to get the word out. It's particularly useful for users who have uploaded a video and want to spread the word. Product sites like /firefox and mozilla.org need acquisition functionality to develop a 1:1 relationship with the user. ----- We're working on social acquisition functionality for /firefox and mozilla.org websites now, but that's out of scope here and not a blocker to what you've done for share, which is great. mozilla.org and mozilla.org/firefox also have multiple assets, serving: Aurora, Beta, GA, The Foundation, PR, B2G, Apps, and Persona, the use case is a bit more complex and the branding team is also tackling those particulars this week as well.
@cmore @wenzel William, Jane and I talked, and for the time being we would like to remove Google+ We can't quite get the flavor in the demo, but we did go through the share experience on other sites and it's a little shifty experience-wise. We'll keep an eye on how Google iterates on sharing and when it's more reliable we'll be excited to include it in the future. Thanks!
Sure, we can make that an option to switch off. Any way we can make the experience less "shifty" though? Per comment 37, we'll have to put OpenGraph data on all pages that use this anyway, and then the shared information showing up on FB and G+ should essentially be the same.
@mcbmoz: The following is share library embedded in a static version of the Collusion page: http://people.mozilla.org/~ocoutts/collusion/ http://people.mozilla.org/~ocoutts/collusion/large.html Since the Collusion page does have have any of the OpenGraph meta data, it will resort to title or best guess for the share services. As mentioned earlier, to use share buttons successfully, you must provide the services with the intended meta data. The meta data is outside of the control of the sharing library and must be part of the base template of the site using the share buttons. Also, as Fred mentioned, services can be turned on and off at will. @Owen: Can you verify that one or more services can be turned off without negatively affecting the layout? Thanks!
@cmore feedback Facebook: Replace page title with H1 and add mozilla.org to end, "Introducing Collusion - mozilla.org" G+: Replace page title with H1 and add mozilla.org to end, "Introducing Collusion - mozilla.org" (@wenzel experience is sketchy on G+'s part, but the value of this is clearer in the context of how the content appears in social search results, so let's proceed - thank you!) Twitter: Replace page title with H1 "Introducing Collusion" +link that Twitter will automatically shorten. Thanks all, we're looking forward to seeing these tweaks!
@owen: Can you please add OpenGraph meta data tags detailed from comment 37 to both static Collusion pages? These will need to be added to the Mozilla.org template, but it will still be good for testing here. For example, in the head add: <meta property="og:title" content="Introducing Collusion - mozilla.org" /> <meta property="og:site_name" content="Mozilla" /> <meta property="og:image" content="http://mozcom-cdn.mozilla.net/img/firefox-100.jpg"> <meta property="og:url" content="http://people.mozilla.org/~ocoutts/collusion/" /> <meta property="og:description" content="Collusion is an experimental add-on for Firefox and allows you to see all the third parties that are tracking your movements across the Web. It will show, in real time, how that data creates a spider-web of interaction between companies and other trackers. " /> Then can you dynamically detect if <meta property="og:(title|url) tags exist in the DOM to populate the following twitter anchor tags? data-text="Introducing Collusion - mozilla.org" data-url="http://people.mozilla.org/~ocoutts/collusion/" data-via="mozilla" Thanks!
@cmore One Mozilla templates are being refactored for this a few other items. Thanks for the note above.
Fred/Owen: The plan for the library code freeze last Friday, April 6th. We need to get this over to Infrasec for their review the week of April 9th. Thanks!
Why is this interactive element just plain text <p class="text">Share This</p> with events attached to it? It would be more semantic and accessible to use a <button>, that way it would be keyboard-friendly as well. Extra sprinkles on the top if you add some well thoughtful WAI-ARIA attributes to make it even more accessible.
Hi All: A demo has been put up here: http://people.mozilla.org/~ocoutts/collusion/ The github repo with all the plugin code is here: https://github.com/mozilla/SocialShare Let me know if you have questions!
Hey Owen. There is actually one problem with the test page before we move forward. The og:image value must be an absolute URL. This is not a problem with the library, but just the implementation of OG on the collusion test page. You can see the error here: https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fpeople.mozilla.org%2F~ocoutts%2Fcollusion%2F Thanks, Chris
Owen: Another question, in the code here (https://github.com/mozilla/SocialShare/blob/master/src/socialshare.js#L70) and a few other places, is it possible to override the data-via value in the HTML so people can implement that value from site-to-site without having to change it in the library?
Depends on: 745958
Depends on: 747532
Depends on: 747533
Depends on: 747963
Chris: yes it is: https://github.com/mozilla/SocialShare/blob/master/src/socialshare.js#L164 What you pointed is the default.
Assignee: owen → nobody
Assignee: nobody → chrismore.bugzilla
Assignee: chrismore.bugzilla → pmac
Blocking bugs are now resolved and we are ready for the second round of QA.
Status? I think we can safely close this and open new bugs for new issues.
This is all complete and on a number of Mozilla websites including the blogs.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: