[wp-trac] [WordPress Trac] #13584: Revert changes introduced for tickets 11274 and 13467
wp-trac at lists.automattic.com
Thu May 27 20:12:25 UTC 2010
#13584: Revert changes introduced for tickets 11274 and 13467
Reporter: demetris | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: 3.0
Component: UI | Version: 3.0
Severity: normal | Keywords: dev-feedback
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
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
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
(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
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
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
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
'''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!
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.
Ticket URL: <http://core.trac.wordpress.org/ticket/13584>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac