openSUSE:osc11 会议改进建议 - 问题详情与解决方案建议

跳转到：导航，搜索

在 openSUSE Conference 2011 上，举行了一个关于“我们需要改进什么”的 BoF 会议。以下是一些改进建议。

案例：分类和门户

问题 1

Wiki 中的页面（采用模块化样式）是一个相互连接的页面网络，按照层级结构组织。通常，大多数页面遵循树状层级结构。但也有一些页面是独立的或孤立的页面。因此，Wiki 有两种可观察到的浏览页面方式。

  • 一种是门户的样式，门户作为一类文章的头部，拥有子门户和/或页面。

各种门户的列表在这里 - 链接 1。

  • 另一种是分类样式，将各种文章分类到子类别中，而子类别又被分类到主类别中。

各种类别的列表在这里 - 链接 2，以及 Wiki 的类别在这里 - 链接 3。值得注意的是，类别（链接 2）优先于门户（链接 1）。门户（链接 1）服务于 Wiki，而第二个链接（链接 3）的 Wiki 类别等同于门户。但同样重要的是要注意，主页作为 Wiki 的起始页，并且第一个类别链接（链接 2）中的链接（除了门户之外）有效地显示在主页顶部的黑色栏中。因此，主页只是以更全面的方式显示的链接（链接 2）。但问题在于当浏览 Wiki 时。这两种样式在 Wiki 中推广不均 - 门户和通过 Wiki 内容的页面，而类别通过导航框中的站点地图以及即使导航显示在黑色栏下方，也列出当前页面的类别。这会导致额外的信息或信息过载，有时可能会让用户感到困惑，例如绝望的用户。必须抽象这些信息。

建议/解决方案

与其他发行版项目（尤其是 Fedora）一样，一次只能推广一种浏览 Wiki 的方式。例如，Fedora 项目 Wiki 提供了一种综合视图和类别视图的组合，由页面下方的类别指示器表示。

  • 因此，在导航框中，必须提供“门户视图”和“仅类别视图”之间的选择。
  • 然后，黑色栏下方的导航指示器必须显示到当前页面的完整路径。例如，到 Portal:Project 的路径应该是 Wiki>主页>Portal:Project，而不是当前的 Wiki>Portal:Project。

为此，必须进行一些重组和更改 - 这在接下来的两个建议中描述。

注意

可以观察到，“门户视图”信息丰富，适合普通用户，而“仅类别视图”浏览速度更快。因此，“门户视图”应该是默认视图。

案例：Wiki 的更改

问题 2

无论显示什么视图，主页都必须显示所有可用的类别或门户，以便快速访问所寻求的信息。Fedora 项目在主页末尾显示所有子项目。我们的 Wiki 主页也应该采取类似的方法。我们可以在主页末尾显示所有门户/类别，那里浪费了很多空间。但是有一个注意事项。如果实施门户视图，主页应该在内容下方显示所有门户的列表，否则如果实施类别视图，则必须呈现所有类别的列表。这样，主页可以有效地用作着陆页。

建议/解决方案

  • 在主页上显示门户（链接 1）或类别（链接 3）的列表，无论哪种情况，主页的 URL 可以调整为 <opensuse.org/Main_Page_Portal> 或 <opensuse.org/Main_Page_Category>。

问题 3

黑色栏下方的导航指示器提供了一条不断变化的路径。这存在一些问题 - 普通用户在处理数字信息时最习惯于层级系统。这就是为什么项目在其网站上采用层级结构以避免混淆的原因。Wiki 的层级结构中有一个小小的怪癖，与主页有关。如果用户浏览到 Portal:Project 或 Wiki 内部的某个地方，并想从他/她来到的主页返回，则没有显示这样的 Main_Page 在路径中。其次，单击 wiki（带有主页标志）需要很长时间才能重定向到主页，并且在某些情况下重定向失败。第三，如果用户正在类别视图中浏览，而默认视图是门户视图，则重定向会将用户重定向到具有默认视图的主页。这导致导航程度降低。

建议/解决方案

前两个建议旨在解决主页不是有效着陆页的怪癖。Wiki 视图设置好后，主页根据用户的视图显示门户/类别，主页将成为从 Wiki 中的其他地方返回时的有效着陆页。

  • 为此，调整后的主页（根据视图）必须显示在导航指示器中。因此，用户可以轻松地导航回保留用户视图的主页，然后可以从主页轻松浏览。

因此，示例导航指示器可能如下所示：wiki>Main_Project_Portal>Portal:Project

案例：搜索

问题 4

搜索有两个范围：一个是页面右上角的搜索字段，它使用 Media Wiki 搜索。另一个是页面帮助框中的“查找页面”，它使用 Google 搜索。人们期望搜索栏在搜索时显示潜在页面/文章的列表，就像在 Ubuntu 的 Wiki 或 Fedora 的 Wiki 中发生的那样。但事实并非如此。搜索“GNOME Shell”或任何其他情况，例如“gnome shell”或“Gnome Shell”，会直接跳转到页面 <https://en.opensuse.net.cn/GNOME_SHELL>。但通过后者执行相同的任务会产生更精细的搜索列表，这正是人们所期望的。它提供了一个从“GNOME 3.0”到“Portal:12.1 – openSUSE”和“Portal:GNOME – openSUSE”的文章列表。它还包括第一个案例中出现的“GNOME SHELL”页面。这导致了两件事

  • 第一个搜索非常有限，因为它可能匹配文章的大小写，并呈现它。如果用户搜索“gnome 3”，第一个案例会显示“Portal:GNOME/Screenshots/3”作为第一篇文章，而第二个案例会显示“openSUSE:GNOME 3.0 – openSUSE”作为第一篇文章，这更相关。

同样，在第一个案例中搜索“12.1”会跳转到 <https://en.opensuse.net.cn/12.1>，这是 12.1 门户，而在第二次搜索中，列出了“Portal:12.1 – openSUSE”作为第一篇文章，并列出了重要的内容，例如“Product highlights – openSUSE”和“Category:12.1 – openSUSE”。这显示了第一个搜索的不可靠性。

  • 但是第一个搜索的另一个方面是，如果名称大小写不匹配，它会自动执行特殊搜索。它会显示一个用户可能期望的潜在页面列表。例如，搜索“12.1 gnome”会产生比另一个搜索更好的结果列表，后者会列出文件的荒谬结果。此外，这里的搜索可以分为各种部分，例如“内容页面”、“多媒体”、“帮助和项目页面”或“所有内容”。

此外，高级搜索（有点难以找到）提供了在任何命名空间组合中进行搜索的功能。虽然这种命名空间功能存在于第二个 Google 搜索中，但它是手动且不友好的。

建议/解决方案

为用户提供相关的选项至关重要，因为它提高了导航程度、可用性和用户友好性。

  • 视角 1：（设计）- 一个需要注意的重要点是，根据设计约定，许多网站顶部的搜索栏提供来自各自 Wiki 或其项目页面的页面列表。
    • 最好将后者的功能实现到前者中，即，将第二个案例使用的 Google 搜索实现到搜索栏中，因为它会产生更好的搜索结果，或者应该为所有使用 Media Wiki 搜索的搜索激活特殊搜索。
    • 高级搜索应该更容易找到，因此它可以放在下拉菜单中，就像 Mozilla Firefox 中的搜索引擎选项一样。
  • 视角 2：（推荐/首选）- 像 Fedora 一样，搜索系统可以集中到帮助框中，或者更好的是一个新的搜索框。
    • 提供选择 Media Wiki 搜索或 Google 搜索的选项。
    • 将搜索字段从右上角移动到搜索框/帮助框。
    • 在搜索字段下方提供一个高级搜索选项，该选项将适用于 Media Wiki 或 Google 搜索。

案例：其他

建议/解决方案

顶部黑色栏中“下载”下拉菜单中的“搜索软件包”超链接应该指向 <https://software.opensuse.net.cn/search>，而不是 <https://software.opensuse.net.cn/>。这不会让用户感到困惑，认为他们已被重定向到用于下载发行版的页面。此外，前者网页看起来干净，带有搜索部分和结果部分。

已实施 2011-12-07 由 Thomas Schmidt

从 "https://en.opensuse.net.cn/index.php?title=openSUSE:What_to_improve_osc11_session_-_Problem_Details_And_Solution_Proposal&oldid=49989" 检索