CiviCRM Community Forums (archive)

This is an old saying: keep it simple and stupid (kiss)

There is a lot of cleverness and ingeniuity going into the code of civicrm. The downside to this is higher complexity and less easy adaptability.

Some examples:
- Login to standalone has been linked to openid. However clever the idea my users have to learn one more and different way of logging in. It does not make it simpler but adds to the difficulty to learn to use the system. And there is little chance for them to come accross another openid login system soon.
- civicrm uses smarty templating. I like the idea of separating business logic and presentation. Only the implementation is turning out to be complicated because the template has so many if's to map the if's of the logic that you need to understand the logic for being able to change the template. So the whole idea just leads to more complexity.


I would like to see
I would strongly recommend to make the user gui much more easily adaptable. Ever customer of my various homepages will use the civicrm in different ways. They need a simple way to adapt. In simple I mean something a non programmer with some html knowledge can handle. This is clearly not the case at the moment.
Or take the menu. It is most cleverly made, constructed from a database. But it is  not easily adaptable. For example there exists a page to enter events registration manually instead of online (for those cases where a participant has no email or just meets the responsible person to settle the registration over the counter). This function is not included in the menu. Why? Most probably because it is too complex to add. Only by chance you hear from an insider that such a function exists.

I do request an easier form of localisation. The ideas are good. But in reality it is complex and heavy.
Let me give an example:
I have worked for many hours translating civicrm into German. At present version 2.0 is 37%, version 2.1 is 41% but we have version 2.2 almost ready. Every version adds some 15% more, at the moment we are at about 50000 Characters. There seems to be no chance to catch up (I do translation professionally and can translate at the speed my fingertyping will allow). A system that is alway just about 50% translated is not acceptable to users that are not fluent in English!!
It does not end there. Creating own templates and user interfaces, how to include those in the translation files?


In summary
In my opinion civicrm should concentrate on a well established core system and an easy and well documented way to integrate into other systems, including functions and widgets to make it possible (API and Hooks are documented, but integration into an other system still needs reverse engineering to do it). 

Most of the actual user interface should be left to the user as the needs are so vastly diverse. Instad of trying to understand a current solution and trying to modify it he should be able to concentrate on his issue and create the gui himself using the civicrm core.
I can see the advantage of new ideas, but is it really an advantage if I have just to add another input form (in html takes me 2h, learning to understand and apply the new method will demand 10h and not being a programmer the person will not profit from the gained knowledge further on), is this the right path to go? At least for me (beeing a web programmer) with such a system I would have been much faster in achieving a running system for the user.

hallo xavier

I hope you understood the central point of my message: kiss

Openid is a very good idea. But if you are forced to use it in civicrm standalone, wether you have your own openid server or not, the effect for the users is the same: additional complexity..

Concerning translation: I use at the moment about half the functions of civicrm. If I could selectively translate only those parts (for an initial effort) I would habe much a bigger chance to finish the translating into German. Despite Switzerland having as its fourth language English my customers will not accept "Swinglish" (mixture of English and Swiss-German). On top I will have to get it translated to French, also an language in Switzerland. A big part are the explanations and help texts (about 50% of the translation effort). Everything that concerns the webmaster, English good enough, I have not found any webmaster that does have good knowledge in English. I guess this is more than halve  the effort.
Adding both I am sure to reduce the effort to 30% of what it is now.
On top explanations show is a marked difference between American and German. They are also different if your clientel are nerds or dummies. Putting those into a wiki webmasters can chose to use what there is or add some of their own.

I am fully aware that all I need to do can be done with civicrm. However my experience in the IT (35years) tells me, that any product that grew to complicated failed to get wide adoption. The core Ideas of civicrm are really good that I hate to see it fail out of excess complexity