Working With Wikis
The struggle, as a developer, of wiki software is in the phrase “simplified markup”. That is, how to give users more options for marking up content while keeping it simplified? With all that in mind, we’ve been diligently at work on adding features, making the parser more forgiving in conversion of markup to HTML, and cleaning up the user interface.
The following is a preview of a few upcoming changes:
Wiki pages are now cached (by default) after the first render. This improves page speed and performance, especially with long, complicated pages or those containing several math formulas. Any changes to a page will generate a new cache file so there should be little worry about new content not displaying right away. The time pages are cached (15 minutes by default) can be adjusted as needed or even turned off completely.
Special pages are pages that have no wiki text, but are generated by the software on demand. They are found in the “Special:” namespace. In fact, it is not possible to create normal pages beginning with the “Special:” prefix; Special pages are automatically generated and cannot be edited. They are built-in to every wiki, from site to group, and bring a lot of functionality that had to be created manually (TitleIndex macro, etc.) or was previously unavailable.
The initial list of available pages includes:
Special:AllPages— All pages in the current wiki, broken down alphabetically
Special:RecentChanges— All recent changes (ordered newest to oldest)
Special:NewPages— A list of all the newly created pages (ordered newest to oldest)
Special:FileList— A list of all files uploaded to the current wiki
Considering and in the works:
Special:Cite— Generates citation instructions for a specific wiki page. The target can be specified as a parameter, e.g.
Special:WhatLinksHere— List all pages linking to a given page. The target can be specified as a parameter, e.g.
Have an idea or request for a special page? Put it in the comments below or add it to our Wish List.
Admittedly, tables have had limited markup capabilities and been a somewhat neglected part of the wiki software until now. We’ve added the ability to create table headers (finally!), span multiple table cells, and align content within cells.
Cell headings can be specified by wrapping the content in a pair of ‘=’ characters. Note that the ‘=’ characters have to stick to the cell separators, like this:
|| ||= stable =||= latest =|| ||= 1.0 =|| 1.0.5 || 1.0.6dev || ||= 1.1 =|| 1.1.6 || 1.1.7dev ||
Specifying an empty cell means that the next non empty cell will span the empty cells. For example:
|| 1 || 2 || 3 || |||| 1-2 || 3 || || 1 |||| 2-3 || |||||| 1-2-3 ||
To explicitly align content:
||= attribute list =||= column =|| ||<. align left || text || ||>. align right || text || ||=. center || text || ||. justify || text || ||^. valign top || more[[br]]text || ||~. bottom || more[[br]]text ||
|valign top|| more
Note that if the content of a cell “sticks” to one side of the cell and only one, then the text will be aligned on that side. Explicit alignment (above) will override this. Example:
||=Text =||= Numbers =|| ||left align || 1.0|| || right align|| 4.5|| || default alignment || 2.5|| ||default|| 2.5|| || default || 2.5|| || default || 2.5|| ||<. left align|| 4.5||
User Interface Changes
One of the bigger tasks when developing any application, be it web or a native program, is the user interface (UI). After all, no matter how useful or powerful an application may be, if a user can’t figure out how to navigate or operate it, the application will be useless. A long-standing issue with the hub wikis has been how/where to place all the controls a page may require (edit, delete, new, etc.), have controls for navigating the wiki as a whole, and maintain a large enough content area to facilitate legibility. For example, some wikis such as Wikipedia maintain a left sidebar with navigation options and some page tools. While such a layout would work well with a hub’s site wiki, it can become problematic with a group-level wiki due to the group’s own navigation sidebar. The user would be left with a very small column of text to read!
With the sidebar issue in mind, we added a couple links to the tabs found just below the title of every wiki page. The first link is to the new Special:AllPages page. The second link goes to the wiki’s main (or starter) page. This means no matter where a user is in a wiki, they can quickly get back to the start or find a listing of all available pages.
As noted above, what may work in one context may not in another. We’re constantly experimenting and finding a good, clean UI is an ongoing battle but we’re committed to it!
Exporting a single page or group pages for easy download could undoubtedly be useful for many hub users. This is a long-requested feature and one we hope to make reality in the near future. Some points to consider:
- What formats to support? XML? TXT? PDF would be the most likely choice as it could preserve rendering and include images found in the wiki text. A plain text version (just the wiki markup) would be easy and have the most compatibility with devices, operating systems, and programs, but wouldn’t allow for the images and attachments to carry along.
- Where to put the options for download?