Metro Rex Phase Iia Build

User Interface Specifications

Metro Rex Phase IIa Build

User Interface Specifications 1

Metro Rex Phase IIa Build 1

Executive Summary 2

Overview 2

About This Document 2

Non-Technical Requirements 2

Current Site 2

Current Database 3

Site Prototype 3

Other Considerations 3

Data Needs 4

Overview 4

Location Information 4

Member Information 5

Listing Information 6

Site Pages 7

Overview 7

Error Messages 7

Pageanation 7

Recognition Bar 8

Search (Public) Listings Function 8

List of Search Results 9

List Detail 10

Contact Form 11

Member Sign Up Form 11

Forgot Username 12

Super Admin Log in 12

Control Panel 12

Add / Edit Listing 13

Add Photo 14

Print Listings 14

Search Co-Brokes 15

Co-Broke Detail 15

Edit Profile 16

Super Control Panel 16

Super control Panel : View Listings 17

View Stats 18

Add / Edit Areas 18

Non-Functional Pages 19

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 (http://www.ipowerweb.com/products/webhosting/index.html)

· 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 www.metrorex.com 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 http://www.jasonlevin.com/mrexiia/ . 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.