[wp-trac] [WordPress Trac] #13584: Revert changes introduced for tickets 11274 and 13467

[WordPress Trac]

#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
 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!

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/13584>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software