Metro Rex Phase Iia Build

User Interface Specifications

Metro Rex Phase IIa Build

User Interface Specifications......

Metro Rex Phase IIa Build......

Executive Summary......

Overview......

About This Document......

Non-Technical Requirements......

Current Site......

Current Database......

Site Prototype......

Other Considerations......

Data Needs......

Overview......

Location Information......

Member Information......

Listing Information......

Site Pages......

Overview......

Error Messages......

Pageanation......

Recognition Bar......

Search (Public) Listings Function......

List of Search Results......

List Detail......

Contact Form......

Member Sign Up Form......

Forgot Username......

Super Admin Log in......

Control Panel......

Add / Edit Listing......

Add Photo......

Print Listings......

Search Co-Brokes......

Co-Broke Detail......

Edit Profile......

Super Control Panel......

Super control Panel : View Listings......

View Stats......

Add / Edit Areas......

Non-Functional Pages......

Executive Summary

Overview

Metro Rex is a real estate exchange currently serving the greater Boston area. The site allows real estate listing agents who have signed up as members to post and manage listings of apartments they have for rent. The general public can then search those listings and call the agent directly. Likewise, other brokers can search for “shared” co-broke listings and call the agent directly. The site is free to use right now, but we will soon be offering the service to brokers on a paid 6-month subscription basis. The general public can always search the site for free.

About This Document

This user interface specification is intended to describe the way that the site needs to work. This document does not address the technical specifications necessary to build the database or technical components of the site. As such, it does not address how the site should be built, but rather what needs to happen on the site.

Non-Technical Requirements

We are assuming the following about site hosting and usage:

the site will be built in php
a mySQL database will house all site data
the site will be hosted at iPowerWeb (
there will be about 100 – 500 registered users in the db
there will be 100 – 3000 apartment listings in the db
there may be 20 or so simultaneous site users
there may be up to 500 site users in a day
cookies are acceptable to use
the site needs to maintain a fair level of security, especially around superadmin screens

Current Site

The current web site was built as an unscalable version of what the new site will be. The site was built in asp using an Access database. Most of the functionality of the new phase II site will be the same as the functionality of the current site. However, some basic updates to the information architecture and functionality have been made to the prototype and are detailed in this document.

Current Database

The current database is a Microsoft Access database. It is our somewhat uninformed opinion that the overall design and structure of the database tables is insufficient. We will look to the site developer to design a better database structure in mySQL. This document will provide all fields needed for the database.

For launch, we will need to move all of the data in the current Access database into the new mySQL database. The site developer will be provided with the current access db file, and will be responsible for ensuring that all data is moved properly into the new database. We would like to view and approve a database diagram for the new site before implementation begins.

Site Prototype

Everything discussed in this document is referencing a prototype of the new web site as desired. The prototype contains all screens and pages of the site as they need to appear on the final web site. There is no database, scripting or business logic of any kind on the prototype; all pages are purely static pages with dummy representational data on each page. (The only two exceptions are javascript buttons to get the correct page href and php includes for common header, footer and some form elements.)

The prototype can be found at . All files will be made available to the selected vendor.

The prototype was built by a front-end design person with some very limited knowledge of back-end coding and no knowledge of database design. Technical decisions such as file format, scripting languages, where and how to break pages down into include files, etc., etc. are at the discretion of the site developer.

However, the final coded site is expected to strictly adhere to the layouts, fonts, classes and design of the prototype. If there are some front-end elements that the selected vendor wishes to discuss changing (for technical reasons, usability, data issues, etc.), those changes can be reviewed by the Metro Rex team. Otherwise, the build of the site will not be considered to be complete if there is any deviation from the prototype design.

Other Considerations

If there are any questions, misunderstandings or confusion over any elements of this document, or if anything has been omitted from this document, the Metro Rex team would be happy to help answer or clarify those issues.

Data Needs

Overview

There are basically three types of data sets that are required for the web site. These are:

location information : the region, cities and city areas the site covers
member information : details on each of the site users
listing information : the details and statistics on each of the rental listings that members can add to the site

There will also be whatever standard data is needed for super administrative access and data reporting.

This section of the document will discuss what data is needed across the web site and what type of data it is. How the data is entered or read out of the db will be discussed in subsequent sections. It is assumed that each location, member and listing will get its own unique id.

Location Information

This is the region, cities and areas that the site covers.

region : The only region for Metro Rex right now is the greater Boston area. However, we expect to move into other regions as the business grows. As such, we wish to have data associated by region. All other location information will be associated with one and only one region. All site members will be associated with one and only one region. All listings will be associated with one and only one region.

For the phase II launch, there will only be one region. This region will be uBOS. The site needs to be able to scale in some way to allow for additional regions. You will notice a hidden field for the region in the php file; you may use this convention or alter the code as needed.

city : A region will have a set of cities associated with it. The list of cities will be decided by Metro Rex staff. There will be about 5 –9 cities for phase II; all of them will be associated with region uBOS.

area : A city may have a sub-set of areas associated with it. An area is a small neighborhood of a given city. There will be from 0 – 15 or so areas associated with each city for phase II launch.

area abbreviation : Each area has a 1 – 5 character abbreviation as well. This is not necessarily the first characters of the area; this needs to be manually selected.

Some cities may not have an area associated with them. Listings may be associated with either a city or an area. Site searching capabilities (to be discussed later) thus need to be able to accommodate searching by an area, by a city (including the aggregate of its areas), or by a city with no associated areas.

Member Information

Each member needs to be associated with a region. The following fields will be captured for each member:

name : text field
role : choose from broker, agent, property manager, or other
phone : text field
mobile : text field
email : text field
fax : text field
user id : 6-10 alphanumeric characters
password : 6-10 alphanumeric characters
office : text field
street : text field
unit # : text field
city / state : text field
zip : numeric
area 1 : select from available cities and areas fields (this does not associate the member with only this city or area; this is just for our sorting and knowledge capture purposes)
areas 2 : same as above
website : text field
signup date : server automatically logs day on which the member information was added to the db
last login : server automatically logs day on which the member last logged in to the web site
total logins : server automatically counts how many total times a user has logged in to the web site
status : can be paid, active, pending, or inactive

There is also one extra field called membermessage. This is a message that the superadmin can enter brief text, which will be displayed on the control panel for all users.

Listing Information

Each listing will be associated with a particular member (and as such, with a particular region). The fields are:

area : select from available cities and areas fields. The listing will then become associated with that particular area (if any) and the city with which that area is associated, or with just the city selected.
location : text field
rent : numeric
floor : choose from none selected, basement, 1, 2, 3… 8, penthouse
avail date : month and day (automatically log year)
beds : choose studio, 1, 1+, 2 – 5
baths : choose 1, 2, 3, 4
laundry : choose none, in unit, basement
parking : none, avail rent, outside, indoor
pets : choose yes, no, maybe
comments : open text
client fee : text field
list type : choose co-broke, exclusive, inactive
cb/dir : choose none, half, direct
contact : text field
phone : text field
mobile : text field
email : text field
address : text field
landlord: text field
landlord phone: text field
tenant : text field
tenant phone : text field
additional : open text
photo 1 : jpeg or gif
photo 2 : jpeg or gif
photo 3 : jpeg or gif
photo 4 : jpeg or gif
date created : server automatically logs day on which the listing was added
date created : server automatically logs day on which the listing was last edited or changed
date made active : server automatically logs day on which the listing was turned active co-broke or direct type
date made inactive : server automatically logs day on which the listing was turned from active to inactive
total views : server automatically counts every time a listing is viewed on the site (detail.php or cbdetail.php page)

If there are additional fields that are considered to be standard for the type of site we are building, we welcome comments and suggestions from the developer.

Most of the Member Information fields will be used for new member signup, member profiles and superadmin usage. Most of the Listing Information fields will be used by members for posting or for the public listings, as well as for the superadmin and statistics compilation.

More on how these fields will be used will be described on a page by page level.

Site Pages

Overview

There are currently about 25 page files in the prototype. The majority of these are static pages that require no work on the part of the developers. There are also 7 include files, 1 style sheet, and nine images.

All of the page files (with two exceptions) are calling three include files and one style sheet:

includes/header.php : has some html elements and the logo
includes/navbar.php : has the main navigation links
includes/recognize.php : has the bar that will either prompt login or allow logout (is currently using php)
includes/footer.php : has the bottom bars with copyright info
main.css : defines all styles for every element across the site

The other include files that exist in the prototype are currently:

includes/loginbox.php : has the username and password input bosex and button to allow users to log in
includes/selcity.php : has a hidden input field and selectbox for cities and regions
includes/selsize.php : has a selectbox for number of beds

Error Messages

On any form pages, there should be a standard way to display error messages. All forms will have some introductory text. Any error message should be displayed immediately after the introductory text, in the same paragraph. The error message should use “class=ero” to define the appearance of the message. It is essential that error recovery on a form not cause loss of data already entered.

Pageanation

No pages on the site should pageanate. All search results and data pulled from the server should always show on a single page. However, if there is any concern about download time to include all of the possible data on a single page, we may need to consider the possibility for pageanation.

Recognition Bar

found at /includes/recognize.php

The recognition page is an include that represents the colored bar at the top of every main page on the site underneath the navigation bar. This page checks whether the user is logged in or not in the session, and changes its message based on login or location on the site. The prototype currently somewhat fakes the four possible states for the recognition bar, as it should appear. The following states should occur:

public pages / not logged in : If the user is not logged in and is on any of the pages currently in the root folder, the recognition bar will simply include a line of text.

broker pages / not logged in : If the user is not logged in and is on any of the pages in the mkt folder, the bar should provide a link to allow the user to login or a button to go to the signup page. The user will not have access to any My Rex pages in the adm folder of the web site.

user logged in : If the user is logged in, the bar will have a link to the control panel, display the name of the account logged in to, and include a logout button. The background image of the bar should change from sky to orange.

superadmin logged in : If the superadministrator for the site is logged in, the bar should have a link to the super control panel, and should include a logout button. The background image of the bar should change from sky to orange. (This state is not currently shown in the prototype.)

Search (Public) Listings Function

found on index.php, search.php and list.php. functionality being called from includes/selcity.php and includes/selsize.php

The search listings functionality allows users to find active co-broke listings from the database. The user is able to choose either a city or an area on which to search. (An all area feature will also be available, but only to the superadmin.) There will only be one region available to search from (uBOS). This should be used as a hidden search parameter, so that the site in the future can allow for multiple regions. A select box will display the list of all cities and areas in that region from which the user can choose. This list should be auto-generated based on the cities and areas in the db. The user can also choose the number of beds on which to search. The default choice will be any.

In the very near future, we will also want to add a search parameter by rent. The values for the search would be:

any
under $1000
$1000 – 1300
$1300 – 1500
$1500 – 1800
$1800 – 2100
over $2100

We would like to add this functionality in to the scripting now, but use a hidden input field set to ‘all’. This will allow us to easily turn on this functionality later.

List of Search Results

found on list.php NOTE: list.php and search.php are the same page; one has the search results, the other is the page with help text in lieu of the results.

When the user performs the search, a list of search results will be displayed. The results will find all active co-broke and exclusive listings that are in the database and that match the search parameters that the user has set. The list feature should not ever display inactive listings.

The intro text on the page should display the date on which the search was performed (current date). The select boxes for city/area and for beds should show the terms upon which the user searched (e.g., if the search was for Back Bay, 2 beds, the first select should default to Back Bay, the second to 2).

The following data should be pulled from the database for all matching listings:

area abbreviation
location
available date
rent
beds
baths
pets
office name
whether there is at least 1 picture associated with the listing

Each of the rows should then display the information from the db for each of these fields. Note that some of these fields display somewhat differently than simply as they are in the database.