B&S v2.2.3 GUI draft.

[George Lee]

Dear all,

I am designing my GUI for B&S assignment.

Here is my drafted GUI. Please give me some comments.


I have some questions as followings:

1.For the search section, I add 3 search inputs (one combobox for Subcontractor name, one combobox for Location and one textfield for a service). For the comboboxes, the default value is "All" meaning that it doesn't matter what the values for subcontractor name and location. To my understanding, search for other fields(# of staff, hourly rate) are unnecessary, am I right?

2.For the search result table, I add the last column as radio button for selecting a record for booking purpose. Is there any other ways to better achieve that?

3.For the booking section, I add a customer id input field to capture 8-digits number and a button for booking action. Are there any way to do that?

Your comments are welcome

Thanks
George (HK)

[ June 27, 2007: Message edited by: George Lee ]

[ June 27, 2007: Message edited by: George Lee ]
[ June 27, 2007: Message edited by: George Lee ]

[Mark Smyth]

Originally posted by George Lee:
I am designing my GUI for B&S assignment.


1.For the search section, I add 3 search inputs (one combobox for Subcontractor name, one combobox for Location and one textfield for a service). For the comboboxes, the default value is "All" meaning that it doesn't matter what the values for subcontractor name and location. To my understanding, search for other fields(# of staff, hourly rate) are unnecessary, am I right?

I didn't have the B&S project but that sounds about right to me. For UrlyBird you just needed to search on the name and location fields.

2.For the search result table, I add the last column as radio button for selecting a record for booking purpose. Is there any other ways to better achieve that?

When you click on a row in the JTable the row is is highlighted in the GUI. This would be the best and most conventional way to select a record for booking purposes.

3.For the booking section, I add a customer id input field to capture 8-digits number and a button for booking action. Are there any way to do that?

I don't fully understand what you mean here, do you mean is it possible to achieve this in Swing? The simple answer is yes lots of ways

The basic setup would be a JButton, a JTextField and an ActionHandler to "listen" for the Book Button being pressed.

You can get the ActionHandler for the button to obtain the customer ID from the JTextField when the Book Button is pressed. After this the action handler calls whatever object / method takes care of booking functionality.
[ June 27, 2007: Message edited by: Mark Smyth ]

[George Lee]

Hi Mark,

Thanks for your explanation.

I am still not sure about what search criteria I should include in the GUI.

In the assignment application background section, it states that
"Bodgitt and Scarper, LLC. is a broker of home improvement contractors. They take requests from home owners for a type of service, and offer the homeowner one or more contractors that can provide the required services."

It immediately directs me to think that customers always ask for a kind of service. That is the basic and the most critical search criterion from customer's point of view.

For GUI requirement, it states that
"It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user.
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."

It does mention at least Name and Location searching criteria must be included in GUI. But, it leaves out other possible searching criteria (Number of staff, Hourly charge, Customer ID).

For the DB interface requirement, the following search method must be implemented,
// Returns an array of record numbers that match the specified
// criteria. Field n in the database file is described by
// criteria[n]. A null value in criteria[n] matches any field
// value. A non-null value in criteria[n] matches any field
// value that begins with criteria[n]. (For example, "Fred"
// matches "Fred" or "Freddy".)
public long[] findByCriteria(String[] criteria);

So, from all the above, it seems to me that implementing the interface method findByCriteria() means all the searching criteria must be included. But, for GUI requirement, it is unclear at this point. I can choose to include all the searching criteria in GUI and ends up with the following search GUI:


But, it may be not very useful for users because searching for "Number of staff", "Hourly charge", "Customer ID" may be rather uncommon.

Any comments?

:roll:

Thanks
George (HK)

[ June 27, 2007: Message edited by: George Lee ]
[ June 27, 2007: Message edited by: George Lee ]

[amer khalid]

I have the same project. I was going to allow users to search on any field like in your second gui. Now that you mentioned I am thinking of making a simple search and advanced search screens. And maybe thats another option for you!

Amer

[George Lee]

hi Amer,

Thanks for your idea to include both the simple and advance search GUI.

I read in this forum that some guys prefer to make a search function on another popup window. I am quite doubtful on this choice because it somehow have negative effects on the usabilities of GUI and user experience. Imagine as an user, every time you want to search for subcontractors for a kind of services, he needs an extra click on a [SEARCH] button to popup a search window.

I will keep the simple search on the original window and add a [Advanced Search] button for popup search window. I suppose most of the users will find the simple search sufficient enough to handle the simple SEARCH-SELECT-BOOK action.

How do you think?

Thanks
George (HK)

[Gabriel Vargas]

Hi George,

In the assignment application background section, it states that
"Bodgitt and Scarper, LLC. is a broker of home improvement contractors. They take requests from home owners for a type of service, and offer the homeowner one or more contractors that can provide the required services."

It immediately directs me to think that customers always ask for a kind of service. That is the basic and the most critical search criterion from customer's point of view.

For GUI requirement, it states that
"It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user.
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."

In my interpretation (after read another threads) bussines rules talks about customers offers services, but in interface specification only is expected search records based in name and/or location fields, so if you include service field in you search it can be an extra work not required. An advanced search for all fields can be a good idea in real world but it also is not required and can be considered an extra work, (look carefully your specifications). I hope it hep you.
[ June 28, 2007: Message edited by: Gabriel Vargas ]

[Nina Binde]

I think Gabriel is right that we do not have to make it complicated.
I am wondering if we need a combobox for the name and location or is it just enough to provide text boxes for the two fields. We can also have another button to search all records. Any thoughts on this one?

Thanks for your replies.

[George Lee]

Hi Nina,

I agreed to have a simple GUI.

So, it is a good idea to replace the comboboxes for [Name] and [Location] with textboxes.

For [Service] textfield, I will insist to keep it there because it is important for customer service representatives to search for a service requested by customer.

how do you think?

thanks
George (HK)

[Nina Binde]

Hi George,

I had overlooked the type of service. But you are right, in real world we do need a search text box for that without which the GUI doesn't make much sense for the customer.
The interface definition for findByCriteria doesn't seem to support the above thought. Like for example, they say Fred matches Fred or Freddy, etc...If we have this for a service:
roofing,painting,plumbing
and you search for painting, it does not return this record.

That gives me a clue that we don't need to provide search text box for service. But again, it depends on if you want to reason out in DesignChoices.txt.

[Gabriel Vargas]

Hi,

George:

For [Service] textfield, I will insist to keep it there because it is important for customer service representatives to search for a service requested by customer.

Yes, this is right but again:

"It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user.
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."

I put my two cents about this requerimient. First paragraph tell us about an exact requiriment(I have this assigment too and i'm in process to implement my design). Second paragraph tell us about "future functionality enhancements" like maybe another searchs, for example specialites. With your interface i'm thinking how make a interface than supports these future functionality enhancements, i'm thinking to made (this weekend) an interface composed by two windows, first window contain search fields (I provide also comboboxes ) and the datatable. In second window i will put a "generic" window than can be used for create, update, book and in title put operation (maybe i'll put a status bar but i'm not sure about this ).

Nina:

The interface definition for findByCriteria doesn't seem to support the above thought. Like for example, they say Fred matches Fred or Freddy, etc...If we have this for a service:
roofing,painting,plumbing
and you search for painting, it does not return this record.

I think than a search by painting service in your example would return records than contains this service, not only recors begin with this service (I implement this in this way), I decide that because a search in the service's field have more sense to be made over all services than only with the begin of the string than contains all services.

What do you think about that?
Thanks.

[Muhammad Shafique]

Hi George,

You specification says:

For GUI requirement, it states that
"It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user.
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."

It does mention at least Name and Location searching criteria must be included in GUI. But, it leaves out other possible searching criteria (Number of staff, Hourly charge, Customer ID).

For the DB interface requirement, the following search method must be implemented,
// Returns an array of record numbers that match the specified
// criteria. Field n in the database file is described by
// criteria[n]. A null value in criteria[n] matches any field
// value. A non-null value in criteria[n] matches any field
// value that begins with criteria[n]. (For example, "Fred"
// matches "Fred" or "Freddy".)
public long[] findByCriteria(String[] criteria);

This problem has been discussed for a number of times. You don't need more than two fields on your GUI. You should bring/select all data if both fields are empty (null). As far as future enhancement is concerned think about a separate search GUI, it may be helpful. GUI design should be flexible enough to accommodate those changes easily. Book radio button no your GUI is an extra field. If customer id field is empty it means record is available for sale/book otherwise not. Simplicity saves a lot of time in SCJD and it does heart your grade, for sure!

Goodluck!

Shafique

[Muhammad Shafique]

This problem has been discussed for a number of times. You don't need more than two fields on your SEARCH GUI. You should bring/select all data if both fields are empty (null). As far as future enhancement is concerned think about a separate search GUI, it may be helpful. GUI design should be flexible enough to accommodate those changes easily. Book radio button no your MAIN GUI is an extra field. If customer id field is empty it means record is available for sale/book otherwise not. Simplicity saves a lot of time in SCJD and it does NOT heart your grade, for sure!

Goodluck!

Shafique