979866 - add multiple date support to mozContact

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Contacts, defect, P5)

Description

[Jose Manuel Cantera]

As per the latest discussions and to honor UX specifications We need to be able to store multiple dates in a mozContact not only the birthday and one anniversary but multiple dates

There are many different anniversaries - 'anniversary' is just a generic term
anniversaries of marriage, death, joining work, the list is endless
On the other hand enabling custom types will help to disambiguate such anniversaries
its all about flexibility of use

The idea is to have a new field called date that will be an array of objects, following a similar structure than we have for other multiple fields (phone, email, etc.). 

date[{
  type: ['anniversary'],
  value: Date
}, {
}]

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't think creating a property that holds all metadata that uses a particular type will work that well.

First of all it feels inconsistent. Why are we doing this specifically for metadata that happens to have the type Date? Why not create a property that contains all string metadata as well? Or all integer metadata?

The second problem is that allowing arbitrary named types means that we're abandoning any schema. I.e. applications can now create arbitrarily named metadata that will not be understood by other applications. Even if they are both trying to deal with marriage dates, one might call it "marriage" and the other "bröllopsdag".


My understanding of the current spec is that "anniversary" is for marriage anniversaries.

If we want to store other dates, lets just add normal properties for those. So we could add a .death property and a .startedWork property.

How are you planning on using those though?

Comment 2

[Tantek Çelik]

Agreed with Jonas's opinion above in general.

In particular "per the latest discussions and to honor UX specifications" is insufficient for this.

Please provide specific use-cases for specific dates so we can see if there already are properties for this in vCard4 (or extensions, e.g. death date is in there IIRC, I don't remember the exact property name offhand) to incorporate, or if new properties are needed.

Thanks.

Comment 3

[Jose Manuel Cantera]

(In reply to Tantek Çelik from comment #2)
> Agreed with Jonas's opinion above in general.
> 
> In particular "per the latest discussions and to honor UX specifications" is
> insufficient for this.
> 
> Please provide specific use-cases for specific dates so we can see if there
> already are properties for this in vCard4 (or extensions, e.g. death date is
> in there IIRC, I don't remember the exact property name offhand) to
> incorporate, or if new properties are needed.
> 
> Thanks.

Ayman, from UX, suggested this multiple dates feature, so he can clarify more about the use cases

Comment 4

[ayman maat :maat]

There are two sides to this: From a purely programaticle PoV with an eye on data management and cleanliness I completely agree with you. However the practicalities of doing this are not great for the UX. TBH if we tried to pre define lists of possible date types this would result to a long and uncomfortable to consume list bing presented to the end user with lots us redundancy in it. A majority of the items in the list would not be used. Secondly if you take a look at date fields assigned to Contact Detail cards from primary, secondary and tertiary competitors a lot of them (not all, but a lot of them) list birthday, anniversary and have a custom field as their labelling options. This is because trying to preempt what the labels should be in these date lists leads to precisely this situation of long, unconsumable lists with largely redundant fields being offered… Which is one reason why we have gone for the proposed solution

The other reason is where we can take the Contacts application. Currently our applications are quite siloed. I have said before too many times, and I will repeat here again: the Contacts App needs a complete UX overhaul. At this point the question of what a Contacts app is …and what a Contacts App could be should be addressed. I can envisage the Contacts app not just being the container for all entry points to contact/communicate with single contact which it is at the moment, but to becoming the aggregator for all Entries related to a contact from wherever on the system. If we scale back now and think of date and date in relation to an event in the Calendar app it becomes clearer that a greater flexibility of usage is required. 

I understand that in terms of Product road mapping we are a long way off this, but I would always champion the strategy of putting down the roots for it now, in the enhancements we are currently making.

Comment 5

[Jose Manuel Cantera]

I agree on keeping the fields 'bday' and 'anniversary' as they are. However Ayman has provided good practical reasons for having more fields in the contact data model devoted to dates. So here my proposal would be to add another field called 'otherDates' with an structure of <type, value> as proposed in comment #1. 

That can be a quick win in the short term. With regards to postpone this to datastore evolution it is true that once we have datastores everywhere in contacts, our data model will be more extensible, however on the other hand we can lose standardization, as different providers may use different field names for extra dates. That's why my proposal is to add another field to mozContact called 'extraDates' or 'otherDates' to capture what Ayman is describing thoroughly. 

Please let me know if you agree with this proposal. 

thanks

Comment 6

[(no longer active)]

(In reply to Jose M. Cantera from comment #5)
> I agree on keeping the fields 'bday' and 'anniversary' as they are. However
> Ayman has provided good practical reasons for having more fields in the
> contact data model devoted to dates. So here my proposal would be to add
> another field called 'otherDates' with an structure of <type, value> as
> proposed in comment #1. 

What would |type| be in that case?  Just a string describing what the date is?  What language would the string be in?

Can you please share what you think about the second and third paragraphs of comment 1?

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

If we want to make a contacts app overhaul then we should do that. Definitely don't let what's in the current API stand in the way.

Once we know what we want the UX to look like, or at least what capabilities we want the UX to have, then we can look at what changes we need to make to the API to support that. I'm happy to make any chances needed to the API in order to support the UX capabilities that we want.

However I think that making changes to the API in the hope that it will work for the UX that we're building does not seem like a good idea. It seems very likely that we'll make a bunch of changes and then it still doesn't end up supporting the UX we want.

For example, if we want to allow the contacts app to manage contacts lists provided by other apps (such as facebook/gmail), then I think we should switch to putting contacts in DataStore (something that we likely want to do anyway).

If we switch to DataStore, that means that it becomes much less important to add fields to the contacts API since applications can easily add arbitrary metadata to the data available in DataStore.

But if all that we want to do is to allow adding arbitrary dates to the UX that we currently have, then that likely means making much smaller changes to the existing API.

So lets start by looking at what UX that we want to build.

Comment 8

[Tantek Çelik]

R+ to sicking's comment. Complete agreed with everything Jonas said. Specific UX mocks first is the right order.

Comment 9

[Jose Manuel Cantera]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #6)
> (In reply to Jose M. Cantera from comment #5)
> > I agree on keeping the fields 'bday' and 'anniversary' as they are. However
> > Ayman has provided good practical reasons for having more fields in the
> > contact data model devoted to dates. So here my proposal would be to add
> > another field called 'otherDates' with an structure of <type, value> as
> > proposed in comment #1. 
> 
> What would |type| be in that case?  Just a string describing what the date
> is?  What language would the string be in?
> 
> Can you please share what you think about the second and third paragraphs of
> comment 1?

Well, we have a similar "problem" with other multivalued fields like telephone or email. There are some types that are standardized and other which are not

Comment 10

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

DOM: Contacts isn't used anymore. 
Closing all remaining bugs.