Kenneth's Nerdometer
A tool to measure the nerd factor. 0 is the ideal. No trace of nerdiness. And 10 is an absolute disaster.
This Nerdometer and its nerd factor is meant mostly as FUN. But it is also a serious signal to current and future developers to remember that user friendliness, documentation (both in code and on the Motion TWiki) and making things simple is high priority in the way we manage the Motion project.
0
My mother can do it without help. Just look up some URL you got in an email in your browser and it works.
You do not need to know about port numbers or IP addresses.
A wristwatch without a date would be a clean cut level 0.
Motion has no features at level 0. Just the fact that it is a daemon started from a command line makes it a bit nerdy. Sorry mom. Go and play with some Windows program.
1
The object or program requires a little bit from you. Without reading anything you just install the program (enter the CD-ROM and answer "yes") or download an installer and double click on it (if you can find it) and everything is installed. There is nothing to setup. It just works. There is a simple GUI where you can see everything.
No Motion is not there when it comes to installation and configuration.
But some of the features can be at this level if we do it properly.
2
OK. At this level the feature requires that you can read. For example the Motion Guide. You do not have to know what you are doing. As long as you follow the instructions it works. And if you read a little bit more you also understand the principle.
Installing Motion 3.2.1 (except ffmpeg) is at this level. If you read the Motion Guide and go step by step you have a running system that monitors ONE USB camera or an input from your TV card. And it saves pictures when things are moving.
Config options at level 2 can be understood basically from their name which is chosen with care so you know what it is. height, width for example. And by reading the few lines of text above the option in the motion.conf you have no doubt what the config option does.
3
So now you really have to start reading the Motion Guide. The feature in question is described in the Motion Guide. And it is possible to understand the text and get it to work based on the Guide only.
The feature itself is somehow linked to something in nature. If it is a complex algoritm the feature has implemented a simplifed control and does all the difficult functions automatically behind the scene. User friendliness has been given higher priority than high flexibility and probably unnecessary configurability.
A config option name is not self explaning and the 2-3 lines of explanation may still not be enough.
4
The feature is not easy to understand. The Motion Guide has a detailed description of the feature and this is needed because the feature can never be explained in the few lines of text you can put in the motion.conf.
The feature may have more options than is really needed. If this is an existing feature is may be a candidate for simplification.
New features added at this level are only accepted if:
- The advantage and the gain from adding the feature is significant.
- People that do not need it can leave it unset and live happily with a fully working system.
- The feature is fully documented in the Motion Guide. And before that in the patch topic or a special TWiki topic about the proposed feature.
The conversion specifiers used in the filenames and on_xxxx features is a good example of this. It is a little more complex than it should be and requires a lot of documentation in the Motion Guide. But the advantages of the feature are so great to many people that it is worth it.
Nerd factor higher than 4 will normally not be accepted.
5
The feature is no longer newbie friendly and may scare people away from even trying Motion.
The documentation is not adequate or too difficult to read without knowing a lot of technical background.
The feature has a few of the following properties:
- The feature is only need by very few people. Maybe only YOU.
- The feature interacts with the other features and maybe change their behaviour in an unpredictable way.
- The feature only works when other feature options are set to very specific values.
- The feature depends on external applications that are not automatically installed as part of the Motion installation.
- The feature does not have some good default values that are known to work for most people.
- The option name is confusing.
- The option name is made from acronyms.
- The option name is ambiguous and could mean many other things
- The option name could cover another already existing feature (example gap vs. minimum_gap).
- The feature requires more options. Motion has more than 100 config options now. A new user has to decide if each one of them is relevant for him and Motion is already a pretty scary first time acquaintance.
There are many existing features in Motion that are at this level and need to be improved. This is not an excuse for adding more too-nerdy features.
6
Like level 5 but probably with more of the listed bad properties. The feature is so scary that most will never even try to use it. The presence of the feature has a negative impact on the general use of Motion.
Documentation is either not there or it is close to impossible to explain what the feature does. The feature approaches the "you can read the code and see what it does" level.
The feature starts being so unique and strange that you have to compile a special version of Motion to use it. You cannot let this feature be part of a standard debian package or RPM because the dependencies are beyond what you normally find in a distribution. And we are talking about more than just installing some -devel packages like the ones for MySQL and PostgresSQL.
Example: the XMLRPC-C used in 3.1.20 is probably between level 5 and 6 when it comes to installation. The httpd interface is based on standard libraries and the user nerd level needed to use it is 2.
7
Following the trend of level 5 and 6.
The feature scares away people from trying Motion. Even the other Motion programmers have difficulty understanding how to use the feature.
Even compiling Motion and getting it to work may be a challenge. The dependencies may need more non-standard dependencies. Installing an RPM is close to impossible.
Documentation is not there. Even reading the code does not help because there are no useful comments in it.
The new code that implements the features alters the function of the existing code in an unpredictable way.
8
It becomes difficult to put words on the nerdiness now.
KennethLavrsen does not understand the feature or the code that implements it and it gets rejected just based on this simple fact.
Not a single soul can ever document the feature in a way that normal people can understand.
The options suggested completely lacks any intuition.
The feature turns Motion into a patchwork where the user has to figure out how to get the bits and pieces working together.
Motion can now do fantastic things but only 10-20 users are actually able to make it work.
9
The feature proposed requires that the users more or less need to be able to program to make it work.
The user will need to know how kernel modules work. The user needs to know advanced protocols. He must know how to setup pipes, TCP/IP sockets even to get the normal features working.
Motion has become a nightmare and the project is doomed.
10
No-one understands anything. Your proposal is incomprehensible and makes no sense at all. Maybe if you try again we will understand and the nerd factor can drop to an acceptable level.
"Do you remember all the op-codes of 386 by heart?"
"Naturally the average user can write the assembler code needed to get a camera working."
"Yes I know it is not easy but it is so smart"
"Look at my nice new code - isn't that smart? No I have not written any documentation. I do not like to write words - only code. Just read the 10000 lines of uncommented C-code and you will see how brilliant I am".
"I know my feature breaks other things but you can easily fix that or we can just release a special version of Motion with my feature working and the rest broken".
Sorry if I offend someone by giving them a nerd factor 10.
This Nerdometer and its nerd factor is meant mostly as FUN. But it is also a serious signal to current and future developers to remember that user friendliness, documentation (both in code and on the Motion TWiki) and making things simple is high priority in the way we manage the Motion project.
Last not least. I,
KennethLavrsen, consider myself being a
nerd trying to stay at an average round level 2-3. It is good to be a little nerdy.
--
KennethLavrsen - 29 May 2005