从低俗的点击诱导网站到最权威的出版物，分享按钮长期以来在网络上无处不在。 然而，可以争辩说这些按钮并非必需。 所有移动浏览器（Firefox、Edge、Safari、Chrome、Opera Mini、UC 浏览器、Samsung Internet）都简化了直接从其原生平台分享内容的操作。 它们都具有一个内置按钮，可以调出一个“分享表单”——一个用于分享内容的原生对话框。 您还可以突出显示文本以分享摘录以及链接。
鉴于用户可以默认进行分享，自定义按钮是否占据了不必要的空间并可能分散用户对更重要操作的注意力？ 人们真的使用它们吗？
一项针对 12,500 名 CSS-Tricks 阅读者 进行的（非科学）调查发现，60% 的读者从未使用过自定义分享按钮。 这发生在 2014 年，而自那时起，原生分享方法得到了进一步改进。 Smashing Magazine 最近进行的一项调查也发现了类似的情况。
您在移动设备上使用社交分享按钮的频率如何？
— Smashing Magazine (@smashingmag) 2019 年 8 月 23 日
用户的技术熟练程度各不相同。 并非每个人都熟悉自己的手机或浏览器，这意味着某些用户难以找到原生分享按钮。 还值得考虑一下桌面上的情况。 桌面浏览器通常（Safari 是一个例外）不提供内置的分享功能——用户只能将链接复制粘贴到他们选择的社交网络中。
一些数据表明 点击率相对较低。 但是，点击率并不是最佳指标。 对于知道如何在没有帮助的情况下进行分享的技术娴熟的用户来说，这些按钮仍然可以充当提示——一个分享内容的视觉提醒。 无论最终如何分享链接，自定义分享按钮仍然可以提供一个线索或一个小小的推动来引发分享。 出于这个原因，衡量按钮本身的点击率可能并不完全公平——人们可能会看到按钮，感到有分享内容的冲动，但随后使用浏览器的内置分享按钮。 一个更好的指标是，无论如何分享，分享按钮添加后分享次数是否有所增加。
我们已经确定，拥有分享按钮可能是有用的。 网站传统上为两个或三个最受欢迎的社交网络提供单独的按钮。 使用一个比较新的 API，我们可以做得更好。 虽然 浏览器支持 目前仅限于 Android 版 Chrome 和 Safari，但这两种浏览器本身就占据了绝大多数的网络流量。
Web Share API
Web Share API 提供了一种简单的方法来调出分享表单——用于分享的原生 UI 部分。 而不是提供一个标准的热门社交网络列表供用户分享（用户可能不是所有网络的成员），分享表单的选项会针对个人定制。 只有他们在手机上安装的应用程序才会显示。 用户将不会看到统一的列表，而只会看到在他们实际使用的网络上分享的选项——无论是 Twitter 和 Facebook 还是其他更小众的网络。
不向用户显示不相关的网络显然是一件好事。 不幸的是，这与某些用户访问社交媒体网站而不是将其下载为应用程序的事实相抵触。 例如，如果您使用 twitter.com，但没有本地安装 Twitter 应用程序，则 Twitter 将不会列为分享选项。 目前，仅列出了原生应用程序，但将来将支持 PWA。
websharebutton.addEventListener("click", function() {
navigator.share({
url: document.URL,
title: document.title,
text: "lorem ipsum..."
});
});API 需要用户交互（例如上面代码中显示的按钮点击）才能调出分享表单。 这意味着您不能做一些讨厌的事情，比如在页面加载时调出分享表单。
文本可能是一段简短的摘录或页面摘要。 标题用于通过电子邮件分享，但在分享到社交网络时会被忽略。
桌面上的分享
虽然我们对移动设备上的 Web Share API 非常满意，但其在桌面上的实现目前仅限于 Safari，并且还有很多需要改进的地方。（Chrome 计划最终提供支持，但没有明确的时间表）。
提供的选项——邮件、消息、隔空投送、笔记、提醒——省略了社交网络。 Twitter 和 Facebook 的原生应用程序在手机上很常见，但在其他设备上却很少见。
与其依赖桌面上的 Web Share API，不如使用一个通用的分享按钮，该按钮会打开一个模态窗口，提供更多分享选项。 这是 YouTube、Instagram 和 Pinterest 等网站采用的方法。
Facebook 和 Twitter 占据了绝大多数在线分享，因此提供详尽的社交网络列表供用户选择似乎没有必要。（Instagram 的选项将是理想的，但目前无法从网站分享到 Instagram。）包含电子邮件选项也比较常见。 对于任何使用基于 Web 的电子邮件客户端（如 gmail.com 或 outlook.com）而不是操作系统默认电子邮件应用程序的用户来说，这都存在问题。
许多人使用基于 Web 的电子邮件客户端 gmail.com 或 outlook.com。 分享到电子邮件的按钮将打开操作系统的默认电子邮件应用程序。 用户将收到一个设置此应用程序的提示，这比简单地复制粘贴 URL 要费力得多。 因此，建议省略电子邮件选项，而是包含一个将链接复制到剪贴板的按钮，这比使用键盘在地址栏中进行复制仅略微容易一些。
提示用户设置他们从未使用过的应用程序比简单地将 URL 复制粘贴到我首选的电子邮件客户端中要费力得多。
选择分享图标
没有通用的标准化分享图标——远非如此。 虽然 Android 符号可能无法被长期 iPhone 用户识别，但 iOS 图标也存在问题。 它与下载图标相同——但箭头方向相反，这意味着上传，而不是分享。
在我工作的 giffgaff，我们对 69 位同事进行了调查，询问他们是否将当前的 iOS 图标或当前的 Android 图标识别为表示分享。 Android 图标以 58 票的压倒性优势获胜。 虽然我们的样本包括 iPhone 用户，但一些长期 iPhone 用户可能不熟悉此符号（即使它已被一些网站采用）。 然后是前进箭头，这是一个被 Apple 弃用的图标，但在其他地方被采用。 这个符号让人联想到转发电子邮件的图标，它因在 youtube.com 上的使用而变得易于识别。 该图标在 2017 年被微软采用，因为 A/B 测试发现其熟悉度很高。
也可以采用上下文方法。 Twitter 会根据用户的平台更改使用的图标。 Ionicons 图标库也采用了这种方法 。
鉴于缺乏一个普遍理解的图标，这似乎是一个不错的方法。 或者，确保在图标旁边包含一个标签，以便真正向用户说明清楚。