pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GUI questions


From: Ben Pfaff
Subject: GUI questions
Date: Mon, 01 Oct 2007 22:10:29 -0700
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

My attempt at a DESCRIPTIVES dialog box has prompted some
questions.  The first one is well posed by jmd, who writes in
comment #1 on patch #6219:

> Putting all the options in a treeview is a good idea. However
> it departs from the user interface of the Chicargo company's
> software. I've been tending to follow their UI fairly closely,
> even though it sometimes conflicts with the Gtk/Gnome HIG. I
> guess at some stage we should decide upon some semi-formal
> policy here.

The main reason that I departed from the Chicago GUI design is
that I haven't actually used its GUI any more than to figure out
how to make it run my syntax files, and didn't look up how its
DESCRIPTIVES dialog box looks before I designed mine.  (I don't
have a license for it, either, and no easy access to anyone
else's copy.)

The reason I left out Z-scores from my initial DESCRIPTIVES
dialog design was that I didn't think that they made any logical
sense there.  It seems to be that they should be on the Transform
menu, or at least in a separate "Compute Z-Scores" menu item
under Analyze|Descriptive Statistics.  They're only a part of the
DESCRIPTIVES procedure because it's convenient to put them there,
not because it makes a lot of sense from a UI perspective.  But
moving them to a new menu item could also confuse users who
expect them to be in the old place.

I wonder what everyone thinks about designing a "good" GUI (at
least, one that we think is good) versus designing one that works
the same way.  Do you think that users will be confused by the
changes, or do you think that they will appreciate any
improvements that we make?  It is hard for me to guess.  It is a
little like OpenOffice.org vs MS Office: OO.o can improve the
interface all they like, but MS Office users won't appreciate it,
because they're used to MS Office.

That's my main philosophical question.  I have a couple of barely
related technical ones too.  First, should we use psppire.glade
for everything, as done so far, or should we use a separate glade
file for each dialog?  Based on my experience thus far, my guess
is that if two of us try to modify psppire.glade in separate
check-ins, there are going to be massive conflicts.  The patch
file that I posted looks pretty clean, but that's only because I
edited out, by hand, a lot of superfluous changes that glade-3
made throughout the rest of psppire.glade (even though I didn't
change anything in the rest of the file).  Conflicts are a lot
less likely if we break things up, since most changes would be to
different .glade files.

Second, there are a bunch of constraints on procedures, and I
don't know the level at which we should apply them.  For
examples, procedures can't run without any data, so should we
gray out the Analyze menu until there's data?  Furthermore,
specific procedures have more stringent requirements; for
example, DESCRIPTIVES needs at least one numeric variable,
CROSSTABS needs at least two variables (for any sensible
results), and so on.  Should that be implemented by graying out
menu items, by displaying an error dialog if the menu item is
selected, or another way?  Finally, there are constraints on what
can be selected in a procedure before it can be invoked; e.g. for
DESCRIPTIVES it's necessary to select at least one variable
before clicking on Paste or OK.  How should this be enforced?

I think that's all for now.  Happy to hear opinions on these.

Ben
-- 
"A computer is a state machine.
 Threads are for people who cant [sic] program state machines."
--Alan Cox




reply via email to

[Prev in Thread] Current Thread [Next in Thread]