RE: [eclipse-dev] Major data-destroying usability bugs

["Dan Fish" <dan.fish@xxxxxxxxxxx>]

Hello all,

Thanks for all of your comments and suggestions. A few brief responses
below:


Jerry said:

> I have even been able to teach new staff how to use the IDE in as little
as
> 4 hours - and have NEVER had the problems that are indicated in this
thread.
> I'm not saying they don't exist, but being on the IDE for 8 or 9 hours a
> day, 5 days a week, I'd have thought I'd come across them at some point.
> For my $0.02, Eclipse is a great product with a great future.

I agree that Eclipse is a great product, and generally very easy to use and
get up to speed in. As I said in the first paragraph of my original post, it
is the best tool I have used out of the last five.

I didn't mean to imply that every user will have this happen to them, just
that a certain non-trivial number will, and that the consequences of the
problem for these people are quite serious.


Jerry also said:

> Dan - just a
> suggestion: Since Eclipse is an open-source product, join the community
and
> start submitting patches for these problems, don't just sit back and sling
> arrows and expect everyone else to jump to attention.

Being an open source project does not absolve the designers from doing their
job well.  I may choose to submit code to the project in the future, if I
have the time.  I may not.  That is pretty much irrelevant to the discussion
at hand, which is: How should Eclipse work, and how can it be made better?

Given that the app is open source, I do feel a greater sense of obligation
to put in some work. Thus the work I put in to recreate the sequence of
events so I fully understood how the design of the tool led to the
difficulty I had, writing up the analysis and a list of concrete
suggestions, and obtaining newsgroup and mailing list passwords, all to
inform the community about this one problem and provide many solutions. And
I will post bugs and feature requests into the system as soon as I get up to
speed on it.

Moreover, since my field of specialty is primarily in usability and user
interface, these detailed suggestions on how to improve Eclipse are probably
the best way I can contribute to the project. I certainly hope people
realize that design and usability work is just as "real" as coding work is.

The most basic suggestion on changing the text of the delete alert panel is
probably a ten minute fix for the person who is familiar with that part of
the code. The time I have invested certainly dwarfs the time request I am
making of that person.


Gary said:

> Even though I cannot agree with the use of tone of the person who started
> this thread, I do agree with his concrete suggestions (see the paragraphs
> with roman numerals).

Sorry about the tone, but users who lose data get annoyed.
I'm glad that you think my suggestions are reasonable.

> My suggestion to Dan is this: log them bugs!

I'll do that as soon as I get up to speed on the bug
submission tools and guidelines, and so forth.


Phil said:

> When this happened to me (quite some time ago) the files were not in local
> history. I had just created the project and was trying to un-clutter it.
Since
> I had never changed any of the files none of them were in local history.
Perhaps
> now deleting a file is now considered to be enough of a change to warrant
a backup
> in local history. I certainly hope so.

I'm sorry to hear you were bitten by a variation of this bug.

My stuff seems to be in the local history, but restoring with a right-click
was not as easy as Leon suggested.  I killed Eclipse during the delete,
because I feared the worst, and then there was a half-day where I was
convinced my data was gone, during which I tried to rebuild my project from
scratch, because of the corruption of the project which started the whole
mess. All of this caused Eclipse to lose track of the project state such
that I cannot seem to access the history that is there via the UI.

But the data is in there. If I rummage around the .history folder, I can see
the contents of various files it deleted. It will be a lot of work, but I
can pull anything out of there which I really need.  Luckily, the data
accidentally deleted was (the only copy of) previous versions of my app, so
being able to look back on those is a contingency, not a necessity.


Phil said:

>> If you are going to claim compatibility with an operating system you
>> ought to obey the behavioral conventions of that operating system.

Kevin replied:

> Its the JDK that provides compatibility with the operating system.  So by
> your argument the JDK should put things in the trash folder on deletion of
> java.io.File's.

Not necessarily.  If a program creates a file in the course of operation, it
can delete its own file without placing it the recycle bin. If it deletes
*my* file then I expect different behavior.  Placing this at the level of
java.io.File would be too broad, in my opinion.  I think it is more of an
app-level usability issue, which will depend on the situation, user
expectations, etc.


Kevin also said:

> However, putting things in the trash folder has some merit (we've actually
> discussed this before).  Feel free to check Core for a similar bug report
> and if there is none add an enhancement request.

I'll do that, as soon as I get up to speed with bug reporting system.


Kevin also said:

> Note that the strength of local history over the trash can is that you
> don't just have the deleted items, you have the modification history of
> items, which is way more useful.  Putting items in both would be space
> innefficient, and in general I would rather have the edit history
(eclipse)
> than just deletion (windows).

I agree that the history feature is great.

However, I think you're setting up a false dichotomy here.  Why does it have
to be one or the other?  Disk space is cheap, and users know how to empty
the recycle bin if they happen to run low on space.

Note that I don't suggest that every single history change be saved in the
recycle bin, because I think users understand that selecting and deleting a
chunk of a file usually means it is gone as soon as they save it to disk.  I
am primarily concerned about the user who deletes whole files, or in my
case, a massive hierarchy of file folders.


Sincerely,
Dan