Newbie friendliness, markup hell, and editing structure

[Magnus Manske-2]

One of the reasons everyone and their sockpuppet scream "WYSIWYG
editor" is the accumulation of intricate wiki markup on even otherwise
simple pages. Coincidentally, this is also what prevents a WYSIWYG
editor at the moment ;-)
It is also said that the template hell and other things scare away
newbies, or lead to their accidental breaking of pages.

Once Upon A Time (TM), I wrote a function into MediaWiki that would
separate some of the meta content into a separate editing area, thus
reducing the clutter in the actual edit box. The code's still there,
deactivated, and probably broken right now.

Today, I rewrote the thing in JavaScript. It separates
* templates, images, and horizontal lines at the top of a page
* templates and some magic words at the end of a page
* categories
* language links
into text boxes of their own. This happens automatically right after
loading the edit page, and it all gets reconstructed into a single
text the moment you save, preview, or diff the edit. On preview or
diff, everything gets separated again.

It is only enabled for the article namespace. Top and bottom edit
boxes can be hidden (I could add an option to hide either as default),
and everything can be reset to "standard", giving the normal edit page
for the moment.

Besides better structuring of article body and "meta" content, it does
clean up whitespace, sort categories and language links
alphabetically, etc.

A demo of what it does to [[Stevan Faddy]], a short, regular biography, is here:
http://www.magnusmanske.de/wikipedia/less_page_clutter.png

Finally, the script:
http://en.wikipedia.org/wiki/User:Magnus_Manske/less_edit_clutter.js

It seems that there is no "withJS" option on en.wikipedia, which would
allow for a transient demo.
To use, add the usual incantation to your monobook.js:
importScript('User:Magnus Manske/less edit clutter.js');

Cheers,
Magnus

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Brian J Mingus]

Smart!

On Mon, Mar 10, 2008 at 4:59 PM, Magnus Manske <magnusmanske@...>
wrote:

> One of the reasons everyone and their sockpuppet scream "WYSIWYG
> editor" is the accumulation of intricate wiki markup on even otherwise
> simple pages. Coincidentally, this is also what prevents a WYSIWYG
> editor at the moment ;-)
> It is also said that the template hell and other things scare away
> newbies, or lead to their accidental breaking of pages.
>
> Once Upon A Time (TM), I wrote a function into MediaWiki that would
> separate some of the meta content into a separate editing area, thus
> reducing the clutter in the actual edit box. The code's still there,
> deactivated, and probably broken right now.
>
> Today, I rewrote the thing in JavaScript. It separates
> * templates, images, and horizontal lines at the top of a page
> * templates and some magic words at the end of a page
> * categories
> * language links
> into text boxes of their own. This happens automatically right after
> loading the edit page, and it all gets reconstructed into a single
> text the moment you save, preview, or diff the edit. On preview or
> diff, everything gets separated again.
>
> It is only enabled for the article namespace. Top and bottom edit
> boxes can be hidden (I could add an option to hide either as default),
> and everything can be reset to "standard", giving the normal edit page
> for the moment.
>
> Besides better structuring of article body and "meta" content, it does
> clean up whitespace, sort categories and language links
> alphabetically, etc.
>
> A demo of what it does to [[Stevan Faddy]], a short, regular biography, is
> here:
> http://www.magnusmanske.de/wikipedia/less_page_clutter.png
>
> Finally, the script:
> http://en.wikipedia.org/wiki/User:Magnus_Manske/less_edit_clutter.js
>
> It seems that there is no "withJS" option on en.wikipedia, which would
> allow for a transient demo.
> To use, add the usual incantation to your monobook.js:
> importScript('User:Magnus Manske/less edit clutter.js');
>
> Cheers,
> Magnus
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l@...
> To unsubscribe from this mailing list, visit:
> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Judson Dunn-2]

This seems like a pretty clear improvement in the interface, at least
for novice users, and as you say it can be deactivated for more
experienced people. As a proof of concept it looks pretty great. I
would say if this were going live, make the defaults be to not show
the header or footer, and only have this active in the mainspace. As
people are experienced more they could turn on the full editing view
in their preferences.

Judson
http://en.wikipedia.org/wiki/User:Cohesion

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Simon Walker-4]

Brilliant - I personally feel that this should be included in the gadgets
seciton of the user properties, and enabled by default for all new users.

Stwalkerster

On 11/03/2008, Judson Dunn <cohesion@...> wrote:

>
> This seems like a pretty clear improvement in the interface, at least
> for novice users, and as you say it can be deactivated for more
> experienced people. As a proof of concept it looks pretty great. I
> would say if this were going live, make the defaults be to not show
> the header or footer, and only have this active in the mainspace. As
> people are experienced more they could turn on the full editing view
> in their preferences.
>
> Judson
> http://en.wikipedia.org/wiki/User:Cohesion
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l@...
> To unsubscribe from this mailing list, visit:
> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Thomas Dalton]

On 11/03/2008, Judson Dunn <cohesion@...> wrote:
> This seems like a pretty clear improvement in the interface, at least
>  for novice users, and as you say it can be deactivated for more
>  experienced people. As a proof of concept it looks pretty great. I
>  would say if this were going live, make the defaults be to not show
>  the header or footer, and only have this active in the mainspace. As
>  people are experienced more they could turn on the full editing view
>  in their preferences.

I haven't looked to see how it works, but if the header/footer are
going to be hidden by default, it needs to be very easy to work out
how to view them - having parts of the page that you can't easily edit
would be a very bad thing.

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Oldak Quill]

On 10/03/2008, Magnus Manske <magnusmanske@...> wrote:

> One of the reasons everyone and their sockpuppet scream "WYSIWYG
>  editor" is the accumulation of intricate wiki markup on even otherwise
>  simple pages. Coincidentally, this is also what prevents a WYSIWYG
>  editor at the moment ;-)
>  It is also said that the template hell and other things scare away
>  newbies, or lead to their accidental breaking of pages.
>
>  Once Upon A Time (TM), I wrote a function into MediaWiki that would
>  separate some of the meta content into a separate editing area, thus
>  reducing the clutter in the actual edit box. The code's still there,
>  deactivated, and probably broken right now.
>
>  Today, I rewrote the thing in JavaScript. It separates
>  * templates, images, and horizontal lines at the top of a page
>  * templates and some magic words at the end of a page
>  * categories
>  * language links
>  into text boxes of their own. This happens automatically right after
>  loading the edit page, and it all gets reconstructed into a single
>  text the moment you save, preview, or diff the edit. On preview or
>  diff, everything gets separated again.
>
>  It is only enabled for the article namespace. Top and bottom edit
>  boxes can be hidden (I could add an option to hide either as default),
>  and everything can be reset to "standard", giving the normal edit page
>  for the moment.
>
>  Besides better structuring of article body and "meta" content, it does
>  clean up whitespace, sort categories and language links
>  alphabetically, etc.
>
>  A demo of what it does to [[Stevan Faddy]], a short, regular biography, is here:
>  http://www.magnusmanske.de/wikipedia/less_page_clutter.png
>
>  Finally, the script:
>  http://en.wikipedia.org/wiki/User:Magnus_Manske/less_edit_clutter.js
>
>  It seems that there is no "withJS" option on en.wikipedia, which would
>  allow for a transient demo.
>  To use, add the usual incantation to your monobook.js:
>  importScript('User:Magnus Manske/less edit clutter.js');
>
>  Cheers,
>  Magnus

Great work. Would it be possible to adapt this into a tool to separate
the source of an article into: references and everything else?

Slightly different: would it be possible to have an editing interface
where tags of the form "<ref name="">{{template}}</ref>" in the body
are pulled out to a separate text box, leaving a token in the body
text (e.g. <ref name="" />)? Separating the content of these tags
would clean up the body when editing and the token left in the body
would indicate that there is a tag here and that it has this name (see
ref text box).

--
Oldak Quill (oldakquill@...)

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Magnus Manske-2]

On Tue, Mar 11, 2008 at 12:06 PM, Oldak Quill <oldakquill@...> wrote:

>  Great work. Would it be possible to adapt this into a tool to separate
>  the source of an article into: references and everything else?
>
>  Slightly different: would it be possible to have an editing interface
>  where tags of the form "<ref name="">{{template}}</ref>" in the body
>  are pulled out to a separate text box, leaving a token in the body
>  text (e.g. <ref name="" />)? Separating the content of these tags
>  would clean up the body when editing and the token left in the body
>  would indicate that there is a tag here and that it has this name (see
>  ref text box).

Technically, yes, should be possible (in the article namespace, there
should be no "funny" nowiki constructs etc.).

But would that really help? I can see where it would be good to have a
reference replaced with, say, some tiny red number that one can click
on an that expands into the reference. But in a plain text editor,
there'd still be the "empty" reference; I'd have to make up some ID
for "unnamed" ones; then make some pseudo-text-table edit box
somewhere.

I could try to whip up some "monitoring script" that constantly checks
where your cursor is and somehow highlights the appropriate reference
in a list box. Might be worth a shot.

That's another thing that came to mind. Currently, I strip "[[", "]]",
and category prefix from categories and language links, and put them
in separate textboxes. But, as these are always single lines
(actually, key:value pairs), would it be more appropriate to change
these into list boxes? Then I could add pretty buttons ("Delete
category", "Add category", etc.). Of course, I could do that for the
current textareas as well.

Cheers,
Magnus

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Magnus Manske-2]

On Tue, Mar 11, 2008 at 12:06 PM, Oldak Quill <oldakquill@...> wrote:

>  Great work. Would it be possible to adapt this into a tool to separate
>  the source of an article into: references and everything else?
>
>  Slightly different: would it be possible to have an editing interface
>  where tags of the form "<ref name="">{{template}}</ref>" in the body
>  are pulled out to a separate text box, leaving a token in the body
>  text (e.g. <ref name="" />)? Separating the content of these tags
>  would clean up the body when editing and the token left in the body
>  would indicate that there is a tag here and that it has this name (see
>  ref text box).

OK, I took the challenge. I integrated a reference management tool.
Works like this:
* It extracts all <ref></ref> tags from the text
* It replaces them with "<<REF1>>", "<<REF2>>", etc.
* These special tags are valid only during editing; upon preview,
diff, or save, they are replaced with the original
* This is /not/ done if the text already contains something like
"<<REFX>>" (X being any number), so it won't mess up texts
* It also does not touch "repeated refs" (<ref name="xyz"/>)

Below the normal text box, there is now a list box, one line per
reference, containing number, name (if set), and text of the
reference. You can
* select a line, and it will highlight the corresponding <<REF>> in
the text (no scrolling there yet; working on it)
* double-click the line, and edit name and text in a dialog
* select a reference and delete it

In the text boxes, you can
* select the <<REF>> tag (double-clicking it will do), and it shows
the corresponding reference in the list
* insert a new reference at the current position (name and text dialogs again)

I have taken care to "default to standard", that is, things will not
be changed (even temporarily) unless it's safe to do so.

Also, new screenshot, editing yesterday's article of the day, [[John
Knox]], with the reference management:
http://www.magnusmanske.de/wikipedia/less_page_clutter.png

Even in this huge, real-life example, the only changes the script
would do (as seen in a diff) are alphabetical reordering of language
links and categories.

Cheers,
Magnus

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Oldak Quill]

On 12/03/2008, Magnus Manske <magnusmanske@...> wrote:

> On Tue, Mar 11, 2008 at 12:06 PM, Oldak Quill <oldakquill@...> wrote:
>  >  Great work. Would it be possible to adapt this into a tool to separate
>  >  the source of an article into: references and everything else?
>  >
>  >  Slightly different: would it be possible to have an editing interface
>  >  where tags of the form "<ref name="">{{template}}</ref>" in the body
>  >  are pulled out to a separate text box, leaving a token in the body
>  >  text (e.g. <ref name="" />)? Separating the content of these tags
>  >  would clean up the body when editing and the token left in the body
>  >  would indicate that there is a tag here and that it has this name (see
>  >  ref text box).
>
>
> OK, I took the challenge. I integrated a reference management tool.
>  Works like this:
>  * It extracts all <ref></ref> tags from the text
>  * It replaces them with "<<REF1>>", "<<REF2>>", etc.
>  * These special tags are valid only during editing; upon preview,
>  diff, or save, they are replaced with the original
>  * This is /not/ done if the text already contains something like
>  "<<REFX>>" (X being any number), so it won't mess up texts
>  * It also does not touch "repeated refs" (<ref name="xyz"/>)
>
>  Below the normal text box, there is now a list box, one line per
>  reference, containing number, name (if set), and text of the
>  reference. You can
>  * select a line, and it will highlight the corresponding <<REF>> in
>  the text (no scrolling there yet; working on it)
>  * double-click the line, and edit name and text in a dialog
>  * select a reference and delete it
>
>  In the text boxes, you can
>  * select the <<REF>> tag (double-clicking it will do), and it shows
>  the corresponding reference in the list
>  * insert a new reference at the current position (name and text dialogs again)
>
>  I have taken care to "default to standard", that is, things will not
>  be changed (even temporarily) unless it's safe to do so.
>
>  Also, new screenshot, editing yesterday's article of the day, [[John
>  Knox]], with the reference management:
>
> http://www.magnusmanske.de/wikipedia/less_page_clutter.png
>
>
> Even in this huge, real-life example, the only changes the script
>  would do (as seen in a diff) are alphabetical reordering of language
>  links and categories.

Thank you! This should really help with references. It makes the body
in the edit window look a lot cleaner (hopefully less confusing for
newbies). Should help most users with readability of text being
edited.

--
Oldak Quill (oldakquill@...)

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Delirium]

Magnus Manske wrote:

> On Tue, Mar 11, 2008 at 12:06 PM, Oldak Quill <oldakquill@...> wrote:
>>  Great work. Would it be possible to adapt this into a tool to separate
>>  the source of an article into: references and everything else?
>>
>>  Slightly different: would it be possible to have an editing interface
>>  where tags of the form "<ref name="">{{template}}</ref>" in the body
>>  are pulled out to a separate text box, leaving a token in the body
>>  text (e.g. <ref name="" />)? Separating the content of these tags
>>  would clean up the body when editing and the token left in the body
>>  would indicate that there is a tag here and that it has this name (see
>>  ref text box).
>
> Technically, yes, should be possible (in the article namespace, there
> should be no "funny" nowiki constructs etc.).
>
> But would that really help? I can see where it would be good to have a
> reference replaced with, say, some tiny red number that one can click
> on an that expands into the reference. But in a plain text editor,
> there'd still be the "empty" reference; I'd have to make up some ID
> for "unnamed" ones; then make some pseudo-text-table edit box
> somewhere.

What'd help, IMO, is not requiring the actual body of the reference to
be inline at the point of the first use, which results in a bunch of
messy markup in the middle of a paragraph. If all the inline references
could be of the form <ref name="foo" />, and the actual definition of
reference "foo" were somewhere else (above the main text, below it,
wherever), that'd make the references a lot more intrusive. It seems
this would be a markup/parser change, not requiring any sort of
interface-side change.

-Mark

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Steve Bennett-8]

On 3/13/08, Magnus Manske <magnusmanske@...> wrote:
>  Also, new screenshot, editing yesterday's article of the day, [[John
>  Knox]], with the reference management:
>
> http://www.magnusmanske.de/wikipedia/less_page_clutter.png

Could you install this on testwiki or something so we can all play
with it? (without having to keep hacking our js files, that is...)

Steve

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Steve Bennett-8]

On 3/13/08, Magnus Manske <magnusmanske@...> wrote:

In general, I really like the goal here - removing metadata from the
body of the wikitext. However, I"m a bit torn by the idea of then
separating and reformatting some of that metadata. It's nice to
display categories in a list and allow them to be manipulated
directly, if the underlying data structure is a list. But the
underlying data structure is really just a number of embedded
elements:

[[category:foo]]
blah
[[category:x]]

etc. The same arguments against wysiwyg apply, in weaker form, here:
the underlying text is rearranged, people may have had reasons for
ordering categories in a certain way etc. For example, how will this
be resaved:

[[Category:Martian rock singers]]
<!-- as per lengthy discussion, DO NOT REMOVE -->
[[Category:Jewish Martian golfers]]

Will the comment be trimmed? etc.

Since there is very little consensus over the "correct" ordering of
metadata, any tool which reformats metadata in some rigid format is
bound to step on some toes. Which is probably just an argument for
*reaching* some consensus on metadata formatting, of course.

Perhaps one solution to this is to make the GUI dynamic, reflecting
the contents of the wikitext. That is, this:
----
{{hatnote}}
Some text<ref>RRR</ref>
Foo
[[Category:blah]]

{{template}}

[[Category:foo]]
<references />
----

Could produce an editing environment as follows:

* Edit box for header stuff, containing {{hatnote}}
* Edit box for main text, containing "Some text <<ref>> / Foo"
* List box for categories, containing blah
* Edit box for footer stuff, containing {{template}}
* List box for categories, containing foo
* List box for references

That is, the wikitext is effectively decomposed into sections, and
edit boxes of the appropriate types assembled in order.

Someone is bound to mention that since it's javascript, anyone can
customise it however they want, but I think that's the wrong approach.
We should be trying to find a good solution that satisfies almost
everyone, and end up with almost all users of Wikipedia using it.

Steve

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Ian Woollard]

On 17/03/2008, Steve Bennett <stevagewp@...> wrote:
>  Since there is very little consensus over the "correct" ordering of
>  metadata, any tool which reformats metadata in some rigid format is
>  bound to step on some toes. Which is probably just an argument for
>  *reaching* some consensus on metadata formatting, of course.

Yes, I've been using the tool for actual editing and that's already
happened; somebody claimed that there was a 'right' way to order the
interwiki language markups and rearranged it after I submitted.

The other problems I've had have been that one time the tool took an
image on the end of a section I was editing and placed it in the
interwiki language box. It kinda confused me because the image wasn't
where I expected. ;-)

I also have been having issues with the references; this is one area
where the editing tool shows great potential, but there's currently no
way to edit a reference, without entirely deleting it and recreating
it from scratch, which is a *huge* nuisance.

But other than that it looks promising. Oh and the 'header section and
templates' section is much too big- it should be about 2-3 lines tall
at most, they can always scroll if they need to.

>  Perhaps one solution to this is to make the GUI dynamic, reflecting
>  the contents of the wikitext. That is, this:

Not sure, perhaps simply a smaller box in each case might be a simpler
and more straightforward idea.

>  Steve

--
-Ian Woollard

We live in an imperfectly imperfect world. If we lived in a perfectly
imperfect world things would be a lot better.

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[PeterAnsell]

On 17/03/2008, Steve Bennett <stevagewp@...> wrote:
> On 3/13/08, Magnus Manske <magnusmanske@...> wrote:
>  Since there is very little consensus over the "correct" ordering of
>  metadata, any tool which reformats metadata in some rigid format is
>  bound to step on some toes. Which is probably just an argument for
>  *reaching* some consensus on metadata formatting, of course.

There is very little consensus about people making a point of having
categories or interwiki links in a specific order or in separate parts
of the document. What ordered metadata can you describe, other than
the example with the comment that is used solely for ease of freetext
editing and could be better defined in a permanent section on the
discussion page? Unless there is any actual reason for wanting to have
one category declared between a template and something else, when
infact the position of declaration is completely meaningless, it seems
like a distraction to talk about it being a lack of consensus.

>  * Edit box for header stuff, containing {{hatnote}}
>  * Edit box for main text, containing "Some text <<ref>> / Foo"
>  * List box for categories, containing blah
>  * Edit box for footer stuff, containing {{template}}
>  * List box for categories, containing foo
>  * List box for references
>
>  That is, the wikitext is effectively decomposed into sections, and
>  edit boxes of the appropriate types assembled in order.
>
>  Someone is bound to mention that since it's javascript, anyone can
>  customise it however they want, but I think that's the wrong approach.
>  We should be trying to find a good solution that satisfies almost
>  everyone, and end up with almost all users of Wikipedia using it.

Still don't quite see what your point is with two interleaved list
boxes to accommodate a preference to define categories in a
meaningless order. As far as the rest is concerned, it would be nice
to have a place just for references, which may facilitate a movement
away from the unwieldy system of intext full citations that we
currently endure because there is no better alternative.

Overall looks promising to me.

Peter

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Steve Bennett-8]

On 3/17/08, Peter Ansell <ansell.peter@...> wrote:
> There is very little consensus about people making a point of having
>  categories or interwiki links in a specific order or in separate parts
>  of the document. What ordered metadata can you describe, other than
>  the example with the comment that is used solely for ease of freetext
>  editing and could be better defined in a permanent section on the
>  discussion page? Unless there is any actual reason for wanting to have
>  one category declared between a template and something else, when
>  infact the position of declaration is completely meaningless, it seems
>  like a distraction to talk about it being a lack of consensus.

I'm primarily talking about the crucial issue of whether interwiki
links come before categories or after them. This matters a *lot*. To
some people. It's one of those sort of irrational situations we have
where X is ok, Y is ok, but changing X to Y is not ok. British English
is ok. American English is ok. Converting British to American English
is not ok. Interwikis then categories is ok. Cats then interwikis is
ok. Moving interwikis before categories is not ok.

The issue of the ordering of categories themselves is probably best
solved by not reordering. Since category ordering affects the visual
presentation, it's not really safe to just arbitrarily reorder them.


> Still don't quite see what your point is with two interleaved list
>  boxes to accommodate a preference to define categories in a
>  meaningless order. As far as the rest is concerned, it would be nice

The interleaved example is probably contrived. I don't think the free
variation of order can be just ignored though. As Ian found out.

Steve

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Gwern Branwen]

On Mon, Mar 10, 2008 at 6:59 PM, Magnus Manske
<magnusmanske@...> wrote:

> One of the reasons everyone and their sockpuppet scream "WYSIWYG
>  editor" is the accumulation of intricate wiki markup on even otherwise
>  simple pages. Coincidentally, this is also what prevents a WYSIWYG
>  editor at the moment ;-)
>  It is also said that the template hell and other things scare away
>  newbies, or lead to their accidental breaking of pages.
>
>  Once Upon A Time (TM), I wrote a function into MediaWiki that would
>  separate some of the meta content into a separate editing area, thus
>  reducing the clutter in the actual edit box. The code's still there,
>  deactivated, and probably broken right now.
>
>  Today, I rewrote the thing in JavaScript. It separates
>  * templates, images, and horizontal lines at the top of a page
>  * templates and some magic words at the end of a page
>  * categories
>  * language links
>  into text boxes of their own. This happens automatically right after
>  loading the edit page, and it all gets reconstructed into a single
>  text the moment you save, preview, or diff the edit. On preview or
>  diff, everything gets separated again.
>
>  It is only enabled for the article namespace. Top and bottom edit
>  boxes can be hidden (I could add an option to hide either as default),
>  and everything can be reset to "standard", giving the normal edit page
>  for the moment.

...
>  Cheers,
>  Magnus

I'm using it now. I really like it, but after a few minutes a few
things strike me:

# How about a box for External links sections? It makes quite as much
sense as one for References or headers.
# When there's nothing for a particular section, it would be great if
your script could collapse the box until opened; and then if you add
stuff into it, it could insert it into the article with the
appropriate header in the appropriate place. That would be neat.

--
gwern

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[PeterAnsell]

On 17/03/2008, Steve Bennett <stevagewp@...> wrote:

> On 3/17/08, Peter Ansell <ansell.peter@...> wrote:
>  > There is very little consensus about people making a point of having
>  >  categories or interwiki links in a specific order or in separate parts
>  >  of the document. What ordered metadata can you describe, other than
>  >  the example with the comment that is used solely for ease of freetext
>  >  editing and could be better defined in a permanent section on the
>  >  discussion page? Unless there is any actual reason for wanting to have
>  >  one category declared between a template and something else, when
>  >  infact the position of declaration is completely meaningless, it seems
>  >  like a distraction to talk about it being a lack of consensus.
>
>
> I'm primarily talking about the crucial issue of whether interwiki
>  links come before categories or after them. This matters a *lot*. To
>  some people. It's one of those sort of irrational situations we have
>  where X is ok, Y is ok, but changing X to Y is not ok. British English
>  is ok. American English is ok. Converting British to American English
>  is not ok. Interwikis then categories is ok. Cats then interwikis is
>  ok. Moving interwikis before categories is not ok.

People argue about the most petty things. As I didn't realise about
the ability to order the way categories are displayed I may be missing
a dependency between interwiki's and categories, or it might just be
people not realising their preference doesn't actually get displayed
differently to anyone elses preference and hence they should just
focus on the meaningful parts of the article.

>  The issue of the ordering of categories themselves is probably best
>  solved by not reordering. Since category ordering affects the visual
>  presentation, it's not really safe to just arbitrarily reorder them.
>

I stand corrected, I didn't realise that one could change the ordering
of the categories by declaring them in a different order. I was under
the naive impression that they were alphabetised and output
generically (and that interwiki's did not interfere with categories or
vice versa for that matter)

Peter

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Steve Bennett-8]

On 3/18/08, Peter Ansell <ansell.peter@...> wrote:
> People argue about the most petty things. As I didn't realise about
>  the ability to order the way categories are displayed I may be missing
>  a dependency between interwiki's and categories, or it might just be
>  people not realising their preference doesn't actually get displayed
>  differently to anyone elses preference and hence they should just
>  focus on the meaningful parts of the article.

Yeah. In case it's not clear, I think we should fix people here - by
definining a preferred order for metadata.

> I stand corrected, I didn't realise that one could change the ordering
>  of the categories by declaring them in a different order. I was under
>  the naive impression that they were alphabetised and output
>  generically (and that interwiki's did not interfere with categories or
>  vice versa for that matter)

I don't think interwikis interfere with categories, or vv.

Steve

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Magnus Manske-2]

(sorry for the late reply; was on vacation)

On Mon, Mar 17, 2008 at 3:44 AM, Ian Woollard <ian.woollard@...> wrote:
> On 17/03/2008, Steve Bennett <stevagewp@...> wrote:
>  >  Since there is very little consensus over the "correct" ordering of
>  >  metadata, any tool which reformats metadata in some rigid format is
>  >  bound to step on some toes. Which is probably just an argument for
>  >  *reaching* some consensus on metadata formatting, of course.
>
>  Yes, I've been using the tool for actual editing and that's already
>  happened; somebody claimed that there was a 'right' way to order the
>  interwiki language markups and rearranged it after I submitted.

If there's a "right" way, the tool can be altered to use it.


>  The other problems I've had have been that one time the tool took an
>  image on the end of a section I was editing and placed it in the
>  interwiki language box. It kinda confused me because the image wasn't
>  where I expected. ;-)

Uh. I'll fix that...

>  I also have been having issues with the references; this is one area
>  where the editing tool shows great potential, but there's currently no
>  way to edit a reference, without entirely deleting it and recreating
>  it from scratch, which is a *huge* nuisance.

Did you double-click on the entry in the list box? That should do it.

Cheers,
Magnus

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Magnus Manske-2]

On Mon, Mar 17, 2008 at 4:03 PM, Gwern Branwen <gwern0@...> wrote:
>  I'm using it now. I really like it, but after a few minutes a few
>  things strike me:
>
>  # How about a box for External links sections? It makes quite as much
>  sense as one for References or headers.

External links are much less structured and thus harder to recognize.
Also, they can be intermixed with a variety of templates that link to
Commons, PG, etc. But, I might add this eventually...

>  # When there's nothing for a particular section, it would be great if
>  your script could collapse the box until opened; and then if you add
>  stuff into it, it could insert it into the article with the
>  appropriate header in the appropriate place. That would be neat.

Should be easy to do.

Cheers,
Magnus

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l