Wikipedia:Advanced article editing

This essay contains the advice or opinions of one or more Wikipedia users. Essays may represent common ideas, or ideas that many users would not support. They are not rules. Think carefully about what they say before following them.

Shortcut: WP:EDITFAST

This essay, Wikipedia:Advanced article editing describes some techniques to improve editing (changing the text) of Wikipedia articles. Most of the tips involve using typical browser settings, or use of standard text-editors. While some special software packages exist, to allow customized editing, they are typically not available when travelling to other computers for wiki-editing.

Faster display

Set user settings

Enable section editing – The top section of an article (&section=0) can be edited separately for much faster update of the intro text (right-click top option "my settings" then in the box named "Editing" also click option "Enable section editing via [change] links").
Hide edit-toolbar – Turning off the edit-toolbar can make a short edit-page appear 2x-4x faster (right-click top option "my settings" then in the box named "Editing" unclick option "Show edit-toolbar").
NOTE: Some article intro-sections do not contain all the top images, so sometimes, making changes within the text of the whole article could be faster, for adjusting the location of images.

Skip slow-parts of articles

During show-preview, all cumbersome tables and navboxes must be reformatted for the preview-page.
Consider commenting-out those massive, gigantic bottom navboxes that typically double (or triple) the S-L-O-W-N-E-S-S of article previews: just put "" around the bottom navbox-template codings. (Even with high-speed Internet, large navboxes take a long time).
Consider conditional-skip of text, using MediaWiki #ifeq-statements: using the markup language, surround omitted sections with "{{#ifeq:{{{hell|hot}}}|freezesover|" and ending with "}}". Although HTML comments cannot be nested, the #ifeq-statements can be nested, as long as the spanned text does not upset the vertical-bar "|" usage.
Consider copying troublesome sections of an article into a test-page for repeated changes & previews: edit as a user-space page (User:XXX/TestZZ) and copy/paste text there for repeated changing/previewing.
NOTE: For broader testing, the copied part of an article often spans 2 or 3 sections, rather than just 1 section as typically being edited. Be sure to copy enough sections for an accurate preview.

Side-by-side editing

The Wikipedia article-edit window is not designed for side-by-side editing: instead, the formatted preview-article is usually on the top-half the page and the edit-buffer is typically far below (near page bottom). By the time various text-issues are noticed, the user often forgets where they occurred within the edit-buffer, far away. However, when using 2 windows for side-by-side editing, the text (or image) is noticed in one window and located/changed in the other window, thereby allowing numerous, precise changes to be made 2x to 10x times (or more) faster, without forgetting the tedious details.

Use NOTEPAD editor beside edit-window

A good method to allow side-by-side editing is to copy the browser edit-window into a text-editor (such as Notepad), then change text in the (Notepad) editor but copy/paste & preview the results in the browser edit-window buffer. However, this can be dangerous when forgetting which buffer has the recent changes.
The nearby editor can allow powerful editing, such as search-and-replace, or perhaps some spell-checker functions.
NOTE: To avoid losing changes, perhaps always edit in the left-hand window ("Notepad"), but paste/preview into the right-hand browser window. The final save would be made in the browser window, but perhaps only after a final, careful edit-preview. Remember a careful preview could save perhaps an hour of (later) finding & re-editing a half-changed article.

Double-copy the edit-window

A quick method to allow side-by-side editing is to copy the browser edit-window, then change text in one window but copy/paste & preview the results in the 2nd window. However, this can be dangerous when forgetting which of the 2 windows has the most recent changes.
NOTE: To avoid losing changes, perhaps always edit in the left-hand window, but paste/preview into the right-hand window. The final save could be made in the left-hand window, perhaps after a final (one-time) preview on the left.

Even proofread alongside an edit-window

The increased speed of side-by-side editing can even be extended to a mere "proofreading" phase. When initially viewing an article, there might be a "wait-and-see attitude" as to whether there are enough trouble spots to warrant editing the article. Instead, consider first reading an article (with no intent to change it), but first click to "edit" in a new window, and then while reading (for the first time) make "possible edits" in the edit-window, while reading the formatted article page in the 1st window.

Click "edit" open in new window (before first reading an article).

Often times, within 10 minutes, numerous improvements could be made that might have taken another 20 minutes to re-locate and remember, if the edit-window had not been instantly available when first reading the page. It might seem like a trivial issue, but compare the results a few times to realize how much time is burned to re-locate and remember such changes.

However, beware the temptation to become a "copy-edit fanatic" when it is usually more important to add new text or new source footnotes to most articles.

Potential impact for side-by-side edit

The potential increase in productivity, using side-by-side as a new way of arranging edits, is almost a magical breakthrough in the ability to easily improve hundreds of scattered details. It is even more powerful than a WYSIWYG editor, for 4 reasons: (1) it allows users to even see/edit the underlying tables or infobox markup-language, before becoming distracted by a wholly reformatted page; (2) the editing can continue while the preview-page is being formatted/displayed in the 2nd window; (3) results do not demand verification; and (4) the diff-listing can remind users about all edits. Specifically:

WYSIWYG editors have the drawback that they insist on live, instant transformations, which can seriously distract attention from rapidly focusing on myriad other details, when such ongoing reformatting occurs. In effect, side-by-side editing allows both levels of attention: either change a few details & reformat to see results, or step-by-step change almost all details (top-to-bottom), uninterrupted, and then wait for the massive reformatting afterward. Again, WYSIWYG-editing could be very distracting if adding a small change distorted the output and shocked attention away from numerous other small details.
Because the edit-preview is processed in a 2nd window, the user is able to continue more editing in the 1st window, while choosing to ignore the in-progress formatting of the display-page, if too distracting at the moment.
It is an utter myth that all changes must be verified (instantly or not). When making 57 changes to a page, it can be better to hope for 54 (of 57) successes, and move onto other articles, rather than to carefully babysit each change and lose time for the next article. Total "perfection" is not necessary in this level of writing, where articles are later hacked by anyone.
During the side-by-side edit, a user can focus on changing the underlying markup language, so when it comes time to run a diff-listing (button "Show changes"), the user is able to review each change (as before/after) and compare the text in the familiar markup style. New typos can appear as unexpected keystrokes in the diff-listing.

Quick editing is not just about fast edit/response feedback, but also about avoiding or limiting either distractions, or forced verification steps, as well. Being quicker, long-term, could depend on spotting edit-problems by using diff-listings in the 2nd window, while further editing continues in the 1st window.

Complex text substitutions

Even a simple text-editor, such as Microsoft Notepad, can be used to handle some complex changes, by using multiple find-and-replace text string-substitutions. For example, 2 edit-commands could be used to add quotation marks around wikilinks (hyperlinks):

Use Notepad edit-replace to change all opening ' [[' (to: "[[ ).
Use Notepad edit-replace to change all closing ']] ' (to: ]]" ).

For wikilinks that already had quotation marks, then replace all double-quote patterns ("") with a single quotation mark.

For several years, there has been a free text-editor, called "Notetab", that allows using highly complex regular expressions to find, replace or swap multiple text-patterns on each line of a page. The free version of Notetab is a simplified version of the commercial-product version, and allows many sophisticated features, without having to buy the full-feature version. Notetab can also be used to count words or particular phrases within a page. For more, see the features described at: Notetab.

Far future

Perhaps in the very far future, a Wikipedia edit-window will have some type of side-by-side display, allowing a scrolling area for formatted output. However, due to the complexity of simulating a formatted-page in a scrolling region, it would probably be many years (over 5 = 2014+) before such, side-by-side, editing could be implemented in a single browser page.

Multi-screen computers, as common decades ago, are expected to become common again (some year) when today's limited computer technology progresses beyond the current "dark age of computing" (how many decades of computer viruses?). There are many intelligent people in the world, and once software monopolies quit promoting bad technology, then computers can quickly improve. Many people really are much smarter than those software companies of the Dark Ages. In fact, hypertext interfaces existed in the 1960s, but numerous complications have thwarted advances, such as possibly supporting search-engine "multi-word" scanning of any document in viewing or text-editing. When computers with multiple screens become more common, then side-by-side editing could become even easier.

Related pages

[ This essay is a draft to be expanded later. ]