On 3 Nov 2011, at 00:46, Mouse wrote:
Well, the first thing is that (a) it must be possible
to get it out of
reverse video and (b) it must be usable in that mode. Large areas of
bright on the screen are not something I can get along with. ((b)
I have the same problem I think. Can't stand black on white. It hurts by eyes.
seems self-evident, but there are a depressing number
that satisfy (a) but end up breaking somehow when that's done,
typically by displaying important things black-on-black or some
operational equivalent such as very-dark-blue-on-black.)
No, we don't have reverse video, but it is not black on white for the most part.
Thanks for the idea though, I'll make a note of that.
The next most important thing (in your case, see my
next paragraph) is
that the GUI must not be the only way to do things. GUIs are pretty
much useless as components and mostly demand a user to drive them.
This makes it impossible to, for example, script operation with input
and/or output redirected.
Absolutely. We also offer a command line tool that can be used for this.
As it happens, we recently added preliminary support for scripting of the GUI so you can
get the best of both worlds.
You write that the GUI "just uses the existing
software supplied", so
this is mostly a non-issue in your case, at least provided that
existing software is documented (which I wish I could assume it is but
have far too often run into cases where it isn't; what you've said
elsewhere makes me think this isn't an issue in your case either).
Yes, I don't think I used any non-public info. It's all in the manual that comes
with the product, and testing against it of course. The flux transition plots could be
produced from the stream format document (well, actually, the stream format document was
created while implementing support for them in the GUI).
Third is that it must not force me to bounce back and
forth between the
mouse and the keyboard. I can deal with - indeed, I've written -
interfaces that are entirely, or almost entirely, mouse-driven. Ditto
keyboard-driven. But interfaces apparently written under either the
assumption that I have a third hand for the mouse or the assumption
that I type with only one hand kill whatever productivity I might
otherwise have had under them.
The most recent version is mostly fine in this regard. I use it mainly via keyboard when
developing. I'm sure there can be improvements though - for example, I am not sure the
configuration screens are easily navigatable by keyboard (although I am sure it works).
The GUI was
designed to be extremely easy to use, even for
non-technical people such as those in libraries and archives.
This may be an issue. Easy to use for novices usually means crippling
for experts. (Usually. I'm sure there are exceptions; indeed, I think
I've seen a few, though I can't think of any offhand.) Again, perhaps
it's just me, but, historically speaking, I usually find it takes
fairly little time for me to become expert enough to be frustrated by
"you don't need to know that" (or, more accurately, "we don't
should want to know that") interfaces.
Well, that depends on what you need to know. We try to put the complexity out of sight
rather than hiding it. There are a few minor features missing though, that is true.
I'm not sure if there is anything we "hide" - we show pretty much everything
that the command line version shows - just in a different way. I am (partly) a user
interface developer professionally, so simple UI's is important to my sense of well
It would be
nice to document it completely as you want, but we have
very limited resources, and unless there is much demand for
something, we would find it hard to prioritise it. I think you might
agree that your requirement is a little unusual... :)
Oh, certainly. I'm not under any delusion that my ideal system is
likely to be forthcoming anytime soon!
I think this initially refered to the firmware protocol being documented. We should
certainly do that, again factoring in our priorities.
However, your suggestions are very useful, and we could improve in some of these areas.
But, you did ask. :)
Yes, and thank you for taking the time to explain!