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

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

Leon,

I found your response underwhelming.

> in the package explorer, if you click the downwards-pointing arrow, and
> select Filters... you can specify name patterns you wish to hide from
view.
> if thats too sweeping (it applies across all projects), click the same
> arrow, and select "Select Working Set..." where you can select the exact
files
> you want to see. nothing as drastic as delete required.

Look, I just don't want irrelevant files in my project. I don't think that
is at all unreasonable. Importing a bunch of stuff automatically, due to an
error on the part of Eclipse, and making me go through lots of trouble to
make it appear to go away, even though it is really still there, is not good
design. Why is the tool making me jump through hoops?


> i think its less confusing to to actually delete the file from the
filesystem
> than to leave it hanging around. and the file isn't really gone (although
it
> isn't in the recycle bin). select the project, right-click, and select
> "Restore from Local History". your deleted files should be there. this is
> documented in the (extensive) online help (search for "deleted", it'll be
> there somewhere).

A) Regardless of whether you find it "less confusing", I *was* confused. I
have 20 years of computer experience, and I work as a software engineer in
Silicon Valley, and I was confused.  What does that say about the design?
What will happen when even less experienced users start to use Eclipse?  No
matter how well-reasoned the developers think the design is, if it is put in
front of the intended users and they have trouble with it, then the design
needs improving.

B) Eclipse should respect the usability conventions of the platform it is
running on.  If files are removed, they should be where users usually go to
find things that were removed.  On Windows, that is the recycle bin. If
Eclipse wants to keep an additional copy somewhere special, and give the
user access to it through a special feature, that's fine. But it is bad
design to *force* users learn new ways of doing things they already know how
to do, unless there is a very good reason.

C) How am I to know that there is a copy somewhere? A file disappears off my
disk, as a user it sure seems gone to me.  I would not automatically know to
go and read about "restoring local history" in the docs. I shouldn't have to
know about advanced features to perform basic operations. This feature
doesn't appear in the File menu, which is where one might go to un-delete a
file, nor is Undo enabled in the edit menu. Actually, it doesn't appear
*anywhere* in the menus at all. In fact, the only appearance in the UI which
I can find is: the second from last item in a very long popup when you
right-click on the project folder in the package explorer window. The
developers should read that previous sentence ten times over and ponder
whether this critical feature is readily apparent to users.

D) The obscure storage format of the local history data made things worse.
You see, after the incident, I searched my entire hard disk for these files,
just in case they were tucked away somewhere on my hard drive, perhaps
within Eclipse or in some temp directory.  I didn't find them.  Now that I
know about the feature, I was able to find where Eclipse keeps this info.
It is located in files very deep within the Eclipse folder with useful names
like "c0d6c964cab0001615bbf12d1ea5a0b9". Now, this is a reasonable way to
store data for use by Eclipse, but when a user is panicked, and looking for
their data, this storage format compounds with the previous design errors to
help convince them that their data is really gone.


>> 3) Eclipse puts a window up during deletion, but the cancel button is not
>> responsive.  What a cruel trick on the user.  Once I realized what it was
>> doing, I wasted crucial seconds hammering on the cancel button, when I
>> should have been killing the app.

> see my response to (2).

Just because the files are really there, how does that make the
nonfunctional "cancel" button okay?  If the button is not going to work,
then it should be removed from the UI.  That is sloppy work, and is
disrespectful to the user.


To sum up, nobody has yet to admit that Eclipse needs to be improved. If
this is the general attitude of the developers on the project, then it does
not bode well for its future.

Here are concrete suggestions:

I) The panel for deleting files from the project should tell the user that
the files will be removed from the hard disk, and should also tell the user
they can be retrieved using "restore from local history". This panel is a
great opportunity to teach users about an interesting feature in the tool
which they might not know about. This can be implemented in 10 minutes.

II) "Undo" should be enabled and functional after a file has been deleted.
That is a key place users will look to when the app does something they did
not expect. The app has all the required state to properly undo the action.

III) Files removed from the hard disk should be placed in the recycle bin.
This is where users will expect to go to find them. This provides a backup,
in case the user does not realize they can undo the action within the app,
and compensates for the obscure format the history is stored in within the
Eclipse folder.

IV) The cancel button in the progress panel should be made functional or
removed.

V) The project corruption issue which started this whole escapade should be
addressed. I don't know enough about the implementation to make a specific
suggestion, but I'm sure you guys can figure something out.


Sincerely,
Dan