Models

[imalexsq]

Here is what we have so far, we need some input on this:

==Manager

• This manages all the properties. Can have multiple users. username, email, firstname, lastname, password(hash), company name, address, city, zipcode, state, website,

== Property

• Belongs to the manager * name, description short(headline), description long, address, city, zipcode, state, county, longitude, latitude, price, sq.ft., bedrooms, bathrooms, type: {single, condo, townhome, rowhome,mobile, multifamily}, yearbuilt, singlestory, multistory, diningrm,famrm, office, basement, loft, hardwood, fireplace, swimmingpool,spa, pets, green, disability,

== PropertyAsset

• Universal model for storing information about the property, like pictures, videos, pdf documents: type (video | image | pdf ), url, width, height, visibility (all | tenants | owner | manager),

== Tenant

• Current/potential tenants of a property * propertyaddress, firstname, lastname, movein, cellnumber, worknumber, email, idnum, idstate, dob, ss.

---

\ Not sure about the following models. We'll have an online application like this one - http://www.managevegas.com/apply.html, what should we do with information like tenant's vehicles? The information in the top part of the app will be used for credit/background checks. The rest will be used for deciding whether to accept an applicant.

Chris' suggestion:

Application --> stores basic information about the application Applicant --> primary, and maybe secondary or even third applicant stored here ApplicantInformation --> more information we need to store, but probably not search. We could store the rest as JSON represented string (think of document database store); we could also try to model every piece of information like creating models ApplicatiantPets, ApplicantCars, .... depends what we are going to do with this information?

[commonlisp]

Each Property may have multiple units, right? In which case, several units (such as singles, 1-, 2-bdrm apartments) may share common property information. There should be a Property --one-to-many--> Unit relationship. What are the common queries we aim to support? A manager may be interested in querying for vacant units, or leases expiring soon. Should there be a Lease table (columns including start date, end date, rent rate, signers, co-signers, parking)? In some areas, appliances are an issue. Not all leases bundle refrigerators and air conditioners. There may be a separate provision for those appliances. In my area, landlords want to avoid the trouble of having to repair or replace them.

Each lessee has her own rent payment history. There may be a service request log (date of request, completion date, requesting tenant, responsible contractor).

Another part of the equation is keeping track of contractors such as gardeners, plumbers, electricians, etc. and their billing history.

We probably should partition the models into a few general groups (though some tables many fall into more than one group). There are at least the Rental Application, Maintenance Request, Lease Renewal, Rent Billing/Payment, Marketing, and Vacancy Query workflows. The Marketing part might be pretty interesting. We can keep track of the effectiveness and expense for each channel.

[SaqibS]

Looks good. It's USA-specific at the moment - we should decide if that's a constraint for the MVP. Some of the details will become more apparent as we progress.

The MVP page explains broadly what features are needed, but I think it'd be good to create a user walkthrough for 2-3 key scenarios - this will dictate which models, views and controls :-) we'll need first.

-----Original Message----- From: Alex Sent: Monday, November 07, 2011 6:43 PM To: SaqibS Subject: [youPM] Models (#2)

Here is what we have so far, we need some input on this:

==Manager

• This manages all the properties. Can have multiple users. username, email, firstname, lastname, password(hash), company name, address, city, zipcode, state, website,

== Property

• Belongs to the manager * name, description short(headline), description long, address, city, zipcode, state, county, longitude, latitude, price, sq.ft., bedrooms, bathrooms, type: {single, condo, townhome, rowhome,mobile, multifamily}, yearbuilt, singlestory, multistory, diningrm,famrm, office, basement, loft, hardwood, fireplace, swimmingpool,spa, pets, green, disability,

== PropertyAsset

• Universal model for storing information about the property, like pictures, videos, pdf documents: type (video | image | pdf ), url, width, height, visibility (all | tenants | owner | manager),

== Tenant

• Current/potential tenants of a property * propertyaddress, firstname, lastname, movein, cellnumber, worknumber, email, idnum, idstate, dob, ss.

---

\ Not sure about the following models. We'll have an online application like this one - http://www.managevegas.com/apply.html, what should we do with information like tenant's vehicles? The information in the top part of the app will be used for credit/background checks. The rest will be used for deciding whether to accept an applicant.

Chris' suggestion:

Application --> stores basic information about the application Applicant --> primary, and maybe secondary or even third applicant stored here ApplicantInformation --> more information we need to store, but probably not search. We could store the rest as JSON represented string (think of document database store); we could also try to model every piece of information like creating models ApplicatiantPets, ApplicantCars, .... depends what we are going to do with this information?

---

Reply to this email directly or view it on GitHub: https://github.com/halixand/youPM/issues/2

[imalexsq]

I call a "manager" the owner of the unit, not necessarily a property manager as that's not who this app would be for. Most managers would own from one to 3-4 units, not more than 20 units, if someone goes over 20 then it would be a property manager, and we can support that eventually, just not now. Searching for properties and tenants and such wouldn't be that big of a deal if you have 2-3 units.

Instead of a search function I'm thinking of a wall feature like what facebook has that would notify the managers of new messages, leases expiring, maintenance requests, scheduled items, etc.

Does that answer your question?

[commonlisp]

Just curious, Saqib: what would be some items that would reduce the US-centricity of the design? Perhaps we don't need to pursue it much for the MVP, but it would be good to keep it in the back of our mind at least.

[SaqibS]

commonlisp: WRT US versus international, a few things which came to mind:

• Addresses should include a country column; zipcode should allow for different types of postcodes; states should accept counties/provinces/etc.
• SS doesn't apply; assume that idnum/idstate are related to ss?
• In UK at least, we don't sell by square footage (or even square metreage).
• Need a flag for furnished/unfurnished.

-----Original Message----- From: commonlisp Sent: Monday, November 07, 2011 8:16 PM To: SaqibS Subject: Re: [youPM] Models (#2)

Just curious, Saqib: what would be some items that would reduce the US-centricity of the design? Perhaps we don't need to pursue it much for the MVP, but it would be good to keep it in the back of our mind at least.

---

Reply to this email directly or view it on GitHub: https://github.com/halixand/youPM/issues/2#issuecomment-2658984

[imalexsq]

My initial idea was to create an MVP that's as simple to create as possible, then to start selling it and go from there.

The larger idea is to one day have a vendor marketplace where owner can assign plumbers, electricians, etc. from a handpicked number of vendors in the system, that are rated from the other managers. There are other features that I have in mind which don't exists in other similar apps, but we need to test this idea first, see how many people pay for it and then work on adding more features.

Let's not go into adding features for overseas owner because it will add complexity to the project at this point.

Would it help if I created some mockups of a few steps?

[commonlisp]

I certainly agree that additional complexity for overseas concerns is not warranted at this point. The MVP doc already looks reasonable to me from a technical standpoint. We may have to tweak the model down the road, but it's probably enough to get started. The accounting part might need some more details, but otherwise it looks like a good starting point. So I don't think we need any mockups at this point, unless the prototype really starts diverging from your vision.

[imalexsq]

I'll do a few mockups anyway since I'll need them for the design.

Here is a github project I've been watching, I know we can't just rip it off, but can we use some of their ideas to make add simple accounting functionality?

https://github.com/huerlisi/bookyt

On Mon, Nov 7, 2011 at 12:43 PM, commonlisp < reply@reply.github.com>wrote:

I certainly agree that additional complexity for overseas concerns is not warranted at this point. The MVP doc already looks reasonable to me from a technical standpoint. We may have to tweak the model down the road, but it's probably enough to get started. The accounting part might need some more details, but otherwise it looks like a good starting point. So I don't think we need any mockups at this point, unless the prototype really starts diverging from your vision.

---

Reply to this email directly or view it on GitHub: https://github.com/halixand/youPM/issues/2#issuecomment-2659359

[SaqibS]

Just thinking on paper (well, in my text editor) - created a [[User Scenarios]] page on the wiki. It may be overkill for this first prototype, but this could be useful to articulate where we're going, and pslit up the work.

doing this upfront will take a little time, but should enable focused coding once we start.

I'm not wedded to the idea if any of you have other ideas. Feel free to add/amend.

-----Original Message----- From: Alex Sent: Monday, November 07, 2011 8:58 PM To: SaqibS Subject: Re: [youPM] Models (#2)

I'll do a few mockups anyway since I'll need them for the design.

Here is a github project I've been watching, I know we can't just rip it off, but can we use some of their ideas to make add simple accounting functionality?

https://github.com/huerlisi/bookyt

On Mon, Nov 7, 2011 at 12:43 PM, commonlisp < reply@reply.github.com>wrote:

I certainly agree that additional complexity for overseas concerns is not warranted at this point. The MVP doc already looks reasonable to me from a technical standpoint. We may have to tweak the model down the road, but it's probably enough to get started. The accounting part might need some more details, but otherwise it looks like a good starting point. So I don't think we need any mockups at this point, unless the prototype really starts diverging from your vision.

---

Reply to this email directly or view it on GitHub: https://github.com/halixand/youPM/issues/2#issuecomment-2659359

---

Reply to this email directly or view it on GitHub: https://github.com/halixand/youPM/issues/2#issuecomment-2659562

[stayhero]

@SaqibS I think that's a good idea.

[imalexsq]

We should add a vendor model too

== Vendor

• Can be assigned to multiple properties ID, CompanyName, MailingAddress, PhoneNumber, FaxNumber, CellNumber, EmergencyPhone, email, website, ContactName, description, services, vendortype{electrician, plumber, locksmith, handyman, glass, hvac, blinds,}

[stayhero]

I added a wiki page. Let's discuss the models here and update the wiki page (that's easier).

Wiki Page for Database Model

[stayhero]

Should we create a separate model for address/contact information? I'm not a friend of a 100% normalized model (among other things because of performance) but we use address very often here.

[commonlisp]

When I was figuring out the routes, it occurred to me that ad management and activities may require their own models. If multiple units are to be advertised in multiple venues, with possibility of reposting, it makes sense to track them. Does that sound reasonable?

[stayhero]

@commonlisp: yes, absolutely.