C'est le premier article issu des RFFs. D'autres suivront sûrement !
Commençant un nouveau projet, je me suis dit que c'était l'occasion de faire les choses bien et de mettre sur le papier un maximum de choses. En écrivant certains Requests For Feature (parce qu'appeler ça des TODO c'était trop mainstream) qui me passaient par la tête, je me suis finalemement retrouvé à rédiger dans un cadre plus général.
Du coup je pense publier ici toutes les entrées à caractère général, histoire qu'elles ne restent pas perdues au fond d'un wiki !
Bon, et comme je les ai écrit en Anglais, bah c'est en Anglais…
Different base configurations
I believe that "A good program always has a good default configuration". Which logically means that if the default config sucks, the program should not be considered as a good program. (Yep, I know that it is a little bit excessive, but I believe it.)
So Freeder should have a good default configuration. Of course. But here comes the definition of what a good configuration is.
[Section 1] will list what is always required by a configuration to be good. [Section 2] will extract some main direction of it, defining what different kind of people is targeted by what good configuration needs. [Section 3] finally wonder about how to implement it both on a technical and ergonomic point of view.
Section 1: Different configuration need
We SHOULD NOT look for the config to convince them all, the config for everyone to find its needs, the config to bring them all and in the consensus bind them.
If it would be a One Configuration like that, it better be hardcoded and not open to modification. That is exactly what the notion of configuration means.
That is what fundamentally motivates this RFF: propose at installation time different options presets.
The main constraint that the default configuration shall follow is consistency. Whoever the configuration is made for, it has to be made for at least a category of people and not only for a single person and so requires :
- To be easilly understood by people using it. Even not targeted people should be able to say "Okey, config has been design for this kind of people so this feature should behave that way". This prevent people from being frustrated. Frustration is a major cause of software abandon.
- To fit these people needs. Though it is a configuration for many people, it has to referes to an idea of how the program should be more than on the specificities of one person installation.
An overview of possible categories of people that a configuration could target is provided in [Section 2].
Section 2: Different configuration philosophies
Some people want to protect their privacy. Even if it requires some sacrificies.
Some people don't care about privacy but want things to work. Period.
Some people always want a full control on what happend and refuse automatic tasks and choices.
Some people prefer a seamless use of their tools.
Some people know nothing about computers. Unfortunately, it's the concern of many people. We can't blame them: they juste want to waste their free time on different fields of interest. This is why people that know about it SHALL do what they can to help people that don't.
Some people dawn configuration. They just can't be batherd by triggering options and just want a plug and play installation. They power their computer on and need it to be exactly what they want it to do. The computer — which in that case usually is a MacBook — has sometimes difficulties to guess it but may try. It is hard to completely fit their willings but should not be ignored.
(Dont hesitate to add your own "Some people"s!)
We can conclude that there are two main opposite directions that can be followed:
- Hackers: They learned to forgot that they are always live-configuring everything they use and need a full control on their tools.
- Muggles: They want to plug and play, whatever the privacy issues it raises.
(TODO: Find better names…)
Section 3: Implementation considerations
Since defautl configurations should be design for mean people inside their categories, they should not be too excessive.
Hackers could play with the settings and so we could considere that the only base configuration should be the one for Muggles. But Hackers themselves prefere to start on a clean basis and defining two set of options is a better idea.
The general toggle button setting hacker options could in the other hand rely inside the settings page. What I think we need is just to be able to change a whole set of options at one time.
I don't thing hiding too many advanced settings in a special section is a good idea because it would not resolve user clustering (between Hackers and Muggles). Basic users should be able to discover more advanced options by wandering inside settings page.
Another difference between configuration kinds is the difference between progressive integration and full initial configuration. In the first case, by default a lot of option (such as activating privacy filters) remains unset and are prompted everytime the backend need it. The user have then the possibility to (1) choose the right option and (2) remember it, or not. In the second case, there are no questions since there already is a rememberd option.
Note that a little bit security for muggles would help educating them and so we should not fully clean their environments, especially to signal to them some hard privacy issues or bad feeds.
The two opposite categories of user that we could target will require to have two different base configuration.
Article publié le 21 Juillet 2014 par