General musings on programming languages, and Java.

Thursday, July 14, 2005

Eclipse 3.1 User Experience

I gave up using Eclipse in favour of vim and ant some time ago, mainly because I did some work from home, on a 233MHz machine (my faster personal machine was stolen last year), and Eclipse was too slow to be useful there. But now I came across a bug in a unit test, and I can't figure out how to write a unit test to find that bug, so I have to do some debugging. Not having Eclipse installed, the first thing I did was launch jdb and type help, which wasn't too 'help'ful. I googled for how to use jdb, and only found a site that seemed inaccurate or out of date. I had a play with ODB (Omniscient Debugger), but couldn't get it to instrument all my classes, just the particular one I was running. So, I'm back with Eclipse, a fresh download. My first thought is that it seems a bit easier to start up, I don't seem to have to tell it on the command line where to put its workspace, it has a nice dialog. I go to Project->New Project and it has an entry for creating the project from an ant build.xml. I'm staggered. So I go about it and it seems to understand the build.xml properly. Eclipse then decides that I've got 100 syntax errors, merely because I haven't told it that I'm using Java 1.5. Let me check that build.xml.. hmm, I didn't have a source="1.5", but the ONLY compiler available on my system is the 1.5 compiler, so Eclipse could easily have detected that and just moved on. The Quick Fix for the first error seems good though - change workspace compliance and JRE to 5.0, or change project compliance and JRE to 5.0. I select workspace. So Eclipse rebuilds and gives me the following warning: taskdef class edu.umd.cs.findbugs.anttask.FindBugsTask cannot be found Back to the build.xml.. etc. I can't see how Eclipse could fail to find that, seeing as ant can. But hey, maybe if I go to Quick Fix I can tell Eclipse where the findbugs task is. Hmm, Quick Fix is greyed out. Thankfully, that's just a warning, so I'll try to ignore this annoyance and continue with my work. All the other warnings seem to be pretty innocent, unused imports, etc. It does seem that Eclipse is hiding some warnings though, as the errors before and the warnings now list exactly 100. Maybe 100 is the limit. I hope it isn't hiding any important warnings. Eclipse seems to italicise my static import of, which seems like a nice little feature. On further use of the debugger, I see that it is italicising all static methods, nice. Well, I found my bug, mainly that two parameters were the wrong way around, and I've exited Eclipse. I'll still be using vim and ant, but I will keep Eclipse around for its debugger. The build.xml parsing is very handy, but not perfect. I hope Eclipse can improve this. I'll still try other debuggers, but ODB left a sour taste in the mouth - poor documentation. I should have blogged that user experience. Maybe the next one.


Anonymous said...

Just RTFM please!!!

Ricky Clarkson said...

Come on, nobody really reads documentation, not until the usability of the app has been shown to be zilch.

Unless the documentation is embedded into the app, e.g., clever little tooltips etc.

You just want to get on with your work.

Randall said...

You know, people invented IDEs for a reason. They increase productivity by leaps & bounds. Ever used Visual Studio.Net? Now there's a real IDE. Eclipse is getting closer to the ease-of-use you get with VS.Net, but until they get the web tools project finished & working, it's a little disappointing. But what you get from an IDE is one central location to keep your configuration. Anything that asks you to set another classpath (Ant) is garbage. Classpaths are the biggest bugaboo in Java and having to deal with it more than once is shameful.

And about nobody reading documentation, that's the most idiotic thing I have ever heard of. How the hell are you going to know how to do things the right way without reading the documentation?

Ricky Clarkson said...

I've used Visual Studio, but not the .NET version.

On one of my development machines, like I said, I am more productive with vim and ant than I am with Eclipse, due to Eclipse being very slow on that machine. So I merely selected the right tool for the job.

>But what you get from an IDE is one >central location to keep your >configuration.

I choose build.xml as my central location, then I can use any IDE/editor.

I don't actually find handling classpaths a problem personally, and once I've done it in ant once, it's fine. A good IDE should be able to export a build.xml for me if I don't like writing XML myself (I believe Netbeans can).

Regarding documentation, people simply do not read documentation. They either believe they know how to use the application, don't want to trawl help files, or don't know that the help file exists.

If the user believes they know how to use the application, then why get in their way? Principle of least astonishment.

If the user doesn't want to read the help files, maybe they've had bad experiences in the past.

Another reason for this is that the help doesn't present itself. Rather than a Help button being on every dialog, Eclipse chooses to keep it in the menus, meaning that you then need to navigate to the relevant part of the help once you launch help, rather than it just being there.

I hope that explains my experience.

Anonymous said...

if you just want to do some debugging, you might have luck with jswat.

I thanked god for jdb when I had to debug a customer problem where I could only telnet to their aix machine from a crummy cmd.exe prompt.

Jonathan Feinberg said...

The notion that "people don't read documentation" is entirely spurious. Do you have any user studies and statistical analysis to support such an idea?

As it happens, the Eclipse documentation is excellent.

Anonymous said...

"Ever used Visual Studio.Net? Now there's a real IDE."

Is this one of those shameless .NET plugs? I have used VS.NET for a C# project every day for the past few months, and every day I'm wishing it was as good and had the features Eclipse has. VS was the best five years ago, now it feels buggy and limited in comparison to the Java tools out there. Maybe it has good COM and Web Services integration, but I don't need those.

Hopefully the next release in October will catch up again, but I can't take seriously anyone who's promoting VS.NET as a great development environment.

Mark Boon

Rory said...

If you cant figure out how to do something in an IDE, and you refuse to read the documentation to find out how to do so, you are an idiot who wastes yours and other peoples time. Its as simple as that.

Ricky Clarkson said...

Rory, I shouldn't have to waste my own time in figuring out how to get the IDE out of my way so that I can get work done.

I don't refuse to read documentation, but I feel that when someone has to read documentation to do something, even when they understand the concepts involved, there's something lacking in the user interface.

Do I need to read a new manual whenever I buy a new car, or do I just get in and drive?

Jim Adams said...

I am afraid that I will have to side with Ricky on the documentation aspect. Users simply do not want to read the documentation if they can get away with it. We all want the IDE to be intuitively obvious. Those of us who develop IDEs want them to be the IDE of choice and the only way that is going to happen is if the out of box experience is such that I can get my work done with minimal distraction. If there are some Aha moments along the way then all the better. Ricky certainly seemed to have some with his experience.

As for the help in Eclipse being Excellent, I will have to disagree. It is good, but not excellent. But then, I want the documentation to tell me how to tweak eclipse itself since I am an IDE developer.

Anonymous said...

There is no 100 limit!
There is a default filter to limit to the 1st 100. Hit the little arrow icon near maximise/minimise on the problem view to change it - at the same time i normally change it to filter on the selected resource only (so i only see errors/warnings for what I'm working on)

Anonymous said...
This comment has been removed by a blog administrator.
Eelco said...

VS.NET a 'real IDE'. OMG! I did a project with that - a sidestep from my usual Java development (with Eclipse) - 2 years ago, and I still have trouble sleeping. What a pile of crap that was.

A full re-compile and restart with every little change? Pages I couldn't edit in the IDE because VS would crash? That horrible WYSIWYG which is always in your way, slowing you down, even if you want to do simple stuff? No refactoring support other than simple text replacement? No hierarchy and call reference overviews?

The only thing I can imagine VS being a good IDE for, is for people who hate to code. :)

Anonymous said...

As for all this stuff about reading the documentation: Of course one needs to read it. But it should be the last resort, not the first. OTOH, it's a poor substitute for a decent interface to slather a poor one in tooltips and pop up help.

I have yet to see an IDE with a decent interface for new users. One can be snobbish about this and say new users should have to learn the hard way, by why? There's no reason for it save artificially elevating the status of existing users.

Failing that, one should be able to learn all about an application simply by experimenting with it. Hidden and obscure features are dumb and pointless (unless they are actually dangerous), except to make the less competent look 31337, dude.

BTW, I found this post because I'm trying to bypass the 100 limit on The tasks list. Clicked the filter icon. No option to change the number of items (or to see later items in the list).

This is annoying. I don't want to filter, I want to see all the items. I don't care if it's a bit slow. Using v3.2.1

Perhaps I'm missing something. I guess I'll have to look at the docs. Crappy. It shouldn't be this difficult without good reason, yet I cannot see one and no-one here has given one.

Anonymous said...

Nope, ReadTFM and it was useless. "Click properties and choose the options you want." (paraphrase) was about as far as it went. Great. Specifically it said:

" 1. On the toolbar of the Tasks or Problems view, click Filter.filter button.
2. Select the radio buttons and checkboxes that correspond to your filtering objectives.
3. Click OK.

Wow! I couldn't have figured that out myself.

Anonymous said...

BTW, you can change the limit on the number of errors (as opposed to tasks) through
Window|Preferences|Java|Compiler|Building|General|Maximum number of problems reported per compilation unit

Like, duh. Anyone could have guessed that.

frankern said...

This only affects the problem count. Still, only 100 will be displayed...

frankern said...

Got the solution from Bill Pugh:

"If you select the triangle in the problems window, you can set Preferences for the Problems view, and this allows you to change the limit on the number of markers displayed."

Blog Archive

About Me

A salsa dancing, DJing programmer from Manchester, England.