Description

The redesign of the editor made some things better, although many things are still bad. Especially the default size is not good. In EditorRedesign it was mentioned as bad, that the text areas is not as wide as a normal text area. I think we should not compare both. Most texts do not need much space. Generally we write texts the autowrap and are automatically formated like standard in HTML. If I have measured correctly I have about 140 characters per line on a 1024x768.

This does look a lot like a normal text editor which is opened in full screen. But why in earth would we want that? Nobody said, why we need a wide text area. Who needs that? In HTML space we have the problem that space is terse. We must try to use space as good as possible!

-- ThiloPfennig 2006-01-20 16:53:33

As an example in standard editor mode I can pretty good work like this:

Example

Just as an example I show what Gmail does with space (this is not scaled, 1:1) :

They have not much more than 70 characters available for me on 1024x768. This enables them to have a full navigation side bar at the left, while people still can read all the text in the text area. And they even have space for advertisements and the right side bar!!! Google is not god, but i also think they have thought a lot about usability before.

• Gmail has much better situation, because years of fighting for netiquette made the default e-mail width not exceeding 70-few characters. This means they have a standard they can look at. Altrough usability and typography experts claim that there should be at most a dozen words per line for convenient reading. Tables are a separate problem and they are broken already. I prefer using CSV anyways -- it's clean, simple and discourages using tables for layout. Adding some basic text formating to it could be nice, though (links, smileys). -- RadomirDopieralski 2006-01-20 21:44:10

I also think that I t would be a good decision to put buttons above and below. It was very wrong to only move the buttons. Why? Because people where used to the old place and now do not find them. And people now do not find a save button if the have typed something which could be expected at the Comment line. I could also post this as a UsabilityObservation because I have just experienced that a new user that has never used this wiki before and had absoltely no input from me did not find a save button and now wants me to use a Word document instead. Also you have to mark "Trivial changes" or select categories at bottom and then scroll back up. This is bad usability, too.

• The whole editor page should be configurable either as a page with several macros (and probably a formatter, to wrap them up in <form> tags), like the MissingPage, or as a theme method/methods, like RecentChanges. Especially the hard-coded QuickHelp is annoying for me ;). If it's done this way, you can have lots of user experimenting with different editor layouts, and you've got some data you can base your choices for defaults on. Without it, any particular decission is just arbitrary and doesn't help anything. -- RadomirDopieralski 2006-01-20 21:44:10

  • My vote for this -- ReimarBauer 2006-01-31 08:32:39

    • I am not pro "make everything configurable" - this is also the reason why I use GNOME, not KDE. Making everyhting confugurable is often a solution if people do not want to actually make a decision of what is better. The problem is that than layout gets drifted apart. That makes theme development extremely complicated - and also you will not find a common layout any more. -- ThiloPfennig 2006-01-31 08:46:29

The problem in this case is that there's no single good solution that will work in all the cases. I'm also not a fan of UserPreferences, but note that this is not configurable per user, but per wiki -- the admin has to do it once, to fit the particular domain of the wiki. As for complicated development -- it's just a question of moving some code from PageEditor.py to a macro. -- RadomirDopieralski 2006-01-31 10:03:53

Details

So i would suggest:

• reduce the default size of text area dramatically! (lets say 75, this is Email default)
• better use the space to the left and right of the text area. Maybe options here?

  • You say so because you're hi-res. What about 640x480 users? -- RadomirDopieralski 2006-01-20 21:44:10

    • What then? They need wider screens? With style sheets we are able to do some magic. Wikis for mobiles would also me nice (WAP). Where do we draw the line. I think for 640x480 there should be special style sheets and/or layout.

      • Maybe there should be a special CSS/layout for 1024x768 and higher instead? Why should your preferences be the default? -- RadomirDopieralski 2006-01-21 23:05:10

        • Somebody show me a page with table where we need a wide editor. I have not seen one page where I need a wide editor, yet.

          • WikiEngineComparison

            • Well, this table does not fit into my monitors screen without editor, but still I can easily edit it because the editor always wraps text. Although, I would recommend splitting up huge tables into two - like they also do it in test articles in magazines, because otherwise you have to use two pages in printing. BTW: The print preview of this page in Firefox1.5/Windows looks very ugly. So you even have problems with this table when you print it. You are right, this is a table where a big window might be useful, but I think it is not an example for a good table, though, because this table is just unusable (for reading and printing even if we put put the editor beside) -- ThiloPfennig 2006-01-30 22:48:20

              • (BTW: SocialText was faster and did MobileWiki already: http://www.socialtext.com/node/75 ) -- ThiloPfennig 2006-04-21 09:33:31

• personally I loved to middle click on any page link on the top to open a second tab in my browser to look after something before continuing in writing. Now the navigation is cut off. And I would have to click somewhere in the help text below. I think some elements in a Wiki should never be cut off.

  • Just change the theme for that. The change is trivial. -- RadomirDopieralski 2006-01-20 21:44:10

    • am using the modern theme that is actively been developed. That's my point at: MoinDev/ThemeDevelopment! Now I would have to use CVS or what to edit a new style sheet if basic things change in Moin. That's because everything is depending on the theme. Would have to use a theme that is actively developed and works in 1.5. Thsi reduces the number of themes dramatically. If I copy Moin and change it now - i will be missing the good innovations. So i rather stick with the standards, especially in Wikis where layout is less important. I rather discuss issues or I would like to develop new standard themes together with other users. But most importantly more flexibily and stability would be nice. I think the usability of Moin should not be changed with themes. Themes should be for color and many some small usability changes. I f not, every wiki with another theme will have totally different user experience. Then we can forget about usability issues. We have this situation somehow today, yet. -- ThiloPfennig 2006-01-21 12:07:15

      • You can inherit from the modern theme. The one modified method can call the original method. You receive all the changes that are made this way, but still are able do add your own bits. -- RadomirDopieralski 2006-01-21 23:04:31

Note that action=edit is an action, you can write you own action, and replace PageEditor as you like with your own code, without touching the core code. I also think the editor sucks but don't have time to work on this currently.

Workaround

We can change settings by ourselves but I think Moin defaults should be good for 90%

Discussion

Plan

• Priority:
• Assigned to:
• Status: