[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: Summary: User Interface Standards
From:       "Andrew B. Arthur" <arthur99 () global2000 ! net>
Date:       1999-09-15 21:53:01
[Download RAW message or body]

> DIALOGS:

> I know the current content isn't very good. Currently there's a
> discussion how to order the buttons. I personally (!) agree that we
> should have OK always on the most left (user reads from left to
> right...). But I don't want to change the current standard, if the new
> solution is only a small improvement, but we have to change 100 existing
> applications, which respected the old standard...

Your section on dialogs versus application is quite confusing. Personally, I
dislike your claiming that all apps fit into two categories, dialogs and
document-centric apps.

Basically, I think of a dialog as something that is called up from inside an
application -- an dialog is never a separate application, except for
extremely rare cases were dialogs are stored in separate binaries to be more
modular or to organize things. Such an example would be embedded capplets
like kcontrol's panels or kicker's panel. I would group dialogs in to a set
of groups for standards: File Open/Close/Save Ones (called from the KDE
libs), Print (again called from KDE libs), preferences (typically
multi-paned windows with all of the apps' options), and custom (for things
that are application specific, such as paragraph formatting in KWord).

Okay, I see two type of KDE applications that a user typically launches. One
type are Full Featured Applications and the others are basically Applets,
Accessories, or whatever you want to call them.

*** Accessory Application

For an application to be considered a accessory application it needs to be
small, fast, and uses no menus or button bars. They simply don't need them
-- they accomplish the task using simple easy to use buttons (that are the
central interface of the app, not a button bar) that are clear to
understand. Classic examples would be kcalc, kmp3, kppp and kscd. This
applications are designed not to be the focus of the user, but something a
user uses once and a while (or leaves on the screen most of the time), but
doesn't need full featured functionality or large memory-using apps.


How do you know your Application is an Accessory Application?

- Small and Simple, Tight Programming is Your Game.
- Nothing but buttons are needed to control it.
- It represents a real thing, examples are kscd represents a CD Player,
kcalc represents are calculator.
- Not enough options to add a menu bar and buttons
- There is almost no text editing involved in this application -- the most
involved is filling in small strings for settings -- and these are not to be
in the main application window, but in a dialog inside of the app..

*** Full Featured Application / Document-Centric

I would say this makes up of 95% of all apps you will use this interface --
don't dare use an accessory application-like Interface on a Full Featured
Application -- otherwise your interface becomes confusing, cryptic and hard
to use (example kfind). Kfind also suffers from it should not use a tab
dialog in the main interface, and the start search button is impossible to
find.

Basically the standards for these look about right now, and stick with
these. One important point about Full Featured Applications, they should not
under any circumstances have a button that doesn't have a matching menu
option.

How do you know your Application is Full Featured?

- You use at least one dialog in your app called from a menu.
- You need to give your users special options.
- You need to display more then 50 characters worth of data.
- You edit a document.
- You pass the user important data about were something is.

I hope you see where I am coming from. Please cc: any comments to me at
arthur99@global2000.net because I have really bad lag in mail from
kde-look@kde.org.


Thanks,

Andrew Arthur a.k.a. AArthur
arthur99@global2000.net
AIM: arthur998

[prev in list] [next in list] [prev in thread] [next in thread]