Page MenuHomePhabricator

Consider to re-label "Save changes"/"Publish changes" to be "Save & Publish"
Closed, DeclinedPublic8 Estimated Story Points

Description

Based on 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 change:

  • This is more clear and less confusing
  • It has similar length
  • Preserves the old name to some degree for older help pages.

Hewiki decided to update locally the Publishchanges message, but keeping consistency with other projects is important (and this was the main point against doing such change locally).

I believe such change may be relevant to other projects (and the pros/cons are not language specific), so we suggest that mediawiki to consider a similar change ("Publish changes" => "Save & Publish").

Please feel free to comment/share thoughts for/against such change and to edit the task itself to keep the summary of the discussion here up to date.

Related Objects

Event Timeline

Johan subscribed.

I'm assuming the user-notice tag was included because all tags were kept from the parent task. If I'm mistaken, please re-add it and explain why.

Jdforrester-WMF lowered the priority of this task from Medium to Low.
Jdforrester-WMF edited projects, added Design; removed WikiEditor.
Jdforrester-WMF changed the point value for this task from 40 to 8.
Jdforrester-WMF moved this task from To Triage to TR1: Releases on the VisualEditor board.

It's weird to press a button that says "Publish changes" when posting a new section to a user talk page.

Report from Facebook: some new users (in education programs) are reporting the "publish changes" button wording is "scary" and there's a request that it be changed to "save" in the Sandbox:

https://www.facebook.com/groups/WikipediaEducationProgram/permalink/2018859428128696/

Note: Legal did not object to the button saying "Save and publish page" when I asked. The length of these words varies significantly by language, so I suspect that people with product/user experience considerations would not encourage the change.

Report from Facebook: some new users (in education programs) are reporting the "publish changes" button wording is "scary" and there's a request that it be changed to "save" in the Sandbox:

@Mvolz, thanks for this note. It appears that these students are accurately grasping the idea that they're making their changes available to the public. Their instructors may want to educate them about the non-private nature of their sandboxes: they are not just saving their drafts for later.

On the technical end, I believe that using different labels for different pages (especially if you wanted to restrict it only to pages named "/Sandbox") would be complicated.

I'm having this input again and again @Whatamidoing-WMF, and I'm educationg then on the public nature or their sandboxes. But still they understand that when they edit an article it should be publish, and when they edit their sandbox it would be "save". It's something that could encourage UX, because we (as experienced editors) are not aware of the slight difference between both types of edition.

Dutch community also received a report about the sandbox situation. Maybe the SandboxLink extension can be adjusted for that, as it has "sandboxlink-subpage-name".

Part of the reason that the button was changed to say "Publish" rather than "Save" was to make it clear to people that the edits they are making will be immediately going onto a public site. People are probably finding this scary because it is scary to have your changes put out publicly. Even changes to a sandbox are going live immediately. Changing the button to say something different to the sandbox could make it even less clear to people that changes to a sandbox are just as live and findable as changes to articles.

There are presently no plans to change this wording.

在T163302#3963255中,@Deskana写道:

Part of the reason that the button was changed to say "Publish" rather than "Save" was to make it clear to people that the edits they are making will be immediately going onto a public site. People are probably finding this scary because it is scary to have your changes put out publicly. Even changes to a sandbox are going live immediately. Changing the button to say something different to the sandbox could make it even less clear to people that changes to a sandbox are just as live and findable as changes to articles.

There are presently no plans to change this wording.

I may understand that why those peoples think that even they "published" their diffs permanently, they don't think that they are publishing, generally because of MediaWiki-extensions-FlaggedRevs or likes, where they ruled that published edition must be the stable revision.

One thing that we've noticed consistently for Wiki Education program participants since the "Publish" label rolled out is that it's extremely confusing in sandboxes, because users take "Publish" to mean "move out of sandbox to make a live article". We've had many cases where users lost their sandbox work because they tried and failed to find a Save button but they knew they didn't want to publish their draft to mainspace and so avoided that button. Many users in this situation assume that, since there is no "Save" button, their draft must automatically be saved (since this is how many other WYSIWYG editors work).

A terminology change that made it more clear that "Publish" for a non-mainspace page is not that same as "Publish to mainspace" would help a lot.

A terminology change that made it more clear that "Publish" for a non-mainspace page is not that same as "Publish to mainspace" would help a lot.

... But it is the same, except the namespace.

A larger problem is that newbies don't understand namespaces, and I can't blame them. I doubt that the label of the Publish button will fix that.

A terminology change that made it more clear that "Publish" for a non-mainspace page is not that same as "Publish to mainspace" would help a lot.

... But it is the same, except the namespace.

A larger problem is that newbies don't understand namespaces, and I can't blame them. I doubt that the label of the Publish button will fix that.

Based on what we've observed and talked with students and instructors about, it's definitely perceived differently in sandboxes vs mainspace. These users know that a sandbox is a place for drafting work that isn't ready to be "live" in the sense of being a normal Wikipedia. In that context, many users interpret "Publish" to clearly communicate the idea of "this is no longer a draft and will be published as a normal article". In an already-live article, "Publish" is harder to misinterpret.

I agree that the practical implications are different. A page in a draft or user namespace is less visible. But it's still visible, and something needs to tell that to people.

Maybe some namespaces could have a custom label, such as "Publish to Draft namespace". But it should still say "Publish", or clarify in some other way that the page is not going to be private.

In any case, that should be in a different task. This task should be closed. The Hebrew Wikipedia tried "Save & Publish" for some time and went back to "Publish".

I agree with @Ragesoss, this is consistent with what we have seen with students and what they tell us they expect from the "Publish" button. The best solution I find would be having a "Save" button in the Sandbox namespace and, once clicked, having a button that explains that this will be publicly saved but it won't be an actual article. Many students are afraid "someone" will find their sandbox if they look for the topic of the article (they are writing about "Foo", I search for "Foo" in the searchbox and I reach their sandbox).

At the same time, the Sandbox should have a button to automatically let editors publish it in the Main space. This should make things way easier for newbies.

Thanks @Amire80. I've filed a new task for it as T297520. Since he.wiki no longer users "Save & Publish", I guess the concept for this task of ensuring consistency across languages is no longer relevant.