[dev] Hiding help entries

[Jan Schneider]

Zitat von Oliver Kuhl <okuhl at netcologne.de>:

> 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.

That's how I understand it too.

> 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

If there is not interface, there's no help link.

> 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.

I would still say no, because the preference help usually doesn't  
explain a feature. Context help for a feature is usually linked from  
feature's interface, not from its preference screen.

>>> 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.

I was only talking about the help items linked from the  
options/preference pages.

>>>> 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.

Yeah, any sane administrator should lock the preferences and features  
down to what their users really need. Horde's interfaces are often too  
overwhelming for the average user.

>>>> 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.

No, it's not. But it's a start. I have no idea how to determine inside  
the help viewer if feature has been disabled, when this is not  
possible with testing preference locks. Maybe the "depends" attribute  
that was mentioned in the cited thread could help.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/