as far as intuitive it goes beyond programs and programming. it is driven by learning curve. against cost. the harder it is learn the more it cost to use. I started the battle in the early 80's Made a lot of money, programming forms the way the office worked. and this idea between program Architects and business has been going before that with IBM and their clunky programs.
Jacques Le Roux sent the following on 8/31/2008 1:07 AM: > From: "David E. Jones" <[EMAIL PROTECTED]> >> 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). > > I totally agree. I also remember this fine idea I read one day of having > different dynamic UI levels. From newbie to expert with as much as > intermediate levels as needed. This is not so hard to achieve (using a > preference menu) but I have seen only a handful of softwares designed > that way. OFBiz OOTB could use this idea, using preferences in my page > for instance ... > >> 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. > > Yes, but users often prefer the intuitive way of doing things (MS DOS vs > MAC for an history reference). You can't change them so you have to > adapt. This does not mean to adapt OFBiz OOTB of course... > I remember we had a similar discussion about date-time representation. > We mostly agree that a sortable format is better, but from international > users POVs it's not the same... > >> 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. > > Yes I see, like it's done in Len Silverston's book volume 2 (that's a > good example to remember) > >> 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. > > I guess people (I included) will claim it's a lack of time, but often > future shows it was rather short viewed. > > "Nécessité fait loi" (I can't find a better expression to summarize. In > English : Necessity knows no laws) > > Jacques > >> -David >> >> > > > >
