[Kolab-devel] TO all anti-spam enthusiasts

[Alain Spineux]

On Jan 3, 2008 11:41 AM, Bernhard Reiter <bernhard at intevation.de> wrote:
> On Monday 17 December 2007 20:02, Richard Bos wrote:
> > > Why do you want to hide the underneath features under vague words.
>
> Administrators ("users" to our Kolab Server) often report that they are
> overwhelmed with options, they also do not understand.
> This is why the administration capabilities should be very strict about
> containing only the most important buttons. We should put up a good argument
> for each button as experienced MTA administrators can use the kolab-templates
> anyway to fine-tune. And they will need to do it.

I thing that set the default to a reliable value and clearly show the
recommended
value to the user is a better solution than to hide the complexity.
If the user can see that all settings are set to the recommended values,
it will be reassured.

>
> > > Why not list them all, maybe ordered from the lighter to the hardest, and
> > > maybe with a hint in ( relaxed, medium, aggressive ) and some more help.
> >
> > Why not combine both ;) ?
> >
> > Each and every measure should just be listed, which could be activated with
> > e.g. a checkbox.
>
> No, this is probably overkill.

We are speaking about 10 or less options, no more !

> Using a few sections with a sensible grouping might be better.
> Single measure can still be defined in the configuration files themselfs.
>
> > Additionally there could be three columns after the checkbox that shows
> > whether the measure is part of a (convenience group as listed above
> > (relaxed, medium or aggressive)).
> > The convenience groups are probably just arrays in php (or maybe a new
> > template file?). By selecting a convenience group all measure that are
> > part of that group will be checked. That way it is also visible clear what
> > the result will be of selecting a convenience group.
>
> I agree that there should be good documentation about what the groups do,
> but on the other hand, I know that documentation will rot pretty fast,
> so for a frist step a hint towards the relevant templates would be sufficient.
> I think that adding another mini-templating system like arrays in php would be
> too complex to do any good. The main work will be to discuss what good default
> are. Doing for three levels instead of the one that we have know is adding
> more load to us.
>
> So even the idea of adding only one level or keep the current and document
> the possibilities of postfix better is still appealing to me. ;)
>
> Bernhard
>
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you