- Opportunity Assessment
- Requirements
- Architecture and Off-the-Shelf Software
- Setting Up the Development Environment
- Prototyping the User Interface
- For More Information
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Prototyping the User Interface
We use static WML decks to mock up a typical query sequence for location, price, and style queries. We mock up multi-page result sets and establish the appearance and content of the property details screens for various property types. It's crucial to have real end users (real estate agents) involved in this process.
Figure 2 shows some of the results of our prototyping efforts for the WML user interface, as displayed by the Openwave WAP simulator.
){kind=link}
Figure 2 User interface prototype WAP screens.
On the first three screens, the agent selects a minimum and maximum price as well as a property type. The agent submits this selection, and a results screen is displayed. The results screen either states that no properties were found, or lists properties that match the query. The final screen lists property details.
Figures 3 and 4 show a prototype for the HTML user interface on an Internet Explorer browser. Note that more information is shown on this web prototype than on the WAP version.
){kind=link}
){kind=link}
Figure 3 User interface prototype web screen 1.
Figure 4 User interface prototype web screen 2.
In parallel to the user interface prototyping, we design our application using the Unified Modeling Language (UML) and Rational Rose. The design is simple and consists of two use cases, a domain model, scenarios, and a design class diagram. Figure 5 shows the use cases.
){kind=link}
Figure 5 Use cases.
The "Agent logs in" use case is very simple because we've decided to use HTTP Basic authentication. This type of authentication is automatically supported by the client browser and the web server, so we don't need to analyze this further. The "Agent queries properties" use case extends the login use case the first time that it's run. The steps for "Agent queries properties" are as follows:
Agent specifies price range and type of property.
Agent submits query, which is carried out against real estate data,
If there are results, a summary of matches is displayed, and the user can proceed to step 5.
If there are no results, the user is notified and can resume at step 1.
The user can select a property and view its details or re-query (refer to step 1).
To support this use case, we produce a domain model with three classes. Figure 6 shows a property class that has an address and an associated lot. There are many other ways we could have done this analysis, but we've chosen to group the data associated with the property and dwelling in a single property class, and to separate the lot and address details into separate classes.
){kind=link}
Figure 6 Domain model.
Next we look at the design classes. Figure 7 shows the classes that we finally arrived at to build this service. These were designed based on experience building similar frameworks. The design attempts to clearly separate view, model, and controller.
){kind=link}
Figure 7 Design classes.
The HttpServlet class is the primary controller of user interaction. It orchestrates calls to workflow processing operations and runs the appropriate viewer to display the results of each operation. The Workflow class contains operation methods to accept query parameters, submit queries, and display the results. To provide page generation and error display, a general Viewer class is subclassed by HTML and WML viewers. The model is defined by the Property, Address, and Lot classes, introduced earlier. The MlsBusinessObject wrappers provide access to the model data and in the final version will provide access to a Multiple Listing Service (MLS) database. In our prototype, this class subclasses a translating XML object that provides XML-to-Java translation services. This allows us to work with an easily updated XML test file of properties. The TranslatingXmlObject subclasses an XML object that provides basic XML parsing and element access services. Query and Results classes encapsulate query parameters and property result lists. Finally, an Errors class contains a list of error messages for display to the user.
To make this abstract stuff a bit more concrete, take a look at Figure 8. This is a scenario that contains two user requests. The first request displays a query form.
){kind=link}
Figure 8 Scenario: Agent performs a query.
The agent submits a request (doPost) from her browser that's passed via a web server (not shown) to the HttpServlet. The servlet invokes the getQuery operation that displays a new Wireless Markup Language query page via a call to the WmlViewer. WmlViewer creates an empty query object and merges this object with a query template. (User interface templates are discussed in the next article.) Once the agent fills in the appropriate query fields, she submits another request. This time, a doQuery operation is called, which sets up the query parameters (setMinPrice and setMaxPrice). It then does the query by calling the MlsBusinessObject. This object gets a result set (details not shown) and turns the XML results into a Java object, filtered by the query parameters. The results would then be shown to the agent by another viewPage call (not shown) to the WmlViewer object.
This concludes our introduction to the Real Estate Assistant. The next article explores the Java source code and XSL user interface templates for this service.