[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-dev] Major data-destroying usability bugs
|
All,
I am the manager for a small webpublishing group doing development using
Apache/Tomcat/Struts and Java. We have settled on Eclipse due to its ease
of use and relative stability. We had been using NetBeans, but abandoned it
due to the number of java exceptions that it was throwing throughout a
session. We have found Eclipse to be extremely stable and robust for our
development needs; this, along the number of plug-ins that are being
developed by the user community has made this product very attractive to us.
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. 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.
Jerry Jalenak
Development Manager, Web Publishing
LabOne, Inc.
> -----Original Message-----
> From: Dan Fish [mailto:dan.fish@xxxxxxxxxxx]
> Sent: Friday, August 16, 2002 1:50 PM
> To: eclipse-dev@xxxxxxxxxxx
> Subject: RE: [eclipse-dev] Major data-destroying usability bugs
>
>
>
> 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
>
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/eclipse-dev
>
This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675.
