[OFBiz] Dev - UI mutations, system promotion and other stories...

[David E. Jones]

Ean, (and others),

I've enjoyed reading through these messages. It's always refreshing in 
a way to step back and re-evaluate how to do things without the burden 
of what is already in place. That doesn't mean I think considering what 
is in place should be left out when implementing the new ideas, but 
stepping back during brainstorming and design is "inestimably" 
valuable....

There are other things in this thread but I'm seeing 2 main themes that 
seem important for the progression and general design of OFBiz:

1. Easier administration of customer/public facing content, preferably 
through the browser or some other real-time remote server interaction 
(like webdav)
2. Design goals of the administrative user interfaces, ie generic and 
"complete" versus task/goal oriented (a good point brought up in this 
last message)

Some thoughts/comments on these, including why some things are the way 
they currently are in OFBiz or rather the intentions during the 
creation of these things:

1. This has come up a few times in the history of OFBiz, and in my 
opinion being able to modify certain parts of public and customer 
facing sites it's a great idea and one that a lot of people ask for. At 
one point we were in discussions with eInnovation in Cincinnati to 
integrate WSPublisher (now OpenEdit) into OFBiz, but they eventually 
pulled back and were flaky over the licensing so it never worked out...

The Content Management stuff was brought up in this context, and some 
effort has been put into moving it in this direction, but it is most 
certainly not finished and the tools that were meant to facilitate this 
application of the infrastructure was never really cleaned up for real 
use. What I'm referring to is the Layout editor in the Content Manager, 
and certainly not the raw Content and DataResource pages (which have a 
couple of design issues, and a couple of things are broken, but they 
generally work...).

This approach is very easy for small companies, or sites that are 
administered by a small group of people. For larger groups and more 
constraints things get hairy... Permissions for editing and viewing, 
revision management, trial and production deployments, etc, etc.

This is great for managing some content on a site, but in my opinion 
quite a bit of a pain for certain other things, especially things that 
are very dynamic. In general some things make very good sense to put in 
the database, but I hate having code in the database for the most part 
because it is so difficult to keep synchronized with other things, to 
edit and do global searches, etc. Of course, all of this can be done 
but now you don't have any of the common tools to use, you have develop 
your own for every single little thing...

2. There's no question that in general the administrative applications 
in OFBiz are VERY generic and are not helpful for guiding the user 
through specific tasks. Some things will guide you through small sets 
of steps, but for the most part people do seem to have a hard time 
getting used to where to find things or where to get started with 
specific tasks they need to do.

The problem with the approach of trying to define simple and limited 
user interfaces that are oriented to specific tasks is that (like Ean 
started hinting at)

1. they become highly redundant (ie lots of screens that deal with a 
specific entity like ProductFeatureAppl or WorkEffortRole, or even 
worse for the "top level" entities like Product, Party, and Content)
2. you end up with TONS of them in a project that is trying to be 
fairly universally applicable like OFBiz which means lots of work to 
develop and maintain, more confusion when trying to figure out not only 
how but WHAT to customize...

My thoughts on this right now are that we should keep the UI's fairly 
generic in OFBiz and to facilitate their use by writing role and task 
oriented documentation that in essence describes where to go and what 
to do when you want to accomplish certain tasks or goals.

That is the intention behind the design and organization of the 
"Application Overview for Users" document in the Undersun on-line 
documentation. And yes, we do charge for that because it is NOT 
necessary to use OFBiz but it does make it easier for various types of 
users to use, and we have a technical writer that is more or less 
dedicated to this. Actually, so far there has been so little money and 
so many complaints about a company that is not affiliated with OFBiz 
doing such a thing that I'm tempted to drop charging for it and just 
open it up. I don't for 2 reasons: 1. spite over the complaints, 2. 
there would be so much load on the server that we couldn't live with 
what we have now and would need another server (or 2).

Another thing related to this, and going right back in some cases to 
the commercial side of the world... is the idea of creating derivative 
works of OFBiz that basically amount to applications that ARE designed 
to be role and task oriented with user interfaces very customized to a 
certain way of doing things and for managing certain types of data. 
Creating these things basically amounts to creating forms with a lot of 
"ignored" fields, and stringing them together in wizard type things, 
plus creating special ways to view or visualize the data, which usually 
have links that represent starting points for tasks related to specific 
data.

This is a nice approach that makes things much easier for users. The 
"specialized" folder in OFBiz has some applications going in this 
direction that are really pretty good. This also opens up a huge world 
of commercial opportunity to create full-featured applications for 
specific types of businesses, or really full-featured solutions that 
can include support and other things that most companies need but can't 
do for themselves, and often can't afford in face of the large 
licensing fees required to acquire the access to the functionality they 
need.

Okay, now I'm blabbing on....

-David



On Apr 4, 2005, at 3:52 AM, Ean Schuessler wrote:

> I would like changes to be even more direct. I think a common problem 
> that we
> have (and this occurs in many places) is that the admin interfaces are 
> geared
> to people who are basically at the level of knowledge of the 
> programmers. The
> interfaces are easy enough to use but almost uniformly I find that 
> clients
> are very intimidated until they receive some training.
>
> The Wiki interface, on the other hand, usually requires little more 
> than a 2
> minute demonstration before users are eager to give it a try. That is 
> the
> reaction I'm looking for as opposed to the current content management
> interface.
>
> I think we need to look for ways to make things more "peel the onion"
> oriented. Make interfaces high-level and task centric, exposing people 
> only
> to what they need to achieve common tasks. The danger, of course, is 
> the
> Microsoft phenomena where things are easy until they get hard and then 
> they
> are very hard. How exactly to avoid that isn't entirely clear to me.
>
> Am I rambling?
>
> On Thursday 31 March 2005 12:12 pm, Adrian Crum wrote:
>> I was picturing developers using whatever tools they're familiar with 
>> -
>> using their local FS, then going to an OFBiz webpage to "commit" those
>> changes to OFBiz. The "commit" process would scoop up the changes from
>> the local FS and put them in the DB. What motivated that idea was the
>> "restarting the webserver" problem. But as you point out, it doesn't
>> make it any easier for developers otherwise.
>
> -- 
> Ean Schuessler, CTO
> Brainfood, Inc.
> http://www.brainfood.com
>
> _______________________________________________
> Dev mailing list
> Dev at lists.ofbiz.org
> http://lists.ofbiz.org/mailman/listinfo/dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2363 bytes
Desc: not available
Url : http://lists.ofbiz.org/pipermail/dev/attachments/20050406/23ac88a0/smime-0001.bin