[wp-hackers] Plugin Settings Menu Location
Alexander Beutl
xel at netgra.de
Sun May 18 21:08:40 GMT 2008
You are only speaking about "use once and forget" pages - and what you
describe is the perfectly wrong thing to do even if it sounds right. Why?
Imagine I write a plugin which really is for handling plugins. The admin
has... lets say 10 Plugins installed and every single one puts in its own
settings page at plugins menu. The admin would need to seek trough 10
different one-time-settings-pages to find the page which would really do
something with their plugins.
They should be accessable right out of the plugins description text (or at
least somewhere near that) and shouldn't take any menu item at all... but
AFAIK there is no way to do that today. Perfect way would be:
a) Press install
b) come to config page - configure and save
c) come back to plugin page - maybe start at a) again...
d) if you ever want to change something again go to the plugins page and
scroll down to the plugin click on a link and be back at that config page.
One should ONLY out one time config stuff there - of course.
> Because you're usually
> never going to change those
> settings ever again. There's rarely any
> need to do so.
Besides: Blogsettings wont change very often too.
2008/5/18, Otto <otto at ottodestruct.com>:
>
> On Wed, May 14, 2008 at 2:16 PM, Austin Matzko <if.website at gmail.com>
> wrote:
> > There's a difference between a "user" and an "admin."
>
>
> No, there really is not in this case. The user should never be
> configuring plugin settings in the first place. The blog's owner is
> the one doing that sort of thing.
>
>
> > The user just
> > knows, for example, that she wants to manage X, so she's going to look
> > under "Manage."
>
>
> We're talking about initial or one-time configuration, not something
> that you "Manage" every day.
>
>
> > 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."
>
>
> Yes, yes, fine, and that makes perfect sense for plugins that do more
> than something behind the scenes or which have more than one page of
> configuration. 90% of the plugins out there that have a config page
> only have one. They don't have a lot of interface, generally speaking.
>
> The reason for plugins having the ability to add pages essentially
> anywhere is that you can always come up with some particular plugin
> that will need that ability.
>
> But consider the majority of cases. Plugin with one configuration
> page. Setting it up is probably something done one-time. Putting it
> into the settings menu is confusing to that initial setup phase,
> because you have to activate it and then go elsewhere to configure it.
> Activating it and then instantly seeing the resulting page in the menu
> is way easier, and it's the right thing to do.
>
>
> > 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.
>
>
> No, that's not at all what I'm saying. I'm saying that usage is
> all-important. That's exactly why putting your plugin's settings under
> the plugins menu is the right way to do it. Because you're usually
> never going to change those settings ever again. There's rarely any
> need to do so.
>
> Obviously specific cases vary, but having every plugin stick something
> into "Settings" simply makes the menu confusing. Most plugins need
> some sort of configuration, but damn few need to be reconfigured every
> so often.
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
More information about the wp-hackers
mailing list