User:Dantman/Skinning system/Customization

Users and skins like to have ways to customize various parts of the ui and extensions like to provide extra pieces of the ui that skins may want to customize. We should take this into account.

Navigation

• Besides sidebar based navigation users need to have ways to customize other types of navigation like single-level headers and infinite depth menus and trees.
• For the sidebar at least users would like to be able to customize it in widget-like ways. With things like ad blocks, blocks of WikiText, and the ability to customize the location of things like the toolbox and language links. Extensions like to provide custom widgets as well.
• Some users would like to be able to customize the navigation to appear differently to logged out users... although so far the only rationales are for hacks that should be solved in other ways. We may avoid this one.
• Some sites have context sensitive navigation trees. eg: The Blender Wiki does this with subpage structure. Users should be able to drop navigation types like these into parts of the ui. And extensions should be able to provide types of context-sensitive navigation.
• To facilitate the use of both simple navigation trees and widget-like blocks, navigation and sidebar should be split apart.
  • One system will allow users to create a few types of navigation blocks. Primarily single-level link lists, header + links lists like in our sidebar, and infinite depth link trees.
  • A separate system will act as some sort of simple widget system.
    • In this system, header + links list blocks from the navigation system may be inserted as navigation blocks. We may also make it possible to insert one single-level link list as a single block and give it a header name from the widget system. This will allow a site to reuse one navigation block in between a skin that uses a single header navigation and a skin that uses a sidebar.
    • This system will also allow blocks of wikitext to be added. As well as custom types of blocks defined by extensions. This method of setup may also allow the languagelinks, toolbox, and search box areas to be controlled.
  • An interface would be provided that allows navigation blocks to be assigned to areas inside different skins.

Search

• Some wikis would like to be able to expand their search.
  • The Blender Wiki allows selection of the blender version and language for their documentation.
    • Perhaps we should add support for custom extra options for search bars. ie: A key (name=) and a list of values and labels. Which a search box implementation can add somewhere and style.
  • Some wikis like to replace the search engine with an external search such as Google search.
• Skins differ on whether they prefer an old Go / Search style search bar, a new vector simplesearch style, or just a search box and a go button with te text "Search". (Maybe we should consider dropping to these three and make most of the decision on what to output a site decision) See User:Dantman/Skinning system/Search, we should kill Go style search and only support a plain search box in skins which has simplesearch-style suggestions applied to it.

Breadcrumbs ( Parent > Sub > Sub )

• Right now we do these as part of subtitles, and we setSubtitle instead of setting a breadcrumb list.
• Skins may want to customize the location and style of these, so we need a separate key for them.
• Extensions may want to provide alternative breadcrumbs based on knowledge of the site's hierarchy.

Alternative page links

• "Alternative page links" are links which point to other content pages (pages on sister sites may be acceptable too) which are grouped by some relation the pages have.
• The one built in type of these we have is language links.
• Extensions may want to provide alternate page relations, such as a software documentation wiki linking to the same page for a different software version. Or sister wiki links to the same page on another wiki.
• Like tools, these should be grouped into a class rather than providing something like language links directly. Skins should try to implement these abstractly so they are compatible with other types. Fancy extra handling of specific types can still be done if the skin still implements things generically but pulls the ones they want to customize out of what that generic abstraction handles.