Re-label the "Save" button to be "Publish", to better indicate to users the outcomes of their action
Open, NormalPublic40 Story Points

Subscribers
Tokens
"Mountain of Wealth" token, awarded by Scott."Y So Serious" token, awarded by matej_suchanek."Dislike" token, awarded by Pppery."Dislike" token, awarded by demon."Y So Serious" token, awarded by greg."Dislike" token, awarded by BethNaught."Love" token, awarded by Liuxinyu970226."Dislike" token, awarded by Ricordisamoa."Dislike" token, awarded by Base."Pterodactyl" token, awarded by Ankit-Maity."Haypence" token, awarded by RandomDSdevel."Like" token, awarded by TerraCodes.
Assigned To
Authored By
Jdforrester-WMF, Mar 29 2016

Description

From feedback we get repeatedly as a development team from interviews, user testing and other solicited and unsolicited avenues, and by inspection from the number of edits by newbies not quite aware of the impact of their edits in terms of immediate broadcast and irrevocability, that new users don't necessarily understand what "Save" on the edit page means. Yes, there's some blurb underneath, but (a) it's not clear, (b) it's (necessarily) filled with jargon, and (c) it's in the traditional "blurb blindness" spot where no-one pays attention.

In user testing this has been particularly highlighted as a point of confusion for new users. Even though "user-generated content" sites are a lot more common today than they were when Wikipedia was founded, it is still unusual for most people that their actions will result in immediate, and effectively irrevocable, publication.

Many other wikis use "Publish", notably including Wikia in their fork of MediaWiki since (?) 2008 or so. Most other similar tools use "Publish" for this action, and reserve "Save" for server-side drafts (something we're unlikely to provide right now, as discussed elsewhere). Re-labelling won't solve all issues, but it will more clearly and obviously declare to the user the nature of the action they are about to take. It may reduce slightly the rate at which newbies make their first change, but hopefully because they are more informed and accepting of what they are doing.

However, changing though trivial in terms of code will be a very visible, and possibly mildly disruptive, change to a lot of existing users' workflows, so we should consider carefully this change and not just rush in.

There are a very large number of changes, so older changes are hidden. Show Older Changes
Elitre changed the status of subtask T134580: CLs to communicate the Save/Publish change from Stalled to Open.Jun 30 2016, 11:31 AM

Change 296719 had a related patch set uploaded (by Jforrester):
EditPage: Allow the 'save' button's label to be 'publish' for public wikis

https://gerrit.wikimedia.org/r/296719

Change 296746 had a related patch set uploaded (by Jforrester):
Vary the 'save' labels to 'publish' for public wikis

https://gerrit.wikimedia.org/r/296746

Risker added a subscriber: Risker.EditedJul 4 2016, 5:35 AM

I'm going to agree with Base. I cannot understand why anyone would think "Publish" is a more appropriate word than "Save" in this context, especially as it does not apply to many of the tasks that are, erm, saved. A single universal word is going to be much easier for editors to use and understand.

That some people are surprised that when they click "save", their edits are publicly viewable, probably speaks more to limited internet exposure than to an issue on *our* interface. Most user-editable websites use the term "save" to indicate that whatever someone wrote will be publicly viewable (or alternately be held in the moderation queue) once that button is clicked. Those that use other terms are the exception.

Incidentally, Scott...Base is not just referring to printed works. He is also referring to the hundreds of pages on every wiki in the Help space, and often in the Wikipedia or similar spaces that teach editors how to operate. It will take years, literally, to get those all cleaned up; we know this because few wikis have managed to even update their Help and similar pages to reflect the presence of VisualEditor. It is reasonable to assume that some projects are just going to override this in their MediaWiki space. If the WMF is okay with that - and based on the history of "fixes" to extensions and creation of new extensions, it often isn't - then it's probably not an issue. But I'm having a hard time imagining that this is important enough for another big battle with communities.

Scott added a comment.EditedJul 4 2016, 10:40 AM

Incidentally, Scott...Base is not just referring to printed works. He is also referring to the hundreds of pages on every wiki in the Help space, and often in the Wikipedia or similar spaces that teach editors how to operate. It will take years, literally, to get those all cleaned up...

That's really not much of a problem on WMF wikis, where rapid mass changes are easily within technical ability, and again, it's not MediaWiki developers' responsibility to update other people's out of date documentation.

I'm going to agree with Base. I cannot understand why anyone would think "Publish" is a more appropriate word than "Save" in this context, especially as it does not apply to many of the tasks that are, erm, saved. A single universal word is going to be much easier for editors to use and understand.

That some people are surprised that when they click "save", their edits are publicly viewable, probably speaks more to limited internet exposure than to an issue on *our* interface. Most user-editable websites use the term "save" to indicate that whatever someone wrote will be publicly viewable (or alternately be held in the moderation queue) once that button is clicked. Those that use other terms are the exception.

Incidentally, Scott...Base is not just referring to printed works. He is also referring to the hundreds of pages on every wiki in the Help space, and often in the Wikipedia or similar spaces that teach editors how to operate. It will take years, literally, to get those all cleaned up; we know this because few wikis have managed to even update their Help and similar pages to reflect the presence of VisualEditor. It is reasonable to assume that some projects are just going to override this in their MediaWiki space. If the WMF is okay with that - and based on the history of "fixes" to extensions and creation of new extensions, it often isn't - then it's probably not an issue. But I'm having a hard time imagining that this is important enough for another big battle with communities.

But save could also be something in the bank, or a thing that must do after earthquake/flood/tsunami... therefore I can't agree with him.

Risker added a comment.Jul 4 2016, 2:36 PM

Incidentally, Scott...Base is not just referring to printed works. He is also referring to the hundreds of pages on every wiki in the Help space, and often in the Wikipedia or similar spaces that teach editors how to operate. It will take years, literally, to get those all cleaned up...

That's really not much of a problem on WMF wikis, where rapid mass changes are easily within technical ability, and again, it's not MediaWiki developers' responsibility to update other people's out of date documentation.

Ah yes, the old "we just change the software, it's not our job to actually explain to anyone how to use it properly" excuse. The fact that you're going to render out of date the documentation of every single Wikimedia instance is quite relevant, as will be the thousands of hours of volunteer time that will be required to update them. No, they're not just quick technical fixes.

The entire purpose of this change is supposed to make things easier for new users; it would not have been proposed otherwise. Therefore, the updating of the pages used to educate those new users is an essential part of this transition. The fact that this change can only be partially implemented on certain types of pages (i.e., the use of the word "publish" is inappropriate for certain types of pages, especially draft pages where beginners often work) actually increases the learning curve for new users, because they would have to learn *two* ways of saving things, which more than doubles the complexity of teaching them.

If you don't like the "Save" word that has been widely used on the internet for over 20 years, then find another word that isn't technically wrong in a lot of the cases where this button would be. This is not in any way a technical problem; it's an English/Spanish/German/etc usage problem.

Scott added a comment.EditedJul 4 2016, 3:43 PM

Therefore, the updating of the pages used to educate those new users is an essential part of this transition.

The point of this change is, in effect, to make the button self-explanatory. That was noted in the initial description of this task. You're grossly underestimating the intelligence of our users and their ability to cope during whatever period there is of updating mentions of the button throughout sites.

The fact that this change can only be partially implemented on the use of the word "publish" is inappropriate for certain types of pages, especially draft pages where beginners often work

Upthread, in T131132#2229477, @Jdforrester-WMF wrote:

I feel that labelling the hacky 'Drafts:' namespace as different from other namespaces when it's just as public, just as subject to libel/etc. law, just as findable depending on your search vector (noindex doesn't always get respected by outsiders), and otherwise essentially the same as them would not be a reasonable thing to do.

If you don't like the "Save" word that has been widely used on the internet for over 20 years, then find another word that isn't technically wrong in a lot of the cases where this button would be.

I hate to break it to you, but every time you change a page, you're publishing that change to the internet.

Risker added a comment.Jul 4 2016, 8:20 PM

Please don't be patronizing, Scott.

James, as the originator of this proposal, has a bias toward its being applied everywhere, and I respect that, although he's not provided much evidence that new users will find the implications and usage of "publish" easier to understand than "save". That would probably take some serious A/B testing, which I know can be quite challenging on live projects. But it's pretty obvious even just in this thread that a lot of people really don't see the draft namespace as "publishing", especially since it isn't actually as public as other namespaces: in particular it's set up to prevent robot.txt-respecting scrapers and search engines from including those pages in their results. Pages in the Draft namespace don't show up in Google, Yahoo, or DuckDuckGo searches (at least on my random sample of 50 pages). Indeed, without some pretty good search skills, they're often almost impossible to find using internal search. They may be publicly visible, but in the same way that a demolition order is public when it is at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'. <ref: HHGG>

Scott added a comment.Jul 4 2016, 9:00 PM

You may see it as being patronizing, but this is basic facts.

MediaWiki is an extremely basic publishing system. It has no core workflow functionality of any kind whatsoever. The "draft" namespace is a crude kludge that simulates a very basic form of workflow, without any form of access control levels that would be expected from a more professional system.

What you're advocating is educating MediaWiki users to form a faulty mental model of the application that is entirely reliant upon the expected good behavior of unknown third parties. No software development organization with any degree of acuity would, or should, ever yoke itself to an immeasurable externality like that.

Risker added a comment.Jul 4 2016, 9:49 PM

Mostly, I am saying "show why this change is better". There's no data to support that this change will have any different result. We have plenty of data to show that important and visible changes to the UI tend to foster significant hostility between the Wikimedia communities and the WMF if they are not well explained, well justified and well documented, and if the community is left to fix all the documentation and any unconsidered or ignored problems that may arise from it. Given there's no evidence "publish" is any more likely to result in better understanding on the part of new editors that their work will be immediately viewable on the internet (or alternately, that it won't be viewable in some cases, such as talk pages, draft space, and many other places where the "save" button currently appears), I don't think there is much benefit in burning off what little goodwill there currently exists between the editing community and the WMF over this particular "tweak".

I have given some thought as to what kind of data would be useful in determining if this is a useful change. Probably the first step would be a survey of new editors on multiple languages with the usual term that is used on the current "save page" button, and the proposed new terminology, to see whether there is any difference in understanding on the part of the new editors. (Example question: You have clicked the "edit" button and have typed something on a page in Wikipedia. You then click the "Save page" button. What do you expect will happen? (a) My edits/changes will be inserted into the page and will be publicly visible (b) My edits/changes will only be visible to me (c) My edits/changes will be sent to a moderator for review before they are publicly visible.... and repeat with the "publish page" question). There's no identifiable success metric here (is it "fewer new editors are surprised"? if so, that requires before/after documentation and testing of a significant number of new editors across multiple languages) and no determination of what would lead to a reversal of the change (e.g., edits from new editors is decreased by X%, or X number of wikis take steps to thwart the change).

I think probably just about everyone would agree with Scott's "crude kludge" comment, and some would go so far as to extend it to MediaWiki itself. It's pretty unlikely to undergo a transformation from the ugly duckling of software to graceful swan. But that doesn't mean the way to improve it is to just come up with an idea and apply it to several hundred million pages when it isn't even clear what result we expect to obtain, of what would constitute success or failure. It's 2016. We ought to be able to articulate this consistently for any UI changes that are applied.

Qgil moved this task from Backlog to Team radar on the Community-Liaisons board.
TheDJ added a comment.Jul 5 2016, 1:55 PM

I suggest we keep to flipping the default for MediaWiki, but keep the old style for WMF.

I think we have spent enough hours on this detail and it is unrealistic to put such a small change through additional huge and intensive procedures as are being suggested. This ticket has already cost 1000's of dollars, and I don't think we should inflate that cost further, just because many people don't trust the judgement of developers any longer.

The user interviews are clear (as noted in the original descriptions), and we should act accordingly and incrementally as we always have. The rest is a community problem which we can't solve, and the best we can do is move out of its way.

I can see your point, TheDJ. At the same time, this change is being based on 2009 interviews with 8 users from the San Francisco area in English only, and only one of them even mentioned the word "publish" in their interviews. All 8 of the interviewees understood that "save" meant their work was going to be saved, although there were some different understandings of what "save" meant. Such a small sample size and small result would be laughed at anywhere outside of website design, but meh. For the record, all 8 users experienced serious difficulties in relation to templates, which have if anything become more complex and opaque since those 2009 interviews.

Risker, that's not the only study that has looked at this. AFAICT the most recent was just a few months ago (and involved six people, which is the industry standard, for better or worse).

Also AFAICT every single study that touches this question (usually as part of something else) has come to the same conclusion: a sizeable fraction of non-editors/first-time editors expect "Save" to work like it does on WordPress, i.e., that "Publish" is a separate button.

But you are correct to point out that this problem has been known for years. IMO this should have been fixed years ago.

BethNaught added a subscriber: BethNaught.

Change 285242 abandoned by Jforrester:
EditPage: Use 'publish' rather than 'save' for the publish button

Reason:
Sorry, should have abandoned this a while ago; I56634ed22 replaces this.

https://gerrit.wikimedia.org/r/285242

Change 281462 abandoned by DLynch:
[WIP] Use "publish" instead of "save" in toolbar and save-dialog

Reason:
Abandoning because this is severely out of date with the discussion on the ticket.

https://gerrit.wikimedia.org/r/281462

As a user and sysop on Wikinews I am protesting against this change as in most if not all that language versions the term "publish" (or its equivalents in other languages) is used for the one special edit when an article is considered ready, well after it was proofread, doublechecked and reviewed, when it usually get halfprotected and is added to the main page and declared to never again modified anymore. The change would add confusion to the redaction processes in Wikinews.

As a user and sysop on Wikinews I am protesting against this change as in most if not all that language versions the term "publish" (or its equivalents in other languages) is used for the one special edit when an article is considered ready, well after it was proofread, doublechecked and reviewed, when it usually get halfprotected and is added to the main page and declared to never again modified anymore. The change would add confusion to the redaction processes in Wikinews.

Have you read my message above? I said:

But save could also be something in the bank, or a thing that must do after earthquake/flood/tsunami...

But save could also be something in the bank, or a thing that must do after earthquake/flood/tsunami...

Well, mankind is working with computers since decades, they're working widespread with the internet for 20 years. So they know unless they are idiots that "save" in an IT context does not mean "bring in your savings". Besides: off course a user is saving his edit, for now and ever, 'cause the edits are literally "saved" forever (as in aslong as article histories are "saved"). So "save" is etymologically dead on target.. While "publishing" is just wrong: the "publisher" of Wikipedia (in terms of law as well as defacto) or any other Wikimedia project is the Wikimedia Foundation.

greg awarded a token.Aug 11 2016, 5:03 PM
greg removed a subscriber: greg.
Alsee added a subscriber: Alsee.Aug 12 2016, 7:15 AM

Have you considered the confusion for new editors when many editors habitually keep calling it the "save button"? That will keep happening for years, and it could persist indefinitely given the human habit for shorter terms.

"Save&Publish" could be an option, and translators can be encouraged to use one word as appropriate. I don't think we even need the word "page" or "changes" on the button. "Save&Publish" is very clear for both cases.

But save could also be something in the bank, or a thing that must do after earthquake/flood/tsunami...

Well, mankind is working with computers since decades, they're working widespread with the internet for 20 years. So they know unless they are idiots that "save" in an IT context does not mean "bring in your savings". Besides: off course a user is saving his edit, for now and ever, 'cause the edits are literally "saved" forever (as in aslong as article histories are "saved"). So "save" is etymologically dead on target.. While "publishing" is just wrong: the "publisher" of Wikipedia (in terms of law as well as defacto) or any other Wikimedia project is the Wikimedia Foundation.

All of your words that I've read carefully, are violating a guideline: Please do not bite the newcomers

By unless they are idiots..., are you asking Internet is for technical users only? If yes, then I would warn you: You Guys Are Making the Internet Counterpart of THAAD, which is dangerous for at least me!

santhosh removed a subscriber: santhosh.Aug 15 2016, 3:33 AM
Base added a comment.Aug 17 2016, 6:53 PM

But save could also be something in the bank, or a thing that must do after earthquake/flood/tsunami... therefore I can't agree with him.

A person has to have really low IQ or other mental problems to not understand which of homonyms with completely different meanings is to be applied in current situation.
On the other hand both meanings of publish are applicable to the button and it is very likely that large part of the audience will get it wrong which is contrary to what is desired.

It's third-party application developers' job to build around MediaWiki, not the other way around.

How about using less obscure wording, something like "We do not care about what problems it might make to people actually actively using Mediawiki". Otherwise it could be misunderstood that you actually care which would bring a disappointment.

That's what happens when you print guides to software. It's not reasonable to expect software to remain static to prevent paper documentation from becoming outdated.

While Mediawiki is a software, Wikipedia is not. Nor are Wikiquote, Wikinews, Wikivoyage, Wikisource, Wikimedia Commons and other Wikimedia and not only Wikimedia projects. Userbase diversity is very very big. We have people as young as less than 10 and as old as over 70 editing projects, from IT specialists to people who know where the power button is on their PC, how to launch IE (which they would call "Internet") and MS Word and how to type text and not a bit more. For many people out there printed materials are the best way to read information from. I understand that for you it might be extremely hard to imagine, it is somewhat difficult for me too. But I have though small but experience helping out on workshops about Wikipedia to GLAM people and other average people and I know that there are many not much digitised guys out there who are still very important for us to have them contributing into our projects. While general computer literacy tends to be better with people of younger generations, the printed materials attachment still persists in some backgrounds as that is how people are taught to work. It is understandable to consider some deep change only long time "technical" users will even notice to be a software change, but in this case we are talking about very outer thing. I hope you are not going to dismiss Wikimedia projects, the very projects Mediawiki is first of all is being built for the same reckless way you do with third-party products.

Like every other change to MediaWiki.

First of all not every, secondly scale and importance of fast reflection are very different in this case while the basis is very shallow. (E.g. Wikidata or VE brought even more work to be done, but those were important changes, I am saying this even though I personally loathe VE)

This is a very melodramatic piece of conjecture that underestimates the intelligence of the user base.

Now this is fun considering that this whole task is based exactly on underestimating the intelligence of the user base.

That's really not much of a problem on WMF wikis, where rapid mass changes are easily within technical ability, and again, it's not MediaWiki developers' responsibility to update other people's out of date documentation.

You were pointed to a real example with poor VE existence reflection on WMF wikis and you are claiming that this is still easy, interesting. Those other people you are referring to are the very people this software is being made for and the very people without whom this software would not even be created in the first place. If that is the level of respect you have to other people who are working hard to make Wikimedia projects happen and who already have a lot of work including many metapedia work to do without having to clean up after another Mediawiki developers mess up then this task looks more of a farce than of real strive to improve stuff for editors.

Risker, that's not the only study that has looked at this. AFAICT the most recent was just a few months ago (and involved six people, which is the industry standard, for better or worse).

I do not know where such standards are applicable but I am pretty sure it is not the case with such a diverse community as we are. We have almost 300 live projects all in a different language (and Mediawiki supports even more), as I have mentioned above we have people with completely different backgrounds in any possible ways. I am pretty sure that usually industries are dealing with more narrow groups. Also we cherish our collaboration basics in our work. We are not some commercial company which core policy could be simplified to "you either use our product or go away" if you put aside all the promotion sugar they might be using.

a sizeable fraction of non-editors/first-time editors expect "Save" to work like it does on WordPress, i.e., that "Publish" is a separate button.

That is a good example of faultiness of the approach. While surely many of our users, including new users have experience with WordPress editing, a whole lot have no such experience. I am actually sure that the latter are still in a majority. To illustrate that: Last year Wikimedia Ukraine was hiring Wiki Loves Earth international coordinator. The first person we chose had to be fired after the first week because it happened that he actually has no clue on how to work in WordPress (which is a crucial skill for someone having WLE blog update among core responsibilities). And it isn't like we just picked a random CV to hire him, ergo the average is worse. And out projects are not blogs, blogs are more suited to use the word which is associated with journalism, book-printing and things like that.

But you are correct to point out that this problem has been known for years. IMO this should have been fixed years ago.

In such things there always is some point of no return. For example, we have a real case when the word we use means not what you expect: "anonymous" in wiki context means exactly the opposite to what an outsider would expect. You are actually anonymous if you are hiding your IP, not when you are exposing it. But it is years too late to change it. With "save" it is just the same thing time-wise while in this case there is no even real ground to make the change.

By unless they are idiots..., are you asking Internet is for technical users only? If yes, then I would warn you: You Guys Are Making the Internet Counterpart of THAAD, which is dangerous for at least me!

To know what "Save" means in IT context one has to have an experience with e.g. MS Word which I am pretty sure most people have. Sure there are exceptions, like my granny of 73 years old just this summer bought her first computer and while she now knows how to use Skype and how to use MS Edge to Yandex-search stuff, she has never used a text processing software yet. I guess there is a considerable part of people who similarly are only used to social media sites and nothing else, but as even internet browsers have the save option in them, and any study or work related activity requires to use a software with a save feature I deem it very very very unlikely that there are really many people who would misinterpret the word "save" in IT context. Unless, as was mentioned, if they have some problems with understanding in general.

// I am sorry for my reply being too long and in some places too emotional, but that's the way best I can write relating to such a change (proposal) with such a poor ground behind it. Having opinion of some mysterious 6 + 8 people more paid heed to rather than opinion from people who would have to deal with the change is not very encouraging too. I have to note that Tech News and the separate MassMessage about this change specifically are not a good way to call for feedback: when people see a wording which points that this will be rather than might be if and only if there will be a consensus about it in the discussion makes most people believe that any feedback is pointless (well not that they are wrong from the look of this task).

demon awarded a token.Aug 18 2016, 3:39 AM

This issue has been discussed previously. The idea is certainly older than March 2016. It would be nice to include links to previous discussions in this task.

@Whatamidoing-WMF writes on Meta-Wiki that "The Legal team at the Wikimedia Foundation supports this change." What is the citation for this claim?

But save could also be something in the bank, or a thing that must do after earthquake/flood/tsunami... therefore I can't agree with him.

A person has to have really low IQ or other mental problems to not understand which of homonyms with completely different meanings is to be applied in current situation.
On the other hand both meanings of publish are applicable to the button and it is very likely that large part of the audience will get it wrong which is contrary to what is desired.
(TL;DR)

By unless they are idiots..., are you asking Internet is for technical users only? If yes, then I would warn you: You Guys Are Making the Internet Counterpart of THAAD, which is dangerous for at least me!

To know what "Save" means in IT context one has to have an experience with e.g. MS Word which I am pretty sure most people have. Sure there are exceptions, like my granny of 73 years old just this summer bought her first computer and while she now knows how to use Skype and how to use MS Edge to Yandex-search stuff, she has never used a text processing software yet. I guess there is a considerable part of people who similarly are only used to social media sites and nothing else, but as even internet browsers have the save option in them, and any study or work related activity requires to use a software with a save feature I deem it very very very unlikely that there are really many people who would misinterpret the word "save" in IT context. Unless, as was mentioned, if they have some problems with understanding in general.

// I am sorry for my reply being too long and in some places too emotional, but that's the way best I can write relating to such a change (proposal) with such a poor ground behind it. Having opinion of some mysterious 6 + 8 people more paid heed to rather than opinion from people who would have to deal with the change is not very encouraging too. I have to note that Tech News and the separate MassMessage about this change specifically are not a good way to call for feedback: when people see a wording which points that this will be rather than might be if and only if there will be a consensus about it in the discussion makes most people believe that any feedback is pointless (well not that they are wrong from the look of this task).

First, hot do you think the "save" you seen, could also be an opposite of "Ctrl/Commond+S"? At least by clicking such keys, on either WikiEditor or VisualEditor, I've got a "save as..." popup, instead of action=submit, isn't this works not for you?

Base added a comment.Aug 21 2016, 6:29 AM

First, hot do you think the "save" you seen, could also be an opposite of "Ctrl/Commond+S"? At least by clicking such keys, on either WikiEditor or VisualEditor, I've got a "save as..." popup, instead of action=submit, isn't this works not for you?

About the same would be on Google Docs, but I am pretty sure that users are capable of distinguishing saving changes (which on that platform is done automatically as the notice there says) and saving web-page of the web-service. At least those users who know about Ctrl+S/Menu-Save feature of the browser itself. The meaning of the word here is just the same so my point is unshaken, the different here is the context, what you apply the word to.

Change 306303 had a related patch set uploaded (by Jforrester):
On public wikis, show "Publish" rather than "Save" on edit pages

https://gerrit.wikimedia.org/r/306303

Change 296719 merged by jenkins-bot:
EditPage: Allow the 'save' button's label to be 'publish' for public wikis

https://gerrit.wikimedia.org/r/296719

@Base We discussed this a little bit on #wikimedia-operations this evening, I noticed there is still some level of opposition in this task. @Jdforrester-WMF considers all the concerns have been addressed and taken in account, do you agree with this assessment?

I don't think all of above has been addressed, Dereckson. There is a lot of noise, but the main points seem to be on T131132#2270369

Still, as a mediawiki user I don't mind too much about the button caption, since I don't use it. But, do not dare
to touch the accesskey! (which would be tempting). My button is simply alt-s, and I'm sure there are lots of wikipedians with a strong muscle memory for that (not to mention the convenience of its location).

Currently, the access keys are:

  • Save page → s
  • Show preview → p
  • Show changes → v

The actions are Save and Preview, which lend itself better to remember then than Publish and Preview.

I personally like the idea of naming it Save & something, also mentioned by @Alsee, be that Save and publish, Save and share with the word… whatever.

This has several benefits:

  • Still using the Save word lets us link with the past: people remembering (or looking at written down notes) the button to press, paper books, outdated documentation, etc. It's simpler to see how it was renamed.
  • We can keep the message names savearticle and accesskey-save, so any downstream wiki that customized them won't lose their changes.

Also, I miss more info regarding the results of usability tests that prompted this change.

This was noted by the usability back in 2009. "Save often" and other software (WordPress) using "Publish" were cited as reasons.

I see that in 2010 Bianca mentioned Wordpress. However, Tram and Mrs Howie were «Familiar with old "save" interface, thrown off by "publish"» (they apparently renamed the button with js but I think they may have added more things to it)

Risker, that's not the only study that has looked at this. AFAICT the most recent was just a few months ago (and involved six people, which is the industry standard, for better or worse).

@Whatamidoing-WMF could you link to those studies?

PS: DYK that this button has been using "Save page" since the first phase3 revision, by Lee Daniel Crocker 13 years ago? And Magnus Manske original code (15 years ago) used "Save changes"

I don't think https://gerrit.wikimedia.org/r/306303 should be merged until there are sufficient +1s attached to it. If the idea has merit and is worthy of being merged, there should be a concrete demonstration of this on the Gerrit change. That shouldn't be a difficult hurdle to clear.

James F. has been pushing for this change, both filing this task and creating the various Gerrit changesets. This is great, but I think we absolutely must avoid the appearance that this change is being pushed through over objections. That never ends well.

Risker, that's not the only study that has looked at this. AFAICT the most recent was just a few months ago (and involved six people, which is the industry standard, for better or worse).

I do not know where such standards are applicable but I am pretty sure it is not the case with such a diverse community as we are. We have almost 300 live projects all in a different language (and Mediawiki supports even more), as I have mentioned above we have people with completely different backgrounds in any possible ways. I am pretty sure that usually industries are dealing with more narrow groups.

I'm very sympathetic to this argument.

Regarding the matter at hand, I'm not really inclined to care much about out-of-date documentation, in print or otherwise. I agree that Wikipedia is not a social media site, but I don't find the arguments against switching (cf. T131132#2270369) from "Save changes" to "Publish changes" to be very compelling. I'm inclined personally to give a +1 to https://gerrit.wikimedia.org/r/306303.

This was rescheduled for morning SWAT again today. I'm uncomfortable deploying it as my google-fu has failed to turn up all of the discussions relevant to addressing the points raised here—sorry to be a roadblock here—I mostly haven't been involved in this ticket so that's a bit strange.

I've asked @Jdforrester-WMF to update this ticket to point to discussions in which some of the specific points that were raised here are addressed.

Change 296746 merged by jenkins-bot:
Vary the 'save' labels to 'publish' for public wikis

https://gerrit.wikimedia.org/r/296746

James F. has been pushing for this change, both filing this task and creating the various Gerrit changesets.

Just following-up on the long-term desire. :-) And yes, I was quite surprised how little of this had ever been captured in Phab/Bugzilla such that I had to create the tasks. It's been discussed many times; I believe I was in a panel discussion about it (and other related issues to editors understanding their liability and un-spilt-milk-ability) in Wikimania 2006, for instance.

This is great, but I think we absolutely must avoid the appearance that this change is being pushed through over objections.

Absolutely. This is why we announced it months ago in hundreds of venues, waited to give people time to consider and give feedback, and considered whether the feedback was sufficiently compelling as to decide not to do this (which is my totally-fun-and-not-in-any-way-controversial job ;-)). We did, several people have (above and elsewhere), and I have decided.

do not dare to touch the accesskey! (which would be tempting).

We haven't (as you can see in the code, at rMW74fa6071c2e5: EditPage: Allow the 'save' button's label to be 'publish' for public wikis for this change, and rMW347ec3352801: EditPage: Show a different label for the button on create vs. modify for the related "change" vs. "page" bit). I agree that breaking accesskeys is profoundly anti-accessibility and should be avoided unless there's a really strong reason.

I personally like the idea of naming it Save & something, also mentioned by @Alsee, be that Save and publish, Save and share with the word… whatever.

I've discussed this before a few times, but I can't immediately see where, so here goes:

PS: DYK that this button has been using "Save page" since the first phase3 revision, by Lee Daniel Crocker 13 years ago? And Magnus Manske original code (15 years ago) used "Save changes"

Yup, though I think it was briefly "Save article", for a year or so in between those two edits, and hence the message key name).

Change 306303 merged by jenkins-bot:
On public wikis, show "Publish" rather than "Save" on edit pages

https://gerrit.wikimedia.org/r/306303

Mentioned in SAL [2016-08-29T21:56:07Z] <catrope@tin> Synchronized wmf-config/InitialiseSettings.php: T131132 (duration: 00m 48s)

Change 306303 merged by jenkins-bot:
On public wikis, show "Publish" rather than "Save" on edit pages

https://gerrit.wikimedia.org/r/306303

Temporarily reverted with https://gerrit.wikimedia.org/r/307446 and https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=818678&oldid=818677&diffonly=1, it seems.

DannyH added a subscriber: DannyH.Sep 2 2016, 4:37 PM

@Whatamidoing-WMF could you link to those studies?

Unfortunately, most of them haven't been published (or they published their main points, and omitted information about this particular issue).

I'm trying to collect some more details. However, it's probably worth being clear about the best of the likely results: "publishing the studies" probably means uploading a slidedeck that provides little more than the conclusions. The raw data is mostly video of in-depth interviews with indentifiable living people, and it is unlikely that the WMF has permission to post them online.

At this point, it might be possible to produce an (incomplete[1]) list of studies with entries that look something like this:

  • March 2016 study with new users. Structured interviews with six people. All were either uncertain of the button's effect, or wrong. Three said they thought that 'save' would make a private copy on their own computer. After discovering how it worked, one volunteered that the button ought to say 'publish' instead.

And... I'm not sure that a list like this would be very helpful. If someone has trouble believing that half the newbies could be confused by this button, then that person is likely to still have trouble believing that half the newbies could be confused by this button, despite now having a list of dates in which newbies said they were confused by this button.

[1] Most of the people who ran the earliest studies haven't worked for the WMF for years now. I therefore assume that some studies will not be found.

Dbrant added a subscriber: Dbrant.Sep 13 2016, 2:33 PM
He7d3r added a subscriber: He7d3r.Sep 19 2016, 1:22 AM

The most recent study to cover this question is reported in a slide deck here: https://commons.wikimedia.org/wiki/File:Editing_-_New_Wikitext_Editor,_Save_Publish_Findings_2016.12.pdf

The end result is that five out of five editors agreed that "Publish" indicated the finality and public nature of the action (so, get your edit right before you click this). One of the five thought that "Save" and 'Publish' had similar meanings, and the other four seemed to think that "Publish" was clearer on these key points.

On the cons, which will probably interest editors more than the reasons in favor of making the change, two were mentioned:

  • One editor speculated that "Publish page" might be harder to translate than "Save page"; however, in talking to translators, it turns out that the reverse is true. "Save" (in a computer sense) can be translated in multiple ways in some languages, whereas "Publish" is quite straightforward, due in part to publication being a key concept in copyright and libel laws all over the world.
  • One editor said that "Publish page" might make new editors think that they were publishing a magazine or a book. Whether it is undesirable to have the button subtly communicate a serious or organized purpose, such as publishing a book, is IMO a matter of personal opinion.

Change 337530 had a related patch set uploaded (by Jforrester):
Show 'Publish' not 'Save' on most public wikis

https://gerrit.wikimedia.org/r/337530

Change 337531 had a related patch set uploaded (by Jforrester):
Show 'Publish' not 'Save' on Wikipedias

https://gerrit.wikimedia.org/r/337531

Change 337530 merged by jenkins-bot:
[operations/mediawiki-config] Show 'Publish' not 'Save' on most public wikis

https://gerrit.wikimedia.org/r/337530

Mentioned in SAL (#wikimedia-operations) [2017-03-15T18:12:17Z] <legoktm@tin> Synchronized wmf-config/InitialiseSettings.php: Show 'Publish' not 'Save' on most public wikis -T131132 (duration: 00m 42s)

OK, this is now live on all wikis except Wikinews (which had a local change a few months ago instead), and Wikipedias (which will come later).

Change 345399 had a related patch set uploaded (by Catrope; owner: Jforrester):
[operations/mediawiki-config@master] Show 'Publish' not 'Save' on Wikipedias except de/en

https://gerrit.wikimedia.org/r/345399

Change 345399 merged by jenkins-bot:
[operations/mediawiki-config@master] Show 'Publish' not 'Save' on Wikipedias except de/en

https://gerrit.wikimedia.org/r/345399

Mentioned in SAL (#wikimedia-operations) [2017-03-29T18:10:27Z] <catrope@tin> Synchronized wmf-config/InitialiseSettings.php: Save->Publihs on Wikipedias except dewiki and enwiki (T131132); set wgOOUIEditPage false everywhere (duration: 00m 57s)

Just to summarize a ~week long discussion in hewiki:
Most users support changing the save button (locally) to "Save & Publish" [he: שמירה ופרסום] (rather than "Publish changes" [he: שמירת שינויים]). The main points regarding the suggested changes: This is more clear and less confusing,it has similar length, and preserves the old name to some degree for older help pages.
We will update locally the Publishchanges message, but to keep consistency with other projects, we suggest mediawiki/other projects, to consider a similar change ("Publish changes" => "Save & Publish")

Just to summarize a ~week long discussion in hewiki:
Most users support changing the save button (locally) to "Save & Publish" [he: שמירה ופרסום] (rather than "Publish changes" [he: שמירת שינויים]). The main points regarding the suggested changes: This is more clear and less confusing,it has similar length, and preserves the old name to some degree for older help pages.

This feels like a conversation that would have been better to have more broadly, to benefit all wikis and languages. Should we make a new task to discuss that idea? (Other suggestions have been made.)

We will update locally the Publishchanges message, but to keep consistency with other projects, we suggest mediawiki/other projects, to consider a similar change ("Publish changes" => "Save & Publish")

Please do not encourage wikis to over-ride the default translations, it takes years to fix things later.

@eranroz, do you want me to talk to Legal about this for you? In principle, changes to this button need to be reviewed by the Legal team before changes are made locally.