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

List:       kde-usability
Subject:    Re: Unknown application's dialog
From:       Irwin K <emerald-arcana () rogers ! com>
Date:       2002-07-08 2:39:53
[Download RAW message or body]

On Sunday 07 July 2002 04:56 pm, Peter Gostelow wrote:

> <fwiw, no comment expected>
> I think this is almost unethical. The shock of finding out that data files
> are different, can lead to confusion (as the orignal poster expressed), and
> later, possible 'I was deceived, can I trust other things?' syndrome. I've
> seen this idea on a smelly GUI, but we can clean it up, can't we?
> </fwiw>

I'll go through the rest of it in more detail tomorrow (headache right now), 
but this is interesting because Aaron stated, in context of Konqueror and 
plugins, that we should be moving toward data-centric views and not 
application-centric views, as you state here.

The model would be that there's only data and not that there's application and 
data.

We had a bunch of arguments about it since that's sort of "not the way" people 
do things in real life: when people read small print they look for a 
magnifying glass for example, rather than stopping still in dread and not 
knowing what to do.  So the idea that "magnifying glass makes me read small 
print" is theoretically applicable to computers in that "konqueror makes me 
read web pages".

But unfortunately Konqueror's not a tangible "thing" so the user simply 
understand that HTML has an associated application (worse; you read HTML with 
a web browser, AND a text editor and they look totally different).

~~

To address your ideas about DnD and mime:

I'm not sure if it's a good idea to ask about MIME types if you do a DnD.  YOu 
say the desktop, but if we do DnD for the desktop only there will start to be 
accusations that KDE isn't consistent (for example, DnD from directory to 
another).

> Before the Desktop accepts the drop, we know:
> 1- The file's mime type (from DnD itself),
> 2- Which App is the best guess (the one it came from),
> 3- This User knows what s/he's doing (lol).

What I'm getting from your list here is that the user's choosing an app for a 
file type that KDE knows... not sure if I'm making a mistake here...

We don't NEED to figure out what App to use for a Data File if the file's 
already registered with the MIME types.  So asking users to choose apps if 
the system already knows is redundant and is probably too much information 
for a user.  Power users can change the app with the "Edit File Type..." 
menu.  (If we wanted to be more usable, we could rename that to "Edit 
Application to Open this File With".... wonder if there's a shorter way to 
say that.

We should look ONLY at the case where KDE doens't have an application 
registered with the MIME type.  For cases where KDE knows, it's a breeze: it 
just fires up the correct application.

I also think it's unfair if an unknown file type simply doesn't launch.  
They'll sit there clicking wondering what's supposed to happen.  If we bring 
up the "App Picker" at least they will have a hope to select an application 
for the data file.  But not launching anything is sort of discouraging, and 
forcing the user to drag and drop seems sort of a silly action to do because 
DnD is associated with copying/moving files, and not choosing apps.

You state an assumption that the user knows how to runn Apps, but that's 
exactly one of the problems here... the user DOESN'T know what app to run 
when the App Chooser comes up.

It's more work (i.e. involves more steps and more mental models) to have to 
click on an app, be told that KDE can't open it, then open another app and 
"test" if the file can be opened in that app.

I'll look at it closer but I'm not sure that this method will solve our 
problem with users not knowing how to deal with what application to launch 
when presented with unknown filetypes.

-- 
-- Arcana  (Irwin)
_______________________________________________
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]