Really nice example of a web GUI. And I have to say it looks so much nicer and more contemporary than the Swing application. Great job, Andrew!
Andrew Monkhouse wrote:I have started work on an example of this.
No! The JTable has a column holding the customer-id. if this field is empty for a record, the room is bookable. Otherwise the room is booked. Simple and easy. Disabling the book-button is just a part of my restrictive gui: don't allow the user to click a button, perform an action if it is not allowed or if it the action is useless (booking an already booked room)
Bernd Wollny wrote:In your case the user has to mark that entry first to see if that record is booked right?
Roel De Nijs wrote:The JTable has a column holding the customer-id. if this field is empty for a record, the room is bookable
Roberto Perillo wrote:
Because if it is as in MVC, then you can consider "model" and "business layer" the same thing (even though they are different things, if we take these concepts too seriously).
Of course this is also possible in my application, resulting in all (valid) records being shown in the JTable.
You don't have to use the JTextFields in my design, if you don't want to; just press Search.
No, not really. You did a great job I prefer a consistent experience for the CSR (so he will easily get used to the application). So the dialog to enter the customer-id will also be used to confirm deletion, update of other fields, unbook, create a new record,... (when added to the application of course). All these actions will be represented by a row with buttons below the JTable.
Do you have any comments about using the "VK_ENTER" key to capture changes to the JTable?
Roel De Nijs wrote:Hi Harry,
I don't use menus, because my application simply don't need them. If you want to search, simply enter the text in one (or both) of the text fields. If you want to book a room, simply click on the book-button (after you have selected a room, otherwise button won't be enabled). My main window always has the same layout and controls on it, so a CSR will be very familiar with the application (no panels appearing or disappearing). And he can book a room very quickly (in my opinion very important, because a customer calls to book a room and I always hate it myself when I have to wait because the computer/application reacts very slow when I call or get called for some booking or inquiry). A CSR types hotel name, presses enter, a list with matching rooms appear, he selects one, clicks on the book-button, enters the customer-id in a seperate dialog and confirms by pressing ok and the room is booked.
I just used a plain text help document, so no online help nor a fancy html-document with several pictures. My user guide is just as my application: easy and simple And because my application is very intuitive (if I may say so myself), it needs not a whole lot of explanation and screen shots to explain the working of the application.
Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.
Jianping Wang wrote:I think your design may be hard to make functionality enhancements like adding cancellation of reservation. My opinion is we may need a tab or toolbar something like that so we can easily add a button to go to another interface.