【问题标题】:Large footer full of links, is it good?充满链接的大页脚,好吗?
【发布时间】:2023-03-25 11:30:01
【问题描述】:

我在一些流行的网站上看到非常大的页脚,其中包含很多内部导航链接。

是否有关于该主题的可用性研究或至少有权威意见?

我应该在未来的项目中使用大型导航页脚吗?

【问题讨论】:

    标签: navigation usability footer


    【解决方案1】:

    作为网站用户和网站开发者,我真的很喜欢带有链接的页脚。

    当您拥有一个网站时,您总是需要制作一大堆难以分类的页面,而且使用率相对较低。尽管如此,它们都是必须存在的非常重要的页面。这些页面的好例子是常见问题解答、隐私政策、联系信息页面、服务条款、信用/版权信息页面等。

    当您创建一个网站时,您希望顶部的导航完全是关于该网站的主要用途。如果您将这些杂项页面的链接放在顶部,则会造成混乱。如果您尝试对它们进行分类并将它们放在单独的页面上,它将使实际尝试查找这些页面的用户感到沮丧。此外,无论是否有任何实际的可用性研究,在我看来,在主导航中包含指向这些页面的链接在美学上都很糟糕。

    我想说 Digg 和newegg.com 是很好地使用页脚链接块的例子。 Digg的顶部导航全是挖掘、登录、加入、搜索,“关于”只有一个链接。 Newegg 的顶部就是寻找和购买产品。所有额外的东西都在页脚的一组链接中。通过将这些链接放在每个页面的页脚中,您可以使它们易于访问、易于查找,但不会干扰网站的主要体验。

    可能有更好的方法来处理所有这些更好的页面,但许多受欢迎的网站都遵循这种模式。我认为可以安全地假设用户已经习惯了页脚链接,或者他们甚至期待它们。如果是这样,那么遵循相同的设计肯定有好处。

    【讨论】:

    • @apreche:这些页脚是矫枉过正的例子。大多数这些链接将不会被使用。该网站的高级用户或频繁用户会比其他人更多地使用它们。但即便如此,我估计只有大约 7 个链接会在很大程度上被使用。这两个站点使用它们的页脚作为主要导航[坏] 和快捷工具(好),但过于广泛[坏]。创建页脚作为主要导航工具也会破坏页面内容[坏]。链接的数量使用户超负荷 - 所以会避免它。出现在一个卷轴下面所以不会被注意到太多[糟糕]
    【解决方案2】:
    • 如果您有 javascript 生成的菜单,那么最好有搜索引擎,这样他们就可以更好地索引您的网站
    • 如果您的网站/页面没有移动优化版本,那么最好拥有移动设备。
    • 您可以 CTRL+F 在页面中搜索可能难以通过级联菜单找到的特定链接。
    • 视力受损的用户可以通过页脚样式菜单更轻松地进行导航
    • 用户通常从上到下扫描/阅读网站。如果他们没有立即找到他们正在寻找的内容,他们会在您的页面底部结束,因此最好有一组导航链接以避免滚动回顶部并再次扫描整个页面。

    【讨论】:

      【解决方案3】:

      我想这与可用性无关,而更多地与 SEO 有关。至少这就是我真正使用它的全部。

      我从来没有设计一个网站,让用户必须滚动到页面底部才能找到他们正在寻找的内容,但我在底部放置了链接以帮助搜索引擎找到他们的方式。

      【讨论】:

        【解决方案4】:

        页脚链接赞成与反对

        优点: 1. 页面快捷方式 2.滚动页面上的导航源 3. 可以提供站点概览(如站点地图)

        缺点: 1. 太多的链接是浪费时间并造成混乱,即 7 +- 2 个块是限制 2. 表示导航结构不佳(通常是导航深度) - 如果用户无法通过主菜单轻松找到它,那么您的问题比页脚链接更大! 3. 很少有用户会寻找这些链接——通常只有意识到这些冗余链接的目的的高级用户。该网站的新手和新手只是想知道“链接是否指向同一页面?”

        我建议将它们用作关键页面和经常导航页面的快捷方式。限制为大约 7 个链接。

        一些支持文献:

        1. http://www.usability.com.au/resources/source-order.cfm/
        2. http://www.shimonsandler.com/category/usability/
        3. http://www.smashingmagazine.com/2009/06/17/informative-and-usable-footers-in-web-design/

        可用性论文和研究中提供了更好的文献。因此,如果您研究此问题,请查看一些学术成果。

        【讨论】:

        • 这些意见的来源是什么?
        • @Sergey:7 年作为可用性工程和 UI 设计师的经验 - 你对这些问题有一种感觉。关于这个问题有大量但零散的文献。这里有一些链接可以支持我的回答:usability.com.au/resources/source-order.cfmshimonsandler.com/category/usabilitypopupon.blogspot.com/2007/01/…[更简单的例如更好]smashingmagazine.com/2009/06/17/…在可用性论文中有更好的文献。但这有帮助。 :)
        • @sergey:页脚的更好示例:joomla.org 将本示例的简单性与 Apreche 示例中提供的有益/有用的功能相结合 - 这将为您提供良好的平衡。请记住,您的主要导航应该出现在页面顶部。如果您有任何特定的页脚设计/可用性要求,请与我联系。干杯
        • @ForerMedia,刚刚看到你的 cmets。感谢您的链接!我会在 SO 上关注你的回答。
        【解决方案5】:

        我尝试在页面顶部放置使用网站的链接,并在页面底部放置帮助/信息与网站的链接。 p>

        基本上,人们正在使用的东西应该放在最容易接近的位置,而他们可能永远不需要的东西放在底部。

        【讨论】:

          【解决方案6】:

          在可用性方面,我认为这不是问题。我没有这方面的硬数据,但是看过很多可用性测试后,我无法想象这样一个内容丰富的页脚的存在会对用户造成负面影响,除非链接数量过多,或者更糟糕的是,页脚难以理解(结构简陋、标签模糊、编码错误等)。在 SEO 方面,认为以这种方式添加链接会以任何方式提高您的页面排名得分将是一个严重的错误。如果谷歌认为你试图在页面底部塞进一堆已经存在的链接,它实际上可能会受到惩罚。在this French news site 中可以看到大页脚概念最令人难以置信的使用,它实际上在每个文章页面的底部重复了整个(是的,整个)主页!太极端了,但显然很受欢迎。

          【讨论】:

            【解决方案7】:

            在他的一次演讲中(抱歉,没有官方消息来源,我参加了现场直播),Edward Tufte 实际上以此作为一个例子,其中认知科学的“7 +/- 2”概念通常被误用,因为它是搜索/关键字识别问题,而不是召回问题。 Tufte 基本上说,由于人类擅长从大量项目中挑选出他们感兴趣的项目,因此拥有许多链接的平面列表实际上比限制在 7 个左右的链接要好。用户不是试图记住链接,而是试图找到他们感兴趣的页面。

            接受的答案中提到的Smashing Magazine 文章实际上肯定了在页脚中使用组织良好的站点地图链接列表(参见Site MapFooter and Site Map Layout 部分——后者实际上使用 Digg 作为好的例子)。至于其他的链接,一是说页面源顺序,不是显示顺序,二是专指为了SEO优化而游戏链接的网站。

            根据我自己的经验,我更喜欢在页面底部有一个全面的站点地图的网站,主要是因为用户 访问该网站的目的不一定是developer 优化,因此对于使用不符合网站预期工作流程的人来说,平面导航结构将更容易。它不能替代一个好的导航系统,但它是一个很好的补充。

            【讨论】:

              【解决方案8】:

              在我看来,最佳位置是一行,最多两行。在每个页面的底部,您唯一需要的就是人们总是需要/想要做的事情。


              在 Stack Overflow 的情况下,我唯一遇到的问题是 总是欢迎反馈 链接侵入了 联系我们 的用途。

              我会保留联系我们并删除总是欢迎反馈链接。

              【讨论】:

                【解决方案9】:

                如果这些链接有用或经常访问,它们一开始就不会出现在页脚中。我认为在主页中保留尽可能多的链接很有用。这是大多数人从您的网站开始的地方。

                【讨论】:

                  猜你喜欢
                  • 2021-05-17
                  • 1970-01-01
                  • 1970-01-01
                  • 2013-06-16
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 2013-04-08
                  • 1970-01-01
                  相关资源
                  最近更新 更多