These are points where my way of working differs from the design 
assumption and the interface becomes obstructive. These may or 
may not be what "most people" do. 

In either case anyone who deviaites from this hypothetical average way 
of working should not have to change the way they use their computer 
to fit in with the file open/save dialogs. 

To suggest that they should is to admit to poor interface design.

1.
>>The most common use for Save As is to save a file in the default 
>>folder offered.

No. Sometimes I will rename different versions of a file to cd but most 
often Save-As is to write a backup or reference copy elsewhere, in a 
safe place.

2.
>>Most people will occasionally put files somewhere besides the default 
>>folder.
Occationally no, often. In this case the bookmark mechanism is a helpful 
feature.

3.
>>Thus, most important operation in "Save As..." is naming the document. >>Prominence in the interface is given to choosing the name.
The false assumption leads to a false conclusion and a default state of 
Save-as that make for more work.

It would not harm users who just wants to mod the filename to see the full
dlg. In hiding this by default , much of the time the user has to either 
drop the "Save in" list box or open the "Browser for other" expander.

One of several obstructions to the flow of work present in the interface.


4.
>> when "Browse for other folders" is expanded, "Save in Folder" should 
>> be insensitive as it duplicates the functionality of the bookmarks list.
I find this logic confusing. Why disable it? It becomes clutter. If it's 
there it should work, what is the point of it not working?

5. "Save in folder" seems to be a complete duplicate to me. It displays identical content to the bookmark panel . Both require a mouse 
operation to display the choices and another to make the selection. 
Pure duplication of function that does not represent any saving for 
the user.

If the full dlg came up by default the choice would be instantly visible 
and one click would do the job.

6. Showing both open and save dlgs in full form instantly gives the user a 
visual key as to where he is, he's familiar with the layout. Presenting 
this differently forces him to assimilate yet another dlg layout and functionality.

The idea that the short form in someway helps the user is probably false.

7. The proto screenshots on the study look great but differ from the 
reality of what I see in one very important respect: the space available
to the path_bar.

There seems to be a lack of testing of this with different fonts,themes and 
screen sizes. On this machine with a 1024x768 screen the path_bar runs 
out of space very quickly and the ammount of scrolling needed and the 
constant realignment of the buttons makes this potentially nice feature
really hard work to use.

It seems themes may have an important effect on the space reqd by the bar.

8. I recall having read about the study that was done at the conception
of Gnome , with non-specialist users being put in front of the interface
and observed to see how they coped. A formal report was produced that 
made a number of suggestions. I think it would be helpful to reread that
report and the HIG that came from it in relation to the filechoose and to 
do some tests with non-gnome users to see how they cope.

9.
In #331306 I suggest a patch to add a "Bookmarks" label . When I first 
used these dialogues I had no idea what this panel was and there was no 
indication at all. This type of error is typical of it being obvious to 
the guy who wrote it so he never even percieves the problem. This 
omittion also suggests lack of testing by direct observation of the user.



Well I hope all that does not seem like I'm ripping it to bits.

I have spent a substantial ammount of time looking into this getting 
familiar with the code and analysing where I think certain problems come
from and suggesting changes of style and patches. So I hope this critique
can be taken as positive and constructive.

You're obviously not going to agree with all my comments but hopefully 
they will be of help in improving the interface.

best regards.

Such an analysis of the spec is pointless. It reflects your view and your way of working with files but doesn't give any insight into the workflow of the average user, or rather the workflows of the different target users.

If you wanted to make a point, you would first have to define what your target users are (and no, that's not you). Then you would try to identify their needs and their typical workflows and create a set of user scenarios that you want your dialog to handle well. At that point you can compare the spec or even the current implementation against this.

Since it is difficult to identify the needs of users in an unbiased way (remember, you are not the user), it would help to talk to users and ask them to describe their workflows when it comes to saving files. Some other usability techniques such as paper prototyping or even a usability test could help as well, but this is something that you would not start without having completed the tasks I mentioned above.

Without such research, all your statements are nothing but your personal opinion and in no way relevant.

OK, let's keep cool. I clearly said this was where I had problems, I no where assumed I was the only user.

>>/me
These are points where my way of working differs from the design 
assumption and the interface becomes obstructive. These may or 
may not be what "most people" do. 
>>

>/sven
but doesn't give any insight into the workflow of the
average user, or rather the workflows of the different target users.
>

That is my whole point. The average user does not exist, that's why it needs to cater for different needs. You now talk of different target users but this is what was so obviously missing from the basic spec.

And it's not just me. You cannot be unaware of the number of users who have major difficulties with this interface, bugzilla abounds with them.

I originally started by highlighting specific points and coding and submitting patches to address the issues. I was told that was inappropriate and refered to the original study linked above.

So I submitted a bug questioning some of the assumptions. This now draws a somewhat irrate reply telling me it is invalid and pointless.

No, the opinions of users are not invalid but the refractory attitude any comments/suggestions/patches receive may indeed make any efforts pointless.

>>/me
... the point of this bug. To see with benefit of hindsight and user 
experiences some some of the design assumptions need to be adjusted and some 
base concepts could be modified.
>>

regards.

I'm dont see why you closed this as invalid (since you did not even post a comment).

There is large sector of the userbase that have serious issues with this interface, even if some small inprovements have been made over the last year, that fundemental problem still exists.

If the core team steadfastly stick to their guns and force everyone to work in a particualar narrowly convieved way that is regreatable but does not render any critique INVALID.

If you're just out on a bug sweep tidy up here, WONTFIX would be a more accurate "resolution".

I see two positive ways to approach this. 

1/ Give the user the choice (OH NO! you cant do that in Gnome ;) ) As is done in Thunar the user can select Bookmarks or Tree presentation to suit his needs.

2/ I think the ultimate solution is a mix of both (more cries of clutter, confusing the poor idiot user ...) . The bookmark paradigm is very useful, it's just insufficient as the only navigation method (in fact is is NOT a navigation method, that's the problem).

The whole idea of bookmarks outlined in the study was that the user only has a few destinations. Conclusion he only needs a few bookmarks. Fine.

A panel with a proper treeview to allow efficient navigation plus the space for a few bookmarks as shortcuts would surely satisfy everybodies needs and be more powerful than either method alone.


Now I fully expect that to be dismissed out of hand or flamed as above but at least the idea is in bugzilla and may light a candle of hope for the future.

If points are still relevant they should be split into one report per one issue. Colsing as INVALID again.

Instead of saying "If points are still relevant " how about you check?

If they have been addressed then it's RESOLVED FIXED . 

As I already pointed out above I _started out_ by filing separate bugs and even provided suggested improvement and patches. I got shouted at and told to stop it. 

You can't have it both ways. 


#1

That is the point of this bug. To see with benefit of hindsight and user 
experiences some some of the design assumptions need to be adjusted and some 
base concepts could be modified.

(In reply to comment #6)
> Instead of saying "If points are still relevant " how about you check?
> If they have been addressed then it's RESOLVED FIXED .

I won't check nine points. If eight issues were fixed and one isn't I still could not close this bug report. That's why one issue should be filed in one report, plus as manpower is not unlimited I cannot check all issues.

> I got shouted at and told to stop it. 

Not sure which bug report(s) you refer to.

> That is the point of this bug. To see with benefit of hindsight and user 
> experiences some some of the design assumptions need to be adjusted and some 
> base concepts could be modified.

This sounds more like mailing list stuff instead of a bug tracker. Bugtrackers are best for well-defined, fixable issues.

Let's try again:

#1
That is the point of this bug. To see with benefit of hindsight and user 
experiences some some of the design assumptions need to be adjusted and some 
base concepts could be modified.


#2
These are points where my way of working differs from the design 
assumption and the interface becomes obstructive. These may or 
may not be what "most people" do. 

...
You're obviously not going to agree with all my comments but hopefully 
they will be of help in improving the interface.



I was at no point suggesting that all my 9 comments should taken to define a new interface.

This bug was pointing out that there were some fundamental flaws in the original spec and that that spec needed reviewing or abandoning. That is a single issue.


Checking what the SaveAs dlg now does shows that many of the issues I identified have been addressed. The general experience is a lot better than it was when I opened this bug.


Marking this as fixed.