Loading Profile...
How do you plan to support matching of fields that Outlook has no room for?
For instance: I have contacts with more than 2 Home telephone numbers, and/or with more than 1 mobile number (oh, crap, it's so essential nowadays!)
I've established new connection with outlook who has an empty contact list. Then synced.
Now what I get? Extra telephone numbers that just do not fit into the tight Outlook room are simply thrown away!
Let me tell you a secret: I'm deeply convinced that Outlook contact internal data model is flawed to the core. It is a nightmare to match with, say Apple Adressbook (which relies on time-proof industry standard vcf). But still, guys, you HAVE to have a matching plan for these cases! Say, each extra mobile number is going to be stored in Other, than Radio, than Callback, that Car, etc. Plus it is essential then to keep track of these links on your side in order not to mess up the next sync.
My luck I'm not relying heavily on Outlook. What a lucky person I am...
I've established new connection with outlook who has an empty contact list. Then synced.
Now what I get? Extra telephone numbers that just do not fit into the tight Outlook room are simply thrown away!
Let me tell you a secret: I'm deeply convinced that Outlook contact internal data model is flawed to the core. It is a nightmare to match with, say Apple Adressbook (which relies on time-proof industry standard vcf). But still, guys, you HAVE to have a matching plan for these cases! Say, each extra mobile number is going to be stored in Other, than Radio, than Callback, that Car, etc. Plus it is essential then to keep track of these links on your side in order not to mess up the next sync.
My luck I'm not relying heavily on Outlook. What a lucky person I am...
I’m amused
3
people have this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
-
Inappropriate?Ilia,
good reasoning! We do though go at it this different. Outlook is not the only client/device that behaves this way. We do have the same issue with the Blackberry for example. What we will do is send on of the "Home" numbers and not send the other. We will then remember which one we did send. On receiving a changed contact from the client we will than look at the original and see what has changed. We then piece the contact back together with the changed data.
We do realize that not all info than makes it to all clients. But the user then can decide to do tweaking with the labels. We don't like to do that.
But it will always be a work around, and never a perfect solution.
I’m happy somebody finally understands what we are up against!
-
Inappropriate?Wow.
A questionable decision. I bet people do not expect to see such behaviour from the service which is labeled "hassle-free". I suggest you should explicitly tell this to your users however hard it may be.
Frankly speaking, if I wasn't aware of how dangerous it is to mess with Outlook (and now BlackBerry, thanks!), I would be enough angry with such an answer. Because you actually corner the user giving him only two options: either monkey around with trick-and-tweak, or simply throw your business app/business phone away...
I belive that still my solution is better "workaround" for a user. With all due respect and understanding that you don't have time for everything, it seems to me that "We don't like to do that" actually means "We don't want to do that".
I’m wishing you good luck
-
Inappropriate?Ilia, thanks for your feedback and thinking about this with us.
Let me clarify what Bart meant with "We don't like to do that". It really is a case of that we cannot make a decision about what labels should map to what fields in Outlook for the user. What we should be doing a lot better is explaining which labels will not make it to Outlook so that the user can make intelligent choices.
However we are working on a solution where most common labels (Work, Home, Mobile, Fax, Other) get sent correctly and in the expected fields in Outlook. Sometimes though there are tricky fields and custom fields. We have no way of knowing where we should put custom fields. Especially if a user changes that field in Outlook and then wants it synced back with the same custom label? Or could be that the user actually wanted it to be in the field it was mapped to in Outlook? See the problem?
Another possible solution is to provide the user with a choice about which labels in Soocial are mapped to which labels in all their corresponding connections. That would give the user the option to choose how their contact data is synced without losing any information -- however requires a bit of work on our part to give the user these options. Up till now we haven't had that many requests for this functionality as the common labels mentioned above do the trick for nearly all cases.
You mention you often have contacts that have more than 2 personal (or Home), 2 work and 1 mobile number. This totally makes sense, why Outlook supports 3 fax numbers but only 1 mobile is beyond me.
On the short term we will be updating our webapp to have a better way of supporting labels in the webapp, because right now frankly we do a bad job of that.
I’m hoping we can give you a suitable solution to the labels in Outlook
1 person says
this answers the question
-
Inappropriate?Thanks, Stefan. Thanks, Bart.
That pretty much explains everything.
I guess my frustration could be explained because I thought that Bart's responce was sorta final vision, a principle position. I'm happy you proved me wrong.
Sure thing, if webapp (or outlook client) could explicitly give the user power to match custom labels it would be awesome. And sure thing it takes a lot of time to develop. But your vector is pointing in right direction.
However, as about the problem of uncertainty described by Stefan, I really was aware of it, and i do know how to solve it. I could easely take you into details if you want ;)
Still, it may be irrelevant, 'cause the explicit matching could be the best solution of all.
I’m confident that you'll do your best, guys!
2 Comments Add a comment
This answers the question
-
Ilia, I'd love to hear your (detailed) thoughts about how to solve it. We can always take it into consideration! -
The trick is to treat field values as self descriptive.
Once being created, we can always remember its original "position" (i.e. label).
Then, if we will track the values themselves, we will understand what happens
to these values much better.
Even if the user will change its label (i.e. "move" it) - we should treat its new
label explicitly and change it in soocial accordingly, without any regards to our field-mapping.
Something like this. Maybe I wil need some fancy diagram to clarify myself. -
Inappropriate?Are you planning to release a chart of the field matching that you are currently doing for various connectors?
I’m excited
-
Inappropriate?We're working on this issue and I guess that when we're done we can put up the mappings chart somewhere so that users can take a look!
I’m happy
1 person says
this answers the question
EMPLOYEE
EMPLOYEE
EMPLOYEE
