10 comments

  1. “We can show additional information like the department, title or a photo of Tim Campbell so that the user can confirm that it’s the person he is looking for.”

    The interesting thing is that, without this additional feature, a list of suggestions is close to useless, especially if you end up with more than one suggestion.
    If I can recognize Tim by his phone number or email address, why not let me search by phone number or email address? You could even go so far as to have a few fields to describe Tim’s photo (“male”, “dark hair”, “glasses”, …).

  2. Interesting, I hardly think of those technical solutions, but it does look like it should work.

    Just an idea; When you are new in a company you might know a face, but don’t know the name. Something like “Guess Who?”, where you see a large group of pictures and can filter on variables that will immediately reduce the number of pictures shown, might help you find the name quickly.

    (http://en.wikipedia.org/wiki/Guess_Who%3F)

  3. Vivek, an interesting idea which might not only apply to a people finder, but also to contacts, e.g. in a CRM. The crucial point will be to build the relation between the unsucessful entries and the successful entry. How do you do it – manual by data stewards or using an automated process? Automating it would be the preferred way, but how do you prevent the system from creating wrong matches, e.g. when a person creates several queries in the given timeframe of 20 mins?
    Do you update the matches over time and how do you deal with a larger number of people with the same name?

  4. This is an interesting approach to the problem, but it seems a much simpler and possibly more effective approach would be to search across more fields (as first suggested here by Random Passerby). Users may remember other attributes about the person such as the department or division they are in, their boss’ name, etc. The addition of tags could also be helpful. For example, allowing employees to tag their own profile with relevant attributes such as their area of expertise, current and previous projects or teams they’ve worked on would increase their odds of being found and wouldn’t require a complex matching algorithm on the back-end.

  5. I think the difficulty with this approach is that the quality is dependent in part on users in a certain state of frustration (possibly not their most collaborative moment). Also, it appears that this solution is most effective when input is collected from as many apps as possible – a costly operation at best. Another problem I see is when there are name clashes. The reason Tim Campbell was added as Tim C in the first place is probably because the company already employed a Tim Campbell elsewhere. Search from “Tim Campbell” in that case leads to a success in terms of “found” but it is a false hit. This complicates the overall design significantly.

    How about considering participation from the one person who is best placed to be aware of the problem of findability: Tim C himself? Tim would probably know that people have trouble locating him. Let Tim populate the list of aliases so that others can use it to their advantage. False hits still are a problem, of course.

    The idea of adding more details such as business area, phone number mail ID etc are all very valid – SAP does this all the time with their concept of matchcodes. Take a look at http://web.mit.edu/hr/compensation/quickcards/ASR-matchcode.pdf to see how MIT has implemented people search using SAP.

  6. On Random Passerby’s comments,

    What you are suggesting is to give additional flexibility for searching while my article is about how to make the best out of what the user has provided – i.e. show likely results even if what the user has entered is wrong. As you suggest, we should give him additional choices to search but what happens when the user makes an error while typing the email address? The article is finding ways to make use of these wrong entries so that later similar wrong entries will give desired results. I have given the example of searching by names but you can expand this by including email address or other variables.
    Another thing, you are right that Tim’s Phone Number and Email Address will help users to RECOGNIZE him, but the question I would ask is will user’s REMEMBER the same information (Phone or Email) to be put in the input field?

    On Julius Huijnk’s comments,

    Interesting game Julius, thanks for the link. This is a wonderful idea to include as an advanced search feature. This will be especially useful for multicultural environments where people will have visually distinct characteristics.

    On Alexander’s comments,
    You are right on dot; the crucial point is in making those relations between incorrect and correct entries. In my example I am building those relations automatically based on user’s actions (Clicking add button). This action indicates a correct entry which is tied to the several incorrect entries. For your example you need to identify what Action the user takes after he gets the search results, does he click the name link? does he click a button? does he select the user from a list? etc. You can’t prevent the system from creating wrong matches but you can restrict displaying these matches by first checking if the matches show a good frequency across different users.

    It will be a good idea to keep the matches fresh over time, though I feel it will be purely speculative to define a particular period. If you find a rationale to do that then please let me know 🙂

    With large number of people with same names we can use the Alias table (fig. 7) to display the high frequency names at the top of the ‘Did you mean’ list while the lower frequency will automatically fall at the bottom. This means that highly sought after staff will be listed at the top of the results page. The additional information like the photo or department will help users identify the correct person.

  7. Hi Vivek

    Thanks for an interesting article.

    Search is not an area of expertise so forgive me if this is a dumb comment. I think it’s great that you’ve recognised that matches may not be found because of typographical mistakes and the like. However, shouldn’t a good search algorithm look for and return close alternatives (i.e. use fuzzy logic) when searching for matches? By this I mean that if someone searches on Tim Campbell, then Tim C should come up as a match anyway – albeit one with not as much relevance as a full match – because the “Tim”s match and the “C” matches?

    Your alias approach could then supplement the in-built flexibility to continually improve search results over time.

    Regards,
    Jessica Enders
    Principal, Formulate Information Design
    http://formulate.com.au

  8. Vivek,

    thank you for a well written and explained article. It has given me a load of ideas that may just help in a couple of places, especially in creating an assessment for my students 🙂

    In reply to Jessica Ender’s comment:

    One such “fuzzy logic” method to suggest alternatives to similarly names comes in the form of the SOUNDEX code. This enabled Smith Smithe Smyth Smythe all to be recognised as “the same”.

    Add this to the people finder base algorithm and you automatically extend the possible results.

    I agree that the concept works exceptionally well in theory and would provide a beautiful method to add to the search arsenal in a contact manager or similar. Take the “Tim C” approach one step further and add nicknames to the search pool and you possibly gain another ‘fast find’ factor to the method.

    Adrian, Lecturer Swan TAFE, Midland Western Australia

  9. @Vivek: Thanks for the inspiration! I’d love to give that system a try. But I guess it needs a reasonable number of searches, failures and refined searches in order to come up with reliable patterns. Unfortunately I don’t have a suitable system at hand to try it out.

    @Adrian: Soundex might be good for the English names, but remember that the problem described deals with people from 140 countries. Soundex isn’t reliable for a corpus with that many different pronounciation schemes.

    What really made me think was the example with people who married and changed their names. Off course, if the person had their maiden name in some alias field and if that field was index as well, we’d be fine. But the real world is far from perfect – and the bigger the companies, the more difficult it gets to maintain central databases like that.

    For me, the idea to observe users and create a benefit from their behaviour is what is actually important here, not just technical ways of how to match strings (from user intput) against strings (in a database/index). Again, thanks for that inspiration!

    Marian

Comments are closed.