> For the first, I suggested that the large (overwhelming?)
> number of components and pallette pages that IBO adds to
> the IDE leads a new user wondering, "How am I gonna learn
> all this?" I therefore suggested two ways to reduce the
> number of new pages.

I wont deny that that this is correct, but I believe that it is less
important than making the components themselves easy to use and
understand. Especially since the only solution to this (that I can
see) is to make the installation/setup more difficult - so you are
trading one problem for another.

How does a user know what they require if they dont know what the
components are for? If they know what the components are for then
there is no harm in putting them on the palette (they can soon
rearrange the palette to suit themselves).

If we arbitrarily decide not to install certain sets of components
then the user may get misled into thinking the functionality does not
exist. It may be overwhelming, but I see no practical way around the
problem.

> In other words, I too do not want to see a TIB_Services
> super-component. I'd rather see separate TIB_Users, TIB_Backup,
> TIB_Gfix, etc, components.

After development practicalities, this sort of thing comes down to
taste, it just means that you dont want me to write this one :-) It
certainly does not impact me too much. If I desperately wanted an
all-in-one component it could soon be created out of the separate
components (or vise-versa for that matter).


Geoff Worboys
Telesis Computing