User:Cpiral/Surf your cache

Further information: Bypass your cache and Browser notes

I hope this helps people understand the browser, the browser cache, and the way they relate to browsing and editing Wikipedia with the basic setup. I caricature an editing method that stretches the concepts, and there is also a section explaining "post data", and taking up the odd possibility of an "edit conflict recursion".

Sometimes being old-fashioned is OK. Before Tab (GUI), this technique must have been a common browsing knowledge and practice. We will be editing several Wikipedia articles in one tab by navigating the cache, effectively turning it into a super-cache.

An Method for editing and viewing wikitext

This council to cancel "Cancel" is not rebellious, but simply "the way things are" for experienced users. Here is a Wikipedia editing method to minimize server and network loads while recycling a cache of data in your computer. Some of the descriptions assume a slow computer. It is designed for speedy editing and data processing efficiency, both on your computer and in your brain. It's in operational contrast to WP:Bypass your cache. Warning:This editing paradigm is incompatible with some versions of WikEd.

Many experienced users use some aspects of this method, since it is integral in verifying new links from the preview. The cost is some attention to the contents of the browser cache as explained below.The risks are clearly spelled out. This method is tried and tested, and it will advancing MediaWiki editorship. "Cancel" is still the safest route for the new editor.

Terminology and concepts

These terms will help us exchange information. "Running over" a page is a new concept, and we differentiate between "browse" and "navigate".

A client is your web browser. It stores a cache of visited pages. It has a bandwidth-free, immediate access to a memory clipboard provided by your operating system's cut and paste depot.

The server is Wikipedia.

Navigating is using the forward '>' or back '<' buttons on the browser to peruse the browser cache.

Browse means to activate a URL. This happens when the contents of the Address bar changes. It is important to understand when this occurs. A URL is activated (1) by directly typing in the address bar, (2) via the "History" of the browsed, and (3) clicking a hyperlink. In (2) and (3) the URL address in the address bar automatically changes. (This too will be useful to know about the browser.) Contrast to 'navigation'.

A chain of 'browsed' pages is stored in the client 'cache' and always visible by 'navigating'.

To Runover a web page is backing over it with the "back button" (left) arrow, and then "driving" right over it by 'browsing' elsewhere. It effectively deletes forward navigable pages from your browser cache.

A view page is the edit page from "edit this page".

A live edit is an edit page with unsaved changes stored only in the browser cache, and not on the server. The browser's history cannot reach a 'live edit' because the browser history mechanism is a server request.

An edit page refers to either a 'view page' or a 'live edit' page.

An 'edit page' can live off of the cache in the browser. It is 'navigable'. We are going to explore the power of 'navigating' a 'chain' to browse and edit Wikipedia. We will take a course well to the left, whereas most browsing and editing habits keep folks well to the right in the 'chain'. You know that the back arrow returns to earlier pages and the forward arrow takes you to the later pages. But did you know that any 'browsing' from leftward in the chain 'chain' erases or 'runs-over' the entire right side of the 'chain'? Now that's power steering! And it will come in handy to delete 'view pages'.

"Edit this page" or even "Edit" is a misnomer. The term this implies the stale version displayed on your 'client', but it actually locates and edits the 'server' version, which could have changed from the displayed version. The term edit actually only executes a view with an option to edit.

"Show preview" adds useless forward nodes on the chain. But temporarily cluttering the browser cache is far better than permanently cluttering the server history logs for failing to see a simple error that a preview might have better brought to your attention. Experienced visual processing eventually wisens somewhat to wikitext.

Optional settings

For speed:

• Set your preferences for advanced editing options to "Do not warn me when I leave an edit page with unsaved changes." You will do this regularly when you test a link from a preview page.
• Set your preferences not to display the preview on top, before edit box. This will keep the search box handy. The search box is handy for identifying pages from all namespaces because it acts as a name-completion device if JavaScript is turned on in your browser settings.
• Set the browser to open new links in the same tab.

For safety:

• Wikipedia shortcut keys. To simply disable access keys, activate "Disable access keys" at "my-preferences-Gadgets-User-interface-gadgets". For further information, see WP:K#Changing and disabling access keys to disable browsing by specific accidental keyboard strokes. All access key operations launch a process that will "browse" (as defined above) except "," and "f". Disabling access keys is not necessary in order to start surfing your cache.
• Your browser's shortcut keys.
• Browser settings can remove the close-tab trigger pictured on each tab. If you offer a close tab trigger on each tab,

and if you have multiple, Wikipedia, surf-caching tabs then there are that many ways to mouse over a close-tab action.

<!Speaking of settings, set your brain setting: An inadvertent ctrl-v can weigh down your cache, because a bug pulls in all The Wikipedia software (MediaWiki) has a subtle bug: If you edit-session two sections of the same article, and if you use the same tab.>

Browser notes

• It is always safe to reload a page. Reloading will not runover any forward pages.

Firefox has a third navigation button, showing both the vertical stack of cached pages navigable by the < and > buttons, and your current location.

The heuristic

Please see the simple #Terminology and concepts section above. This is a caricature scenario. Some real editing examples follow.

• Start an edit session with a fresh window so that your edit window is almost all the way to the left, (where it would be completely safe from runover).
• Save your work to the clipboard often. ("Select all." "Copy.")
• "Save page." only when leaving the computer.
• When navigating left, back to a live edit, the tab title will start with the word "Edit". Clue in on that, not the rendered page.
• When navigating left back of a live edit for information to inform an edit, navigate, immediately, right back to the live edit page.
• Finish any multiple edit sessions by saving right to left.
• Keep any unsaved edit pages in view so that you don't forget them, Accidental edits are a negligible risk, but know your keyboard shortcuts. These vary, and they may be deactivated in some cases.
• Boldly browse from your live edit page, leaving (to the left) your live edit page behind. This could inform your edit while adding useful forward content to the chain. Other links besides Cancel are active for this type of editing.
• Even edit the second page used to inform your first edit! Click click click.
• When using "Save page" save your chained page edits from right to left in the chain. Save page, ironically, destroys all other forward pages. (Beware if the "right arrow" is not dim on your browser.)
• Runover preview pages when you're done with them. A series of "Show preview" edits is a minefield of accidental edits waiting to happen.
• When browsing, check the dimness of the right arrow. It may contain live edits if not dim.

At most this method implies a short term, intense editing of one or a few edit pages in the chain. At least, it means either "runover view pages" or "Don't Cancel button an edit". The overall effect is increased efficiency.

It will be difficult at first, to leave a live edit. It takes some getting used to. Start small. Perhaps stay small. But teach your mouse to become highly aware of how things work. That's really what this is all about—browser know-how.

Example scenarios

• Use the search box to type "Template:cite". Browse to the particular cite template your article needs and cut a copy of the template. Return back to your article in the cache chain, and paste your cite.
• Click on "User Page Guidelines" while editing a discussion page. Edit the guideline too, while you are there. Save that page, then return back to your discussion.
• While editing a session, navigate left to see the wording of the entire article. Return immediately.
• While viewing and editing a watchlist, visit the page for one last look, make an edit there, and return back to the work of checking off watchlist items to be deleted.

Benefits

The benefits outweigh the cost, but at a price. You must pay attention and remain awareness that "I have edit pages in my browser!" There are two side benefits, those of advancing browser skills, and those of recycling.

If there is need you can recycle.

• It rests data processing from both the server and client, and reduces the network bandwidth requirements.
• Using the back button, both saves bandwidth and kills edit pages. Using the cache is recycling.
• It reduces the bandwidth of sending a page you already have in the chain. Cancel causes the server to send an exact duplicate to the one already sitting in your client.
• It reduces the number of pages in the chain and thus the data processing your computing devise must perform to render 'navigated' pages.

Unused latent features are a wasted opportunity.

• No more need to generate or focus on browser tabs or browser windows. It's just you, the chain and the navigation buttons.
• You have learned why some browsers include, next to the back arrow button, a "full left rudder".
• It encourages viewing wikitext because it eliminates the Cancel task and edit click-o-phobia.
• It erases the edit page "accident waiting to happen" from the client. Back over them and "click away".

Risks

The risk is that you could lose a live edit page, either by forgetting it to the left or 'running-over' it toward the right. If you forget it to the left, it will remain for as long as you don't close the window (or tab), and as long as your browser does not clear it's cache. That could be months.

The more of your cache that contains live edits, the riskier it is, but the more benefit of making use of your client's data. If you browse from the chain while deeply leftward, you runover all of it. You could try to use the browser history access them, but the live edits are not on the history mechanism access, because it uses the server, not the client. The live edits are so gone they're not even "history". If you cut-off a forward chain containing a live edit, it is lost forever and quite impossible to retrieve.. If you use the back button to setup a view page to be runover, make sure you are "all right", all the way to the right of the chain, or at least remember not to runover live edits to the right.

If you have several previews, and you navigate left and save an earlier draft, you will not get an edit conflict, and you will lose the most recent edits.

On the other hand go ahead, do runover a long series of "Show preview"/edit cycle pages once you have posted the completed edit to the server. This will help organize and minimize the cache you navigate.

If the forward navigation button is active (not dim) you are in runover mode, where any browsing will make the forward cache "history". The reality with the history mechanism is that it does not save the edits on your live edit pages. It only returns the server's copy, or in other words, the pre-edited version. You must navigate the cache chain in order to return to your live edit page.

Pre data and post data

Show preview button only updates part of a single "dynamic web page" and does not qualify for a page in history, so although the server does receive your wikitext (to render the edits you have made), it does not store it. It only sends back the preview section of the dynamic page. Save page cements the deal in both the browser's history and in Wikipedia's history. But the cache contains every change of a dynamic web page, and these can add up to quite many pages if you preview a lot.

Post data. A live edit is not an edit "session". An edit session would have your edits living on the server. A live edit is post data. You've seen the back arrow produce the warning about "this page contains post data". But did you know that post data is data you entered? You entered it in order to then post it. A data integrity feature may sometimes require this, but Wikipedia's data integrity scheme is the Edit Conflict page. To increase editing speed, this method treats a live edit page just like any other page, irregardless of whether or not it has post data.

Edit Conflict Recursion

An edit conflict can result in... an edit conflict! We live in a world where there is the possibility of an edit conflict recursion. Having Witnessing and gracefully navigating with zero click-o-phobic contradictions: an Any edit conflict no matter how deeply recursed can be fixed by redoing the same edits to the edit box. Save page. Repeat the edit box work yet again. Save page. Redo until there is no edit conflict screen.

if you set your edit to double click

• ya can't select display text by double click, but you can wikitext.
• ya can end up at the pink strips screen where you are editing an edit
• ya could destroy a forward linked edit by going back to select some text

Summary

The Cancel button adds a useless page to the forward chain, and ignores the potential power of quickly navigating the chain. It is clutter. It's redundant. It sandwiches the edit page with the same historical page. Cancel gums up slow computers (like this ol' Mac here). It makes first-place editing second-place at best. It confounds a busy wireless cell sites and smaller portable computing devices, and even increases the load on Wikipedia servers. I use the cancel button when I'm too tired to think about a chain. "Chaining-up" live edits is a safe and efficient way to work if your mental memory is working well and you are unlikely to be interrupted, and it has the side benefit of resting the server and network.

The analogy to leaving behind a live edit is "pushing data" onto the stack as is done with Reverse Polish notation calculators. They are much more efficient, and those of us who use them are loathe to pickup up a normal calculator. Another side benefit is learning browsing realities such as how to more powerfully "Cancel" an edit by running over it.