David E Jones wrote:
The general idea is an interesting one, ie of really separating things by role
and eliminating dependencies.
I like the stuff you guys at Brainfood have done with WebSlinger, and it
certainly makes things easier for people in certain roles.
Webslinger definitely makes certain things easier but it also destroys
the portability proposition of the widget system. We are currently
looking at supporting form widgets as a native document type in
webslinger, which may restore some of that portability.
One thing I have been curious about is building a XUL renderer, which
should be pretty thin.
In a way I wonder if points #1 and #2 that I listed above are actually possible. My theory
over the years is that they are simply not possible, and all attempts are guaranteed to fall
short because those requirements are not "internally consistent". It would be
interesting to have a well-funded R&D project to get feedback from a bunch of people,
assemble a number of possible designs, then implement and test those designs in various
organizations. I'm not sure if that will ever happen, and I suppose even if it did the
winning design would probably be so biased by politicking that the stated result might not be
accurate.
Actually I think this is essentially going on and has for some time. I
think the difficulty of the problem is why there are so many "web
frameworks". There is no clear solution so people keep throwing things
up to see if they will stick.
I think the fundamental disconnect is analogous to automobile body
design -vs- powertrain design. On the one hand, you have people that
want to draw pictures of awesome looking cars and on the other hand you
have people who want to tackle physics problems to deliver power in a
system. Making those things blend together seamlessly, as you indicated,
requires an understanding of all the principals involved. Great
industrial design combines the intuition of art with the rigid demands
of engineering and you can't really get one or the other for free.
Anyway, it's a tough problem. The main issues I see are kind of like what you
listed Ean, namely:
1. different organizations have different roles and different skills sets, so
to be effective you'd really need to document a variety of organizations and
combinations of skill sets and be flexible enough to address at least a few of
the most common ones, or the ones that should be most easy for an organization
to assemble
2. it's not possible to completely eliminate dependencies between what
different people in different roles are doing; there might be some things you
could do to either mitigate (handle automatically or transparently/implicitly)
or obviate (fail fast/early) the problems, but these dependencies are an
inherent part of what is being built and IMO they simply cannot be totally
eliminated, especially if you want reusable parts of the screens, etc
My favorite approach so far to getting people to handle this well is to divide
front-end developers into those who are mostly visually talented, and those who
have gotten into scripting and such too. These people will have to get used to
working together in order to get things done, IMO. From time to time you'll run
into a person that is great at both, but not usually. Those who are into
scripting and working with straight HTML can usually get into using the OFBiz
widgets and FTL templates and do quite well with them (and without very much
training too). But that isn't everyone, and you certainly need someone who can
break things down and implement the technical things to drive them.
Some tools make this easier, and therefore require less technical knowledge, but those
tools typically also restrict what you can do. If you want to keep it cheap and simple
then that's great, just do what the tool makes easy. If you really want to be able to
design and build anything that is "internally consistent" then you're going to
need more flexible tools and more knowledgeable people.
Or am I wrong and the silver bullet solution does exist and I just haven't yet
had the pleasure of experiencing it?
Even HTML is almost still too far into the engineering realm. The truly
beautiful tool is Photoshop, which makes the process of image creation
almost totally artistic and lets you forget that you are manipulating
data structures. In the free software world, Inkscape is actually quite
impressive in this way. You can totally forget that you are manipulating
SVG and simply draw. There is really no analog for this in the HTML
world, especially because of CSS.
In some ways, SquareSpace.com's online web design tool approaches what
I'd like to see a tool do, though it introduces many limitations. I'd
encourage everyone to look at its demo video. If we could provide a CMS
tool that acts like that and expose the power of the OFBiz business
logic into it, the world would be ours.
Hopefully this time I'm less snarky, without being too depressing... :)
A tough problem can be fun.
