← Back to team overview

openerp-community team mailing list archive

Re: Usability features branches

 

On 09/16/2013 09:26 AM, "Lionel Sausin, de la part de l'équipe informatique
Numérigraphe" wrote:
Hi, Personnally, I would most appreciate if you made merge proposals to the
trunk when applicable.

I known OpenERP SA is not reactive to this type of MP's (I have made quite a
 few myself that not been reviewed for months/years). Even though, I remain
 convinced that most of this this belongs to the core. Maybe if the
community reviewer made a first review it would help the R&D team process
the MP's faster ?

One thing that's easily overlooked is that OpenERP is a very complex piece of software, and the R&D team spent *a lot* of efforts during the last few years in order to simplify it for new users. That is the single most important criterion when it comes to usability, which is a highly subjective topic in the first place. So if the trade-off is to require an extra tweak for advanced cases vs having first-time users be puzzled over a field's meaning, the balance will be in favor of the former, in most cases. Because you won't ever get to the advanced case if the user can't finish the first workflow. And generic trumps specific, of course.

So when it comes to MPs, it will really depend on the kind of "fix". Some improvements would be acceptable in trunk (with an appropriate priority), and you can assess that yourself in most cases: is it completely generic, is it likely to puzzle first-time users, etc.

For the rest, it might be better to put them in extra modules and offer a configuration interface similar to v7's "Settings" checkboxes, possibly via an index module, as Niels suggests. But you should watch out for updatability - a stable series ideally requires modules to be frozen at the data model level, and this won't be the case if you need to add an extra column in the settings model whenever you add a "tweak" module.

Perhaps you could do this via a module naming convention or module category naming convention? Let's say your "index module" adds an extra Settings page: it could dynamically generate checkboxes to install any local module that matches the given prefix or belongs to the special category. The module summary and [sub]category could be sufficient to present a meaningful config page without actually needing to install the modules, and without changing the actual data model when a new module is available.
It sounds like a lot of overhead to manage a few tweaks, though.


Follow ups

References