Please have a look and think about it

[Gerrie Myburg [ MTN - Innovation Centre ]]

I have been having a look at open for business and think that the system
has a great deal of potential. The only problem that I have is quit
minor and I think worthy of serious consideration. I think that the main
impression that an end user will have of open for business is one of
slight inconsistencies.

 

These inconsistencies manifest themselves in the form that warning and
error messages are displayed and the way that the interaction with the
application is enforced. I have been looking at the code and it is clear
that most of the problems are caused by the way that some of the code
has been written. The manifestation of the problems are:

 

* Inconsistencies in the way that messages are dealt with. Some of
the messages are hard coded and others are taken from the resource
files.

 

* Exception messages are displayed to the user in a pretty 'raw'
form. If I were an end user and were to see some of these exception
messages I would run away in absolute horror.

 

* Look and feel differs between modules. As one example, the
Accounting module main screen is totally different to the rest of the
modules. The problem does not just stop there. The look and feel between
some of the basic screens also differs inside one given module.

 

* No online help is available in any form whatever. Any end user
that is not an expert in the field would have no idea what is going on
with some of the forms.

 

* Data validation has some problems. The validation seems to be
done on the server side. At one point I could enter negative values in
an integer field that should only be able to accept positive values.

 

I know that the maxim of "however get the vision get the job" holds in
the case of collaborative systems. But I cannot do anything unless there
is some or other consensus that the issues that I am raising need
addressing. If we can start a discussion on these questions then we
might consider a code freeze on some modules, clean up the modules then
carry on like this until these issues are resolved.

 

If this is to be done then it also implies that there might have to be a
rethink of the standards and the way that the standards are enforced. It
serves no purpose to clear away existing issues just the confronted by
the same issues at some later date.



NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/disclaimer

[Jacopo Cappellato]

Hi Gerrie,

and thanks for your comments.
Please see my inline comments:

Gerrie Myburg [ MTN - Innovation Centre ] wrote:

> I have been having a look at open for business and think that the system
> has a great deal of potential. The only problem that I have is quit
> minor and I think worthy of serious consideration. I think that the main
> impression that an end user will have of open for business is one of
> slight inconsistencies.
>
>  
>
> These inconsistencies manifest themselves in the form that warning and
> error messages are displayed and the way that the interaction with the
> application is enforced. I have been looking at the code and it is clear
> that most of the problems are caused by the way that some of the code
> has been written. The manifestation of the problems are:
>
>  
>
> * Inconsistencies in the way that messages are dealt with. Some of
> the messages are hard coded and others are taken from the resource
> files.
>

This is a known issue: the i18n effort is far from complete even if it
is a slowly progressing task. But there is no need for a code freeze in
order to fix this: it's just a matter of moving the hardcoded messages
to the properties files and send a patch.

>  
>
> * Exception messages are displayed to the user in a pretty 'raw'
> form. If I were an end user and were to see some of these exception
> messages I would run away in absolute horror.
>

I agree with you that having a way to configure the detail level of the
error messages would be a nice feature to have; if you want to work on
it, or if you have a patch to submit, you could attach it to the
following Jira issue:

https://issues.apache.org/jira/browse/OFBIZ-255

But again, I don't see a reason for a code freeze for this.

>  
>
> * Look and feel differs between modules. As one example, the
> Accounting module main screen is totally different to the rest of the
> modules. The problem does not just stop there. The look and feel between
> some of the basic screens also differs inside one given module.
>
>  

Mostly all the components already use the same CSS styles... but yes the
older screens still needs to be cleaned up a lot.

>
> * No online help is available in any form whatever. Any end user
> that is not an expert in the field would have no idea what is going on
> with some of the forms.
>

Search for the archives for discussions about documentation and online
helps...

>  
>
> * Data validation has some problems. The validation seems to be
> done on the server side. At one point I could enter negative values in
> an integer field that should only be able to accept positive values.
>

Data validation on the server side is probably the safest option
available: you'll find an interesting discussion about this subject in
the mailing list (happened a few days ago).

>  
>
> I know that the maxim of "however get the vision get the job" holds in
> the case of collaborative systems. But I cannot do anything unless there
> is some or other consensus that the issues that I am raising need
> addressing. If we can start a discussion on these questions then we
> might consider a code freeze on some modules, clean up the modules then
> carry on like this until these issues are resolved.
>

In my opinion, many of the above points are interesting, but none of
them will really need a code freeze to be implemented (just someone
willing to work on them).

>  
>
> If this is to be done then it also implies that there might have to be a
> rethink of the standards and the way that the standards are enforced. It
> serves no purpose to clear away existing issues just the confronted by
> the same issues at some later date.
>

What standards would you like to see enforced?

Thanks,

Jacopo

>
>
> NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/disclaimer
>
>