RFF

Requests For Features

Introduction to RFFs

Request For Feature: 1

Status of this issue

This is an introductive issue defining the basic goal of the present file and some useful guidelines.

Introduction

This document is a chronologicaly ordered list of features ideas. It could have been named "TODO list", but giving the same name to every file is too boring so we chose another name. We believe this is a good name, but if you don't like it, it is up to you to append a new Request For Feature (a.k.a. RFF) about it to that file.

Piece of guidelines

You SHOULD try and use about the same typological style for each issue. E.g. start with an explicit title, then note your RFF id (please have it increase by step of exactly 1…). Write down a little abstract of your feature content and its type in a section named "Status of this issue". Developp, conclude and finally sign and date your request.

For each indefined situation, you MUST refere to your common sense.

Élie Michel, 07.19.2014

Different base configurations

Status of this issue

This is a feature for future production release of Freeder. It is not needed for developpment phase but should not be forgotten.

Introduction

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 have 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 target 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 prefere 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.

Conclusion

The two opposite categories of user that we could target will require to have two different base configuration.

Élie Michel, 07.19.2014

This is the end of file

This section is not a RFF and should always appears at the end of this file. If you have not enough time to edit a full RFF — or if you are too lazy — you can just add you pitch idea to that simple list.

It is RECOMMENDED to finally write a full RFF from you ideas (and then remove it from this list) when you have time — or motivation — to do it.

Since it just have to be a pitch collector, you MAY add items that only you can understand, although it is not recommended.

• Configurations différentes
• Bonne doc (Guideline)
• Est-ce que Freeder va voir la balise <link rel="feeds" … /> dans un html normal ou pas ?