[buddypress-trac] [BuddyPress Trac] #787: All profile field data becomes searchable links--is irrelevant for some data types

[buddypress-trac]

#787: All profile field data becomes searchable links--is irrelevant for some
data types
-------------------------------------+------------------------------
 Reporter:  jeffsayre                |       Owner:  johnjamesjacoby
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  2.1
Component:  XProfile                 |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch ux-feedback  |
-------------------------------------+------------------------------
Changes (by boonebgorges):

 * keywords:  needs-patch => needs-patch ux-feedback
 * priority:  minor => normal
 * type:  defect (bug) => enhancement
 * milestone:  Future Release => 2.1


Comment:

 This is a longtime annoyance that we should be able to make some progress
 on for BP 2.1. I think that a full overhaul of this feature is going to
 take a lot of work, but maybe we can break it down in a way that is spread
 over versions (or at least is not so overwhelming). Some thoughts:

 1. We should come up with intelligent defaults for each field type. Dates,
 for instance, should almost certainly be set to false (and actually, are
 already hardcoded as an exception in
 `xprofile_filter_link_profile_data()`). If someone could make a list of
 field types and make initial recommendations about default states, that
 would be helpful.
 2. Currently the linking logic is like this: Split the string based on the
 placement of commas. (If a string is longer than 5 words but has no
 commas, bail.) For each comma-separated item, if it's less than 5 words,
 make it clickable. The two primary results of this logic are (a) 1-5 word
 entries are made clickable automatically (think: "Chicago" for "City"),
 and (b) "lists" of items are kinda sorta parsed (think: "foo, bar, baz,
 barry"). Arguably, the behavior in (a) is acceptable; the behavior in (b),
 while a good idea, is not - it leads to many false positives and false
 negatives, and it's unreasonably English-centric. So we might want to drop
 the (b) behavior (at least by default).
 3. Ideas are welcome regarding where to put the admin setting, and what it
 should look like.
 4. Ideally, there would be a nice UI that would allow users to make any
 phrase in a field linked to a directory search. (Think of it like Twitter
 hashtags, but without requiring the `#` symbol.) Years ago I wrote a
 plugin http://wordpress.org/plugins/custom-profile-filters-for-buddypress/
 that introduces square brackets for this purpose (think: "I enjoy
 [cheeseburgers] and [fried chicken]"). This works, but is not, by itself,
 good UX. To build a real interface for this (which would, I imagine,
 involve selecting text with the mouse and clicking some sort of button)
 will take some design work, and some fancy javascript to implement.
 Ideas/mockups welcome.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/787#comment:10>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac