When Should A Feature Be On By Default?

[Jeffro]

Just before the release of WordPress 3.1, there was a flare up of discussion again on the Hackers mailing list regarding the admin bar. While the conversation was nothing new, there was a part of the discussion that gave me some food for thought. The question is, when should a new feature in software be turned on by default?

When I sat back and started thinking about it, my preference is that new features should be disabled in a new software version release but that the release notes should do a good job of explaining to me why I would want to turn that feature on.

So I find myself agreeing with Chip Bennett again concerning new features that alter the look of the public facing website, even if that look is meant for administrators eyes only.

http://lists.automattic.com/pipermai...ry/037703.html

I believe that *most* users, when they learn about a new feature due to that new feature changing something about the appearance or output of their site,are going to be quite unhappy that said new feature was enabled - and thus,changed their site - without permission.

New features that change the public-facing appearance or output of users' sites should not be enabled by default.

The discussion concerning the admin bar has come and gone, a few times now but this discussion can easily branch out into software in general. The admin bar was just an example and this thread is not meant to be strictly about that feature in WordPress but software in general.

[Ryan]

There's some features that should just logically be turned on by default. I don't think the admin bar was one of them though since a lot of people wouldn't want it magically appearing on their site.

We're encouraged to click that "upgrade" button whenever a new version comes out, but if it does something weird and annoying one time, then users are going to be a lot less likely to upgrade immediately next time.

This sort of thing doesn't bother me too much personally, as I'm generally running the latest trunk or beta locally anyway, so I see these things crop up and deal with them before I need to push them out live on my sites, but for others I could see this being a real PITA.

[dgwyer]

I think there are a couple of immediate reasons why some people didn't like the admin bar (initially). Firstly, it is very visible on the front end and this is quite a change to the normal appearance of your site if you haven't seen the admin bar before (i.e. on WordPress.com). Secondly, some people think that this admin bar was visible to everyone and not just to those people logged in to their WordPress site.

I wrote the Admin Bar Minimiser Plugin so that you can still have it turned on but the impact of it is, well.. minimised. In fact when minimised you only see a small 'Show' tab in the top left of the screen.

In the next release I am going to add a couple of settings so that you can alter the opacity and label text of the tab. So, if you want you can have the tab completely hidden unless you hover your mouse over it, and you will be able to change the 'Show' label to a '+' for example. I wonder if this minimising feature could be introduced into WordPress core to make the impact of the admin bar less visible, and hence more appealing to users? ;-)

As for turning on features by default, in general (as far as the developer goes) there is a real temptation to switch on most things just so that they get exposure/usage/testing etc. From the user point of view though it really depends on the feature and how much that feature is going to be used on a daily basis. There is not much point in turning on a visible feature if you would only use it occasionally.

As a bad example..

For all Skype users (certainly here in the UK), over the last few months, every time you opened Skype there has been this REALLY annoying advert pop-up that you have to close in order to do anything. This has been driving me nuts and has put me off using Skype lately, especially as there seemed no way to turn the thing off in the options! This really should of had a 'Do not show again' checkbox, or other way of disabling.

[andreasnrb]

Luckily there is Admin Bar Disabler. http://wordpress.org/extend/plugins/admin-bar-disabler/ so you as the owner of the website can decide who sees the abomination and who does not. Not all logged in users should see it at the get go.

[chipbennett]

You'll notice that I said my piece on the latest Admin-Bar discussion on the Hackers list, and then went quiet. :) As you said: the decision had already been made, so there was little sense in continuing to debate it.

That said: I utterly despise the "Apple mentality" wherever it rears its ugly head. That is: the attitude that "minimal is best", and that the developers always know what is right/best regarding what options to expose to the end user, and what new features to enable/disable by default. It is the same attitude that would put in the capital_P_dangit() filter, by default, without exposing a built-in option to disable it.

I believe this mentality is disrespectful to end users, and assumes that end users are either too ignorant or too stupid to learn about and understand a new feature. Rather than enabling by default something like the Admin Bar, focus efforts on educating end users so that they understand the benefits of the new feature, can understand how to enable it if they choose to do so, and can therefore make their own, informed decision regarding that feature.

A general principle that demonstrates respect for end users would be: Any new feature that impacts the front-end display of a user's site should be enabled by default in new installations, disabled by default in upgrades.

Regarding the Admin Bar specifically: depending on how the end user's Theme is coded, enabling the Admin Bar could quite possibly wreak havoc on the front-end layout. Granted, a well-coded Theme should have no problems handling the Admin Bar, as generally, IMX it has only been Themes that use position:absolute improperly, e.g. for nav menus, that have had problems with the Admin Bar.

[Ryan]

Granted, a well-coded Theme should have no problems handling the Admin Bar, as generally, IMX it has only been Themes that use position:absolute improperly, e.g. for nav menus, that have had problems with the Admin Bar.

I wouldn't say that all themes which didn't work with the admin bar are coded improperly per se, just most of them. There's a few logical reasons for using position: absolute in that way, particularly if it never dawned on you that a bunch of code junk would be magically injected into your theme. In fact I think the admin bar itself is added in that way via position: absolute.