Skip to:
Content

Opened 17 months ago

Last modified 5 weeks ago

#5500 new enhancement

Date xprofile field enhancement

Reported by: sooskriszta Owned by:
Milestone: 2.4 Priority: normal
Severity: normal Version:
Component: Component - XProfile Keywords: has-patch needs-testing
Cc: vivek@…

Description

I can't claim that this will useful for all or most communities. I do believe that many communities, especially "social networking"-type communities will find it valuable.

This could be formed by 3 dropdowns: one each for date, month and year. The sequence of the dropdowns should be dictated by the date format selected by admin in WordPress settings.

There should be 2 mutually exclusive options (checkboxes):

  • Show year in public profile (unchecked by default) - so by default the public profile shows only date and month.
  • Show age instead of date of birth (unchecked by default) - overrides previous option..if checked the profile shows calculated age in years (today - dob), instead of the date of birth

The admin should also have the right to limit registration/profile access by age. e.g. A checkbox and a textbox in admin panel
Only allow members over years of age (unchecked by default)
In frontend, the dropdowns only list dates that would make the member's age over the admin-specified minimum age. If admin has not selected any minimum, then the member's age should be at least 0 days.

Standard validation rules for dates apply.

Attachments (4)

enhanced-date-field.png (78.6 KB) - added by sooskriszta 15 months ago.
Suggested "enhanced" date xprofile field UI wireframe
buddypress-15-07-24--10-25.zip (1.9 MB) - added by axelskynet 6 weeks ago.
The file contains a version of the plugin and the patch file for it.
1.PNG (53.1 KB) - added by sooskriszta 5 weeks ago.
Date of birth (actual screenshot)
2.PNG (52.7 KB) - added by sooskriszta 5 weeks ago.
Age (actual screenshot)

Change History (29)

comment:1 @boonebgorges17 months ago

Thanks for the detailed request.

IMO, this is too specific for a field *type*. Date of Birth might be of interest to many communities, but the underlying logic - a field that allows for date input, and can display it in a number of different ways - could be used for many other purposes.

So, I'm going to propose that instead, we use this ticket to discuss ways of improving our existing Date field. I can imagine adding the following:

  • Show "time elapsed" instead of the date. This would be roughly equivalent to the "Age" feature requested above. So you'd enter "September 4, 1934" and the display value would be, say, "80 years ago"
  • Options for which dates to show. Past only, present only, specific year ranges
  • Time + date

The stuff about restricting site membership based on age/DOB does sound useful, but I think it's pretty straightforwardly plugin territory. On the bright side, if we built an enhanced Date field type, extending this to cover Age more specifically would be extremely easy.

What do you think?

comment:2 @sooskriszta17 months ago

Your note makes perfect sense to me.

We should build in the "privacy" filter - don't show year - if possible, though.

Last edited 17 months ago by sooskriszta (previous) (diff)

comment:3 @sooskriszta17 months ago

  • Cc vivek@… added

comment:4 @sooskriszta17 months ago

  • Summary changed from Custom xprofile field: Date of birth to Date xprofile field enhancement

comment:5 @DJPaul16 months ago

  • Milestone changed from Awaiting Review to Future Release

comment:6 @DJPaul16 months ago

My gut feeling is many simple fields will be a better/less complicated UI than just a few field types with various options to configure behaviour (I imagine power users would appreciate the fine-grained control, but we're trying to build for the 80%).

comment:7 @boonebgorges16 months ago

I agree with that idea in general, but I think that a simple toggle for setting beginning and ending dates for the date field might be an exception. It's hard to think of a use case for the date field where these settings *wouldn't* be useful. That said, I'm willing to listen to the wisdom of the crowds on this point.

comment:8 @DJPaul15 months ago

See also #5646

We should agree how we want to approach this sooner rather than later, because we've had tickets from multiple people for each approach.

comment:9 @sooskriszta15 months ago

I am convinced that DOB is too specific.

Let every date field have 3 additional features:

  • Show year (On by Default). If admin switches this off, then in the public front-end only date and month are shown, e.g. 1 January
  • Dates to list: year x to year y, or from x years before today to y years before today (accept negative values for x and y to allow for future dates)
  • Show time elapsed i.e. Today - Date. I differ from Boone on the language used though. I'd say simply 80 years, not 80 years ago. Here's why: Showing age: 37 years makes more sense than 37 years ago Showing countdown: If Today - Date is negative, i.e. we are counting down to an even in the future (say birthday party) then we don't want to grapple with a separate text string...we just want to say 15 days

comment:10 @boonebgorges15 months ago

sooskriszta - Thanks for the feedback. But the UI you're suggesting here, as I'm envisioning it, would be several times more complex than what I think we're leaning toward. Those three additional features will translate into four or five different settings of different types. Any chance you might want to mock up how you imagine the interface looking?

The options laid out by sooskriszta are helpful in that they show all the different ways that date fields might be used. It's pushing me more in the direction of DJPaul's position that we should probably just have separate field types. That said, I do think that (eg) a DOB field still should have some settings; some sites will want to set the earliest date to be 12 years ago, while others may want it to be 21 years ago, etc. I also think there's some merit to having the option for a DOB field to display as age.

Would it maybe be helpful if we came up with three or four examples of how date fields might be used. That would help us to get a sense of where the use cases intersect, and what if anything would go into a general "Date" field in terms of settings/UI.

@sooskriszta15 months ago

Suggested "enhanced" date xprofile field UI wireframe

comment:11 @sooskriszta14 months ago

  • Keywords dev-feedback added

comment:12 @ircbot13 months ago

This ticket was mentioned in IRC in #buddypress-dev by OC2PS. View the logs.

comment:13 @boonebgorges9 months ago

#6038 was marked as a duplicate.

comment:14 @slackbot9 months ago

This ticket was mentioned in Slack in #buddypress by oc2ps. View the logs.

comment:15 follow-up: @johnjamesjacoby6 months ago

A few ideas here:

  • Is there an existing date-picker JavaScript library we can lean on?
  • Is there an existing PHP library that would map date & time formats to fields with appropriate boundaries?
  • Date & time fields could have many different usages and permutations of combinations. Are there any event calendar plugins that are doing this really well we can learn from or partner up with?
  • I think I would ultimately like to see our "Date" field replaced by a more robust "Date/Time" field. One with a few popular options to choose from (date only -- all day, date & time, date range, date & time range, etc...)
  • Make it so fields are mapped to WordPress's format, and not hard coded to Day/Month/Year order

In general, I think there is good discussion happening here. Our current Date field is not ideal, but exactly what is ideal likely needs to influenced by other successful projects that use dates & times.

comment:16 in reply to: ↑ 15 @sooskriszta6 months ago

Replying to johnjamesjacoby:

  • I think I would ultimately like to see our "Date" field replaced by a more robust "Date/Time" field. One with a few popular options to choose from (date only -- all day, date & time, date range, date & time range, etc...)

JJJ, I feel date (date only) and date range (event - all day, datetime range) have very different use cases. Date seems more appropriate for profile fields. While date range is more of an event-based field - perhaps more suited to a new "Events" component.
e.g. Profile field: Date of Birth
Events field: Birthday party date/time

@axelskynet6 weeks ago

The file contains a version of the plugin and the patch file for it.

comment:17 @sooskriszta6 weeks ago

  • Keywords has-patch added; dev-feedback removed

In my testing patch works well.

comment:18 @DJPaul5 weeks ago

  • Keywords needs-testing added
  • Milestone changed from Future Release to 2.4

Thanks again for the patch. Not convinced that we should do this yet, but we'll definitely take a look at your work.

Can whoever tests this first attach some screenshots of the UI changes to this ticket? They'd be interesting to see.

comment:19 @sooskriszta5 weeks ago

The UI is very similar to my wireframes actually.

@sooskriszta5 weeks ago

Date of birth (actual screenshot)

@sooskriszta5 weeks ago

Age (actual screenshot)

comment:20 @axelskynet5 weeks ago

We have added the text note "Note: Year range is allowed between 1902 and 2037 years only." because the core has year restriction http://share.redix.ru/s/?file=andreyivanov/2015-07-25_0115.png&w=598&h=366. Even if user selects the year out of this range it will be saved but will not be shown on Frontend. BuddyPress developers can fix this issue if it will be needed.

comment:21 @slackbot5 weeks ago

This ticket was mentioned in Slack in #buddypress by oc2ps. View the logs.

comment:22 follow-up: @boonebgorges5 weeks ago

I'm coming around to the idea of including these features, but I think the suggested UI needs some refinement. Some thoughts/ideas, for discussion:

  • Let's break out the options into a separate metabox - "Field Options" or something like that. Or maybe even two separate metaboxes: "Range" and "Format"
  • The year/no-year checkbox is kinda arcane. If we're going to support this, let's make a more general set of formats, so that admins can decide in a more fine-grained way how they want dates to be formatted. The easiest way to do this would be to provide a set of hardcoded formats: "February 25, 2015", "February 25", "2015-02-25", etc. More complex would be a free-form field with swappable placeholders, akin to PHP's date() (but more user-friendly). Defaults should be sensitive to localized date values/WP settings.
  • We could use better labels for the two radio buttons related to Range. I suggest something like "Fixed" and "Dynamic".
  • If we're going to make these improvements, we can remove the 1902-2037 restriction, which I'm sure was implemented to avoid problems with freeform data entry.

Thanks for your work on this so far!

comment:23 @DJPaul5 weeks ago

The 2037 thing was to prevent bugs based on how PHP handles dates on 32bit operating systems. I know it was a UI-only "fix" because people can send whatever value in the form submission, but figured that was a harmless edge case. See https://en.wikipedia.org/wiki/Year_2038_problem (I took one year off of that for safety).

I forget why I took it down to 1902, but probably a related reason.

As long as we can dynamically find out the maximum year supported in PHP, we should be able to implement the restriction only for affected sites.

comment:24 in reply to: ↑ 22 ; follow-up: @sooskriszta5 weeks ago

Replying to boonebgorges:

  • The year/no-year checkbox is kinda arcane. If we're going to support this, let's make a more general set of formats, so that admins can decide in a more fine-grained way how they want dates to be formatted. The easiest way to do this would be to provide a set of hardcoded formats: "February 25, 2015", "February 25", "2015-02-25", etc. More complex would be a free-form field with swappable placeholders, akin to PHP's date() (but more user-friendly). Defaults should be sensitive to localized date values/WP settings.

Can't say I understand what you mean. Could you rephrase/elaborate?

At the moment year/no-year checkbox literally does exactly what it says on the tin.
If year shows 1 Jan 2016 (based on WordPress date format), then no year shows 1 Jan.

comment:25 in reply to: ↑ 24 @boonebgorges5 weeks ago

Replying to sooskriszta:

At the moment year/no-year checkbox literally does exactly what it says on the tin.
If year shows 1 Jan 2016 (based on WordPress date format), then no year shows 1 Jan.

Yes. But what I'm suggesting is that this checkbox is too specific to your use case for us to adopt in BuddyPress. What if I only want to show years? Only months? Only month + year? There are valid use cases for all of these. So I'm suggesting one of the following:

  1. A curated list of format options. Maybe a radio button of options like:
* February 23, 2015
* February 23
* February 2015
* February
* 2015
  1. A parameterized system for defining your desired format. Perhaps we'd define some subset of PHP's date() syntax, maybe something like this:
Enter your desired date format. Use the following placeholders for various parts of the date:
  - %F - Full month name (eg, January)
  - %m - Month number, with leading zeroes (eg, 04)
  - %d - Day number, with leading zeroes (eg, 13)
  - %j - Day number, without leading zeroes (eg, 4)
  - %Y - Year number
  etc

Format: [ %F %d, %Y ] (February 23, 2015) // this would maybe update dynamically as a preview

These are just some ideas. It would be very valuable to see what existing form-building plugins do. We don't necessarily need (or want) to build a full date-format system, but perhaps looking at examples would give us a sense of what would be a useful subset of such a system.

Note: See TracTickets for help on using tickets.