Revert changes introduced for tickets 11274 and 13467

[demetris]

I propose to revert two large sets of changes that we have been seeing over the last few days in trunk:

Changes in menu labels and screen titles. See ticket: #11274

Additions of text in the contextual help panels. See ticket: #13467

I propose this for two reasons.

First, it is too late in the development cycle for changes of that significance:

The first set (tracked in #11274) changes some of the most prominent UI strings, breaks continuity and introduces some strange naming schemes for no obvious benefit.

The second set (tracked in #13467) adds a large amount of strings to what already was a huge number of new strings for the 3.0 release. (At the moment I am writing this, the new strings in v3.0 are 1159 — one thousand one hundred and fifty nine.)

Second, there was no prior evaluation, discussion or planning for either of these two sets of changes, and there is no time to evaluate them now.

I think these two reasons are serious enough to justify a full reversal, even though reverting itself would be no easy task in this case (we are talking about dozens of commits.)

I also took some time to look at the two sets of changes and try to understand what their benefits are and whether they would justify consideration at this stage of the development cycle.

Here are my thoughts...

(Supposing for a moment that we are not about to hit an RC, and that the time is appropriate for this discussion.)

Let me start with the SCREEN TITLES and MENU LABELS.

It is said in the relevant ticket (#11274) that the Edit Posts/Pages screens are not just for editing; that people also use them to view their Posts/Pages. So, the argument goes, these screens should have more general titles; we should remove the Edit bits.

From my experience with WordPress, I think that is wrong.

If you want to view your Pages or Posts, you can go to the front of your site and enjoy theme in their proper form. When you go to the Edit Posts/Pages screens, what you want to do is edit/manage/review your Posts and Pages. In other words, these screens are managers, not viewers. So, there is nothing wrong with the word Edit in their titles and no reason to break continuity.

This set of changes also introduces a strange naming scheme in the admin menus: second-level items share the same name with their top-level parents.

(Since other Edit screens are not very different in purpose, the same applies, more or less, to all of them.)

Now to the CONTEXTUAL HELP PANELS.

As far as I understand, there is only one argument FOR changing that part of the UI at this stage of the development cycle:

The changes were already planned for v2.7 and we are too late in implementing them. So (the argument implicitly goes), let’s make the changes now!

This makes no sense!

If the changes were planned for v2.7, then we had enough time to put them in early in v2.8-dev, early in v2.9-dev, or early in v3.0-dev. We survived three releases without them. We will survive one more.

That is, as far as I know, the only argument in favour of the changes at this stage.

Taking some time to look at the help panels (and, as I said above, trying to forget that we are about to hit and RC) I could discern no other merit in how this is working out at the moment. I only found problems. Let me enumarate a few:

First, if that amount of inline help is needed, that would imply that the UI has major problems that make it nearly incomprehensible and that the UI/UX attention should be focused at those problems instead.

The UI, of course, does not have such problems. It has several issues here and there, but the solution is not adding masses of text! The best course of action here, in my view, would be, first, to identify the problematic bits (those parts of the UI that are not self-explanatory or intuitive), and then improve them by the means we have available: better placement and arrangement, better icons, better ANCHOR text, better TITLE attributes, contextual help that would be really contextual (see below for a suggestion on that), etc.

Second, the texts for the help panels are written in a style more appropriate for a book and inappropriate for a web UI. People who want to use tools want to use tools; they don’t want to read books.

Third, while the help panels are dubbed “contextual help”, they often decontextualize whatever real contextual help there is now. If you want to see, for example, what a metabox is about, the concept of the new contextual help says that you must go to another place, click on a tab, try to scan an unscannable mass of text, and then go back to accomplish your task. Not good!

There is however one concern that may be behind the push for the help panels, and I would like to address it here because I think it has merit: Explanatory text within metaboxes, above textareas, below buttons, etc. clutters the UI. And, because of that, it would be nice if we could get rid of it in some way. As I said, I think this concern has merit. But, if it indeed is a drive behind the changes, have we considered alternative solutions? E.g., why not put the necessary explanatory texts in collapsible boxes that are shown/hidden by clicking on a nice info icon? (The circle with the iota in it.) Or by clicking on a nice help icon?

Fourth, even if the help panels were the best solution overall, committing such a number of new strings so late will affect the quality of the strings. It is not reasonable to explect we will achieve a good result by the final release.

A very undesirable side-effect of this is what, for lack of better inspiration, I will call “mediocre strings lock-in”. In general (and very sensibly) we avoid changing strings unless there is very good reason. That means that we must always aim at having the best possible strings by the final release, because we will have to live with them for a long time. Now there is simply no time to do that. (And there are parts of the UI that have not been properly audited yet for string quality/consistency/etc.)

It is interesting to note here that the “mediocre strings lock-in” can only affect the original, English strings. A good translator can, and usually will, improve a mediocre string upon translating it, and a translator can always revisit the strings at a later time without disturbing other localizations. We do not have that luxury for the original strings.

Fifth, as I mentioned above and as I think it’s worth repeating, the new contextual help strings increase the number new strings (which had already hit a new high before that) to almost twelve hundred. That is too much for the L10n teams!

IN CONCLUSION

Let us start treating the WordPress UI with a bit more care. And let the reach and scope of the WordPress project inspire that care in us.

Cheers!

[westi]

If we need to in future we will revisit and improve the strings we will.

Opening a ticket like this isn't constructive it is much better to keep focused discussion on the tickets relevant to the changes.

Contextual help is staying as it is an important improvement.

There will be a gap between the strings freezing and release to give the translations teams a chance to catch up and translate as many of the new strings as they can manage.

Closing as WORKSFORME

[demetris]

What do you want me to do, westi, in order to be constructive?

I am bringing up issues as they appear. It is not because of me that the issues appear at this point of the development cycle.

[westi]

Replying to demetris:

What do you want me to do, westi, in order to be constructive?

I am bringing up issues as they appear. It is not because of me that the issues appear at this point of the development cycle.

Either comment on individual issues on the tickets which introduced the changes or bring things up in the dev meetup.

Huge essays on tickets about a number of issues don't help things get resolved in a timely manner.

[Denis-de-Bernardy]

There will be a gap between the strings freezing and release to give the translations teams a chance to catch up and translate as many of the new strings as they can manage.

On the plus side, this means we'll have another (lengthy) delay before releasing. That'll mean more (much needed) testing, and (even more needed) bug fixing.

[demetris]

Replying to westi:

Replying to demetris:

What do you want me to do, westi, in order to be constructive?

I am bringing up issues as they appear. It is not because of me that the issues appear at this point of the development cycle.

Either comment on individual issues on the tickets which introduced the changes or bring things up in the dev meetup.

Huge essays on tickets about a number of issues don't help things get resolved in a timely manner.

So, you want to dictate when I open tickets and what I put in them?

Is there something in my involvement with this project that makes you think I cannot be trusted with deciding whether an issue, some thoughts or some observations warrant their own ticket?

As for not being constructive, let us have some UI/UX experts audit our UI, and then we can talk about being constructive and not being constructive.

By the way, I wanted to thank you for adding my item to yesterday’s agenda. To be honest, given the nature of my proposal, I did not expect it would be included.

(I also did not expect this ticket to live long. But the issue is important in my estimation, and I felt I had to do what I had to do.)