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

["leon j breedt" <ljb@xxxxxxxxxxxxxx>]

hi,

disclaimer: i'm a user of Eclipse, not a developer. i just hang out here
because its development interests me.

my response, but i won't be continuing discussion in this thread (we need
eclipse-user & mail2news gateway!!!)

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

how do you create your project? when you import files using File -> Import,
you are given the option to select the files you want only. however, if
you're getting the project from version control, you're pretty much forced
to have everything thats in the repository in your project, there's
unfortunately no way around this that i can see, since Eclipse doesn't store
a project filelist anywhere that i know of.

this question does expose a limitation of filters/working sets though, they
are stored in the .metadata folder as far as i know, and apply against all
projects, which isn't necessarily desirable if you're working on different
projects with different layouts. also, setting them up is a manual process.


> 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.
i'm not dismissing your concerns, for me they were just less of a concern,
since i typically don't delete something with any action labeled "Delete"
unless i have a backup or am sure i don't want it back (once burned, twice
shy).


> 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.
i'm not quite sure how i came up with that response either. anyhow, i agree
that Cancel should behave like a transaction, if it doesn't, its a bug.

> 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.
i don't speak for any of the developers, my opinions are my own.

> 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.
+1

>
> 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.
+1

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

> 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.
i know its possible to catch VM shutdown in 1.3+, so it should be possible
to
correctly save state when you "kill" it.


regards,
leon.