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

List:       kde-usability
Subject:    Re: Usability Strategy Discussion
From:       Peter Gostelow <peter () grandad ! co ! za>
Date:       2002-07-06 14:34:17
[Download RAW message or body]

On Sat 06 July 2002 05:56, Aaron J. Seigo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday 05 July 2002 09:33, Peter Gostelow wrote:
> > 1- The KDE project is neither commercial nor market driven, but a fun
> > thing people like to do in their spare time.
>
> for SuSe, mandrake and others it is indeed a commercial thing. and it is
> market driven, only its market isn't guaged by people trading in dollars
> for bits. and it is a fun thing some people like to do in their spare time.
>
> it's all three!

Heh, I see you changed the meanings, but I get some of them. I feel more 
comfortable discussing a subject after the definitions have been cleared up.

>
> > 2- Whatever public value KDE has, its real value depends on the
> > developers.
>
> twist: the public can become developers (which includes writing code,
> writing docs, translating, testing, helping w/bugs, websites, etcetc) ..
> the barrier only exists where people in the "public" put it.
>

Again, a shift in meaning. I used 'public' to refer to those who don't use or 
develop KDE at all. The public has views about KDE and gives it some value 
based on whatever they read or heard. Now, are those values important, or the 
developers? There is strong public pressure to alter KDE's chosen path and 
they should resist it, imho.

> > 3- KDE emulates a single user desktop on multiuser server/client network
> > POSIX compliant operating systems.
>
> hrm.. i don't think so. seeing as all my network resources are accessable
> quite transparently to me (fish:// anyone?) and i can (and do) run apps as
> different users and have dozens of open terminals and have dcop tools and
> ....... no, this is simply a UI that allows me to use this multiuser
> networked system.

This is rather a tough point. Any terminal work is okay for non-gui work, such 
as accessing a gui blind, or incompatible gui, system. But a gui terminal 
isn't a login tool. We use it because there is no other way. If the gui 
understood a single user can open several accounts, it would know how to 
spawn and manage them within the gui iteself. It should allow roaming 
accounts, too, since that is native to networks. I should be able to login 
from anywhere and get my personal config.

Users have already asked about these issues, so I'm not raising anything new, 
merely suggesting where the real problem might be. Since KDE does support 
multiple desktops, it seems the obvious place to allow a user to login again. 
Then, switching desktops is equivelant to switching accounts. Whether it's 
possible to pull apps from different accounts into a single 'workspace' is 
also worth considering. Sometimes I'd like to move an app from one account to 
another because I started it from the 'wrong' one:( Yes, the shell ui doesn't 
allow this, but a gui might.

Developers are able to use the desktop model because they understand the OS 
behind it. Increasingly, however, users want to do everything from the GUI, 
without considering what goes on underneath. This will stress the single user 
model and certainly limit its capabilities from the user's viewpoint. The 
whole point is to get users away from the shell prompt, isn't it?

>
> > 4- KDE uses 3 interface conventions: X11, MacOs, and Windows.
>
> no, it uses the KDE interface conventions. there is no X11 interface, but
> you will find similarities between KDE and MacOS, Windows, BeOS, and other
> systems.

X11 uses copy-on-select and focus-on-mouseover, AFAIK, which other GUIs don't 
support. MacOS provides a single menubar which reflects the currently active 
window. Windows uses double-click to activate icons etc. Perhaps these are 
just cosmetic, but their purpose, I assume, is to loosely emulate various 
GUIs. Perhaps I overstated the point?

>
> > 5- A UI is an interface layer between the user and the computer (apps).
> > 7- A UI allows the user to access apps forming an app/user relationship.
> > 8- An app customises the UI to make the app more usable.
> > 9- A good UI offers a range of features for apps to improve their
> > usability.
>
> ok ...
>
> > 10- A GUI allows the users to imagine their work, rather than describe
> > it.
>
> i have no idea what that means =)

Sorry, that is obscure. When copying files, for example, a GUI shows pages 
thrown from one folder to another. A text UI prints, 'copying A to B' and 
possibly dots to show its progress. The GUI allows people to picture what the 
computer is doing. GUI users imagine pages being thrown from one file to 
another whenever they copy, text ui users won't (unless exposed to the idea).

An extreme case is the text game which starts, 'You stand outside a small 
building..'. Shown several pictures, no-one will ever point to a building and 
say, 'That's that game!', but write the text (describe it) and everyone will 
say, 'Yes, I played that'. Doom, otoh, cannot be described with any degree of 
accuracy - it must be seen.

>
> > The GNU/Linux was motivated by people who wanted to explore an operating
> > system with minimal restraint. The idea of presenting a graphical view of
> > a text based system is a rather interesting challenge (er, to some..).
> > The
>
> the command line is simply an interface to the underlying OS. it isn't the
> OS itself. UNIX in not synonymous with "the command line", it is one part
> of the system. the fact that the two are held in the same breath is really
> a testament to the completeness and power of the command line as
> implemented in UNIX.

Agreed, but evidently I missed making the point, perhaps 'text oriented' is 
clearer. Almost all files are stored in plain text and most tools (awk, grep, 
yacc, lex, etc) only work with text data. Unix origins began with minix (or 
some such), which stored (system) data as plain text. The idea apparently was 
to allow changes using a line editor. The printing system only printed plain 
text, too, hence my describing Unix as a text 'oriented' system. With few 
exceptions, that philosophy still exists (e.g. .desktop files). Moving from 
line editors to screen editors etc. relied on ansi (or similar) standards, 
which still used text (ansi strings) to do the work. HTML and SQL probably 
continue the same idea (i.e. human readable).

So, to me, the idea of providing real graphics using binary streams/bitmaps is 
a radical depature from the original view. The core system still remains 
'text oriented'. I think there is a trend for Linux to support graphics, such 
as the frame buffer, but that is far removed from a 'pure' GUI OS. I see a 
clear distinction between using an OS to develop graphic apps and a graphical 
OS.

>
> > fact that _other_ people want to actually _use_ it, is largely
> > accidental.
>
> no, not accidental at all. it was created  to be used, the driving force
> was not for academic meandering and testing of theories.

Point taken. However, I was referring to the same public, as noted above. Was 
the driving force to allow Unix users to have a GUI, or pursuade all users to 
use Unix because it has a better GUI? Somehow, I expect a both answer:)

>
> > incompatibility exists, is it reasonable to question KDE's usability when
> > the system itself hasn't found a 'user market'?
>
> it has a market: the hundreds of thousands (i read millions somewhere?) who
> use it. the market found it. strange, i know.

Yes...what was I thinking? Probably that the market isn't static and those 
joining it bring different usability issues which makes usability a moving 
target. A well defined market that simply expands or shrinks in number is 
easier to identify than one with rapidly evolving needs.

>
> > Are people raising the usabilty question because - like the hackers -
> > they finally have a free OS to explore usability issues? While a free OS
>
> perhaps some. i'm raising the usability question because i want:
>
>  A) a system i can use that is comfortable and efficient
>  B) a system that is Free(dom) that i can share with others (e.g. my
> family)

Heh, I'd like it to be intuitive, too. For some mad reason I try to 
right-click on a menu itself so I can edit it. That just feels the right 
thing to do.

>
> > However, multimedia and printing services should form part of the OS
> > itself (GNU/Linux), or the GUI driver (i.e. X11). It's possible to
> > include
>
> they do: lpr or CUPS and X ... they are part of the OS. they aren't in the
> kernel, and that's good design.

Yes, however, lpr doesn't support graphical printing very well (if I 
understand the CUPS take on it). For me, PostScript is not the answer, a 
graphical equivalent to printcap might be. CUPS is relatively new and relies 
on a browser, which is inconsistent with Unix 'behaviour' (human readable). 
Also, I dislike the 'We'll give you the system, but you must pay for the 
drivers' attitude. Is that what we should expect from KDE?

Maybe I haven't groked the printing system yet.

>
> > multimeadia as part of the user interface, but that exceeds the 'window
> > manger' definition and certainly blurs the distinction between a
> > multimeadia/printing system and a ui with that capability.
>
> of course it exceeds the window manager definition because it fits into the
> "Desktop Environment" definition.

Okay, I assumed a wm _would_ be a DE:) Somehow I expected X to support all 
multimedia needs (both audio and 3D animation etc.) and not suffer the blight 
of libs (ogg, png, mng, SDL, OpenGL, etc.). Perhaps that will happen when the 
standard wars die down.

>
> > any ongoing X11/QT/KDE discussions? As a project, KDE should have a well
> > defined scope and not exceed that by emulating missing parts other
> > sub-systems don't supply (e.g. printing) - just to make GNU/Linux
> > 'usable'.
>
> it doesn't emulate missing parts, it provides an interface to the existing
> parts. e.g. kprint is a way for the user to join up his graphical apps to
> printing services such as CUPS and lpr.

Good.

>
> > Perhaps usability hackers should have separate projects to thrash out
> > suitable approachs to Bazaar type projects before intergrating with them?
> > I
>
> nice, but i want a usable desktop and KDE is pretty damn close. i'm after
> results, nothing more.
>
> > they'll be more interested. If the project presents results to the KDE
> > team, identifying the exact problems they're trying to solve, and
> > possible alternatives they dismissed or ignored, it might advance
> > usability far more than pursuasive argument. Assuming the solutions
> > work:)
>
> hrm... well, the coding that has been done towards usability in KDE has
> been welcomed with open arms, and developers are starting to ask more about
> usability and take it seriously ... the disconnect is not as wide as it
> seems,

Excellent!

> it is closed a bit tighter with each every usability-related commit
> that happens in CVS. talk on the other hand............

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]