[haiku-commits] Re: haiku: hrev44039 - src/kits/interface headers/os/interface src/preferences/keymap
- From: John Scipione <jscipione@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 18 Apr 2012 15:41:42 -0400
Now that the emotional side is out of the way, let's get down to the nuts and
bolts of the matter.
On Wed, Apr 18, 2012 at 4:36 AM, Stephan Aßmus <superstippi@xxxxxx> wrote:
> You are right that these apps don't use standard buttons. But in fact I have
> changed the look in MediaPlayer from the old *non-consistent* BeOS look to
> be consistent with the Haiku BButton style while at the same time providing
> a nice, uncluttered interface by merging the buttons together.
Or, as I look at it, you changed it to resemble an real-life media player that
has it's buttons merged together to save space, see my response to Ingo below
for more details on this.
> CD-Player may use non-standard buttons, but it was also updated to at least
> use the BButton rendering for the frames to improve consistency. It used to
> have ugly, non-consistent buttons.
>
> So while you absolutely have a point that Haiku is nowhere as consistent as
> Axel made it sound in his initial reply, the conclusion might be different
> still: Instead of introducing more (unnecessary) inconsistency (which I am
> *not* accusing you of), the consistency of Haiku can further be improved.
> For example by merging CD-Player into MediaPlayer or using the same button
> implementation in it as is already used in MediaPlayer. For example, I have
> adjusted Clockwerk, an external application, to use the same buttons as
> MediaPlayer to improve overall consistency. Another example where glaring
> inconsistency should be fixed is SoundRecorder. It still uses the old BeOS
> transport button look that has nothing to do with the normal Haiku button
> look.
What I see when I look at CD Player is an app designed to look like the front
panel of a compact disc player, and that is emoted by more than just the look
of the buttons, the time signature controls also add to the effect.
Similarly when I look at Media Player what I see is an application designed
to look like the front panel of a hardware media player, perhaps an in-dash
automobile mp3 player or perhaps something that would be found in your home
entertainment center. Again, this is more than just about the buttons, the
green status bar and green in the volume slider also emote that as well.
I am not criticizing the authors of these apps for making these design
choices, instead I am praising them for their work to make these apps
resemble the real-life devices they are meant to emulate while still feeling
like Haiku applications which provide the expected behavior for these
controls. The fact that they look a bit different than standard is not a
problem, it is a good thing, it helps familiarity.
Axel is a proponent of a consistency philosophy that has never existed on
any release of Haiku or BeOS. The design concepts were set into motion on BeOS
before him and without his consent and continue despite his disapproval. In
short, I appeal to a higher power than Axel, the programmers at Be who set
this whole adventure into motion. (I don't claim to know God's stance on the
matter).
On Wed, Apr 18, 2012 at 10:37 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> I'm not sure the same argument applies to Keymap and DeskCalc. The layout
> Keymap displays is explicitly intended to resemble *your* keyboard's layout
> so it easier for you to match the keys. So this part of the application is
> indeed supposed to match a real world device. I don't think the same applies
> to DeskCalc (and why it doesn't use the standard color scheme is unknown to
> me).
So, Keymap, which emulates a real world device, a keyboard, is okay, but,
Deskcalc which also emulates a real world device, a desktop calculator, is
not. Let me go ahead and disagree with you there. Both emulate real world
devices, and, as I've tried to express, in those instances in Haiku the design
standard as exemplified by Media Player and CD Player and the volume sliders
and all the other examples I provided earlier is to provide stylistic guides
to the user for these kinds of apps to give them a sense of familiarity with
the analogous real world device when appropriate.
> That aside, I do find the rounded corners more pleasant to look at for large
> arrays of buttons, i.e. in both cases.
I agree with this, although that is not really the point here since Axel's
complaint was not that the rounded corners looked bad, but that they are
not consistent with the rest of the interface. I am trying to show that this
is not true, that it is consistent because of the standard set by apps
in the base system and 3rd party apps as well.
Axel is defending a consistency philosophy that exists only in his mind. Like
with the style issue that aren't documented anywhere he brings up from
time-to-time, I have trouble reading Axel's mind and consequently make the
mistake of not following these unwritten rules.
This is a source of great frustration for me. This is a problem that should
be fixed by writing and maintaining clear and concise guidelines that lay
out the salient points. The coding style guide is a good example, and should
be updated to reflect new and/or previously undocumented rules. If this
discussion does nothing but help to produce a similar style guidelines
document for application developers we will all win. It's important to know
where we stand on these issues.
>> Similarly Media Player, which also emulates a real-world device does not
>> use standard BButtons either. The buttons are different and the sliders are
>> different. In fact that apps looks totally different then any other app.
>> Which is a good thing, the design expresses the idea that the author
>> intended. The old design even featured rounded corners on it's buttons.
>
> I would think the reason why MediaPlayer looks like it does is less because
> it tries to look like a real world device, but rather to achieve a very
> compact GUI.
Or another interpretation, the interpretation that I took, is that Media Player
looks like this because it is emulating a real-world device that has it's
buttons squished together in order to save limited physical space. You see
this trick used all the time in hardware devices.
And, that's a bogus reason to design Media Player with squished together
buttons if you weren't emulating a real-world device, you have plenty of space
to work with, no reason to squish the buttons together like that. And that
explanation doesn't account for the greenish tint to the status bar nor the
greenish tint in the volume slider either. The most obvious reason (to me
anyway) is that these design choices were made is to emulate the look of a
real-world device. The compact GUI argument simply doesn't hold water when you
consider the overall design of the look of the app.
Let me reiterate this to make it clear. I am not criticizing the author of
media player for his or her design choices. The app looks and works great.
I am simply pointing out that the reason that the design choices were
made in that app were to emulate the look of a real-life media player, and
that this is a good thing deserving of praise, not a bad thing deserving
criticism.
>> Look at the slider bars in the Media preferences to set your volumes which
>> emulate the look of sliders on hardware mixer device and are inconsistent
>> with the look of sliders elsewhere in the interface.
>
> Those sliders are actually multi channel sliders. That aside, all these are
> examples of controls for a special purposes (media control buttons, volume
> sliders). I don't mind those looking different from their general purpose
> counterparts, as long as they are used consistently throughout the system
> (and third-party apps).
Be that as it may, the design of the sliders certainly look like the sliders
found on a hardware mixer to me. And the connection between volume sliders
and a hardware mixer are obvious to me. So, either I am way off base here, or
this connection was made intentionally.
>> Look at Pulse, which emulates the LED displays found on the cases of many
>> computers (including the BeBox I am guessing) which looks like no other app.
>>
>> Look at the clock app that doesn't use any standard controls at all,
>> instead builds it own to emulate another real-world device, in this case, a
>> clock.
>
> Both applications are demos, fun applications that we've inherited from BeOS.
Be that as it may, they are in the base system and therefore legitimate
examples to use for this argument. Perhaps Axel grudgingly accepts these apps
as getting a pass, grandfathered into as an exception to his idea of how Haiku
should be designed.
>> Given all these examples it would be inconsistent for me to NOT attempt to
>> style these interface elements to look a bit more like the device they are
>> meant to emulate. Either that or the developers of the above applications
>> all made this same mistake I did.
>
> I do indeed think that is the case. There seems to be some tendency to mimic
> real world devices where they exist. Particularly in case of audio/media/dvd
> players there are indescribable horrors out there, which only allow for the
> implication that someone chose form over function (combined with bad taste).
So you at least can see where I'm coming from here even if you disagree with
my argument and conclusions. If I am confused, it is for a good reason, the
choices made in the apps in the base system that have real-world analogs seem
to have design choices associated with the real-world analog. There is no
document that contradicts this, all I have to go on is what I see.
> I don't think it is advantageous to mimic a real world device's look just for
> the sake of it. Mimicking the interface concept -- if it is superior -- is
> another thing.
I can agree with that, and this line of thinking can go too far as well. Look
at QuickTime before the X version for example, that app had non-standard
controls and the such and it just looked and worked horrible. The designer
went too far and failed to achieve the goal of simultaneously giving design
clues that make the interface familiar while still maintaining the
expectations that the controls have a similar function to other apps in the
system. But that doesn't mean that these kinds of changes should be outright
banned and told to be reverted without even giving them a look.
Thanks for listening,
John Scipione
Other related posts:
