Jacques Le Roux wrote:
From: "BJ Freeman" <[EMAIL PROTECTED]>
I find the biggest hurdle is how to get from here to there.
the intuitive part.

Yes the UI is data centric, not human centric. There are not much ergonomy concerns so far in OFBiz. But as we all now, all is there, ready to be disclosed. How to do it is another thing. Remember that the 1st aim of OFBiz UI is to demonstrate OFBiz features...

This has been discussed enough times that I'm surprised it is still coming up...

It's not a matter of data-centric versus human-centric, it's a matter of data-centric versus process-centric and role-centric.

The most important principle to keep in mind is that in order to make something easier to use you must simplify it, or in other words you must remove as much functionality as possible, or in other words add as many constraints and assumptions as possible. In other words, you give up flexibility for the sake of simplicity (which may or may not help usability). Another important principle is that design for low-frequency use and high-frequency use are very different things (in other words you design differently for things people do rarely and things people do frequently, trading initial ease of use for efficiency over time).

The base applications in OFBiz are data-centric and intentionally inclusive. They are meant to be flexible and complete, and are not generally designed for one specific activity or another. To use OOTB people will require training, and over time people may also have to tolerate moving between various screens in order to complete an activity.

The original idea discussed behind specialpurpose applications (which has only loosely been followed) is to write applications that are designs for specific activities and processes. In order to do this those activities and processes should be defined first. What is really happening there is that things go there when they aren't sure where else to put them. For the applications that are derived from the base applications there seems to be more incremental attempts at creating something useful rather than a process of gather requirements, design according to those requirements, and then implement according to the design.

-David


Reply via email to