GUI: Should we make the window size resizable?

[Satish Avadhanam]

Guys, one very quick question. Must we make the window size resizable. I did not do it, so a little bit worried. Does it have any effect on the GUI score?
Any inputs are appreciated. Thanks.

[Javini Javono]

Hi,
Based upon seeing previous posts to this forum, it is my understanding
that the window size must be resizable; and, Sun specifically will test
your user interface to see how it responds to changes in the window's
size.
Having said this, however, the limits of resizibility I do not know. For instance,
I believe you may be able to set up your application so that the window is
not allowed to be set by the user to be smaller than 640 x 480 pixels.
Thanks,
Javini Javono

[Satish Avadhanam]

Thanks Javini. So we need to make the window resizable and not smaller than 640x480. Ok, will have to work on that now. Thanks.

[John Smith]

So we need to make the window resizable and not smaller than 640x480.
It's perfectly acceptable to control the minimum frame size, but the minimum size should be dictated by the contents and the layout of the components of the frame, rather than some arbitrary dimension, such as 640x480. If all that you have in a given frame is a label and a textbox, it makes no sense to force the user to view it in a 640x480 frame. Other than that, I absolutely agree that the frames must be resizable, -- and with a good use of layout managers, it comes automatic.

[Jacques Bosch]

Mine was also resizable, but I forgot to enforce a minimum size.
Still got full score for GUI though. Feeeeeuuuuuuuu.......
J

[Satish Avadhanam]

Thankyou all.
Here is a short description on my layout.
Main frame is there.
Used Main Panel -- this contains five other panels as result panel, search panel..and other three
I added main panel to the frame content pane.
I used SpringLayout to layout these five panels in the main panel. In the individual five panels too, used SpringLayout to layout components like textfields, buttons.
What I was wondering is Eugene said -- "if you use a good layout manager it comes automatic" i.e. automatic resizable of components inside.
I would really appreciate if anyone can give some links as where I can learn this concepts of how I can make other components inside of frame resizable...or if they can throw some light on how to make them like pointing to some sun tutorials. I am searching for quite some time...and this post is one among them
Appreciate any help. Thanks.

[Satish Avadhanam]

And to add, the problem is when the window is resized, the components are staying at their size.
If say there are four buttons when the window is at its preferred size, then when I resize it the buttons stays like that. I mean they are not getting small or big as window. They just like to stay their size
Am working on it, but if anyone was thinking....so here is the scenario.
Thanks alot.

[Satish Avadhanam]

Guys,
Am getting at it. Thanks.
Anyways, I'm not sure if am doing the right(best/ atleast good ) way...so any pointers to links where I can get comfortable with resizing concepts would be great.
Thanks.

[George Marinkovich]

Hi Satish,

Originally posted by Satish Avadhanam:
Guys, one very quick question. Must we make the window size resizable.

I didn't make my GUI frame resizable and wasn't penalized for not doing so. I suspect there is some subjectivity in the grading, but it seems clear to me that not having a resizable GUI doesn't fail one of the major requirements for the GUI (I remain skeptical that it will cause you to lose 25% of the possible GUI points). Assuming you use combo boxes for your search criteria, display the JTable with suitable column widths, have a nice way to book the GUI, have a nice way to edit the configurable parameters (including a JFileChooser to select the database file), have a nice way to display errors to the user, validate the format of the customer id the user enters, organize the layout of your GUI so it reflects a logical workflow, and don't required the user to edit the configuration parameters if there's no problem with the ones in the suncertify.properties file, then you've hit the main points that I think are important in the GUI. If you have time to make the GUI resizable with a minimum size then go ahead and do so -- it's the right thing to do.
This issue is discussed at some length here: Topic: NX: Will they think my GUI is too simple?
[ March 07, 2004: Message edited by: George Marinkovich ]

[Andrew Monkhouse]

Hi everyone,
You may be interested in reading the thread "Cert nightmare. If you are impatient, jump down to Kathy's comments about half way through the page.
Regards, Andrew

[George Marinkovich]

I think everyone would be well advised to follow Kathy's well-informed suggestions and so I would urge everyone to look at the link Andrew posted. I especially appreciated this part:

Not to beat a dead horse here, but perhaps the biggest problem we see with exam candidates is that they do TOO good a job --- coming up with solutions that solve more than the specification asks for, modifying the spec to make it 'better', using their own non-standard (even if better) techniques, etc.
There are no extra points given for doing something special, clever, novel, especially cool, more performant, if it isn't justified by the requirements and ESPECIALLY if it involves deviating from a common (or at least *known*) solution.

I believe the correct approach to the GUI is to make sure that you meet all the explicit requirements given in the assignment instructions. The guiding principal for your GUI should be to ensure that it is easy for the user to understand and to use. A secondary consideration should be flexibility; more flexible is generally better.
The GUI should be intuitive to use, meaning the GUI should perform in a manner similar to the way the user has been conditioned to expect by the behaviour of similar applications. Your GUI should invoke in the user the minimal amount of astonishment. Ideally a user should be able to fumble his way through using your application without the benefit of your user's guide, based only on his previous experience with other application GUIs and what he sees on the screen.
I suggest a process of prioritization. Some aspects of the GUI will have a very large impact on the user's experience. Other aspects of the GUI will have a substantially lesser impact. My advice is to get the biggest bang for your buck, implement the most useful aspects first and the less useful aspects as time permits. If an application makes me enter search criteria rather than selecting them from a combo boxes I'm not likely to care much whether the GUI is resizable or not. Try to think from the user's perspective, try to understand what reasonable expectations he will have. If the user selected a database file location the last time he ran your application, he's going to wonder why the application asks him to select (again) the database file location the next time he runs the application (can't the application just use the configuration items from the suncertify.properties file, and only force the user to edit the configuration items when there's a problem?).
Unless you are some kind of GUI expert it is well worth your time reading GUI advice from knowledgeable people (for instance Kathy Sierra). They may bring up things related to the GUI that you haven't thought about. What about a toolbar? You may not have thought about it since you're already providing a menubar. Would a toolbar add value to the user? How much added value? How much work is it to add a toolbar? Maybe the menubar is sufficient for this application; the added work of adding a toolbar may not be justified for this application in your mind. This is the kind of analysis you need to perform for the GUI. Some things are so incredibly easy to add (mnemonics, accelerators, tooltips, etc.) that even minimal improvement to the GUI may justify the negligible cost.
Before you submit your application, you should be able to honestly say that you like using your GUI. It's probably even better if you can find someone other than yourself who can say the same thing. If there's something about your GUI that annoys you, then it's probably going to annoy your examiner as well.

[Satish Avadhanam]

Hi George & Andrew, thanks. I will try to give a visual idea of how my main GUI looks like as I don't know how to copy and paste it here
Please comment on it. Thanks.

JFrame 
    + mainPanel(JPanel)
        + headerPanel(JPanel)
            + headerLabel(JLabel, says "CSR Bookig Application")
        + searchPanel(JPanel)
            + searchLabel(JLabel, tells this logical section is "searching"
              section)
            + nameLabel(JLabel, corresponding to nameField)
            + locationLabel(JLabel, corresponding to locationField)
            + nameField(JTextField, to enter name search string)
            + locationField(JTextField, to enter location search string)
            + exactMatch(JCheckBox, flag to indicate exact search)
            + serachButton(JButton, to search)
            + browseAllButton(JButton, to browse all the records, this is 
              located on the extreme right of the panel)
        + bookPanel(JPanel) 
            + bookLabel(JLabel, tells the logical section is "booking" 
              section)
            + ownerIDLabel(JLabel, corresponding to ownerIDField to book)
            + ownerIDField(JTextField, to enter owner's ID)
            + bookButton(JButton, to book the record)
        + resultPanel(JPanel)
            + resultTable(JTable)
        + applicationLogPanel(JPanel)
            + applicationLogLabel(JLabel, to show all types of messages, 
              errors, and other successful/failure operations information)

I did not include any exit button. Now as I read the posts, will include it. But don't know where
GUI has a menu bar with only one menu "File" that has one menu item "Quit".
As I read through the thread pointed by Anrew, I got to think about a couple of things.

1. GUI has no menu bar or no file menu.
2. No pull downs for specifying origin/destination airport. (manual entry
text fields used)
3. Uses a drop down for seat selection for flights with manuy available
seats.
4. Layout is illogical. After resizing the JFrame turned into an illegible
mess right in the middle of the screen. Layout manager problems.
5. Urgent notifications were not done with dialogs for example, when a user
tries to reserve too many seats, or tries to quit. (GUI terminates without dialoging the user or providing the opportunity to cancel.

Well, in the above mentioned five points here's what am doing.

1. Used it.
2. Am not using any pull down's for search. I mean here the scenario and
application is different right. The user can enter the name and
location and select the checkbox for exact match. He should then click
the search button. I think this is perfectly OK here. Again, we can use
editable combo boxes to search, but I think this is more user friendly.
User can browse all the records by clicking on the browseAll button.
3. Am not using any drop down lists...do we need any? If so can you please
throw some light on where we can use.
4. Am allowing resizing. But I got some doubts here. See if main window
is resized. all the panels and components adjust themselves to have a
nice look. But what I was thinking is what if the window is made very
small, I mean say 50x50 pixels...what should I do now? Should I add
scroll pane here or should I set some minimum size for the main window
after some testing?
5. Am not using any dialogs at all. But obviuosly will add them now for
exiting the application.

And again I think its not easy to come to conclusion depending on scores because the graders are obviously different. One think "GUI without exit button is of no use" while other might think "what made him use an exit button".
Guys, please comment on the GUI design..and to admit this is my first GUI and its making me All comments are greatly appreciated guys. Thanks alot.

[Satish Avadhanam]

George, if you can comment on the design that would be very great. Thanks.

[Jacques Bosch]

Grading might be subjective, but maybe this will still help I hope.
I got full score for my GUI.

George wrote:
Assuming you use combo boxes for your search criteria, display the JTable with suitable column widths...

I didn't use any combos for searching. Only text fields.

I did not include any exit button. Now as I read the posts, will include it. But don't know where
GUI has a menu bar with only one menu "File" that has one menu item "Quit".
As I read through the thread pointed by Anrew, I got to think about a couple of things.

I have a Quit Button at bottom right.
Also have a menu bar, with a single File menu, with a single Exit menu Item.
J

[Satish Avadhanam]

Hi Jacques, you gave me the assurance on usage of ComboBoxes and George told setResizable(false) is OK if our GUI looks and feels good.
Thanks.

[Jacques Bosch]

Still think resizable is better than not resizable, though. IMHO.
And should be little work.

[George Marinkovich]

Hi Satish,
There are many good things that I see in your GUI. I hope you won't mind if I make it easier on myself and not comment on the good things but only criticize the things I don't like. So these are just my opinions and you should feel free to accept the ones with which you agree and reject the ones with which you don't.
1) I think the name and label text fields should instead be non-editable combo boxes with drop-down lists of the all the unique values for each field. This way you are only allowing users to enter valid search criteria, you don't have to worry about wildcard matching, and you are being very nice toward the poor user. Here's an experiment: imagine you have to enter 30 bookings using your application. Start with the first one, go to the name field and type in "Bitter Homes & Gardens", then hit the search button. Book the record. Go back to the name field and type in "Philharmonic Remodeling", then hit the search button. Now maybe you're a better (faster) typist than me, but I'll wager at some point before you get to 30 you're going to start wondering why you can't just go to a combo box and select "Moore Power Tool Ya" rather than typing the silly thing into a text field.
2) You aren't required to have the exact match check box. You are required to exactly match the name and location search criteria. You are not required to offer a wildcard match capability. Doing so is beyond the scope of the project.
3) I don't like the browse all button. Can't I get the same effect by blanking out the name and location text fields and pressing the search button?
4) I would expect to see the results of my search before I have to see the booking section. I think you might agree if you conduct the experiment I mentioned in 1 above. For each use case it's nice if you can maintain a top to bottom work flow. For example, searching for a record, you start at the search panel, click the search button, see your result set in the JTable (proceeding down the screen). When you book a record you start a the JTable, highlight the row, click the book button, enter the customer id (proceeding down the screen).
5) It might be better for errors to be presented to the user in a dialog. This dialog can be made modal if the error is severe enough to warrant this. You can also display a considerable amount of text to the user to explain the error (and maybe how to fix it) if it's necessary.
6) In real life you probably wouldn't want a menu item with only a single choice, but I understand why that could happen with this assignment. You might consider having File-> Edit Configuration and File-> Quit. Or you might want to replace the menubar and use a toolbar instead possibly having only two items (Edit Configuration and Quit).
7) I recommend making the frame resizable (with some minimum size you can discover during testing). If you find that it's a substantial amount of work then I think you can get away with setting the frame to not be resizable.
8) I took two different approaches for exiting depending on whether the application was the client or server. For the client the user could exit by File->Exit, by the Exit menu bar item, or by clicking on the close window decoration. For the server the user could exit in the same ways allowed in the client or by pressing a Shutdown Server button. However, in the server, I brought up a confirm dialog to make sure the user wanted to shutdown the server (because of course shutting down the server has an adverse impact on any clients). I don't think this confirmation is really needed, it's just one of a host of things that I did that in retrospect are probably beyond the scope of the project. The confirmation dialog is probably a good example of what you shouldn't do.

[Satish Avadhanam]

Hi George, thanks for going through and replying in length.

Originally posted by George Marinkovich:
Hi Satish,
There are many good things that I see in your GUI.

Thankyou.

I hope you won't mind if I make it easier on myself and not comment on the good things but only criticize the things I don't like. So these are just my opinions and you should feel free to accept the ones with which you agree and reject the ones with which you don't.

Mind? Am always happy to see your reply. (Well, its getting a bit sentimental...will deal with all these senti' things after the exa But have to admit, each and every of your 400+ posts helped me alot. And there are other felow ranchers who helped -- Andrew, Jacques, Javini, Nick and others...but will save this "Thanking Ceremony" till I a pass the exam )

1) I think the name and label text fields should instead be non-editable combo boxes with drop-down lists of the all the unique values for each field. This way you are only allowing users to enter valid search criteria, you don't have to worry about wildcard matching, and you are being very nice toward the poor user. Here's an experiment: imagine you have to enter 30 bookings using your application. Start with the first one, go to the name field and type in "Bitter Homes & Gardens", then hit the search button. Book the record. Go back to the name field and type in "Philharmonic Remodeling", then hit the search button. Now maybe you're a better (faster) typist than me, but I'll wager at some point before you get to 30 you're going to start wondering why you can't just go to a combo box and select "Moore Power Tool Ya" rather than typing the silly thing into a text field.

So George, you are saying that instead of TextFields, its better to populate the existing records in db in a combo boxes. And when the user wants to search, he can just locate the required hotel name or location from the combo box and search for it. Now, all records with name/location will be populated in the JTable. If he wishes to book, he can then book. Will try to implement it. Thanks.

2) You aren't required to have the exact match check box. You are required to exactly match the name and location search criteria. You are not required to offer a wildcard match capability. Doing so is beyond the scope of the project.

Ok. From above point, if we are providing all the unique existing records in combo boxes as name/location then this does'nt have much use right.

3) I don't like the browse all button. Can't I get the same effect by blanking out the name and location text fields and pressing the search button?

Both have the same effect George. And now if we are not using TextFields the functinality is provided by selecting "Any" in the both name/location combo boxes. So if CSR has to searach all, he has to select "Any" in both name/location and select the search button. To make search a bit easy, he can just select this button. You think I should change the name from "Browse All"/"Search All" to a different one?

4) I would expect to see the results of my search before I have to see the booking section. I think you might agree if you conduct the experiment I mentioned in 1 above. For each use case it's nice if you can maintain a top to bottom work flow. For example, searching for a record, you start at the search panel, click the search button, see your result set in the JTable (proceeding down the screen). When you book a record you start a the JTable, highlight the row, click the book button, enter the customer id (proceeding down the screen).

Yes, that's right. I did'nt think about it. Thanks.

5) It might be better for errors to be presented to the user in a dialog. This dialog can be made modal if the error is severe enough to warrant this. You can also display a considerable amount of text to the user to explain the error (and maybe how to fix it) if it's necessary.

Yes, I can show it using dialogs too. I saw some tools like websphere show errors at the bottom. So thought so..but again everything we do is for CSR.

6) In real life you probably wouldn't want a menu item with only a single choice, but I understand why that could happen with this assignment. You might consider having File-> Edit Configuration and File-> Quit. Or you might want to replace the menubar and use a toolbar instead possibly having only two items (Edit Configuration and Quit).

I think I will stick with menubar only as from the link given by Andrew, the first reason to fail was no menu bar only. I can add "Edit Configuration" to the file menu. Using this, CSR can change the db location only right in local mode? He cannot configure others like port, host name as he cannot however jump from server to server on the fly. Or should I let him change other configuration like port, host too and next time he starts the application he can use defaults right?

7) I recommend making the frame resizable (with some minimum size you can discover during testing). If you find that it's a substantial amount of work then I think you can get away with setting the frame to not be resizable.

Am still working on this George. I allowed the frame resizing, but most of the layout code is being duplicated in the event handler method(around 100+ lines). Am still working on an alternate solution to do this. Will try for sometime after changing the above things as you said. If its getting more work...will not worry abour resizing then

8) I took two different approaches for exiting depending on whether the application was the client or server. For the client the user could exit by File->Exit, by the Exit menu bar item, or by clicking on the close window decoration.

Me too, same.

For the server the user could exit in the same ways allowed in the client or by pressing a Shutdown Server button.

Yep, I too provided exit button in Server configuration, network client connection and local connection configuration GUI's.

However, in the server, I brought up a confirm dialog to make sure the user wanted to shutdown the server (because of course shutting down the server has an adverse impact on any clients). I don't think this confirmation is really needed, it's just one of a host of things that I did that in retrospect are probably beyond the scope of the project. The confirmation dialog is probably a good example of what you shouldn't do.
I did'nt think of confirmation dialog in the configuration panes, but will definetely add them. Also will try to provide an exit button in the main application somewhere at the bottom, probably far east towards book button.

Thanks George.