Figure out some logical structure and stick with it, that's the general rule.
What that structure actually is is less important than sticking to it.
What I generally do is place classes together based on functionality.
So in your case I'd make a package for the user interface classes.
Under that subpackages for classes used only in the client and the server (with the shared classes in the base user interface package).
Make a parallel tree for utility classes, etc.
May seem a lot of work for a small application with one or two classes per package but when you get into larger projects with hundreds or thousands of classes it can really help.
Someone forgot to do that where I now work and we have more than a bit of duplicate functionality because classes are in places they shouldn't be and get forgotten about, packages have literally hundreds of classes that are only loosely related if at all, making them hard to find, etc.
It pays thinking about that package structure for a while before you start coding, a day or even a few days on a large project is no luxury.
That's part of the design process, book the time on someone else's budget ;)