discuss: consistency in KDE GUI

[Aaron J. Seigo]

On Friday 22 December 2006 14:39, Big O wrote:
> On 12/22/06, Friedrich W. H. Kossebau <friedrich.w.h at kossebau.de> wrote:
> > Am Freitag, 22. Dezember 2006 15:10, schrieb Orville Bennett:
> > > On Dec 22, 2006, at 8:57 AM, Friedrich W. H. Kossebau wrote:
> > > > Hi,
> > > >
> > > > Am Freitag, 22. Dezember 2006 14:47, schrieb Orville Bennett:
> > > >> On Dec 22, 2006, at 1:12 AM, subbukk wrote:
> > > >>> Should KDE core libs be engineered to encourage (or enforce) this
> > > >>> consistency?
> > > >>
> > > >> How do you encourage consistency with a set of libraries? I can see
> > > >> how you could enforce this, but "therein lies the path to
> > > >> destruction my son."
> > > >
> > > > Oh. What do you mean by this?
> > >
> > > By forcing someone to conform to your standards of what is best, you
> > > encourage them to go elsewhere.
>
> (WARNING: The following statements are based on nothing more than
> supposition and wild speculation.)
> Now that that's taken care of...
>
> > Unless you give good arguments for the standard :)
>
> I think even when you give good arguments for the standard someone
> will still want/need to change them because a) Your "standard" has
> become outdated. b) someone just doesn't like it. Your standard, while
> appropriate for you may not be appropriate for everyone else. Now if
> you're saying KDE should just focus on itself and isn't a platform for
> developing independent apps, then this discussion is moot.
>
> > And giving the developer a default implementation in terms of a lib also
> > helps things to be done more quickly.
> > E.g. noone is forced to use a QPushButton. But don't we all use it?
> > Because it get's us a button that does nearly all in the way that makes
> > sense?
> >
> > > Some applications violate certain
> > > aspects of the HIG as it stands, and will probably continue to do so
> > > in the future.
> >
> > Are you sure they all violate by decision? Perhaps some developers simply
> > concetrated on other things, those which were the itch they want to
> > scratch. And just made a quick'n'dirty implementation for the things that
> > had to be done, too. Because there was no default (implementation).
>
> Let's look at amarok. The menubar, as of 1.4 has no File entry. It
> says Engage. WTH does that means w/ respect to audio playback?
> Nothing. Not one single, solitary thing. Now I look at that, chuckle,
> say "Cool". And go on playing my music. Another user may groan, say
> "Ugh." in disgust and continue playing music. Inevitably, we both
> eventually will want to find out what the heck is up there. And so
> slowly, but surely, we reach. And we may find something we've never
> seen before. I believe that's when I noticed last.fm radio
> integration.
>
> So in this case, and we'll say it was intentional, the developers have
> found a sly way to introduce new functionality to both new and
> experienced users. "But Orville" you say, "surely you read the release
> anouncement on the dot." Yes, I did. And promptly forgot everything
> therein soon after. I mean, sure I know the amarok devs have a
> penchant for the flashy, and that this was probably some gimmicky way
> of announcing the "launching" of 1.4, in tune with the release
> codenames.
> But what about those who don't read the dot. or the release
> announcements, or just installed a distro and want to play some music.
> The windows users trying out the amarok live CD or their first linux
> distro won't necessarily see the codename tie in. He sees the file
> menu and may go there or not. But "Engage", it piques an interest. It
> draws you. It interacts with you. Well, you get the idea. And before
> you know it, you've discovered something. Maybe you'll use it, maybe
> not, but it's permanently etched in your mind.
> It also looks far better than File in big red letters. That's just annoying
> :-)
>
> > > If compliance were forced upon them they could choose
> > > in the begin, they could easily have chosen another platform to
> > > develop on, if it's forced after, they could choose to spend valuable
> > > time trying to undo this instead of contributing to their respective
> > > apps. And that, that would be a shame.
> >
> > Sure. :) But I don't see your point here. If they don't want to feel
> > forced by using the convenience libs (which "enforce" the standard), they
> > would have to implement the things anyway on their own. So what would
> > they loose?
>
> Freedom? 

i don't see what freedom a developer loses here. you know, other than making 
the user experience suck.

> Convenience libs can provide convenience while still offering 
> the choice to deviate from the norm if desired. 

sure; any app is free to supply their own Configure Shortcuts dialog, for 
instance, even today.

> KDE can still dictate 
> policy (and enforce with avengeance) in it's own apps, as well it
> should. 

=)

> But to enforce this _in the libs_ is to unnecessarily 
> restrict those who may seek to use the platform.

we've always enforced these things in the libs. never been a problem; in fact 
it's been a blessing. why?

a) it creates similarity between apps that our users LOVE (and that's why we 
create software: to be used, ergo for users; that includes us)
b) it saves HUGE amounts of time, both today and down the road.

e.g. when we get to reworking the application shorcuts systems we likely won't 
have to touch one line in any application. a recompile and every app will 
have a nicer configure shortcuts dialog that is consistent with every other 
one.

look at other platforms where they have to invest amazing amounts of effort to 
keep things looking similar and still end up a soupy mess.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-quality/attachments/20061222/bb6f4451/attachment-0001.pgp