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

List:       kde-usability
Subject:    Re: Unknown application's dialog
From:       Peter Gostelow <peter () grandad ! co ! za>
Date:       2002-07-07 20:56:57
[Download RAW message or body]

On Sat 06 July 2002 20:18, Irwin K wrote:
> On Saturday 06 July 2002 01:48 pm, Irwin K wrote:
>
> I've thought a little more about this and asking the user afterward if the
> file opened successfully might not be such a bad idea.  If it's done, KDE
> can register the file type as the application that it was opened with,
> preventing any future instances where this file is opened.

That would be fantastic. I worked this into my thoughts further on. But, KDE 
can never find a mime type for every unknown file. The question is, how much 
effort should be spent before giving up? Should KDE do anything about 
orphaned files scattered about the system?

>
> It also fits the model more naturally: instead of checking, "Use this
> application always" before selecting the application, you get to see the
> results first, and THEN you can say, "Yes, I like this result.  Use this
> application always."
>
> The task analysis is brief and is included in the mail as an attachment for
> those who might want to review it.  Comments and criticisms are invited.

I kinda said things backwards and gave reasons after making nonsensical 
statements, but I hope when you get to the end you won't think I wasted your 
time.

The crux of the matter, as I see it, is the User *thinks* Data files are Apps 
_because_ you can click on both of them and they 'open'. When that doesn't 
happen, the User doesn't _understand_ the problem, gets confused, and panics. 
We know you can't run data files directly, but Users usually don't.

<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>

We can be honest with the User about data files, and still have them 
'runable'. Just make _sure_ the User understands data icons and bin icons are 
_not_ the same (show mime type?). Maybe flash a 'Launching kate for 
myfile.txt., click stop to abort.', when data icon is clicked. Puzzled users 
might query why that sometimes happens _before_ tragedy hits and the tears 
start. Have the option to turn it off.

(Thought: icon text format app::file, or ?!?::file, e.g. kate::foo.txt (run 
foo.txt with kate), or ?!?::blah.foo (no App, must DnD) )

Consequently, dressing up the 'pick an app for this file' dialog doesn't 
answer the User's question, 'Why should I have to, what's all the fuss 
about?'. We know why, but didn't tell the User. If confused, it's a bad time 
to start explaining. It might seem like we're passing blame, or trying to 
hide something (we are, but harmlessly).

So, try to figure out an App when the file is dropped on the Desktop. At that 
point you have, the Desktop, the File, the App, and the Right User (!!).

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).

The desktop can then ask the App if it will _accept_ files of its own type. 
Apps like kmail may refuse, kate will accept. When all else fails, prompt the 
User. At least the User will know there is a problem +before+ the file is 
dropped and may choose not to.

At this point we know the App won't launch the file, so we now look for 
another App. It will still DnD without an App and the User might want this, 
so lets see if we can go ahead with DnD only.

Prompt User with, 'Do you want to open <File name> when you click on it?'. If 
yes, we're in trouble, but lets try anyway. So throw up an icon view of all 
apps with title, 'Choose the program you want to open <File name>'. We reject 
apps that don't accept the mime type (we know its mime type since we're busy 
dropping it), so we're left with those that do. Hopefully, there won't be 
many and the User will know them. We don't catagorise them, just show them.

(I think picking an App when we drop to the Desktop is better than when we 
launch because we at least know the mime type. Apps won't have to crunch the 
data to guess.)

If there are absolutely no matching Apps, then just maybe default to a binary 
editor, at least the User can look at the file (without breaking the App!) 
and not grumble too much. If it is broken, the bin editor will show that and 
is aurguably the best tool to fix it.

Hmm...maybe all this could be a walk through wizard? At least that can explain 
with pics and text what's going on. Or is that overkill? We can turn off 
wizard, too (Kcenter/DnD), with expected results.

Anyway, the yes/no follows, so the file may not have an App to launch. If not, 
at least we're prepared. If the User clicks an App we accept it and our 
problems are (hopefully) over.

The file is eventually dropped and the DnD is completed.

Finally, an unknown file type (or problem with the App, missing, aborted..etc) 
on the desktop will never, ever launch when clicked. period. The User who 
tries to open the file may not be the same as the one who dropped it. It's 
unfair to expect one User to figure out what another was thinking:)

Instead of launching, when the User clicks a data file of unknown type:

Prompt the user, 'Can't open <Data File name>, but you can Drag 'n Drop'.

At this point, the User knows:
1- There is a problem,
2- Knows how to dragndrop (okay assumed, but easy to explain, right?),
3- How to run Apps.

Therefore, the User can pick an app as they _normally_ do, and DnD the file.  
(Currently, you reclick and scratch for another App, so letting the User do 
it from the Desktop is not that bad. Also, the User knows the Desktop 
better.)

At this point the User has found an App for us, so if it accepts the mime 
type, we just need the User to tell us whether to always use it.

On first drop, prompt User, 'Should I always use <App name> for <File name>?', 
and fix the mime type. If not, well, leave it DnD only.

Note: Don't prompt until after the App has accepted the drop, but before it 
_is_ dropped. That way, we know the app can read the type?

Next time user clicks it, it runs! The computer appears to 'learn' while the 
user keeps working.

Suggestion:
A power user can select mime type from properties and then launch it. Okay, 
the properties mime type is the exec file, not the .desktop mime type. Gah! 
You know what I mean?

Comments. We can use the same wizard ('Launch Assistant'?) where ever we need 
it.

The goals are:
1- Avoid dropping unknown file types on the Desktop. (In fact, anywhere)

2- Work with what the User already knows (dnd).

3- Don't change the way the User does things (icons,wizard is ok?).

4- Avoid saying 'mime types', rather 'these need that'.

5- Hide the details, let the User _show_ what goes with what.

Technical issues remaining:
1- Qt will only DnD a known mime type?

2- Apps accept (don't validate) the dropped data?

3- The User's minimum skill/experience?

hope that made sense,
Peter

_______________________________________________
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]