Moinmoin Header got (too?) big

With version 1.5 the header of moinmoin got big, and many people on our site think unclear. Can it be refactored to use less space and get back the original clarity?

• Get more concrete about what is unclear.

I second this. Right now, in the 'Classic' theme, there are about 26 active (i.e. clickable) elements only in space of about 1.5cm from the top of the page. Some of them are not really useful when browsing.

Other themes are even worse, because they usually also add the list of actions and some additional action links, like edit and info.

It's good that MoinMoin is feature-rich, but I think it's bad that it results in incomprehensible mess. Obviously, there should be themes that look like this. But there default theme for anonymous user doesn't need those WikiGnome tools. They have to allow the user to focus on the content of the page.

• you should have a look at modern_cms for anonymous users -- ReimarBauer 2006-02-03 19:47:17

It's not really much a problem of MoinMoin, but rather of its themes. On the other hand, there's no support to encourage more systematic and better theme organisation -- no way to tell actions from each other in terms of where they should be displayed, or how 'advanced' they are. -- RadomirDopieralski 2006-02-03 19:01:28

Definitely. And actions should probably all of them be verbs. e.g. "Info"-> "See history" or "Track changes" (see interface proposal at the end for decoupling of history and other page infos). "Add link" should be something like "Add quicklink" or "Bookmark", I find the current name confusing (looks like you're going to add a link to the page). And finally "Attachments" -> "Manage attachments". At the very least, if these or other more self-explanatory texts are not adopted, enabling via CSS an onhover hint (blob) would help user interface discovery by new users. -- AlvaroTejero 2006-09-20 08:06:33

Increased urgency of lock warnings

If you're used to a wiki with strict locking, you are very likely to just over-read (ignore) the lock warnings of other wikis, like this wiki. Adding some very prominent visible clue would help, like (a smaller version of) something like this added to the left of the message:

I second this, current visual cue too weak. Using the red color and bold for "warned", etc messages could be a compromise. -- AlvaroTejero 2006-09-20 08:06:33

Quicklinks

Text should be "+Quicklink" and "-Quicklink" IMHO, just one char to add semantic info.

Then you could also use "+Notify" and "-Notify", for consistency.

-- JürgenHermann 2005-09-23 13:09:20

Current status (1.5.4) is "Add link" and "Remove link". I find this confusing (see proposal above). I find "Subscribe" and "Unsubscribe" more intimidating than "Notify changes" "Stop notifications" -- AlvaroTejero 2006-09-20 12:38:31

Category based headers and presentation customization

It would be interesting to throw a custom header (logo graphic, navigational links, css) based on a tag similar to a ProcessingInstructions tag. ie: #homepage If no instruction were found, would use site-wide default. This might be non-trivial if header is currently thrown before parsing the page. --MattWestervelt

Another possibility that allows content based presentation customization (but can't add links except changing it's display property in the CSS) is to use the page category as a CSS class for the div id="content" (In case there is more than one category in any page, we could use only one: the first, or the last (KISS principle)) instead of a processing instruction. In this way, there is no HTML code modification other than <div id="content" class="thispagecategory"> and the rest is only CSS editing, and the content itself is the indication (no need to add more metainfo).

An example of this application would be to add a background graphic to identify the type of page, change colors, or table layout.

As an example, in the CSS you could add (colors are only suggestions):

div.CategoryMoinMoinBug table {
   background-color: red; 
   font-size: 1.1em; }

div.CategoryMoinMoinBugFixed table {
   background-color: green; }

div.CategoryMoinMoinNoBug table {
   background-color: blue; }

Please note that since I'm not a programmer, I can't estimate how much work this could be. --EduardoMercovich, 2004/11/05.

Edit / update anomalies

This isn't really a MoinMoin issue, but having installed MoinMoin at work, and all of us using it extensively, we *fervently* wish that an external editor (e.g. gvim) could be used with the main textarea for editing pages. Does anyone know of a browser enhancement that does this? We are a Linux/Mac shop, but a Windows solution might give us some ideas.

• mozilla/firefox plugin to use an external editor for textareas (Appearantly this doesn't work for modern Firefox; haven't checked with Mozilla. The project hasn't been updated for a couple of years.)

• You can use 'itsalltext' addon for firefox - have a read here http://slgeorge.wordpress.com/2009/02/04/comfortable-wiki-editing/ -- Mike

Could the wrap="soft" parameter be added to the textarea definition for all editing boxes? Some browsers do not provide it by default.

• quote: "The wrap attribute is not part of the HTML standard, and when you include it the W3C and WDG validators will report it as an error."

In MoinMoinTodo it says: EditText now adds the page's timestamp to the FORM, and refuses the save if the timestamp changed between loading the editpage and saving.

I don't like this feature. On WikiWiki I'm able to make a small edit, click on Save and look at the result. Then I just push the back button and do additional changes or correct something I did wrong on the previous edit. This isn't possible on MoinMoin. Of course I can always use EditText again, but this is significantly slower. --MarkoSchulz

Marko, would a preview-button (opening a new window!) solve that problem for you? Also, note this from MoinMoinTodo: When a save is in conflict with another update, use the rcs/cvs merge process to create the new page, so the conflicts can be refactored. Warn the user of this! -- JürgenHermann

Good idea => Of course, one could add a special case by also storing a unique session cookie in a hidden field. If it's the same client, then we assume they're just pressed the back button and we let them overwrite the changes. -- MartinPool

The C2 and UseMod wikis check the user in case of a conflict. If the user is the same, the save is allowed. We presume that users can handle conflicts with themselves. (This could be a problem if multiple users edit from the same IP.) --CliffordAdams

• UseMod lives at http://usemod.org/cgi-bin/wiki.pl

Cookie mode is planned anyway, and I will add it for that; IP is not unique enough (Proxies!), but IP+User-Agent+Something probably is, I will give this some thought. -- J?rgenHermann (with an "?"

It is very likely that cookies will not be available on the majority of internet appliances for a long time, nor will they be available in browsers that do not support them or browsers that block them. I recommend gracefully degrading in the case that cookies aren't supported by the client. -- SunirShah

If the raw text of files is stored in Wiki format and converted on the fly to HTML when requested, is there a compelling reason why this couldn't degrade gracefully to a parameter added as part of the URL? Also, it would probably make sense to use a hash of the User-Agent instead of the raw string. -- AlanMiller

Edit Selection

It would be great to be able to edit only a marked selection of a Wiki-Page. Like that a lot of conflicts could be avoided, since I'm only marking the text I want to modify. This feature would be much more powerful than MediaWiki's Subsection-Edit. But how to implement it? Well there'd be some solution somehow...

-- NicoDietrich

Pure speculation: on selection event + double click send a signal to MoinMoin declaring a document chunk locked. People intending to edit overlapping chunks get a "currently blocked" message, people editing the page as a whole through the form see a comment such as ## 348 characters at this point currently edited by another user. The javascript editor popping up should be really simple, allowing only for inline markup (bold, italic, monospaced). Another, less ambitious approach consists on predefining the smallest unit which is available for in-place editing, instead of letting the user do so through selection. On hover of any (paragraph|table row|enumeration item|code fragment|heading) one would see a small link at its upper right corner with "edit", à la http://tiddlywiki.com). Is there interest to think further along these lines? -- AlvaroTejero 2006-09-20 08:06:33

Include macro reference not counted

Consider that part of what Include does is create an explicit link as well as including the contents. However, it doesn't show up in the OrphanedPages page. I understand that architecturally this is not trivial, but from the user experience point of view it's still a bug. It's possible that Include could be modified to optionall include text without an explicit link to the page from whence the text comes. I'd suggest that if it explicitly links to the page, it should be considered a reference for the purposes of the OrphanedPages page; if it just includes content without an explicit link, then it is really orphaned and should show up on the OrphanedPages page. -- Michael K. Johnson 2/19/2004

UserPreferences

see also UserPreferencesRedesign

User Preferences addition

While I see how the message box at the top of the page (seen after submitting an edit) can be informative at times, it can still be rather annoying and distracts from the initial impression I get when submitting (OMG, what did I do? Oh, it's just the messege...).

Therefore,

I think the user preferences page should have an option "Display message box after editing" or something... or maybe some kind of filter "only show messege box for..." (or "show messege box only for..."). This shouldn't be terribly hard to implement, just an extra check at rendering time. --IsaacFreeman

Add a more complete and all-in-one-place user guide

For example, see the one at http://history.punk.net/history/moin.cgi/history/WikiHowtoSupplement

Automatic table formating

See example at http://mac.plonter.co.il/plonwiki/HelpOnMacros. This was done manually, and could be done automatically by the parser/formatter.

How to do this:

• Add "even" to the class of any even table row (excluding the first one which will be the header), and an table_row.even to the css

• Put the cells of the first row of the table in <th> tags, and add th rule to the css

• Add a markup to disable automatic formating, for those rare cases when people want to spend their time on designing custom tables (which is crazy, but there is no law against it). Maybe something like <tableclass="classname"> which will replace the default wikitable class, which is autoformated by the default table.wikitable.* rules in the css. if classname exists in the css, the table will use this class design, and if it does not exists, it will use standard table design.

this markup:

|| header cell 1 || header cell 2 || header cell 3 ||
|| row 1 cell 1 || row 1 cell 3 || row 1 cell 3 ||
|| row 2 cell 1 || row 2 cell 3 || row 2 cell 3 ||
|| row 3 cell 1 || row 3 cell 3 || row 3 cell 3 ||

Will be formated as:

<table class="wikitable">
    <tr>
        <th>header cell 1</th><th>header cell 2</th><th>header cell 3</th>
    </tr>
    <tr>
        <td>row 1 cell 1</td><td>row 1 cell 2</td><td>row 1 cell 3</td>
    </tr>
    <tr class="even">
        <td>row 2 cell 1</td><td>row 2 cell 2</td><td>row 2 cell 3</td>
    </tr>
    <tr>
        <td>row 3 cell 1</td><td>row 3 cell 2</td><td>row 3 cell 3</td>
    </tr>
</table>

Using CSS like this:

table.wikitable {border: table border}
table.wikitable th {background-color: header bgcolor}
table.wikitable tr.even { background-color: even row bgcolor}

Check example html: auto-format-tables.html

I find this excellent, shipping by default a table style which enhances readability would definitely help a lot. -- AlvaroTejero 2006-09-20 08:06:33

"Infos" link on toolbar (was "Get Info")

"Infos" is clumsy English, it should read "Info". Actually it should probably read "Diffs" since that is a more accurate description. -- JasonStirling 2005-09-28 05:58:33

Will change it to "Info". Diffs is not more accurate, as history / diffs is just one part of what you can get. Thus, "Info" being more general matches better. -- ThomasWaldmann 2005-09-28 06:19:49

IMHO, "History" or "Changes" is an established piece of wiki/versioning systems Standard User Interface. And, at the same time, the statistical information (hits) and general information (where the attachment number looks to me a little bit redundant) are much less frequently used. My proposal would be to split these actions, so that "Track changes" would be a much more clear element of the default UI and the other two would be available by default through the "More actions" menu. -- AlvaroTejero 2006-09-20 08:06:33

Ask if save changes before leaving the PageEditor

I've got lost many of my article drafts due to miss-handling mouse or keyboard. For example, while editing the text: I click outside of the textarea and press backspace; click the back button of 5-button mouse; or just close the web browser. My idea is that the editor should ask him/her if he/she'd like to save changes before leaving the page. In order to do this, we can use the javascript event, 'onbeforeunload'. I've inserted some modifications into the wiki and tested it on IE 6, it works well. You can get more detailed information from /AskSaveChanges. -- SeungikLee 2005-10-20 16:13:22

• Is a cross-browser implementation easy? -- AlvaroTejero 2006-09-20 08:06:33

Rename page has unuseful default

The rename page currently shows two fields: New name and Optional reason for the renaming. The New Name field contains as a default string the current name. This is not useful at all. In the majority of cases one finds himself deleting this text first and then entering the new text. Ideally one would type the new name, optionally hit tab to visit the optional reason field, and then hit enter to commit.

• The default is good and useful. For example: choose Rename Page, the rename dialog opens, hit tab to move into the new name field, type the new name, hit Enter. The only thing missing is to change the focus to the new name when the rename dialog opens automatically. Note that in a good rename interface, the old name is the default new name, and is selected when you start to rename.

  • So you say that a useful default is the only string which is known, by principle, not to be going to be the new name? Sorry, but I fail to see the logic. I'd rather have the old name as a reference, e.g. "Rename page XXXX to: [ ]". Could you provide a reference for in a good rename interface, the old name is the default new name in a web/forms context?

    • An example of good rename ui on Mac: You click a file name, the name become selected. You either type the new name or click to put the cursor somewhere in the name and type. Click out of the text or hit tab to confirm. An example from the web: In JotSpot, you can rename a page by clicking on the page title. The text is replaced with a text field (but is not selected). You either select and type or put the cursor somewhere and type. You confirm by clicking the same button near the text field. You can try this in my test wiki. In this case, JotSpot rename is too good - you don't want users to rename pages, because renaming pages creates broken links.

    • In many cases you intend to modify the existing name, not change it completely (like for instance to correct a typo). Having the old name there but selected is the best of both worlds. You can just start typing and the old name disappears, or you can hit an arrow key and modify the text.