|
This is a list of ideas I've encountered whilst editing since 2015. Some I've since found solutions for ...I do need to do some housekeeping of this section.
If you've stumbled on this page and know a suggestion already has a solution - do feel free to add a note next to it.
- Whilst the expand/collapse section function in mobile view is helpful, functionality would be enhanced by having a 'collapse previous section' (or 'collapse all sections) function at the bottom of each expanded section. Not having this means that the user still has to scroll up to find the relevant collapse button. Linked to this suggestion is the ability to collapse the lead in mobile view, thus turning the sub-headings effectively into a clearly visible Table of Content.
- Alerts for Cross-wiki Notifications disappear completely from the drop-down Notifications list once they've been marked as 'read' (unlike en-wiki, where they remain on view). There is no way for these notifications from other projects to be retrieved at Special:Notifications, nor for any Preferences to be altered to allow their retention. I find this severely limits my ability to return to threads on related projects.
- The Special:Contributions page should contain a "click for IP range contributions" button, to quickly enable the display of IPv6 edits across the /64 range.
- Suggestion: Provide a Preference option to enable a user to activate a skip to top and bottom button on the frame of all pages they visit. Rationale: Not all users like this function as they feel it gets in the way, whereas other users really value its functionality. But try visiting WP:ANI on a mobile device to see how much scrolling is needed to move around easily.
- Suggestion: Permit autoconfirmed editors to self-protect their own userpages. In the wake of discussions on civility and harassment re WP:FRAMBAN, and having experienced a multiple IP-hopping sock posting unpleasant remarks on my own talk page wishing me dead recently (see revdel-ed edits June 2019), I've been considering how editors could protect themselves from abusive posts by others. I've concluded that one solution could be if every registered editor had the ability to self-protect their own talk pages against edits from non-autoconfirmed users for a period of up to, say, 24 hrs within a set period of time. It would auto-expire, but could be reactivated again. It would not need a page protection request to an admin, and I'm sure it would reduce the level of hostility from blocked users coming back as deranged or abusive IPs, yet still permit genuine (autoconfirmed editors and IPs) from posting as it would not block them.
- Suggestion: The new user log at Special:Log/newusers should allow selection of only usernames who have already made a contribution. (Benefit: Would enable speedier identification or accounts which violate username policy and to permit easier posting of welcome messages to the active ones.)
- Suggestion: (Courtesy of Thnidu: Add a small 'info' icon next to the Publish changes button in both editing tools to bring up a brief explanation of function to help differentiate saving edits in userspace/drafts from actually 'publishing' to mainspace. e.g. "This 'Publish changes' button will save the page, with your changes. The saved version can be seen by anyone." It functions in userpages, sandboxes, drafts and main articles. To actually move a draft article into mainspace, see Moving a page or Wikipedia:Drafts#Publishing_a_draft.
- Suggestion: When choosing to switching editors between Visual Editor and Source Editor, remove the need to Confirm (except when editing Talk pages, where edits might be lost).
- Suggestion: When previewing in Source Editor(Alt-Shift-P), continue to display editing window at cursor position, rather than returning to top of page. (Very irritating when working in long pages, lists or tables)
- Suggestion: Enhance searching facility where search criteria match two Categories (e.g. topic category against a template for enhancement category). There appears to be an exciting proposal here: WP:Category intersection, but no solution as yet. (Value: Would focus efforts on improving articles by interested users)
- Suggestion: Enable feedback for page creators under New Page Patrol to be optionally inserted into the Talk Page of the Article itself (Purpose: greater visibility of helpful comments. See here and here.)
- Suggestion: Email notification from Watchlists should include a) the number of bytes changed + or - , and b) the first 40 or so characters of the changes made.
- Suggestion: Email notification text should use different wording whenever a new Section heading or topic is added, so as to help editors who are only interested in seeing new topics or section changes differentiate email types.(Useful for separating emails with message rules in email client)
Suggestion: Article sub-headings should include the numbering and sub-numbering, as displayed in the Contents. (especially important in longer articles) (Available in Preferences>Appearance)Suggestion: Provide optional Footer template allowing a a user to skip from the bottom of long Talk Pages and Help Pages up to the Table of Contents/Top of Page. (Would be especially useful when working from a small mobile screen) (This exists: ((Skip to top and bottom)))- Suggestion: Provide a link at the top of each article to Jump to contents to enable users to quickly get to the table of contents, rather than have to scroll down manually each time. - especially frustrating when one is repeatedly editing and previewing changes to a long article with an equally long header.
- Suggestion: Allow switching between citation template with retention of shared elements entered in one template to another.(Would avoid repeating data entry when wrong template has initially been selected.)
- Suggestion: Hovercards should be made to work in Wikipedia's Help fields.
- Suggestion: Hovercards should show the quality assessment of the article being displayed.
- Suggestion: A Favourite this page button should be available under Preferences for repeat editing or viewing of key articles.
- Suggestion: Preferences and Beta choices set in EN-wiki should apply when logged on to all other language wikis.
- Suggestion: Preferences should clearly indicate what each Default settings normally is. How else can a user assess what impact using Restore all default settings (in all sections) will have on page appearance and functionality?
- Suggestion: The ability to sort Watchlist by date would be very helpful in removing pages accidentally 'watched' during bulk-editing activities.
- Suggestion: Save all to Watchlist should be made to work on all pages listed within a selected Category for speedy monitoring of related articles.
- Suggestion: File uploads to Wikimedia Commons should only go ahead at the end of the upload process, with final user-authorisation needed, and not at the start.
- Suggestion: Email alerts to changes on Watchlist articles should include a count of the number of characters added/removed.
- Suggestion: We received notification emails of changes to articles on our watchlist. But I would suggest an on-page watchlist alert would be a useful tool, along with a 'clear' facility to quickly remove those we've seen or wish to ignore.
- Suggestion: Provide a facility to add/remove articles in Watchlist from within the User contribution page.
- Suggestion: The timescales for deletion requests are ridiculously short. An uncontentious article can sit in mainspace for years, but if someone slaps an 'improve or delete notice on it, then we're given just seven days to put it right, or it's gone. Aren't we allowed holidays, or a week away from the computer? Maybe an automated delete if nothing happens to a page after, say 2 to 6 months. But as with Wikimedia, why a week? - it's just potty, and quite insulting. Imagine a suite of related articles being attacked in this way - would anyone notice before every one had all been deleted, or could the one or two people lucky enough to spot them in time be able to address all the issues in just 7 days? We need to be realistic here whenever articles are challenged. If an article is unlikely to attract a legal challenge for defamation, nor is breaching any major guidelines, why do we need to act with such unseemly haste? There are a lot of poor articles here, but that is a legacy of the early days of Wikipedia. Deleting them all with just a week's notice is not the way forward.
Suggestion: Users to be able to 'favourite' Wiki Help pages to create their own bespoke 'How To Do It' library. (Solved with Page Creator script)- Suggestion: Search results should show presence of internal links in those results to help ensure quick checks and enhancement of articles where links are needed, but not present.
Suggestion: Display the highest 'Quality grading allocated to that article at the top of the main article. This would readers understand how the community assess the article's quality or completeness. (I found this facility already exists under 'Preferences')- Suggestion: Allow sorting of articles in other languages by size of article, or by quality grading (to enable the most extensive articles to be quickly found, accessed and translated).
- Suggestion: Wikimedia should allow upload of associated files used to create images (eg the raw PowerPoint or other graphic files from which jpgs were created) This would allow others to access and make changes or modifications much more easily.
- Suggestion: Wikimedia should discourage the "Exterminate!" approach. Whilst recognising the need to keep Wikimedia free of copyrighted material - and the good job done by many to ensure this happens - it is utterly ridiculous to expect action to address minor concerns can be executed in just 7 days. Where an infringement has been identified, but where there is no 3rd party challenge or threat of legal action, it would seem appropriate for Wikimedia to show that it is taking action, but to act at a reasonable pace - something it is utterly failing to do at present, in my opinion. For that action to be received, then fully acted upon in such a short timescale is utterly impracticable. Not even the courts act this fast when a legal challenge has been made - so lets put some common sense into warning notices, giving at least a months to six weeks notice for something to be done, and for demonstrations of the matter being pursued to an appropriate conclusion. We weaken Wikipedia and Wikimedia if we fail to act, but we also weaken it if we make rules that turn a handful of sensible editors into gung-ho exterminators, out to purify the system at all costs and with unseemly haste. Here's what happened over the Christmas 2015 period to one image image of a statue in a public place that had been uploaded correctly by the photographer, had sat quietly on Italian Wikipedia for some years and was being used in mainspace. When I transferred it to Wikimedia to use on en.wikipedia it was (rightly) pointed out that Italian law meant that copyright permission from the creator is needed for works in a public place. As you can see, I immediately undertook this task to investigate and gave evidence of progress. But to no avail. This unseemly haste is the issue here - certainly not the principle of ensuring Wikimedia only contains legally held material. Lets use some sensible timescales that would be appropriate and commensurate with action taken in a court of law, and not a hanging party - that's just what I want to see. Encouraging over-hasty deletion simply discourages the rest of us from doing our best for the integrity and value of Wikimedia content.
- Suggestion: WikiMedia should work with photo-sharing websites such as Flickr to promote and encourage awareness-raising of the benefits of users changing default settings to Creative Commons. Reason: So few users appreciate their images are set to be copyright, but can be changed to the benefit of projects such as Wikimedia.
- Suggestion: Wikimedia should encourage those uploading iMnage to supply alt-text, and for this to be included within the use this file on Wikipedia text.
- Suggestion: Enable Mobile preview option within the normal preview window, rather than requiring users to first save their edits before being able to see how they appear when laid out for mobiles.
- Suggestion: Find and replace in Wikipdeia's visual editor needs greater clarity. Found text needs to be much more visible than the pale blue. Try find-and–replacing hyphens with en dashes. Not only are they impossible to spot, but the program does not track to the next 'found' selection, so users have to scroll down to look for them. Ideally there would be a Find–and–replace funbction in normal wikimarkup editing.
- On the off-chance that someone might one day make an update to the operation of Lupin's Live Spellcheck tool, I'd like to offer the following observations based on a few thousand correction/edits made with it during the last week or so. Basically, it's an excellent tool, but:
- Ignore typos in Wikimedia and Wikipedia image filenames, or in text containing [sic] or
((Notatypo))
- Edit summary should include the text 'identified with Lupin's automated spellcheck' tool, or equivalent. This would help other editors appreciate how/why the edits were made. (
 Done: Just copy Lupin's script to own userpages and edit line 874. Mine now has its own description.)
- Increase the time period before displaying a prompt to continue checking. Change this from 1hr 40mins to at least 4 hours to allow a full set of corrections to build up which can then be addressed in one session. ( Done Copy and edit line 1224 of script to own userpages. Mine now runs 1000 cycles.)
- Sandbox pages should not be allowed to be indexed by search engines. I regularly find partial drivel I have thrown together in a sandbox page appearing in Google search results, and this seems daft. It needs a noindex command.
AutoWikiBrowser
As a new user of WP:AWB, I encountered a number of criticisms over the way I initially (usually unintentionally) employed it. These suggestions are based on those experiences:
- Whilst AWB's Manual clearly states it should not be used for Controversial edits, there appears to be no published guidance as to what does and does not constitute controversial. This is not helpful. The tool's own default settings probably permit more edits of this nature to be carried out than is necessary - especially for new users (hyphens to dashes, etc), so one has to suggest that its default settings are not correctly set.
- Whilst AWB's search of the 500 latest New Articles has highlighted some appalling additions which needed immediate action through WP:CSD, or recommendation for WP:AfD, some editors (including myself) believe that more time needs to be given to new articles before anyone can tag them for improvement or deletion. Whilst Speedy Deletion is still appropriate for a number of serious issues (especially G1, G2 and G10), all other article creators need to be given a little bit more time if they are not to be put off from creating content. "New" needs to be defined as anything older than 30 minutes, not 30 seconds. (Comment made a year or so before ACTRIAL)
- The AutoWikiBrowser portal needs a discussion section dedicated for New Users. The current discussion section is clearly frequented by experienced users, and I suggest it is off-putting for new users of this powerful tool to feel they can ask more basic questions there.
|
_rose-coloured-glasses.jpg){kind=small}
.svg){kind=small}
