User:RW Marloe/How could Wikipedia be better?

=Proposals for Wikipedia development= The overall design of Wikipedia is excellent and it is useable once you learn how, most of how I think it could be improved is in usability and editing. Here I have listed some details of what those might be:

Guidelines
The guidelines of Wikipedia are thorough and effective. An additional "Axiom rational" could be used for short stub articles and articles that may appear to contain original research or that is lacking verifiability and references. When Wikipedia encourages contributors to be bold, start new articles and extend existing articles, that "should contain enough information for other editors to expand upon", contributors should of-course check for an existing article and have some prior knowledge of the subject. "Initial research may be done either through books or reliable websites. You may also contribute knowledge acquired from other sources" (quotes from Ideal stub article). Those other sources could be common knowledge, an axiom. Therefor a genuine Axiom rational would be used with a new axiom Template message until more verifiability and references are added.

Appearance and Simplicity

 * The culture of Wikipedia is of generosity and good faith, with a community of people protecting articles from misuse and vandalism. Articles are maintained by undoing unnecessary edits and using protection tools for articles. A voting system could be utilised for reviewing new edits on protected articles (that have been draft saved but not yet applied to articles, positive votes would apply it). A voting system could also be used for increasing protection levels to valued sentences or paragraphs of information. An interactive system of voting on new edits and preserving existing information could be very useful.
 * Further information: Pending-changes protection


 * The "From Wikipedia, the free encyclopaedia" under the title of every article, for aesthetics it would appear better without it, as it is under the logo, clearly understood once and unnecessary to repeat within articles. There are some different language versions of Wikipedia without this.


 * The project namespace colon ":" and namespace prefix could be replaced, with a section name, in a label floating or fixed to articles and browser windows. The sections would then be more clearly noticeable and differentiate them from all other regular encyclopaedia articles and be able to be labelled in multiple namespaces, as some can be categorised in multiple similar topic namespaces. There would be six labeled sections for all present project namespaces: Contributing and Editing Section (new), Help Section, Media and Files Section, Templates Section, User Section and the miscellaneous Special Section. Categories, Glossaries and Portals should not be a project namespace as they are fundamental to overall navigation and browsing.
 * ''See also: Categories Glossaries and Lists, Outlines and Portals


 * A table of contents box that automatically shows and hides when a cursor is near or over it, would be a small and useful improvement, together with regular locked show and hide views of contents.


 * Article improvement template messages usually at the top of articles should only be visible to users that are loged-in, for experienced users, as template messages disrupt the overall continuity of article format and are of no purpose to brief readers, except for neutrality and factual accuracy messages.


 * The "Download as PDF" from the Sidebar (left) print/export box could be improved. The rendering could have options to create a PDF as it currently does or create pages in the exact style, arrangement and layout as a normal Wikipedia article, with it precisely presented as it is in the browser window width, separated into pages.


 * A function for user watchlists, that alerts of any edits by others, to specific edited text, on any article by selecting a "Watch this edit" check box before saving. An accurate additional feature to watchlists, as the watchlist only lists a user of the latest edit to an entire article the user is watching.

Editing

 * A useful feature for people editing who might have forgotten to login, would be a login panel beside the text box when editing or contributing. The login panel could be used at the top or bottom of an "edit this page" page, to remind people to log-in or allow people to create an account, before editing.


 * Wikia has been doing a lot of work designing a simple "what you see is what you get" editing tools. This would be a welcome enhancement, as soon as possible. As Jimmy Wales has said "a lot of people were afraid to contribute to the site by the sometimes complicated code", known as Wiki markup, needed to format entries. "If you click edit and you see some Wiki syntax and some bizarre table structure, a lot of people are literally afraid. They're good people and they don't want to break something." Jimmy also stated that there could still be the option to still use the current way, that "We have to support our old power users because they build the site", he said. "But we also need to have a ramp for new users." I would agree entirely, it can be cumbersome and time consuming to write code. There will be more participation and it will become more simple and efficient.


 * On a "what you see is what you get" Wikipedia there would be an edit page with an identical layout of an article, but all of the parts that make up the page (text, info boxes and media) would be interactive. There would be no page code to learn or hassle of previewing the page. So all anyone would need to do is click on the edit page and select which part to change and save, without the disconnection of code and the end finished appearance.


 * Edit Boxes would be floating layers that are simple spaces to create and add an edit, it would include all content to be added, with a Toolbar for formatting options and settings. An Edit box would not be used when an edit is simply only a short text written edit (view the navigation text cursor section above).
 * A contextual menu would open anywhere selected on the page, presenting a contextual menu to edit. An Edit box is then opened, multiple floating Edit boxes could function simultaneously and each could be submitted and added independently. Edit boxes would be automatically positioned near a correspond indicator to each place on the page being edited, their size would dynamically adjust to the content inside the box automatically.
 * To quickly view the page under the Edit box floating, just moving the cursor, onto the page, dynamically the Edit box slides across to the Sidebar (left) showing what is under Edit box, to edit again move the cursor over the Edit box ant the left and it would slide back, to continue.
 * A dynamic Table creation and adjustment tools, with simple controls (rows, columns, width, hight, cell borders, cell background).
 * Selecting (floating) would show a Difference Between Revisions View.
 * To save an edit without submitting it, select and open any Draft edits from a special user page.
 * A universal Wiki swatch palette of active colours (with saved user favourites), for all editing.


 * The editing on a "what you see is what you get" Wikipedia, could be so simple, with automatic options and editing that would be exactly set to wikipedia editing, layout and formatting standards. Without the need to learn Wiki markup or check lengthy help pages. The selection to edit a page could just be as simple as switching edit on and off, without leaving the page and with no need to refresh a preview of the changes.
 * Main article: Wiki editing interface

Browsing and Reading

 * A universal title bar with switch buttons to simply change between or  and Wikisearch bar. Changing from one to the other, encyclopaedia or dictionary whilst in an article goes to the subject and topic most accurate to the article, in the other.
 * See also: Proposals for Wikipedia Search


 * There are three ways that people use Wikipedia, which are reading, navigation and contribution. With the purpose to present the article centre stage to read. To enhance this there should be two additional improvements, in a simple reading web application that presents original Wikipedia content:


 * View switch buttons to view as.


 * 1. Editing View
 * Preserving all the normal current familiar appearance, full functions and features for use with common computers.
 * 2. Reading View
 * A feature that enlarges every article in an animated way, full to a web browsers window, this hides the editing attributes, for basic reading. The Sidebar (left), Top tabs (above the article) and User options (top right) would be behind articles on a gray background, theses would be accessed by reducing the article, by clicking on the thin grey border around articles to resize the article into the normal layout and position.
 * The mobile version Wikipedia Mobile (en.m.wikipedia.org) is optimised for small screens of smartphones, portable multimedia devices, small netbooks and tablet PCs.
 * 3. Fullscreen View
 * The fullscreen view is a third stage, based on the Reading View, with additional settings that would include text size adjustment and a two page browsing option.
 * Capable of turning from page to page, instead of scrolling. Browse and read using two settings, through the whole A-Z index or through each see also related to an article, viewed one by one. This has an ease of navigation and would transform browsing each page as though is was a real encyclopaedia book.
 * The fullscreen view would be optimised for use with widescreen televisions and computers with large displays.

Language Versions

 * Main article: Wikipedia Machine Translation Project

The multilingual coordination of languages could be seamless and automatically translated, to a user account selected language.

There could be two options:
 * 1. Consolidation of Multilingual Versions
 * The combining of all multilingual articles maintaining a completely comprehensive encyclopaedia, where each users selected language determines the translation, this would be an accuracy and consolidation measure, as many articles exist in some language versions of Wikipedia and not in other language versions.


 * 2. Manual Translation Process
 * A simpler process of current manual translation, for people to manually translate articles and create the article in a selected language, that there isn't an article of, in that language Wikipedia and to make it easier to do.

The manual process is probably the most appropriate with Google Translate currently used, because comparative definitions in languages can be vastly different, by individual, cultural, lingual and regional factors. The implementation of combining of all multilingual articles would lead to sentences and paragraphs changing rapidly, increasing the chances of edit conflicts by all language users editing simultaneously, which may result in incomprehensible articles. One of these options would be an improvement.

Article Attributes
In the top tabs (above the article) could be an additional article tab page for free links of related material, allowing all large articles to be less compressed giving the reader an easier read, named "Attributes". The important parts of articles would remain on the article, the usual images, infoboxes, navigation boxes and the small numbered superscript link for citing sources, which would scroll and present them on the "Attributes" page automatically.

It would include all the alternative names for a specific article and replace the redirected quote link under headings, redirected addresses and redirected pages. It would list sections for alternative names and relative names, key words, see also articles, references, categories, portals, linking between projects and a section with a basic list of all other free links that are in the article, hidden text would have a section also. All listed attributes include a position link to view and automatically scrolls to each.

The section with a basic list of all other free links that are in an article, would be automatically compiled alphabetically. A useful list with a separate piped links section, is an easily list to browse and restore broken links.

An "Attributes" tab would be a convenient and practical visual tool to aid the organising and referencing of articles. Derivatives would compliment and be similar to disambiguation pages and what links here pages. Wikipedia search results would use the "Attributes" in the search engine to formulate more accurate referenced results.

Article History

 * The differentiation of disambiguations and redirects in user history is needed, to clearly identify the deference of regular articles and disambiguation pages and redirect pages. They could be indicated by an small icon or text.


 * The ease of viewing and reading an articles history version could be more clarified in help pages. A more comprehensive overview is required, as the Revision View is basic view of an articles pervious version and the Difference Between Revisions View is a detailed summery view of an article.
 * 1. Revision View
 * Basic and simple view of the whole page, with a small directional navigation at the top, to view the previous revision, current revision and newer revision. It is viewed by selecting the time and date in the list of a history page.
 * 2. Difference Between Revisions View
 * Detailed with a highlighted edit line summery at the top, to compare selected version sentence edits, of what is added and omitted for comparison. There are three types of ways to select an articles history; "(cur)" is a comparison of the selected date with the current version; "(prev)" is the comparison of the selected date and the previous edit chronologically; and a Compare Selected Versions option to view two versions with intermediate revisions not shown, this is a flexible selection to compare two versions of divergent dates, in the Difference Between Revisions View. It is possible to generate a Difference Between Revisions View between any two versions. In the article history list, select the left radio button for the older version, the right radio button for the newer version, and click "Compare selected versions".


 * There is a missing link to compare the current version with either one of the two being compared in a Difference Between Revisions View, it should have a "Current revision (diff)" option link beside both compared revision details, presented on all previous revisions but not displayed on the current revision being compared. This would be a timesaving shortcut, without needing to select the time and date for a Revision View and then select it.


 * The abbreviated links in brackets are inconsistent, as user contributions have the abbreviation of "(hist) (diff)", watchlists are "(diff) (hist)" and article related changes are "(diff) (hist)". It should be either "(diff) (hist)" alphabetised or the opposite way. User contributions, watchlists and article related changes are all histories that have a different layout to regular article history lists. Regular article history lists have the abbreviation of "(cur) (prev)".


 * A new "Revision Details Box" could be included beside every edit on the history page list with a tooltip box, which appears when hovering over the edit size. The small detailed summery would state the total number of additional or removed; characters and letters, words, sentences, and paragraphs, which are or were readable text on the article (not a Wiki markup count or the number of bytes). This is an important measure of the size of each edit, easily recognised and indicated by an increase with a positive green number (+10) or a decrease with a red negative number (-10) . It would give a simple representation, that is quick to hover over and check. This also could include a count of changes to references. These coloured counts could even link to the Difference Between Revisions View and include the colour coded text.


 * The highlighted list at the top of the Difference Between Revisions View requires a line scroll link to quickly and automatically move the internet browser window to view the selected paragraph edit, lower down in the revision.


 * In the Difference Between Revisions View, a text repositioning indicator could be part of the edit line summery, as some edits are just a copy and paste movement of unchanged words, sentences or paragraphs, from one place to another. A move could be identified by an identical "Text Move" link indicator, beside each moved word, sentence or paragraph. The unchanged text that is moved could be highlighted in yellow (removed or moved) with green (added), identifying the edited text between the two revisions viewed.
 * See also: Proposals for Interaction of Talk and History Pages


 * A new "Author View" could present user details, from a list of all remaining users who typed the selected text or line (hovering cursor) on the current article being viewed. Directly and simply indicating and relating who typed which text and when, with user page and user talk links. This would layout the whole page and have a floating column of usernames and dates on the left, that correspond and scrolls automatically, to both and each selected text or author. It would also provide a dedicated space for all cited attributions, when copying within Wikipedia, easily linking (if copied) each edit and editor to the to the original author and article it was copied from, notifying the original author in the process.


 * The "edit this page" tab should only be used on a current article, when viewing an old revision in the Difference Between Revisions View or Revision View, the tab would read "restore" instead of "edit this page", as demonstrated in the diagram an the left. This would define the distinction of restoring in past versions from editing in the current version, similar to undos in page history lists.

Categories, Glossaries and Lists

 * The use and layout of Categories and Glossaries must be defined more in help article guidelines, there could be more information about how to use them for navigation and browsing, because they are both very similar. To connect for quicker and easier navigation Categories, Glossaries, Outlines, Overviews, Portals and Lists could all be linked in topics by the subject, using prominent navigational boxes at the top right-hand side of articles. This would be a wider integration and similar to Navboxes that link a limited amount of specific information. ''See also: Outlines and Portals


 * The temporary customisation from ascending to descending, of list information in tables, of single column or in multiple columns with ascending to descending of each column, is used, though the reordering of columns should be used more often. To be able to rearrange lists can be very useful when reading them in different contexts or interpreting the list in different ways, from alphabetical names, to countries and dates. Enumerative, hierarchical or faceted are also alternative ways to organise information.


 * The order of the see also section in all articles is unclear, as to the guidelines of type of alphabetical order. I prepose lists be at the top, with a gap and then all other related links below lists, because sometimes lists are alphabetised within all the links.

Chronology and Locations

 * The positions and time of all articles is relevant and important to correlate the subject in relation to the readers interests, consistent with basic information with article category tags, at the end of the page, location and chronology could be tagged. ''See also: Outlines and Portals


 * The location of a topic in an articles uses WikiMiniAtlas which opens by selecting the globe icon [[Image:Erioll world.svg|18px]] in the top right corner, this is a floating interactive box, it can be shown and hidden, more location information can be viewed by selecting the coordinates, where Google Maps and other map resources can be used. The advantage of geographic information is that each location can reveal other articles surrounding it, near the same place. It is an important medium to browse and discover unrelated information other than each articles place and locality to another.


 * A chronology box, with a horizontal scroll bar to navigate though a timeline of relevant articles, timelines are sometimes used but should be standard on all articles, referenced with timeline standards. Articles could be automatically inserted into interactive timelines, by connecting all wiki markup date links, through basic links or written in different date formats by using piped links. A "date index" for all Wikipedia dates could then be chronologically referenced, similar to the A-Z of all contents, including a past, present and future sections, with a separate index chronology for fictional dates. Both location and chronology used in an interface as described utilise the diversity and instant browsing of digital media, for the ease of use and convenience.

Outlines, Overviews and Portals
The use and layout of Outlines and Overviews must be more explained in help article guidelines, there could be more information about how to use them for navigation and browsing, because they are both very similar.

The navigational use of Outlines, Overviews and Portals could be enhanced and easier to use, they could be integrated with Categories, Glossaries and Lists, by using prominent navigational boxes at the top right-hand side of articles, including all Categories, Glossaries, Outlines, Overviews, Portals and Lists by the relevant subjects and topics of the article. This would be a wider integration and similar to Navboxes that link a limited amount of specific information. ''See also: Categories Glossaries and Lists

Search and Results

 * A unified "Wikisearch" page, with single text edit box and simple or  search buttons. The page language would be selected by account settings. A feature for misspelt searches is a search text box with the last search remaining in it, to easily edit and search again.


 * A suggest drop-down list on the start page wikipedia.org. On Wikipedia's homepage for all languages, with auto-completion in search results while typing, to give popular searches.


 * The search results for words are highlighted with bold text in each result, which could include an active link for the word, when selected the reader is taken to the article that is automatically scrolled to the sentence, with the relevant word also highlighted.


 * The ability of a special page search parameter to search for all users created disambiguation pages or redirect pages, separate from all regular articles.

Talk
The manual nature of talk interaction on Wikipedia could be improved to become efficient, effective and simple.
 * A link to respond below all user paragraphs, as a "comment" named action, it would function for each reply automatically setting indentation for each response, with the text cursor readily blinking in the right place for typing, indicating the current region of text being edited, saving a comment would also automatically stamp signatures and dates after each save. This system would be easier and simpler than a common "[edit]" and produces a commenting standard.


 * Article Discussion sections could have a resolved template button that can be selected from the toolbar when editing.


 * Threads of talk and discussions could be in page history lists, alongside the time and date of an edit, used for a certain version, perhaps a collapsable thread that hides or a link to the section on an article discussion page, specific to the edit.


 * The distinction of talk could be more defined, as Article Discussion (article talk) and General Correspondence (talk between users). There are two types of interaction:
 * 1. Article Discussion
 * The user talk interaction concerning articles and article sections, could be organised automatically and presented in user talk pages, with a section including all articles and article sections that have been discussed, where all related responses would be typed and automatically correlated.
 * On the article discussion saving a new section would automatically put it in chronological order. The title of the article discussion and new section would be automatically put it in chronological order on the user's talk page, in a short revision link and date of the initial edit:
 * Main discussion: Article discussion section (29 July 2024 )
 * The discussions about an article and to discuss improvements to an article, should be viewed and shared with all users, centred around article discussion pages. Contributions could still be referenced and noted in a user's talk page, for more people to encounter a link to the article discussion.
 * 2. General Correspondence
 * The general communication between users would benefit from account settings for default archiving of old correspondence and a respond button. The archiving of old discussions on a talk page and archive boxes should be an automatic, integrated and basic function.

Wiki Markup

 * There is an Image Annotator tool missing in Wikis. The use of active free links, highlighted text and placemarks, that interact with key guides, legends and lists for charts, diagrams and data on images, graphics and maps. It is required for simple navigational interface, explanatory referencing and general information and illustrative purposes. If an image is used and places on the image are related to a description or topic, it could be tagged to written text, the place would temporarily be prominent when the cursor hovers over it and will highlight the relative text to emphasise the correlation. The location of a tag placemark could be written with new Wiki markup language in the extended image syntax, similar to coordinate syntax, identifying where the placemark is in the image and which quoted text is to be highlighted. A variety of placemarks could be used, of text and symbols, exactly the same as normal free links, with notable information in an image tagged to a pixel, path or area.
 * Further information: Wikipedia Usability Clickable Images and Image Annotator


 * The automation of free links can be maintained when any article title is changed or any other title change is made, by applying changes to all articles using piped links, from the what links here list and automatic synchronous transclusion. This will restore broken links automatically and reduce overall redirects to an article, whist still keeping all the redirects.

Wiki Markup Errors

 * There is a general text overlapping issue with floating boxes and tables of images or text content, predominantly if they are positioned on the right, when a browser window size is adjusted. Especially with the section edit links labeled "[edit]", which can float over other text or behind floating boxes. The positioning of lateral and vertical content margins and borders require precision constraints. The code to have space between left and right content is

or, it can separate text between the between left and right content.


 * History page edits that may be undone are sometimes unable to be undone, a notice exclaims "the edit could not be undone due to conflicting intermediate edits, if you wish to undo the change, it must be done manually". This is a simple important action and the intermediate edits could each be reviewed, during an undo action or separated and presented alongside a manual undo.


 * The deletion of article histories can happen, when an article is moved without the history or other ways, with the loss of information and revisions, that may be of significance or value. There could be structured function to establish this as incapable of occurring.