[wp-hackers] Plugin Settings Menu Location

[Austin Matzko]

On Wed, May 14, 2008 at 2:34 PM, Otto <otto at ottodestruct.com> wrote:
> On Mon, May 12, 2008 at 8:13 AM, Austin Matzko <if.website at gmail.com> wrote:
>> That's right: this makes sense from a usability perspective. One of
>> WordPress's chief virtues is its extensibility, and the way that it's
>> extended should be transparent to the end user; in other words, they
>> shouldn't have to figure out which feature is from a plugin and which
>> is core.
>
> A user knows what plugins they have and have not activated, and they
> should not have to hunt around to find where the settings for a plugin
> they just activated are.

There's a difference between a "user" and an "admin."  The admin knows
what plugins are installed,  and the admin may be in the dashboard
only long enough to activate and configure the plugin.  The user just
knows, for example, that she wants to manage X, so she's going to look
under "Manage."

> So I disagree with you and I agree with Matt in this case, and my
> plugin configuration pages are going into the plugins menu.

I'm not sure how far to go with the "what Matt thinks" line, but I
don't believe that's his view, based on what he said at the recent
Milan WordCamp.  See about 40 seconds into this video:
http://www.vimeo.com/1007293?pg=embed&sec=1007293
Someone asks why the new dashboard looks like it does, and he replies,
"what we decided to do was to allow more room for plugins to expand
all the different sides, to break it into menus organized by different
action types. . . . and now there's room for . . . plugins to expand
the menu."

Besides, to a certain extent it doesn't matter what Matt thinks, for
the reason you mention: *you* control where you put your plugins' menu
options.

>> Something else to consider is the weight of precedent: almost all of
>> the popular plugins I can think of...
>
> ... do it the wrong way. Insert "jump off a bridge" analogy here.

That analogy assumes that putting settings under "Settings" and
manageable items under "Manage" is like jumping off a bridge, and I'm
not convinced it is.  The main reason I disagree is that the other
position looks at menu organization from the structure of the *code*
rather than the structure of *usage.*  In other words, it says that we
should put X plugin options under "Plugins" because X's code happens
to be in a plugin.  I'm convinced that it's more user-friendly to look
at things from the perspective of use: if something manages something,
it belongs under "Manage."  My experience working with clients further
convinces me, because usually they don't care whether it's a plugin or
core functionality that lets them accomplish X; they just want me to
set it up so they can do X.