Fig. 1 - Buyer Search Screen
The proposed system is centered around the screens that are used to enter the data and our comments are organized based on those screens.
When in buyer/guest mode they should not be able to see the exit button at all. Is it possible to remove or hide the exit button when in buyer/guest mode?
To assist the buyer in entering a search and to reduce the amount of help on the help screen, can we have little instructions on the screen to assist the buyer in getting started? Maybe a little block of text at the top on how to get started, and as you move the mouse over a field it will tell you what to do in a little box along the bottom.
Can we reduce the number of list boxes they have to go through by having predefined ranges? Ranges for price, square feet, age. ie:
$80,000 - $100,000
$100,000 - $125,000
etc.
The buyer would pick one of these ranges.
There should be no defaults when the buyer enters a search. If the buyer was not paying attention to their search, it could limit their results. All fields should be blank when performing a search and they only enter the data that is important to their search.
Can we add realtor functions to this screen when in realtor mode? This means that we would not need the realtor screen that you proposed. The realtor should be able to search for houses in the same manner as the buyer.
We need to have the House's ID number visible on this screen. The buyer needs to be able to identify a specific house to a realtor.
The buyer should also be able to see properties that have been sold in the last two weeks. If the buyer comes in one day, looks at a property, comes back a few days later and looks for the same property the system should tell them it has been sold.
Can we add realtor functions to the Listing Information Screen. The realtor should be able to update, create, add comments to a listing right from this screen.
This screen is no longer needed as it has been proposed. The search screen and the listing screen should contain all the realtor functions. However, there should be a screen for the administrator that contains the functions specific to the administrator.
It is important, especially in the buyer mode, that the error messages be as helpful as possible. In your proposal, if there are no houses found for a set of requirements the message "NOT FOUND" is displayed. The system should instead be able to tell the buyer that no houses that meet their requirements are listed, and that they should change their requirements or ask for assistance.
There are still a few questions concerning the security of the data. This issue is addressed indirectly through the use of login names for users. Id's will keep people from tampering with data that is not their own while using the application. Is it possible for one of our realtors to exit the program, start up Access or some other database program, import the data into their database, edit it, then save it back to it's original location? We ask this because a few of our realtors are quite familiar with Access and other database packages and this would not be beyond them. If the database itself were not protected then we would have to look at getting a secondary security system that would lock directories.
| what we are proposing | what might be desirable |
|---|---|
| only four regions within a city are defined - the northwest,northeast, southwest, and southeast quadrants | finer map resolution, i.e. more regions available from which to select; perhaps even several levels of map, from quad to neighbourhood |
| it is possible to select only zero or one region in the city for any one given search | make it possible to select any of the regions independently of any other selection that has been made |
| it is possible to select only zero or one property style for any one given search | make it possible to select any property style (e.g. bungalow or duplex) independently of other ones |
| many controls are cryptic in function, having only single words as labels | rename the controls according to a schema that is perhaps further from the Windows standard |
| searches are static: criteria are entered and then a "search" control is invoked | make searches dynamic: criteria are entered which become real-time constraints on the set of matches |
The two tables in section 3.6, one of which has been included, are confusing. The format of these tables makes them hard to read and the points they raise are rather cryptic. Are these items that are in the proposal but you won't have time to implement them? Could they be implemented at a later date or are they impossible? These tables will have to be clarified for us.
Thank you once again for your proposal. We look forward to hearing back from you.