Edit On Top

Usually, wikis allow their users to edit pages by clicking on EditPage, a link in the page footer area. Some people argue that putting this link into the page header area would save unnecessary scrolling on long pages.

This discussion came up on EddiesWikiCommentsForNextVersion, since EddiesWiki allows a customizable EddiesWikiPageTemplate. Nevertheless, this topic relates to any wiki which shares the same page design.

One of the EditTextVariations.

One school of thought is that having all EditPage/Reply to comment widgets on the bottom increases signal by slightly increasing the amount of time between the impulse to blather and the ability to do so. It may also cause a few more people to actually read the entire page before throwing in their (probably redundant) two cents. (I think I first saw this argument on Arsdigita's Building an Online Community page, but I'm having no luck in googling for it.) -- JoeWeaver

[This argument sounds a lot like the origin of the qwerty keyboard - an artifice to force users to slow down because of the limitations of the medium. I'm not sure it's terribly effective in this case.] -- AnonymousDonor

I'm really not sure if that argument is correct or if you're correct, but it bears pondering.

I am sure that many of you have noticed this in page navigation on tutorials on the internet. where the navigation between pages occurs at the top for rapidly following the tutorial by skipping the scroll to bottom, and the choices at the bottom for those who have read through the page content and wish to go to the next page.

If it appears only in one position, the bottom would be the logical position, for it would be assumed that anyone wishing to edit a page has read more than the top few lines. (new content should be added at bottom, not as the habit of some is, at the top. But appearance in both places would be preferred. -- Another AnonymousDonor

I agree very strongly with your arguments. On the other hand, I sometimes decide to edit a page which I have read, but not directly after reading it to the bottom. One easy example would be to adjust link referrals to other wiki pages. Thus I navigate to the page and need to scroll to the bottom to perform what I am up to anyway. So I would favor the top and bottom positions.

The other idea would be to have the wiki page in frames, so that there is a top or bottom area that doesn't scroll away - then it is up to the page designer where to place it and also the duplication of functionality would be avoided for short pages.

There is even a third way I have seen on the web: no EditPage-button at all, but simply double-clicking the text changes from read-mode to edit-mode. The drawback to this is that people get confused with the usual feature that double clicking opens links. -- Michael

That third way is not supported by various browsers. -- vk

In tutorials, I find it tedious that the Continue or Next function has to be found at the foot of the page. On Wiki, however, I merely need to know how big the page is before I start to edit it, so that I know when a Wiki page is TooBigToEdit for my browser. When I simply need to reach the top or bottom of a page to reach a link, I don't mind using Home (or ctrl-Home) or End (or ctrl-End) as needed (most browsers recognize at least one of these methods). -- vk

I don't understand what all the fuss is about, since most browsers use [home] and [end] for navigatigng to the top and the bottom of the page. If you're that desperate to have one, write your own WikiBrowser. But to AskWard? to change the interface sounds like a bad idea to me. -- AalbertTorsius

A web browser has certain limitations. A solution would be using a 'thicker client'; something 'heavier' than a web browser. Changing the original Perl code, as per your suggestion, would be a server side solution. As always, ThereIsMoreThanOneWayToDoIt.

Take a look at WhyWikiWorks and try to determine whether making it easier to hit the 'edit' button faster would be a net GoodThing, or a net BadThing. Personally, I think it would encourage ThreadMode and noise. Someone looking to make a thoughtful, refactoring contribution is not going to be particularly discouraged by having to go to all that effort to actually scroll through a page they are going to improve to find the edit button.

Of course, for a menu that's "on top" by default, the functions required can be coded as bookmarks (favorites). Apart from personal preference, no good reason has been given for not doing that, and a number of people already do it. - vk

[See StaticMenu for discussion and and implementation(s) of the fixed menu concept.]

CategoryWikiNavigation