Daring Fireball: When 'Smart' Cut/Copy/Paste Attacks:

The worst part is that unless you understand that word-wise selection puts you into a special mode, the “smart” C/C/P behavior seems to kick in at random. Sometimes spaces are removed and added automatically, sometimes they aren’t.

Features that seem to kick in at random are bad features.

It's not a "wizard" if it creates a completely new window (and recenters it after I've moved it) after every time I click "Next".  Its a collection of dialogs, and its crappy interaction.

If you expect to have to manipulate a form in javascript, don't name a submit button "submit".

Celia  wrote in message ...
> I'm looking for a good book on web site layout and design.
> Can anyone suggest something for someone who's familiar with application
> programming and layout, but want's to move to the web?
> I'm hoping to find something practical covering everything from what
> components make up a web page to common usage standards.
> More of a UI book than a programmers manual, but not an escoteric
> philosophical treatise either.

Well, it doesn't have to therefore be a book using Swing exactly, however there is no way to broach this topic *without* getting into philosophy/psychology of user interface designs.

Best so far is About Face 2.0: The Essentials of Interaction Design.

But really, all its a matter of doing is making things look like other things you've already seen -- take advantage of research already done in the form of successful products already out there. Don't try a new layout or interaction metephore without 1) ruling out the existing ones as not being able to handle the necessary interaction, 2) trying it out on test users before calling it "final", and 3) really being sure that the interaction you've designed is absolutely necessary (can it be simplified to metaphores already known).

It all comes down to "expected behavior". What would a user expect to see, based on the applications they already know (assume they know Office, IE, Wordpad, a standard mailer like Outlook, Outlook Express, or Eudora)?

Then realize there are places in Swing where the expected isn't and you'll need to do derivations and overrides to get it that way. E.g., menu items shouldn't have tooltips, but creating a JMenuItem with an Action will create one that you'll have to undo; toolbar icons shouldn't have text and should all be the same size, but creating one with an Action will set the text and the button sizes may vary if your icons are different sizes; hitting a key in a non-editable JComboBox should skip to the item starting with that letter, but that works on the String.valueOf of the model item, not what the renderer may be showing.

Layout Management is key. Learn GridBag, learn Border, maybe try the new layouts in Swing for 1.4. I haven't had much luck with them, but then again, I've been good at GridBag since it started as the XmpTable widget for X-Windows/Motif.

Its lots of little things, and there's no one catalog of all of them. Its all a matter of experience and comparisons. If it doesn't act the same way a typical windows app might act, there had better be a reason for it, or go fix it. This is extremely time-consuming. Anybody can get a quick and dirty swing, gnome, or windows app out there, but it'll take *weeks* of time actually giving it the polish that a professional work might have, with a lot of nitty-gritty digging into the implementation of components and googling for examples to figure out what the hell to actually do. Be sure your customer base (or at least your boss) is willing to pay for that, but don't think you won't have to sell the idea.

That's about all I can say on it for now, but I'll probably post more later...

One of the biggest problems with inheritence for the sake of code reuse is that you can often inherit methods that no longer have any validity in the derived class, yet nothing in the compiler can tell you that unless the derived class goes out of its way to override the method and add a "@deprecated" sign to it.  Even then, sections of your code may never get the warning if they refer to the object by its base class anyways (Base b = new Derived()).

Case in point, JDBC.

PreparedStatement logically shares a lot from Statement, from a conceptual level, so it makes sense to have PreparedStatement derive from Statement.  However, one method in Statement, if called by a PreparedStatement, utterly breaks every time you use it, assuming you're using PreparedStatement the way it was intended:  executeQuery(String query).

If you've gone to the trouble of creating a PreparedStatement using the factory method in Connection, and setting the parameters, you can still accidentally call that version of the method instead of the appropriate executeQuery() with no parameters.  This will immediately get the runtime error of "not all variables bound", which at first glance of the code makes no sense, since you can see right there that you've set all the parameters.

All because there's no way for the compiler to tell you that method has no meaning in the derived class.  Even in the case of having no parameters to set, the presense of the method in PreparedStatement is useless because it wastes the entire step of "preparing" the query in the first place.  it actually evaluates the query *twice*, once at construction, then once again at the execute, since it has no real way of knowing that they are the same thing.

API designers, keep that in mind.  If you want to share interfaces through inheritence, but one derived interface might make an inherited method invalid/useless, then refactor -- create a base class with the common methods, and then derived classes with the additional methods that make sense.

Compilers should be able to catch mistakes like this, but they can't when you don't construct your hierarchies correctly.