On Sun, May 31, 2015 at 01:54:50PM +0000, Arnt Gulbrandsen wrote:
> If I may... If you google me you will find old old reasons to hate
> me, and those reasons are connected to GUIs. I do know one or two
> thinks about the subject.
>
> It is possible to make a good GUI that is separated from its
> functionality in the manner many contributors to this thread are
> thinking of. But it has a touch of RFC1925 compliance: "Pigs fly
> just fine, given sufficient thrust." Committees like to design such
> things, implementing them is hard work.
>
> An example may make it clearer:
>
> You have all seen disabled menu items. Those often correspond to CLI
> switches that lead to error messages in a given situation. But there
> is a difference: using the CLI switched lead to an error message
> when the user issues a command, while the menu items have to be
> disabled before the user issues the command.
>
> A GUI generally needs much closer contact with the object it
> manipulates before it issues a command than a CLI does. The CLI
> needs better error error reporting for actions that fail, the GUI
> needs much more information ahead of time... if it is to be good.
> There are other differences as well, e.g. good GUIs divide complex
> operations up into simpler ones in a manner that does not quite
> resemble good CLIs.

Yes, clearly the interface that a GUI uses needs to be designed to
facilitate interaction. But it us probaby a mistake to design it along
the lines of one command = one mouse click. You'd want this
programmatic interface to have the data gathering and imperative tools
that any decent API would have.

How to present this to the user and interpret her intentions is the
proper domain of user-interface design. Making sure that the
information needed is accessible is the proper domain for API design.
The two are different.

-- hendrik

>
> Writing sucky code is easy. But who wants to do that.
>
> Arnt