NX: Create, delete, and read in GUI

[Jim Thompson]

My requirements, for URLBird, for the User interface, just mention the search and booking a selected record. Does this mean I do not add read, create, and delete in the GUI, and just create those functions for possible future use? I will use read for the update function, but not use the create and delete in my project.

[Nicholas Cheung]

Hi Jim,

My requirements, for URLBird, for the User interface, just mention the search and booking a selected record. Does this mean I do not add read, create, and delete in the GUI, and just create those functions for possible future use?

YES. My GUI contains only 2 buttons, for search and book.
I even do not provide the user those "not being used" buttons.

I will use read for the update function, but not use the create and delete in my project.

I guess we need to implement all functions that declare in the interface that provided by SUN, even though those functions are not being called.
Nick.

[Xie Ruchang]

Hi,
I have on top of [Search] and [Book] buttons, a [Unbook] button in case customer cancel booking over the phone or CSR book wrongly. The argument against this approach is what happens if another CSR deliberately unbook a booking and give it to another? Since there is no security, this feature is given and used based on TRUST.
The nice thing about this feature is that you can test the program easily by booking and unbooking with searching.
Best Regards

[Jim Thompson]

Thanks

[Philippe Maquet]

Hi Frankie,

I have on top of [Search] and [Book] buttons, a [Unbook] button in case customer cancel booking over the phone or CSR book wrongly. The argument against this approach is what happens if another CSR deliberately unbook a booking and give it to another? Since there is no security, this feature is given and used based on TRUST.
The nice thing about this feature is that you can test the program easily by booking and unbooking with searching.

As you say, your Unbook solution has pros and cons, and because of the latter you could loose points IMO.
So what about an "Undo" feature instead ? If you hide your "Unbook" button, keep the unbook code and maintain a stack of the last bookings client-side, I think you can implement an Edit|Undo command very easily.
Best,
Phil.

[Xie Ruchang]

From the perspective of GUI Design, undo is only for those operations that are not persistent. After booking, database has been changed, there shouldn't be an undo function. The ACID principle tells us that a transaction has to be durable, cannot undo. It is a good design before committing the booking to the database to ask the user for confirmation.
Whether have unbook function or not, the same inherent problem of security exists, so that is not the issue and I don't think marks will be deducted IMO.
Usually, in Use Case Analysis, when we describe "Book Accomodation" use case, it can includes CRUD. (Create, Replace, Update and Delete). So I think I can adequate justify my decision.
Regards

[Philippe Maquet]

Hi Frankie,

From the perspective of GUI Design, undo is only for those operations that are not persistent. After booking, database has been changed, there shouldn't be an undo function. The ACID principle tells us that a transaction has to be durable, cannot undo. It is a good design before committing the booking to the database to ask the user for confirmation.

The most important thing with GUI Design (and it goes over all GUI design principles IMO) is ... giving the user the best possible experience (in on other words make a user-friendly GUI).
The problems with confirmation message boxes are that

they make user's work slow

they are inefficient

Slow, because they force the user to confirm all operations, even the correct ones.
Inefficient, because after 2 days working fulltime, an average CSR will even not read the message box anymore : he will just press "Enter" or click on "Yes".
But anyway, Frankie, what are the differences between "Unbook" and "Undo" after all ?
Unbook is an *additional functionality*. Your client didn't ask for it and may accept it or ... not. And in this context, the fact that a CSR is able to cancel bookings made by another CSR is probably a feature.
Undo is *an additional feature of an existing functionality*. It's just another way to provide the "Book" functionality, without the need of a confirmation message box and with enhanced security (against mistakes which can be corrected).
Regards,
Phil.