openSUSE:What to improve osc11 session - Problem Details And Solution Proposal

Jump to: navigation, search

During the openSUSE Conference 2011 a BoF session with the topic "What do we need to improve" took place. Following are some proposals for improvements.

Case: Categories and Portals

Problem 1:

The pages in the wiki (which is modularly styled) are a web of pages that are connected with each other according to a hierarchy. Commonly, most of the pages follow a tree hierarchy. But there are some pages that are independent or lone pages. Thus the wiki has two observable category of browsing through the pages.

  • One is the style of Portals which have an independent portals as a head of a type of articles which have sub-portals and/or pages.

The various portals are listed here - link 1.

  • The other is the Category style which categorizes various articles into a subcategory which are again categorized into main categories.

The various categories are listed here - link 2 and the wiki's categories here - link 3. It can be noted that the Categories (link 2) supersede the Portals (link 1). The Portals (link 1) cater to the wiki and the second link (link 3) of wiki's categories is the equivalent of portals. But it is also important to note that the Main Page serves as the starting page for the wiki and the links provided in the first Category link (link 2) other than the Portals are effectively displayed in the top black bar of the main page. Thus the Main Page is the link (link 2) only displayed in a comprehensive way. But the problem arises when one browses the wiki. Both the styles are unequally promoted in the wiki - the Portals and pages through the contents of the wiki, while the Categories through the Site Map in the Navigation box and by listing the category of the current page below even when the navigation is displayed below the black bar. This leads to extra information or its overload and may sometimes confuse a user, say a desperate user. This information must be abstracted.

Proposals/Solutions

Like other distribution projects especially like Fedora, only one style of browsing the wiki must be promoted at one time. For example Fedora project wiki provides a combination of a comprehensive view and category view represented by a category indicator below the page.

  • Thus in the navigation box, a choice between 'Portal View' and 'Category-only View' must be presented.
  • Then the navigation indicator below the black bar must present the full path to the current page. For example, the path to the Portal:Project must be Wiki>Main Page>Portal:Project instead of the current Wiki>Portal:Project.

To do this a bit of restructuring and changes must be done – which is described in the next two proposals.

Note

It is observed that the 'Portal View' is informative which is good for the average user while the 'Category-only View' is fast to browse through. Thus the 'Portal View' must be the default view.

Case: Changes to wiki

Problem 2

The Main Page, whatever view it displays, it is essential to display all the categories or portals that are available for allowing speedy access to the information sought by use. Fedora project displays all the sub-projects at the end of main page. A similar approach must be taken in the Main Page of our wiki. We could display all the portal/categories at the end where a lot of space is wasted. But there is a caveat. If the portal view is implemented, the main page should display the list of all the portals below the content else if the category view is implemented, a list of all categories must be presented . That way the Main Page can be effectively used as the landing page.

Proposals/Solutions

  • Display a list of portals (link 1) or categories (link 3) in the Main Page whichever the case and the main page's URL could be then adjusted to <opensuse.org/Main_Page_Portal> or <opensuse.org/Main_Page_Category>.

Problem 3

The navigation indicator below the black bar provides a mostly changing path. This has its problems – an average user is most used to hierarchy system when dealing with digital information. This is why projects employ hierarchies in their websites to avoid confusions. There is a minor quirk in the hierarchy of the wiki which pertains to the Main Page. If a user browses to Portal:Project or somewhere deep inside the wiki and wants to land back at the Main Page from which he/she came from, there is no such Main_Page displayed in the path. Second, clicking the wiki(with the home sign) takes a long time to redirect to the Main Page and in some cases the redirection fails. Third, if the user is browsing in a category view, and the default view is the portal view, the redirect would redirect the user to the Main Page with the default view. This results in decrease of degree of navigability.

Proposals/Solutions

The previous two proposals were devised to address the quirk of the Main Page not being the effective landing page. The wiki view being set, and the Main Page displaying the portals/categories according to user's view, the Main Page will be an effective landing page when returning from elsewhere in the wiki.

  • To achieve this, the adjusted Main Page (according to the view) must be displayed in the navigation indicator. Thus a user can easily navigate back to the Main Page that has the user's view preserved and then he/she can browse easily from the Main Page.

Thus a sample navigation indicator may look like: wiki>Main_Project_Portal>Portal:Project

Case: Search

Problem 4:

There are two scopes for search: One is the search field in the upper right corner of the page that utilizes Media Wiki search. Other is the “Find a page” in the Help box of the page that utilizes Google search. One would expect the search bar to display the list of potential pages/articles on doing a search through it like it happens in Ubuntu's wiki or in Fedora's wiki. But it is not so. On searching for “GNOME Shell” or any other cases of it like “gnome shell” or “Gnome Shell” it directly leads to the page <http://en.opensuse.org/GNOME_SHELL>. But doing the same task through the latter results in a more refined search list that one may expect. It provides a list that ranges from articles “GNOME 3.0” to “Portal:12.1 – openSUSE” and “Portal:GNOME – openSUSE”. It also includes the “GNOME SHELL” page that resulted in the first case. This results in two things:

  • The first search is very limited, as it may match the name-case of an article and present it. If the user searches “gnome 3”, the first case results in “Portal:GNOME/Screenshots/3” as the first article while the second case results in “openSUSE:GNOME 3.0 – openSUSE” as the first article which is a more relevant result.

Similarly searching for “12.1” in the first case leads to <http://en.opensuse.org/12.1> which is the 12.1 portal while in the second search lists “Portal:12.1 – openSUSE” as the first article and also lists important things like “Product highlights – openSUSE” and “Category:12.1 – openSUSE”. This shows the unreliability of the first search.

  • But there is another side of the first search, if the name-case doesn't match, it automatically does a special search. It results in a list of potential pages that a user might expect. For example searching for “12.1 gnome” results in better list of results than the other search which lists absurd results for files. Also the searches here can be categorize into various sections like “Content pages”, “Multimedia”, “Help and Project pages” or “Everything”.

Also, an Advanced Search (which is a bit difficult to find) is provided in which search can be done in any combination of namespaces. While this namespaces feature is present in the second Google search, it is manual and not user-friendly.

Propoals/Solutions

Providing relevant options to the users must be a priority, as it increases the degree of navigability, usability and user-friendliness.

  • Perspective 1: (Design) - An important point that is to noted is, according to design conventions the search bar on top of many websites provide the list of pages from their respective wikis or their project pages.
    • It would be better to implement the functionality of the latter into the former i.e. implement the Google search that the second case uses into the search bar as it produces better search results or the special search should be activated for all searches when using the Media Wiki search.
    • The Advanced Search should be easier to find, thus it could be put in a dropdown menu as an option like the option of search engines in Mozilla Firefox.
  • Perspective 2: (Recommended/Preferred) - Like Fedora, the search system can be centralized into the Help box or better a new Search Box.
    • Provide the options to choose either the Media Wiki search or the Google Search.
    • Move the search field from the top right corner to the Search Box/Help box.
    • Provide an Advanced Search option below the search field that will serve for both of the Media Wiki or the Google searches.

Case: Miscellaneous

Proposals/Solutions

The 'Search for packages' hyperlink in the dropdown menu of 'Downloads' in the top black bar should direct to <http://software.opensuse.org/search> instead of <http://software.opensuse.org/>. This would not confuse the user that they have been directed to the page that is used for downloading the distribution. Plus the former webpage looks clean with a search section and results section.

Implemented 2011-12-07 by Thomas Schmidt

Retrieved from "https://en.opensuse.org/index.php?title=openSUSE:What_to_improve_osc11_session_-_Problem_Details_And_Solution_Proposal&oldid=49989"