Re: [Boa Constr] Interface comments

[Bernhard R. <ber...@in...>]

Hi Riaan,
thanks for the prompt reply.=20
I will try to answer and explain as much as I can.

Note that every program need one principal designer.
And you are the designer for boa.=20
It is not my intention to give you advice which necesarrily=20
is best and would lead to the best results, because you have to
decide and it is better get one consistant system instead of
a patchwork by multiple people.
I am trying to discuss some of the design principle and I do have
some experience with IDEs and developing interfaces.

Talking about Borland, I have a couple of years ago stopped to deal
with their products, because they never were excelent. Just because
VB and Delphi are very popular does not mean that they are well
designed. It is no argument, it is just that most people have not
bothered to do better.

To actually really improve Boa, I would need to have the time to do a full
examination on the interface, which I have not. So I hope that my
sometimes half baked comments might be at least inspiring.



On Tue, Jan 16, 2001 at 02:48:10AM +0200, Riaan Booysen wrote:
> Bernhard Reiter wrote:

> > My comments are attached. Generally: Boa feels too big.

> Sorry to have to tell you this but Boa will get bigger still.

My problem is not that it is big, but it feels big. :)
Of course bigger programs are harder to make right on all edges.
Smaller programs can be tested more thoroughly, but you'll know.
I was just suprised that you started adding thinks for tasks were
other tasks could not relyably be done. Trying to do all in once
is likely to be very hard and likely to fail.
Despide this you have done a nice job and I am not complaining.

> I definitely agree with your later statements though, that users who=20
> do not need specific functionality should be able to turn it off.

This would definetly help.
Main reason that Boa feels so big is that you are not guided enough
through all the different actions you can take. This does not mean
you have to limit the power user of course.

Having the possibility of opening more than one frame designer and
more than one collections editor seems to be overkill from my point
of view.

> I have quite a clear vision of what Boa is and where it's going.
> Some of the things that you see as weaknesses, I see as strengths.

Naturally.
But you have to expect that boa might never become a tool which is
good for many people. (Which is my goal in helping to improve it.)
And we are in free software, we can have many versions.
Maybe boa-constructor-imperator (the big version) and
boa-constructor orophias (the small island version). :)

> Boa is not just a Frame Designer, it aims to be an Python IDE
> supporting as many Python technologies as possible that aid the
> development process.

I know. Integrated tools are harder to maintain and improve.=20
Of course we all use a tool-box and it is very nice to have all the
tools fit together.

> Also I've adopted quite a few conventions from Delphi. They may not
> all seem intuitive to someone who has not used Delphi, but would
> to someone who has (I hope!).

I cannot tell. But maybe delphi users will.
But python is certainly different from Delphi and you can adopt
different conventions when you want it.
As the designer you probably do not have any problem learning your
own conventions.=20

> > It was much more stable this time than last time.
> Thanks, but also thanks to Kevin Gill and Shane Hathaway.
Thanks Kevin and Shane.

> > ps.: My wxPython article in German in
> > http://www.sw-development.de/deutsch/magazin/magazin.html
>=20
> I wish I could read it, but my German is worse than my Prolog :)
> Babelfish will probably not do it justice, but I'd like to try if you
> could mail me a copy.

The article is not online. :(
I still have to put it online and work things out with the
publisher. (They are new in the market, it was the first issue.)
Boa is only mentioned very brief.

> > and its mentioning of Boa was well received.
> I'd love to read some of the feedback.

Most of it was not in writing.
Tom Schwaller of famous the German "LinuxMagazin" told me that you
wanted to try Boa now. He always wanted to, but I was faster. ;-)

We already agreed on a).

> >         b)
> >=20
> > It should be possible to use a different editor.

> To what degree of integration? With which editors?=20
> I'm editor agnostic.=20

Nedit, (g)vim and (x)emacs come to mind.
It should be nice to have a documented way on how to use a different
editor. It is mostly a reminder so you think about it in your design
decisions.

> To a certain degree you can already use a different editor, just
> save after posting changes. Will it be sufficient if Boa could detect
> when another application saved changes to a module and prompt to
> reload?=20

This would be a start!

> This way (if the other editor also detects when Boa saves)
> you should be able to easily switch between Boa and your favourite=20
> editor.

Yes! Maybe you should enable it that an external command can be
configured and run when Boa changes the code. So the editor can be
triggered.  This is the most basic integration, but it should be
useful.

> >         c)

> > There are too many GUI rules to learn.=20
> > First it looks like I can have most windows I will need on my screen and
> > I just use notebook-like tabs to switch between them.  The frame design=
er
> > window obviously deviates from this rule.
>=20
> This is the way Delphi does it. I definitely prefer this to the VB like
> frame in a window editing style.

This is okay, IMO.

> > But Collection editors break it somehow.=20

> Also like in Delphi, collection editors have their own windows.

That you can open more than one of course explains this.
I would vote against having more that one open at a time.

> > They are a submenu of the=20
> > inspector and the post and chancel buttons of the inspector are not
> > ghosted (visibly disabled).
>=20
> They should not be disabled, they should actually post and close all
> Designers. This has been fixed.=20

Okay.

> > On the other hand the properties of the objects in the collection
> > editor do again appear in the inspector, but now I cannot use the post
> > or chancel buttons. There is no button to use now. This was suprising
> > for me, I consider it unintuitive.
>=20
> As far as I understand you, this has been fixed.

Okay.

> > I suggest to place the collectors editor on screen from the beginning.

> All of them?=20

Well just one. But as I said I have not yet find the situations to
actually find it useful to have more than one open.

> On a busy frame there might be quite a few! Remember you
> are also not limited in the number of Designers which you have open.
> This is not practical.=20
> I think it's better to open them as needed.=20

I agree, when you have multiple windows open.
I though that the collection editor is to be used only once and then
commited and closed.

> > (You might want to use the up to now unused space over the editor window
> > and make the main window a bit slimmer.)
>=20
> Which unused space? I ran out of space a long time ago :)

Depends on your screen. I was talking about what show up as upper
main window on my screen. It is quite empty in the right side, here.

> > When editing collection properties I suggest to open another inspector.
>=20
> I don't agree. The inspector shows the currently selected item from
> which ever Designer (Frame, Data or Collection) that you selected last.
> I do agree that Designers should unselect their selection if something=20
> is selected in another Designer. It's on the todo.

Okay.

> >         d)
> >=20
> > I was also severly confused by the options of the elements in the main
> > window and the places were I can use these element.=20
>=20
> This is probably confusing at first because different pages behave
> differently, but is explained on the Palette page of the application=20
> help (slightly out of date).=20

It there is the possibility to make it more intuitive without
reading help I think it would be appreciated.

> > It seems a good idea
> > to me to disable the options when I am not allowed to use them.
>=20
> This is not technically correct, because the palette's control pages
> work on the concept of 'loading' your cursor (the action will only be=20
> completed once you click in a receptive window) you can actually
> select a button to be added before you even open the Designer.
> Only the the Dialogs palette page require that you have source view=20
> open before clicking on a button.
>=20
> > Like Disable application, when I am in the Frame Designer.
>=20
> Feel free to create as many Application modules when you have the
> Frame Designer open. There is nothing illegal about that.

I get it know. IMO the normal way of actions should be limited.
This probably guides almost all users better. Why not change this
"loading" the pointer concept. It is also getting in the way when
you need to create like three buttons and so on. This would allow
you to just disable and enable the palette selection. I would regard
this as a use usability advantage.

> > Disable Zope, when there is no Zope connection.
> > And so on.
>=20
> The Zope palette also work on the 'loading' principle. But I agree that=
=20
> it should not be there if the user has Zope support turned off.

Agreed.

> > It will reduce the choises and help to focus on the work.
> > The less options a user has, the higher the chance that he will select
> > the right one.
> >=20
> >         e)
> >=20
> > The current keyboard accelerators=20
> > should be shown in the menus entries, behind the label.
>=20
> wxPython does not yet support the standard right aligned accelerators
> and I was hoping for them to appear before adding this.

Okay. Nice.
(To my shame I must admit that I forgot to thoroughly check the TODO list.)

> I've just added the accelerator after the menu between <> brackets.

Nice.

> >         f)
> >=20
> > If you need a sort of commit button to make a change in a window
> > permanent, it should look the same for each window (including subwindow=
s.)
>=20
> If you are refering to commiting changes in a view (e.g. the Source=20
> control) to the model this is always Refresh.
> Commiting changes from the model to the disk is always Save ;)
> Commiting changes to all GUI building windows is Post.
>=20
> Do you want refreshing your source to also be done with a Post button?
>=20
> Each is different, even though technically the GUI builders are views
> which commit changes to the model, they run in a session which freezes
> the other views until the session is either commited or cancelled.

See this is very complicated. Why not make it simpler and all
concepts the same. Not thinking very deeply about I guess that it
can be done.

> >         g) (almost an addition to c) )
> >=20
> > The big part of a good inspector is, that you can inspect each
> > object with it.  When using Boa I had the impression that the
> > main control point is the inspector once I have pressed a button
> > in a frame to design it.  So I always have to get back to the
> > inspector to commit my changes to do something else.
> >=20
> > Sometimes the main control point for my subsequent action will
> > again change the windows to the main window (like editing
> > something in Data.)
>=20
> I don't really understand you here, could you please rephrase.

It is about what to do next and the role of the inspector.
In NeXTStep an inspector was just there to inspect any selected
object, no matter what it was. So the object metaphor held.

Boa does not seem to make it this way, because of the cancel and
post buttons. AS I learned from your mail, these buttons do actually
close all designers. The inspector can inspect various objects, why
are they in the same window? (As you can see, it did confuse me. :))

I assumed that the changes made in the inspector will be posted,
when I press the post button and thrown away, when I do not press
the post button. For inspecting collection object properties, this
does not hold.

> >         h)=20
> >=20
> > It would be nice if Zope and CVS capabilties=20
> > could each completly be switched off.
>=20
> OK, but is CVS really that intrusive?=20

Yes. It is just the overwhelming=20
capabilities that should be switched off by default.

> You won't know about CVS unless=20
> you choose to go into a CVS folder, and when you do, the view is so
> much more useful than seeing Entries, Repository and Root files.

Well I was fearing as with some integrated system, that there will
be some intelligence acting and I do not know what will happen.

> Thanks for your comments and article!

You are welcome, thanks for sharing Boa.
I guess that Boa will get much more popular in the future.
(Did you btw clear up the bugs in the bug-tracker sometimes?)

Best,
	Bernhard

--=20
Professional Service around Free Software                (intevation.net) =
=20
The FreeGIS Project                                         (freegis.org)
Association for a Free Informational Infrastructure            (ffii.org)
FSF Europe                                            (www.fsfeurope.org)