Preface

My suggestions for a new default theme for Moin2

The major release of the Version 2.x of MoinMoin offers great opportunities to create a new, modern way of presenting wiki pages to the user.

As the doctype is already HTML5 and the final release of Moin2 is still a bit away, there is also the possibility to also include many brand new features of HTML5 and the stuff that comes along with it. Because the new 2.x release will stay around a long the time, we should really work on the current state of the art here!

Also I want to describe some general thought which are independent from the current state of web design and web development, such as general user experience issues.

And last but not least we should not forget that the common user needs optical changes to a software that he got the desire to trying something out again, with a good well-thought design / UI / etc. we can catch the common people more than with listing the massive feature changes

The sizes and typography, and also some other parts are highly theoretical in terms of designing a page. The "freedom" on a webpage, to use the theoretical best values for dividing and sizing of page elements are almost nowhere give because you have almost everywhere restraints because of pictures, etc. on which you have to depend on. Perhaps a wiki theme is the best thing to try to accomplish some things you dismiss otherwise in favour of client input or some pixel-based restrictions because of images etc.

Layout

Some general design thoughts relating to the positioning of the elements on the page.

Sidebar vs. Full Width

The trend on computer displays are clearly going to widescreen, which is great for movies etc. but reading a long text which goes over the whole width of the screen, it makes things even worse. The aspect ratio of a computer display is already not the best for reading something. (For that read more below at "Typography") The conclusion for pages with focus on text is, don't steal more than really needed from the height of the content area, take the space you need preferably from the left or the right side (which side is due to the culture and country the viewer lives in, see "LTR & RTL"), or short: for wiki pages a sidebar navigation is more preferable than the current theme. A sidebar on both sides of the page could also be a possibilty (of course floatable when someone have a small screen).

Which part where?

• Page title stays on the top
  • but not inside the scrollable content area, so that it is alway clear on which page you are
  • page title may be different than page name (page title is first h1 within page content)
• Only other element which stays on top: Breadcrumbs
  • Breadcrumbs are sometimes really long and are the only thing which doesn't work good with a sidebar
• Content area under the Page title and the breadcrumbs
  • this part with scroll attribute
• Sidebars
  • left sidebar include the Action links etc.
    • perhaps also the user login - register on a seperate page is okay because there is the need to type in more information. but a login only requires two forms, user and password.
    • When logged in, display on that position who is logged in

  • right sidebar optional, or for example activated while creating or editing a page, including a drag&drop area for easy uploading of files

    • Drag & Drop - Upload Examples:

      • https://github.com/blueimp/jQuery-File-Upload/wiki - good documentation, not too bloated, the example runs with Python on the serverside

      • http://aquantum-demo.appspot.com/file-upload - jquery-based, which is used for Moin2 already

      • http://www.plupload.com/ - BIG libary/tool which can also handle drag & drop upload, from the guys who brought us TinyMCE

  • if country is a ltr writing country, sidebars are switched, right nav, left optional

A download dropbox on the right side inside the content area.

Sizes

The area where the most important part is, is the text area, i write some things on the text lenght in the typography part.

Typography

The rules of typography have a long tradition in printed publications but almost completely apply to text displayed on a computer screen.

Rules for good legibility in printed publications are:

• for "linear reading" (aesthetic content, literature) the maximum line length is 60-70 Chars
• for "informational reading" (text for quick informations, quick reading and quick understanding) the maximum line length is 40-50 Chars
• for "differentiating reading" the maximum line length is up to 80 Chars

In general, the rules for good legibiltiy strongly recommend not to use more than 80 chars. If you do not know the type of the text is but want it to be legible use 50-70 chars, many designers say.

Even in the wikipedia which contains many texts which are really long, the rules of good typography and especially legibility don't recieve the attention they should.

But have a try for yourself and read a text that you formatted like this, and subliminal you recognize that you can read longer, faster and also understand faster what you are reading.

The rules of printed typography could be realized really easy for wiki content, just use the em and ex measurement units! (they are also used in the printing area for the exact same purpose, see: http://en.wikipedia.org/wiki/Em_%28typography%29)

Why use em and ex? Because fonts have different char widths, and you cannot give a recommendation in an absolute measurement unit and also not in percentage, because that also differs from PC to PC.

Okay every where is a exception in some special cases, when for example the 60em get to wide when using a font with a big char length compared to the char height, in printed publications you then also got to have a look that the 60 chars do not get longer than 14cm because then you have to horizontally move your head which causes fatigue and reading appeal get lost very fast. (I don't have a solution how you could estimate that in screen use and implement but if you know a easy way tell me *g*)

The line height is said to be in general about 20% bigger than the used text size, but could be also bigger than 20% if the line length is very long.

Text color should perhaps be #444 because it is easier on the eyes, when reading long texts. Only on mobile phones it should be #000, there it looks better.

I will finish this soon, right now, too much paid work to do..

Feel free to delete or reword this - I think your analysis should include an enumeration of the hyperlinks and boilerplate that make up the UI on the existing/proposed theme(s).

• Thanks - I didnt finish my writing by far!!! But I had much to do so I've forgotten this page. I made this page for my suggestions, perhaps in the end we could place a summary of all ideas somewhere else - for the student who do the Moin2 theme for the SoC 2011!

Suggestions of others

Composition and Grouping of UI Hyperlinks and Boilerplate

• what kinds of custom links can be added by a wiki user or a wiki administrator?
• is the current grouping the best way (are there conflicts for best way for top bar vs. sidebar)
• how does Moin compare to other popular wikis, are there links (or groups of links) that could be added or eliminated
• how should UI vary based on current page action: show, edit, preview, info, etc.
• can better positioning/naming of hyperlinks improve the productivity of a wiki user (faster learning curve)