[dev] Hiding help entries

[Oliver Kuhl]

Hi,

Eric Jon Rostetter <eric.rostetter at physics.utexas.edu> schrieb:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Prefs help entries usually don't document a feature, but help the user
>> to decide how he wants to set the preference. If he doesn't have the
>> choice, he doesn't need this help.
>
> Are we talking about help entries in the Options pages, or generic help
> pages in the various apps that just happen to mention something controlled
> by a preference?

The point for me initially were the help entries for the options page.  
I don't have an overview about how all help links in all applications  
are created. So what happenes with those help links somewhere in the  
applications when you disable a feature or lock a preference? If a  
feature is completely disabled, I would estimate the help links to  
disappear. If a preference is locked, I'm with Eric and not sure if in  
some situations a feature is still there (but not configurable  
anymore) and a help would still be appreciated.

>> Admins shouldn't depend on the online user help to make decisions
>> about preferences or configuration items.
>
> That is true, but this isn't a perfect world. I'll ceed to your
> point though really, as it isn't proper even if it is too often done.

Admins are not the problem because they should know what they do and  
can be done. If they see everything, maybe disabled features should be  
marked as such. However, anything is fine since admins at least see  
what users see.

>> No, but it means that it doesn't make sense to show a help for it. The
>> user doesn't get to the help entry because he doesn't even see the
>> preference. He would only get to it from the help index, and then he
>> wonders what it's all about, because he never sees the preference.
>
> If we are talking only about the help for the Options page, then I
> agree.  I assumed we were talking about all help menus, not just that
> for the Options page.  I need clarification I guess on what is being
> considered here.
>
>>> To hide based solely on the locked state is bound to cause documentation
>>> loss.
>>
>> Or to avoid confusion.
>
> Depends on which help files we're talking about.

Talking about this from a users or providers point of view means, that  
the help entries should be consistent with the existing and enabled  
features. In our case, we have about 250.000 users which could use our  
webmail. Documentation is a must have to prevent people from calling  
our hotline and creating costs. ;-)
It is always a challenge to find the balance between feature richness  
and convenient handling and another reason why we have to disable some  
of those sort of cool features like pgp support or shared stuff.

>>> And last, should we not implement this for configuration as well as
>>> preferences?
>>
>> Yes, maybe, but it's much easier for preferences.
>
> But once again, just because it is easier doesn't mean it is correct.
> If we should do it for both, then we should either do it for both,
> or do it for the easier one and put the other on the to-do list (or
> even offer a bounty, etc).

The question here is if locking prefs is enough to remove a feature  
like pgp totally from the help. Some prefs are only displayed  
depending on configuration options so I would say that prefs only is  
not enough.

Gruss,
     Oliver.