Hi Chris,
Thanks for taking a look.
On Mon, Dec 19, 2011 at 09:54:54AM +0000, Chris Smith wrote:
> On 18/12/2011 21:06, Andy Smith wrote:
> > An address will at its simplest be a name and an entry name, so the
> > user can distinguish different addresses from each other without
> > having to read all the details, e.g. "Me (Work)".
>
> How is this going to be used and by whom? Is it just a PIM tool for the
> user or will others be able to query it -- you mention 'emergency
> contact' below, which implies query by others?
It's for a company to contact its customers in ways that the
customers want to be contacted. So they can have some contacts who
deal with billing, others who deal with technical queries about the
service, and so on.
> What about scale: how many users do you expect?
More than 100, less than 10,000.
I would expect there to be an average of between 1 and 2 contacts
per user. The vast majority of users will have a single contact that
is used for every purpose. There will be an occasional user who
requires separate contacts for billing, etc.
> > The point is, it won't be possible to enumerate all possible address
> > details that could ever be useful, so they can't be columns of a
> > database table.
> >
> > The different purposes might be things like:
> >
> > - billing
> > - emergency contact
> > - technical contact
> >
> > Each purpose would have different address details that were
> > required. For example, "billing" might require at least an email
> > address and postal address while "emergency contact" might require
> > at least a mobile phone number and email address. The applications
> > will have to enforce that.
>
> Required by whom?
The service provider is going to have certain minimum requirements
for contact. For example, a billing contact will need to have an
email address (for delivery of emailed invoices), a postal address
(for delivery of posted invoices, and to track them down if they
don't pay).
So it is the service provider who will set the minimum requirements
and the apps will have to enforce this.
I can imagine that the user may add a mobile phone number or a
jabber id to the billing contact and then *optionally* the system
could warn them about billing stuff via those means also. For
example, they might get a courtesy SMS or jabber notification if
their service is about to be suspended for non-payment.
There are actual feature requests by the users for this
functionality, so I'm confident I am not getting excited and
imagining it. :-) However, all that "send an SMS, try their Jabber"
fluff is of less importance than the mere functionality of having
multiple contacts with email and postal addresses. So that must come
first and the other stuff later. I just want to leave the way open
for it.
> Please don't confuse what *you* consider required
> information with what the *user* considers to be required. If you do,
> you'll end up with subverted entries, e.g. a normal entry with a
> nickname 'Emergency contact' and no phone number or, worse, an emergency
> contact with a bogus phone number.
The app will have to enforce the minimums like an emergency contact
always having a phone number.
Ultimately users can't be forced to keep contact details up to date
or accurate, but at the moment the existing user database has merely
a single email address and a single postal address.
When the user really needs to be contacted by the service provider
it would be nice to be able to try a few other supplied email
addresses and phone numbers, especially if the user has indicated
that they are emergency contacts. The next step after that is often
suspending the service...
> I am consistently irritated by online shops that insist on a phone
> number 'in case something goes wrong with your order'. I don't want
> them to phone me, ever. Not under any circumstances. They have my
> email address (begrudgingly, but that's another rant) and that is
> sufficient.
This is already a strictly "no phone calls" operation, but
unfortunately people often don't read their email or they use email
providers who are happy to accept the mail for delivery and then
send it to /dev/null.
People can get upset when their service is suspended due to
non-payment and then they later discover that 6 weeks of late
payment reminders and final warnings were dropped on the floor by
their email provider.
Yes, this is not the service provider's fault. Yes, this is the
user's fault, especially if they then continue using the same email
provider. However, chasing non-payment is a loss-making activity and
having to suspend someone's service can be taken very personally. If
it could be fixed by a simple SMS, direct message, alternate email
or—shudder—speaking to someone on the phone then that seems like a
win.
This basic functionality is the most-requested thing at the moment.
It is hard to get implementation details out of people though.
You really can't appreciate just how bad email is in the modern
Internet until you have customers that you can only contact by email.
If something goes wrong with something they've paid money for, and
you can't reach them by email, the majority of the time this is user
error or email provider failure. The customer however does not say,
"sorry you couldn't email me, thanks for all your effort". They say,
"I never got these emails, your system is broken, why didn't you
phone me?" :-)
So I can understand why an online shop asks for a phone number. My
system will not require phone numbers or anything else besides email
address and postal address. But users *want* to provide phone
numbers, and if they do I will make it use them where appropriate.
> > .----------------------------------------------------------------.
> > |addr_book |
> > +----------------------------------------------------------------+
> > |id Primary key |
> > |user_id Foreign key to the users table |
> > `----------------------------------------------------------------'
>
> How many address books do you expect most people to need? Rather than a
> hierarchical design, perhaps it would be better to have a tag/keyword
> based design. There are quite a few entries in my address book that
> don't fit neatly into one category (a friend and a colleague, for
> example) and I find that a hierarchical design imposes artificial
> boundaries in this case.
I was expecting just one. Good point. The addr_book table can be
done away with and just put the user_id in ab_entry.
> > .----------------------------------------------------------------.
> > |ab_entry |
> > +----------------------------------------------------------------+
> > |id Primary key |
> > |ab_id Foreign key to addr_book table |
> > |name Name of the person this entry relates to |
> > |nickname Nickname for the entry, e.g. "Me (Work)" |
> > `----------------------------------------------------------------'
> [...]
> > In some ways this seems excessive - I mean, there's a four way join
> > there, just to get a list of email addresses.
>
> Again, what is the scale of this? How many users, queries, updates?
> Joins aren't that big a deal if your indexes are well chosen, but
> perhaps it might be better to put the 'usual' data as columns in
> ab_entry, leaving abe_detail for additional data. That way you get an
> efficient summary lookup.
Yeah I think you're right, it should be fine. Was just wondering if
I was going over the top with it.
It will still be the most complex set of relationships in the
application as it stands (there are some three way joins in other
parts), but I guess that is human beings for you; always complicate
matters. :)
Cheers,
Andy
--
Please post to: Hampshire@???
Web Interface:
https://mailman.lug.org.uk/mailman/listinfo/hampshire
LUG URL:
http://www.hantslug.org.uk
--------------------------------------------------------------
