Regarding the button image question...I would tend to agree with you
myself, but then you have the added problem of what to do when you have a
toggle that performs a similar function, but one not actually seen in anyway
by the user...for example, a toggle to turn encryption on/off! I've used a
single speedbutton for this with two glyphs...one showing an unlocked lock (
it's default setting ), and another showing it locked ( it's depressed state
). The problem gets worse when you have both these quite different needs in
the same application, and possibly even on the same form or toolbar!
Consistency is sometimes more important on an application level than general
method don't you think? So if I employ the standard method of showing what
will be if clicked, then when the user looks at the button which changes
configuration, because he can see the current configuration it's okay, but
then he looks at the encryption button and if the same technique is used
thinks encryption is already on! Of course using the button's depressed
state can solve the problem as far as the encryption toggle is concerned,
but you really can't use it in the other case because you're dealing with
four possible values! All would be depressed! So perhaps this leads one to
consider that such a button is NOT the right control for this particular
event...or that the event itself must be altered so that it can be! Perhaps
it would be much better to use an "average" glyph on this four-way
button...one that shows an image not depicting any of the particular choices
to be made, but symbolizing the over-all purpose of the control. Then when
clicked the four choices, each with their own image appear...possibly in a
dropdown menu...from which the user can make a choice directly without
having to switch across those actions he or she doesn't even want to see!
Now you might ask why not use four separate but indexed buttons of which
only one can ever be in a depressed, "on", state. That IS the solution it
seems that most applications use. Just take a look at any word processor
and no doubt you'll see three buttons for font style and three more for text
alignment!. But I believe that another solution exists...one that doesn't
use so much screen real-estate, and one that doesn't add to the already
overwhelming number of controls our applications require! And that solution
involves the categorization of available controls into groups that can be
expanded/shown intelligently...as needed...or hidden away when not. Such
methods are already in use via menus, and unpinned control bars, but they've
hardly been exploited to the degree they can be!
I've been looking for examples using alternate solutions for needs
like this but so far have come up empty so if anyone has thoughts on this
please respond!
As to the other design questions, I've just about finished the paper
I was writing that this was culled from, however before continuing with it
here I'd really like to get more responses. It may be of no interest to
anyone OR it may just be the time of year...the holidays...that have kept
others from responding. So I will wait a bit before finishing this. But I
do wish to say in answer to the comment below that it seems I didn't get my
point across correctly.
My comment about a singular monitor being best was not meant to
describe an optimum solution, but the one we must design for! Whether a
user has one, two or four monitors, we must design multi-form applications
in such a way that the user has the choice of where they may go on the
screen in any particular situation, and if that means spreading them all out
over four different monitors so that he or she can use them equally without
needing to open/close/minimize/restore than lucky for them! But we
certainly cannot design for this possibility! We must design the app so
that it can be used in an optimum way where there is but one single monitor
available! And so the needs of the single monitor user must be given first
consideration. As an example, do forms 1 and 3 need to be seen at the same
time? And if so, are we going to size them so that the user has to
constantly juggle back and forth between them using the taskbar and/or
systems buttons, or are we to design the interface so that all concurrently
needed info is available on screen at the same time...either by combining
into one form or resizing along the horizontal axis so that both fit
properly? When you look at these important questions in terms of the aspect
ratio of the standard monitor and then compare them to what is possible on a
wide aspect monitor the problem increases because you would really like to
be able to give the user of the latter an added benefit of some type that
takes advantage of this extra screen real estate without hampering the
majority of users. In fact do we not owe it to our audience to do so when
ever possible? I believe we do just as much as I believe we must provide
for high-end graphics cards and their abilities even though the majority of
users are still using a model built three years ago! Game companies know
the value in this. And it is one of the main spearheads of technological
innovation! Part of our job is to give our users something to reach for,
and as far as I've been able to tell, the advent of wide aspect monitors has
not yet been embraced in any substantial way.
from Robert Meek dba Tangentals Design
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Kovács László
Sent: Monday, January 02, 2006 6:04 AM
To: Delphi-Talk Discussion List
Subject: Re: Interface design
Hi,
----- Original Message -----
From: "Robert Meek" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, December 31, 2005 7:23 PM
Subject: Interface design
> TAction's ImageIndex at each click of the button. But should the glyph
> seen
> at anytime reflect the current style that the interface is set to OR
> should
> it reflect what the style will be IF the user clicks it? I've seen
> programs
----------
I'd choose the second one, so it should reflect the style which will be
activated IF it is clicked.
I'd expect this behavior in general, since the actual style is in front of
my eyes,
since I'm looking at it...
Or am I wrong?
----------
> Now some might argue that the more common use of multiple monitors
> can provide a great and positive quality that we as programmers can use in
> the design of our applications to better the way in which we evaluate and
> interact with the information being presented , and that by means of
> stacking and/or row banking we can allow for a lot more leeway in the
> design
> of visual presentations then they yet have. However the ONLY way that can
> be true is if the boundary edges of aligned monitors are first made
> visually
> inconsequential! Then the total working area and it's overall width and
> height could make it possible to substantially alter
> presentation...especially when that presentation may call for more than
> one form in view!
---------------
In some cases having more monitors is a life saver.
(See below), but if you design your interface
think of people who has only one.
---------------
> But as it is now, the apparent edges of tangent monitors
> causes such distraction to the eye that any value gained is just as
> immediately lost! And that doesn't even take into account the
> requirements
> of keeping each monitor in "phase" with each other so that slight
> differences in contrast, acuity, and image centering do not further the
> visual disjunction that can so easily occur!
> Taking these things into account it's easy to see that under ANY
> circumstances one singular monitor is by far much better than any multiple
> setup possible. And if one agrees with this, then it's also apparent that
-----------
I disagree with this.
As long as you don't want the multiple monitors to see only one
virtual monitor (just like windows does it with "extend desktop" function)
definitely not.
Treat the extra monitors as extra monitors, and than it's OK to use.
I give some examples:
1. You are a programmer, and you have to debug an app., on monitor
A you see your debugging IDE (may be Delphi ;)) on monitor B you see
your app.'s output window.
2. In most of my time I do video editing work, and it's very nice to have
the currently edited video's preview in fullscreen on monitor B, while I can
see the editor (different controls, timline, etc.) on monitor A.
So the key is that the "more than one" monitor should not to
"want to look like one monitor".
In this case we can benefit from having multiple monitors.
------------
All these above are just my honest opinion, the truth may differ.
;)
By(t)e
Laca
www.kovacslt.fw.hu
mailto:[EMAIL PROTECTED]
__________________________________________________
Delphi-Talk mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi-talk
__________________________________________________
Delphi-Talk mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi-talk
