Originally posted by Satish Avadhanam:
Guys, one very quick question. Must we make the window size resizable.
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.
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
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.
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.
Assuming you use combo boxes for your search criteria, display the JTable with suitable column widths...
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.
Originally posted by George Marinkovich:
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.
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.