Alan Horkan | 1 Jun 2005 14:58
Picon
Picon
Favicon

Re: Modifiers + Scroll => Zoom, which modifiers to use?


On Mon, 30 May 2005, Christian Neumair wrote:

> Date: Mon, 30 May 2005 23:22:02 +0200
> From: Christian Neumair <chris <at> gnome-de.org>
> To: usability <at> gnome.org
> Cc: gnome.org <at> mgmiller.net
> Subject: [Usability] Modifiers + Scroll => Zoom, which modifiers to use?
>
> Bug 79352 [1] suggested that "shift-mousewheel could zoom in / out on
> nautilus views", which sounded like a good idea. Now that Nautilus HEAD
> zooms the current directory view when the user presses shift+zoom, Mike
> Miller suggested [2] to use the ctrl key as zoom-triggering scroll
> modifier, since other applications (many win apps, probably firefox or
> mozilla) have this binding. Also note that currently, Epiphany has ctrl
> +scroll bound to quick scroll (double-stepped).
>
> Windows(/FF [probably]):
> ctrl+scroll: zoom
>
> GIMP, Nautilus:
> shift+scroll: zoom
>
> we have to decide whether consistency with win is important here, or
> whether double-stepped scrolling should be bound to ctrl.
> Any opinions?
>
> [1] http://bugzilla.gnome.org/show_bug.cgi?id=79352
> [2] http://bugzilla.gnome.org/show_bug.cgi?id=79352#c8

(Continue reading)

Alan Horkan | 1 Jun 2005 15:06
Picon
Picon
Favicon

Re: Modifiers + Scroll => Zoom, which modifiers to use?


On Wed, 1 Jun 2005, Alan Horkan wrote:

> Date: Wed, 1 Jun 2005 13:58:07 +0100 (BST)
> From: Alan Horkan <horkana <at> maths.tcd.ie>
> To: Christian Neumair <chris <at> gnome-de.org>
> Cc: usability <at> gnome.org, gnome.org <at> mgmiller.net
> Subject: Re: [Usability] Modifiers + Scroll => Zoom, which modifiers to use?
>
>
> On Mon, 30 May 2005, Christian Neumair wrote:
>
> > Date: Mon, 30 May 2005 23:22:02 +0200
> > From: Christian Neumair <chris <at> gnome-de.org>
> > To: usability <at> gnome.org
> > Cc: gnome.org <at> mgmiller.net
> > Subject: [Usability] Modifiers + Scroll => Zoom, which modifiers to use?
> >
> > Bug 79352 [1] suggested that "shift-mousewheel could zoom in / out on
> > nautilus views", which sounded like a good idea. Now that Nautilus HEAD
> > zooms the current directory view when the user presses shift+zoom, Mike
> > Miller suggested [2] to use the ctrl key as zoom-triggering scroll
> > modifier, since other applications (many win apps, probably firefox or
> > mozilla) have this binding. Also note that currently, Epiphany has ctrl
> > +scroll bound to quick scroll (double-stepped).
> >
> > Windows(/FF [probably]):
> > ctrl+scroll: zoom
> >
> > GIMP, Nautilus:
(Continue reading)

Alan Horkan | 2 Jun 2005 15:26
Picon
Picon
Favicon

Re: The Desktop: useful or just a relic?


On Wed, 25 May 2005, Bosshard Raphael (bosshrap) wrote:

> Date: Wed, 25 May 2005 14:45:11 +0200
> From: "Bosshard Raphael (bosshrap)" <bosshrap <at> zhwin.ch>
> To: usability <at> gnome.org
> Subject: [Usability] The Desktop: useful or just a relic?
>
> Topaz thoughts..
>
> Again a silly questions to the gods of usefull interfaces;
>
>   Is the desktop useful (or is it just a relic from ancient times?)

Yes.  :)

> Most people I know use the desktop (the thing in the background where
> all these funny icons are) to store data. They create folders with names
> like "Music" and "Private" and "None of you business" and put stuff into
> them.

> But whenever they want to access them, they use the file-picker, because
> the application they are using is concealing those nice folders. The
> desktop is the least accessible place on the screen.

Long ago I learned the habit of opening the application and then opening
the document because if there is more than one text editor or graphics
program on your computer there it is the best way to be sure the document
opens in the correct program.

(Continue reading)

Picon
Gravatar

Re: The Desktop: useful or just a relic?

On 25/05/05, Bosshard Raphael (bosshrap) <bosshrap <at> zhwin.ch> wrote:
> Topaz thoughts..
> 
> Again a silly questions to the gods of usefull interfaces;
> 
>   Is the desktop useful (or is it just a relic from ancient times?)

It might have served well when documents where only text and image and
users had at most two or three applications open. But I believe that
this metaphor is aged and is being replaced by other interfaces (the
next Big Thing being system-wide metadata search).

> 
> Most people I know use the desktop  (the thing in the background where all these funny icons are) to store
data. They create folders with names like "Music" and "Private" and "None of you business" and put stuff
into them.
> 
Yes, this is what desktops were designed for.

> But whenever they want to access them, they use the file-picker, because the application they are using is
concealing those nice folders. The desktop is the least accessible place on the screen.

That's the first main whole design error of desktop systems - their
primary function is not easy to do, so it is not done on a regular
basis.

> 
> Imagine drag and drop: minimize application, open folder, open folder, open application, move
application to the left, move folder to the right, drag file into application, close folder, close
folder. Silly.
(Continue reading)

Thom Holwerda | 2 Jun 2005 16:57
Picon
Favicon

Re: The Desktop: useful or just a relic?


Topaz thoughts..

Again a silly questions to the gods of usefull interfaces;

  Is the desktop useful (or is it just a relic from ancient times?)


Definitely useful. A relic, yes, but a relic isn't nescesarily useless :).

Most people I know use the desktop  (the thing in the background where all these funny icons are) to store data. They create folders with names like "Music" and "Private" and "None of you business" and put stuff into them.


Most people I know use it to store application icons, ie. Internet Explorer, Outlook (yes, most of my friends use Windows). Or links to games, whatever. You get the idea. They rarely, if never, use it as a place to store photos and music files. They go into "My Documents", "My Music", etc.

But whenever they want to access them, they use the file-picker, because the application they are using is concealing those nice folders.

If they want to open a file that is associated with a currently running application, then yes, this is a problem. However, after observing a lot of computer-illiterate people, I have come to the conclusion that very few people *actively* multitask (I do not find running Outlook & Explorer at the same time "active multitasking"), or edit multiple documents at the same time. This is different for us powerusers, obviously.


The desktop is the least accessible place on the screen.


Yup. Except on OSX. Exposé all the way (I will get back to that later).

Imagine drag and drop: minimize application, open folder, open folder, open application, move application to the left, move folder to the right, drag file into application, close folder, close folder. Silly.


What are you trying to say with this paragraph?

What about a different to store data? What about a "sidebar" (instinct anti-longhorn reaction expected) with all folders in the home directory? Plus, maybe, some "persistent search" folders (All images, all music-files by Jethro Tull, conversations with ALICE...).

So, what you mean is: instead of putting icons *directly* on the desktop, we simply make a piece of the desktop grey and put the icons on that? :). 


I guess there are better ways then the one example above. Do you have any ideas?


I can't get the Expose idea out of my head. Sliding all windows out of place to reveal the desktop in OSX is a simply case of moving the mouse to a screencorner, or pressing F11, and the desktop appears. That way, the desktop is no longer the "the least accessible place on the screen". I believe Kristian Rietveld is interested in working on a Expose like feature using Xgl [1].

---

Now, I myself use the desktop very often. It's basically where I put the files I'm currently working on. A lot of people assume that users *first* open applications and *then* open the file using the app. I think it's the other way round: people *first* locate the file, and *then* open the associated application by clicking on it (that's a reason why the spatial metaphor was unusable for a lot of people). Taking this into account, there needs to be a place where people can easily access their 'current' files. This can be done via either Beagle (which poses a problem as then you have to have something to let beagle search for, i.o.w., your keywords must be very effective, else it will *still* take long to find the correct file) or via the desktop. The latter is a concept a lot of people understand, and by implementing a faster way to 'Show desktop' (faster than a button at least), I don't think we need something else.

But, as always, that's just me.


Thom Holwerda
---
Main news posting guy at http://www.expert-zone.com, bringing you the OS/Computer news that really matters
---



_______________________________________________
Usability mailing list
Usability <at> gnome.org
http://mail.gnome.org/mailman/listinfo/usability
Thom Holwerda | 2 Jun 2005 17:07
Picon
Favicon

Re: The Desktop: useful or just a relic?

Topaz thoughts..

Again a silly questions to the gods of usefull interfaces;

  Is the desktop useful (or is it just a relic from ancient times?)


Definitely useful. A relic, yes, but a relic isn't nescesarily useless :).


Most people I know use the desktop  (the thing in the background where all these funny icons are) to store data. They create folders with names like "Music" and "Private" and "None of you business" and put stuff into them.


Most people I know use it to store application icons, ie. Internet Explorer, Outlook (yes, most of my friends use Windows). Or links to games, whatever. You get the idea. They rarely, if never, use it as a place to store photos and music files. They go into "My Documents", "My Music", etc.


But whenever they want to access them, they use the file-picker, because the application they are using is concealing those nice folders. 

If they want to open a file that is associated with a currently running application, then yes, this is a problem. However, after observing a lot of computer-illiterate people, I have come to the conclusion that very few people *actively* multitask (I do not find running Outlook & Explorer at the same time "active multitasking"), or edit multiple documents at the same time. This is different for us powerusers, obviously.


The desktop is the least accessible place on the screen.


Yup. Except on OSX. Exposé all the way (I will get back to that later).


Imagine drag and drop: minimize application, open folder, open folder, open application, move application to the left, move folder to the right, drag file into application, close folder, close folder. Silly.


What are you trying to say with this paragraph?


What about a different to store data? What about a "sidebar" (instinct anti-longhorn reaction expected) with all folders in the home directory? Plus, maybe, some "persistent search" folders (All images, all music-files by Jethro Tull, conversations with ALICE...).

So, what you mean is: instead of putting icons *directly* on the desktop, we simply make a piece of the desktop grey and put the icons on that? :). 


I guess there are better ways then the one example above. Do you have any ideas?


I can't get the Expose idea out of my head. Sliding all windows out of place to reveal the desktop in OSX is a simply case of moving the mouse to a screencorner, or pressing F11, and the desktop appears. That way, the desktop is no longer the "the least accessible place on the screen". I believe Kristian Rietveld is interested in working on a Expose like feature using Xgl [1].

---

Now, I myself use the desktop very often. It's basically where I put the files I'm currently working on. A lot of people assume that users *first* open applications and *then* open the file using the app. I think it's the other way round: people *first* locate the file, and *then* open the associated application by clicking on it (that's a reason why the spatial metaphor was unusable for a lot of people). Taking this into account, there needs to be a place where people can easily access their 'current' files. This can be done via either Beagle (which poses a problem as then you have to have something to let beagle search for, i.o.w., your keywords must be very effective, else it will *still* take long to find the correct file) or via the desktop. The latter is a concept a lot of people understand, and by implementing a faster way to 'Show desktop' (faster than a button at least), I don't think we need something else.

But, as always, that's just me.


Thom Holwerda
---
Main news posting guy at http://www.expert-zone.com, bringing you the OS/Computer news that really matters
---



_______________________________________________
Usability mailing list
Usability <at> gnome.org
http://mail.gnome.org/mailman/listinfo/usability
Alan Horkan | 2 Jun 2005 17:58
Picon
Picon
Favicon

Re: The Desktop: useful or just a relic?


Removed CC's.

Please try and avoid crossposting.
Please choose one list at time and stick with it.

On Thu, 2 Jun 2005, Thom Holwerda wrote:

> Date: Thu, 2 Jun 2005 16:57:11 +0200
> From: Thom Holwerda <slakje <at> quicknet.nl>
> To: Desktop Devel <desktop-devel-list <at> gnome.org>
> Subject: Re: [Usability] The Desktop: useful or just a relic?

> > Imagine drag and drop: minimize application, open folder, open
> > folder, open application, move application to the left, move folder
> > to the right, drag file into application, close folder, close
> > folder. Silly.
> >
>
> What are you trying to say with this paragraph?
>
> > What about a different to store data? What about a
> > "sidebar" (instinct anti-longhorn reaction expected) with all
> > folders in the home directory? Plus, maybe, some "persistent
> > search" folders (All images, all music-files by Jethro Tull,
> > conversations with ALICE...).
>
> So, what you mean is: instead of putting icons *directly* on the
> desktop, we simply make a piece of the desktop grey and put the icons
> on that? :).

There have been various suggestions and even a few implementations of the
concept of a "Shelf" to keep certain more important documents close to the
front, a search through the mailing list archives should turn up some of
these suggestions.

If you were determined to stretch the metaphor and make real world
comparison even the Panel as it is now could be condisered as a shelf.

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Dia http://gnome.org/projects/dia/
Open Clip Art http://OpenClipArt.org

Alan's Diary
http://advogato.org/person/AlanHorkan/
Christian Neumair | 2 Jun 2005 22:32

Nautilus: Overwrite Existing File/Folder Dialog Buttons

Hello usability geeks! :)

We've got Nautilus users who complain that when they copy multiple files
and there is a conflict (moving foo to bar, where bar/foo existed
beforehead, that is), they want that we offer the following 5
possibilities:
Skip, Skip All, Replace, Replace All, Cancel

They should all be presented in one dialog. I fear they might look very
scary. Is there anything "creative" we could do about them? We had a
little discussion in #nautilus on IRC on that:

22:17:57 <Manny> hrm if we have multiple conflicts when moving, we are
meant (according to some users) to provide replace all, skip all, skip,
replace and cancel. Isn't this a bit much for one dialog?
22:18:10 <Manny> let's ask the usability crew :)
22:18:18 <interatom_> hehe, you have to check out the kde dialog for
this case
22:19:00 <Manny> as jdub said...whenever they have an empty space in
their dialog, they stick in a widget!
22:19:08 <Manny> s^dialog^$0s^
22:19:41 <interatom_> but it sucks there's no skip all
22:21:18 <Manny> yup, but the backend supports it
22:21:30 <Manny> I still have a private patch for it but 5 buttons in 1
dialog just suck
22:22:02 <quinn> You know what I'd like? Something like the Gedit save
confirm dialog listing all the conflicts.
22:22:19 <quinn> So you could check, say, the ones you wanted to
overwrite and go from there.
22:22:39 <Manny> quinn: won't work here
22:23:07 <Manny> nice idea, but doe to the fact the VFS works we can't
investigate all conflicts at the same time
22:23:15 * quinn nods
22:23:33 <Manny> especially if you move FTP hierarchies, this might not
be desireable
22:23:37 <Manny> ...or we'd have to collect conflicts and afterwards
present them
22:23:58 <Manny> we'd have to skip them at the first run and then
re-transfer them if desired
22:24:09 <Manny> but somehow this sounds scary
22:24:10 <arc_> Manny: nautilus could decide when to try to resolve
conflicts in that way... (remote fs and so)
22:24:28 <Manny> arc_: what do you mean by "in that way"?
22:24:41 <Manny> the files are shoveled by the VFS, one after an other
22:24:56 <Manny> we have a callback which returns what will be done with
a particular file which is currently shoveled
22:25:26 <arc_> Manny: the way that gedit does

gedit resolves this obviously in a very creative way, and we can
investigate moving to that system, which would require some backend
bending. But for now, I think it is better to just polish the conflict
dialog. Do you think that it is reasonable to put 5 response buttons
into 1 dialog? If yes, what would be the preferred order? I've come to
the conclusion that

Replace All, Skip All, Skip, Cancel, Replace

could be quiet appropriate. What's your opinion?

--

-- 
Christian Neumair <chris <at> gnome-de.org>
Nickolay V. Shmyrev | 3 Jun 2005 02:58
Picon
Favicon

HIG - Human Interaction Guide

Hi all. 

There is one thing I was always wondering. HIG nicely specifies how
Gnome Application should look, but it says almost nothing about not less
important thing - how application should behave. And a bit's of helpful
information about behavior are deeply hidden.

Just quick review of gnomefiles application shows that they all are
different, even if the look similar, they work in completely different
ways. There are a lot of moments that can and should be cleared, let me
point to some of them:

How application should save it's geometry - on per-document basis or
globally. What to do on document overwrite or input-output error. How
application should work with document metadata. How to provide document
navigation (browser-like style or another way, I have no ideas). How
handle multiple documents, what to do if users request tabs. Should
application provide file menu or something like this. What should task-
based application do, or do non-document application allowed. When
developer should write applet and when use notification area. Should applications
be spatial.

Is it possible to append such chapters to HIG or it should be standalone
document?

I know, that without appropriate support of development platform it
would be hard to reach consistency in application behavior, but HIG
experience shows that just writing a standard of something similar helps a lot,
supporting libraries would be much easier to write if there will be
document with detailed description.
Picon
Gravatar

Re: Nautilus: Overwrite Existing File/Folder Dialog Buttons

What about extracting the "process all" to a checkbox option, thus
avoiding the Skip All/Replace All redundancy? You'd have this
interface:

The following existing files will be replaced with the new ones:
<List box with all the files being processed>

[X] Ask what to do for each file

[Cancel] [Skip] [Replace]

or with a radio button:

The following existing files will be replaced with the new ones:
<List box with all the files being processed>

( ) Apply this action to all files
(.) Ask what to do for each file

[Cancel] [Skip] [Replace]

On 02/06/05, Christian Neumair <chris <at> gnome-de.org> wrote:
> Hello usability geeks! :)
> 
> We've got Nautilus users who complain that when they copy multiple files
> and there is a conflict (moving foo to bar, where bar/foo existed
> beforehead, that is), they want that we offer the following 5
> possibilities:
> Skip, Skip All, Replace, Replace All, Cancel
> 
> They should all be presented in one dialog. I fear they might look very
> scary. Is there anything "creative" we could do about them?

Gmane