I'm going to break the mails into smaller bite size chunks therefore
concentrating the discussions hopefully. So as a proposed solution to
the options page, it's similar to the filter methods in the plugin
page, however in this case we can have any number of pulldown options
you can think of, all located in any which way you want. We can try
and define them and then let plugin developers fit their options
within preset options or add a new one. The inspiration for his
actually was when Michael mentioned the hundreds of options that could
be available. The only programme I know well enough to know that
they've got serious problems with options, and yet it all works for me
is photoshop. So under preferences you've got 10 main headings and
each has a collection of options. That's the methodology I'm thinking
we can adopt here. In addition we've also got the next and previous
links on either side which should help with additional queue for
people to go through the various option sub-pages. Obviously we still
need to consider what the default option sub-pages will be but this
solution should hopefully be a decent solution for the issues/problems
that have been mentioned with regards to the previous solutions.
I've also updated the footer to have the black sides, because I
actually quiet liked that from bishop's mockup. I did check the option
of having the top and bottom elements being smaller, but that really
did look odd, which is why those elements are a similar size
throughout the actual page.
Finally I've included a slightly wider version. Now from my point of
view the narrower option is just a tighter solution. It's not narrow
as much as it is essentially the correct size. The wider option (which
isn't that much wider I must add) just looks overflowing and does look
odd.
The wider version is, to my eyes, only trivially wider. It provides
no benefit or drawback compared to the narrow version.
I'm not sure I like the drop-down control for option selections. I
still think a single Options page with expandable sections would be
nice to see.
Okay peeps,
I'm going to break the mails into smaller bite size chunks therefore
concentrating the discussions hopefully. So as a proposed solution to
the options page, it's similar to the filter methods in the plugin
page, however in this case we can have any number of pulldown options
you can think of, all located in any which way you want. We can try
and define them and then let plugin developers fit their options
within preset options or add a new one. The inspiration for his
actually was when Michael mentioned the hundreds of options that could
be available. The only programme I know well enough to know that
they've got serious problems with options, and yet it all works for me
is photoshop. So under preferences you've got 10 main headings and
each has a collection of options. That's the methodology I'm thinking
we can adopt here. In addition we've also got the next and previous
links on either side which should help with additional queue for
people to go through the various option sub-pages. Obviously we still
need to consider what the default option sub-pages will be but this
solution should hopefully be a decent solution for the issues/problems
that have been mentioned with regards to the previous solutions.
I've also updated the footer to have the black sides, because I
actually quiet liked that from bishop's mockup. I did check the option
of having the top and bottom elements being smaller, but that really
did look odd, which is why those elements are a similar size
throughout the actual page.
Let me first capture some things that I do like in the latest set of
mockups.
I like the page heading and subheading. Overlooked when we're aiming at
everything else, I think these succinctly say what we're trying to do.
Also, I like the way that we're defining a narrower column in these
pages. I agree that we should not use the entire page width for a textbox.
Still, I like your wider sample better, not just for aesthetic reasons,
but because of the additional room it provides for more complicated
controls underneath.
Please remember that although our built-in form system only currently
supports a limited number of controls, these controls should eventually
include things like a fancier javascript-based grid for freeform
key-value pair entries. Complex controls may need the room.
The overall objective of this page is to let the user edit the option
they want as quickly as possible. We perceive that this page will have
many options on it, and so organizing them feels important.
Unfortunately, I must admit that I'm not fond of the dropdown or
next/previous links for this purpose. It doesn't feel as quick as it
should. Whether ajax is used or not, it'll still feel like a page load
moving from group to group.
As skippy suggested in his email, I think I would like to see an options
page that has all options tucked into sections that expand.
An idea that may have slipped through previous messages is to include an
"Options Search" in the place where the dropdown appears in these mockups.
If all option sections are shown on the page, it should be possible to
show only those option sections that match keywords typed into this field.
So for example, if you are looking for options to control your photo
uploads, you might type "photo". If the word "photo" appears in the
options section for the Flickr silo, then that section would remain on
the page while others were vanished. By including text for the "help"
links along with the control labels, appropriate keywords will be
present in each section.
Upon completing the search, the sections could be expanded, allowing
direct view of the options most likely to be of concern.
By including a search, finding the correct options becomes trivial. It
will not matter if you know which section contains the options you are
looking for. If you do know the section, open it -- the interface works
as-is.
Anyway, that's my great idea and now I'm spent. Do with that what you
will. That said, I think we should reach some conclusion to this soon.
We're rounding the corner for 0.4, and it would be nice if we had all
of this figured out and implemented before 0.5.
Owen
I am hitting a wall grasping the concepts of how these options will be
classified, and how they will be filtered based on user. If all
plugin options will be simply classified under "plugins", themes under
something like "presentation", then why not leave them on their
corresponding page, and simply hide the deactivate/activate button
based on permissions? In some ways, that might be beneficial in that
Ok, but let me rephrase this first set of options since they make some
assumptions as written that we should not make.
Choice 1 - Options for each discrete component appear on their component
pages.
Options for a specific plugin appear on the plugin list. Options for
the theme appear somewhere near the theme selection. Options for core
appear on a dedicated core options page.
Choice 2 - All options appear in a single place.
A single Options page displays options for every component -- plugin,
theme, core.
Please ignore for the time being anything having to do with organizing
options on their respective pages for either choice.
There are considerations to take into account when making a choice
between these two. First, when a user looks for an option, where will
they instinctively look in the admin? Second, will security
implications interfere with the access of options? Third, what is the
most efficient way to allow admins to find and change a setting - get in
and get out?
What comes next is my opinion on the above.
When a user (admin or not, but particularly users who cannot install
plugins or themes but have the ability to set their options) looks for
an option, I believe that they will not instinctively know whether the
setting they are looking for is something provided by a plugin or theme.
Given a choice of menu options, I think they will certainly choose
one that says "Options" over one that says "Plugins".
As a result, they would end up hunting for the correct options page if
we chose Choice 1. This is inefficient, and since efficiency is a goal,
it's also ineffectual design. Even if they did know they were looking
for a plugin option, they would be able to find the option on the
combined full list of available options.
If people are looking for plugin options, and the options are all on the
options page, then they would never go to the plugin activation page to
look for options. Even if they did, it should be trivial to include a
link there to the options page to remind them where the options are.
And if we're really fancy, we could link directly to the individual
plugin options. But they're probably not going to make this mistake
more than once.
If someone has some logic to dispute the above, that's what would
convince me to change my mind. So far, I'm unconvinced.
Can we decide on this one thing before we move to the next issue, which
is how to disclose the options?
People have been talking a lot about grouping things, and there is
currently no way in the code to group anything. We can surely add
stuff, but before we do, we should decide what the best way is so that
we're not making coding changes to accommodate functionality we're not
going to use. Whatever we decide, it's likely to change the
architecture of plugin UI radically. I am not opposed to this (what
we're doing right now is not perfect), but I don't want to do it twice.
So yes, can we please come to consensus on this one thing before moving
on to the next?
Owen
> Can we decide on this one thing before we move to the next issue, which
> is how to disclose the options?
+1 for an "all Options, regardless of origin, on a single page".
-1 from me. It breaks the traditional computer interface that most
folks are comfortable, IMNSHO. I don't go to a single screen on my
Mac to configure every single piece of software I've installed (which
is a bit of how I view plugins -- discrete pieces of code and/or
software packages that I install to increase my productivity and
functionality), I configure each in its own preferences menu (or, for
some items in a System Preferences pane).
By moving to a one-size-fits-all/lump sum model, you're losing the
interactivity advantages afforded to those that leverage these
traditional computer interface schemes.
The idea is to design top-flight blogging software, not bust interface
paradigms.
Just my $.02.
--
-Doug
There is a great deal of difference between being accustomed to poor
interface design and actually having a good interface. I'd rather
Habari users became comfortable with finding their options all under a
single navigation item.
Still, I think it is inappropriate to characterize plugins as separate
applications. Plugins extend Habari. Applications do not extend the
operating system.
In that case, consider what does extends the operating system. In both
OSX and Windows there is a single control panel that houses all
configuration options for the operating system. When new options are
available (at least in Windows) they are revealed in the control panel.
If I remember correctly, the options in OSX even stay within the same
control panel window until you click some kind of "back" button.
> By moving to a one-size-fits-all/lump sum model, you're losing the
> interactivity advantages afforded to those that leverage these
> traditional computer interface schemes.
I think it's possible to put those interactive controls into what I've
described. I also am not aware of any implicit advantages over a
proposed alternative.
Owen
I don't disagree. What I do know is that average users are very
quickly frustrated with having to learn new interfaces. If a piece of
software has an interface that is familiar and/or a direct analog to
something they're already comfortable with, you will retain the users.
If they have to go hunting to find what they're looking for (read:
MT3.x interface), you'll frustrate and lose users' interest.
> Still, I think it is inappropriate to characterize plugins as separate
> applications. Plugins extend Habari. Applications do not extend the
> operating system.
>
> In that case, consider what does extends the operating system. In both
> OSX and Windows there is a single control panel that houses all
> configuration options for the operating system. When new options are
> available (at least in Windows) they are revealed in the control panel.
> If I remember correctly, the options in OSX even stay within the same
> control panel window until you click some kind of "back" button.
>
This is incorrect. All system-level options are contained in the
System Preferences application. Applications that want to put options
on the main Syspref pane end up on the bottom, ala
http://img.skitch.com/20080108-g2ye56efuhs1125td8y4sqh4mk.jpg
Clicking on the preferences icon takes you to a sub-pane, ala
http://img.skitch.com/20080108-be1mycxfnn1x389dwhtci7jwhy.jpg
> I think it's possible to put those interactive controls into what I've
> described. I also am not aware of any implicit advantages over a
> proposed alternative.
>
Throwing all the options into a single page is clutter. Imagine if
your XP Control Panel was one GIANT screen with your network, graphics
card, firewall, installed software, group policy settings, etc. all
listed on a single pane. Interface nightmare, IMHO.
--
-Doug
It's interesting that users will be frustrated having to learn new
interfaces, but making it like Movable Type will frustrate them too.
What ever will we do???
If there is no analog to our software with an acceptable UI, then I
think we're perfectly within our rights to build something in which
options are easy to locate.
>> Still, I think it is inappropriate to characterize plugins as separate
>> applications. Plugins extend Habari. Applications do not extend the
>> operating system.
>>
>> In that case, consider what does extends the operating system. In both
>> OSX and Windows there is a single control panel that houses all
>> configuration options for the operating system. When new options are
>> available (at least in Windows) they are revealed in the control panel.
>> If I remember correctly, the options in OSX even stay within the same
>> control panel window until you click some kind of "back" button.
>>
>
> This is incorrect. All system-level options are contained in the
> System Preferences application. Applications that want to put options
> on the main Syspref pane end up on the bottom, ala
Yeah, all of the options are in the same System Preferences application.
> Clicking on the preferences icon takes you to a sub-pane, ala
Right, with the little back and "Show All" buttons at the top.
The salient point here being that you don't go hunting in a Hardware or
Audio area for the options pertaining to your sound card. Or even if
those sections are separated out, those areas are all contained in a
single place.
It's like when 3COM cards come with that extra little application. I'm
left wondering why they couldn't have created a stinking Control Panel
applet like every other proper network card, so that I'd be able to
configure it in the same place as everything else.
> Throwing all the options into a single page is clutter. Imagine if
> your XP Control Panel was one GIANT screen with your network, graphics
> card, firewall, installed software, group policy settings, etc. all
> listed on a single pane. Interface nightmare, IMHO.
I think maybe you're skipping ahead in the discussion. We're only
answering the question of whether principal plugin options should be on
the plugin activation page or on a shared options page with theme and
core options. We're specifically not discussing what that page looks
like. There's no point in that until the first decision is made.
Besides, one could easily make the argument that options would be
identically cluttered if plugin options (of which the bulk of options
will be anyway) were all on the plugin activation page, or that there is
a way (say, make it look like the System Preferences page in OSX) to
organize options on a single Options page that makes it all work.
Owen
Aside from the fact that clicking an option opens a new window, this
is largely how I'd like to see Habari operate. Groups of related
controls would be lumped together under a heading somewhere, allowing
an operator to drill down to those sets of options they want to
manipulate.
> Throwing all the options into a single page is clutter. Imagine if
> your XP Control Panel was one GIANT screen with your network, graphics
> card, firewall, installed software, group policy settings, etc. all
> listed on a single pane. Interface nightmare, IMHO.
If all the options were in a single list, without categorization or
hierarchy or navigation, I would agree with you.
But I think a hierarchical view -- headings and sub-headings -- that
can be expanded or collapsed would be a pretty good way to minimize
the amount of time an operator spends clicking about when they install
and / or reconfigure their site.
Thinking back to my WP days, I had a fair number of pluins installed,
many of which inserted their own menus. Once I had the settings
running the way I wanted, I didn't have to go back to twiddle them.
Sticking with the OSX metaphor: how often do you open up the
"Displays" item, or the "International" once you have things set the
way you like? Now, how is that different from a collapsed-by-default
set of options in a Habari Options list somewhere? You're not
changing them, so they wouldn't be displayed -- they'd be tucked
inside the "My Cool Plugin" heading, which could be expanded if you
decided to change those settings.
Cheers,
Scott
You just pegged my Sarcasm Geiger. *grin*
The MT discussion from earlier was based upon MT4.x. I can whip up
some screenies from a test MT3.x install that I have to illustrate
just how confusing it used to be. MT4 is light years better than it
was, but it is far from perfect in an overall sense. I was previously
advocating specifically for the way in which they model plugin
options.
> If there is no analog to our software with an acceptable UI, then I
> think we're perfectly within our rights to build something in which
> options are easy to locate.
> > This is incorrect. All system-level options are contained in the
> > System Preferences application. Applications that want to put options
> > on the main Syspref pane end up on the bottom, ala
>
> Yeah, all of the options are in the same System Preferences application.
No, "links" to all of the options are in the Syspref app. The options
are contained on a separate screen.
>
> > Clicking on the preferences icon takes you to a sub-pane, ala
>
> Right, with the little back and "Show All" buttons at the top.
>
> The salient point here being that you don't go hunting in a Hardware or
> Audio area for the options pertaining to your sound card. Or even if
> those sections are separated out, those areas are all contained in a
> single place.
>
> It's like when 3COM cards come with that extra little application. I'm
> left wondering why they couldn't have created a stinking Control Panel
> applet like every other proper network card, so that I'd be able to
> configure it in the same place as everything else.
>
I think you're misinterpreting me here. I'm not advocating for an
NVIDIA taskbar entry, I'm advocating for plugin options being
explicitly tied with the plugin itself in a very direct fashion.
The arguments against segmenting the options out is that users that
don't have access to activate/deactivate plugins may become easily
confused. Imagine another use case, where such a user becomes quite
acclimated to changing plugin options in a monolithic options screen
such as the one you advocate. Now, a user WITH de/activation rights
goes ahead and deactivates the plugin user A is concerned with. With
no warning, those options entries go away and user A is left
scratching her head as to where she misplaced that option.
> I think maybe you're skipping ahead in the discussion. We're only
> answering the question of whether principal plugin options should be on
> the plugin activation page or on a shared options page with theme and
> core options. We're specifically not discussing what that page looks
> like. There's no point in that until the first decision is made.
>
> Besides, one could easily make the argument that options would be
> identically cluttered if plugin options (of which the bulk of options
> will be anyway) were all on the plugin activation page, or that there is
> a way (say, make it look like the System Preferences page in OSX) to
> organize options on a single Options page that makes it all work.
>
I'm advocating an interface that encourages a "drill-down" approach to
options setting. I want to manage my spam-fighting options, so I hit
Options->Plugins->Spam Dogma 3.1 and configure the woolyboogers out of
the sucker. No muss, no fuss, and I know I have a repeatable workflow
every time.
The problem WordPress has is that it doesn't enforce such a
drill-down, allowing plugins to hook into the top-level menu items
willy-nilly. This is not a good thing and thus should be avoided.
--
-Doug
That's pretty much what I was advocating with the MT screenies I
posted last week.
However, I'm objecting to placing plugin options within the same
context as system-level ones. I think they deserve (and work best
within) their own context inside of the application's flow.
--
-Doug
If all the options were in a single list, without categorization or
> Throwing all the options into a single page is clutter. Imagine if
> your XP Control Panel was one GIANT screen with your network, graphics
> card, firewall, installed software, group policy settings, etc. all
> listed on a single pane. Interface nightmare, IMHO.
hierarchy or navigation, I would agree with you.
But I think a hierarchical view -- headings and sub-headings -- that
can be expanded or collapsed would be a pretty good way to minimize
the amount of time an operator spends clicking about when they install
and / or reconfigure their site.
~Randy
I would like to see one page, but not one long list. I think all
options (plugin, theme, core etc..) should be available in one single
spot, similar to the KDE control centre. You can go to each "option
module" without ever leaving the control centre, but it's not just one
super long page of inputs.
I would also like to see the line blurred between core and
plugin/theme options. So if we had a "look and feel" section for the
options page, plugins and/or themes that deal with that section, could
place their options there right along with the core options.
Say I install a smilies plugin (like the great Tabasamu plugin ;) ),
I'm extending habari to use smilies, so I want to set those smilies in
habari, not in some page with other "plugins". Also, say you had a
contact form plugin, I don't want to set my personal data, like email
etc.. for the core options, then go to another page and set more
"personal" options for plugin A, then plugin B.
Basically, I want to use Habari, not a bunch of plugins.
But yes, there are cases out there where a plugin would require it's
own page, or section of options... well, I think ... there must be
.... ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org
iD8DBQFHhD+fIC5Lv8K7w/sRAqfgAJ0VbuxP5/Otg/NX93S0BvDayXbn5gCfWb6A
UCZYQbmYE+qiiSh1gNu9WxY=
=B3AV
-----END PGP SIGNATURE-----
> since this email would be no good without a mockup from me, I thought
> I'd provide the open/hide option in there as well, just so we've got
> another option on the table as well.
I like the look of that!
I think it might be helpful to include a text description alongside
the section headers. This would serve two purposes:
1) it would explain to new users in general terms what the section
contains. Some new users might know what "Syndication" means in the
way of options, for example.
2) it would help steer plugin authors toward using the appropriate
section when adding options to their plugins. "My plugin modifies the
Atom feed, so it should go in Syndication, I guess".