Helper Info in Admin for PHP date formatting

[miklb]

I do not recall ever seeing this added, but I love the idea of using echo $content->pubdate->format(Options::get('dateformat')) in themes. Which leads me to believe that if we are going to use PHP formatting strings in the admin, the regular user should have some kind of help bubble/link to format their date & time. Ideally there would be some nifty interface to choose a format, but until that comes along, some basic formatting info or at the minimum a link to the PHP date manual would suffice.

[chrismeller]

There are already settings on a user's profile for the date format (along with timezone, etc.), but they aren't taken into account anywhere that I'm aware.

I'm not sure what you mean by "regular user". You mean a normal anonymous visitor to the site, the site's admin, or some non-admin user who has an account and is logged in?

[miklb]

No, I'm saying that someone not familiar with PHP isn't going to understand that if they want the date to appear as December 31st 2013 they need to put F jS Y into the Date format box.

Perhaps I didn't make clear - the /admin/options page is respected in that snippet of code in the theme. Helping "regular" users i.e. non-hackers/coders/etc format the time should be a goal.

On Tue, Dec 31, 2013 at 2:11 AM, Chris Meller notifications@github.comwrote:

There are already settings on a user's profile for the date format (along with timezone, etc.), but they aren't taken into account anywhere that I'm aware.

I'm not sure what you mean by "regular user". You mean a normal anonymous visitor to the site, the site's admin, or some non-admin user who has an account and is logged in?

— Reply to this email directly or view it on GitHubhttps://github.com/habari/habari/issues/590#issuecomment-31386166 .

[ringmaster]

On 12/31/2013 11:22 AM, Michael Bishop wrote:

Helping "regular" users i.e. non-hackers/coders/etc format the time should be a goal.

I agree. Any thoughts for UX that could be better than a link to the PHP date() function docs, which would still be confusing for users?

Owen

[chrisjdavis]

Well we could have a select that has a few sane defaults listed in Han readable. When you select one it passes the correct syntax to the form either in the text input or a hidden one.

How about that?

Sent from my iPhone

On Dec 31, 2013, at 10:44 AM, Owen Winkler notifications@github.com wrote:

On 12/31/2013 11:22 AM, Michael Bishop wrote:

Helping "regular" users i.e. non-hackers/coders/etc format the time should be a goal.

I agree. Any thoughts for UX that could be better than a link to the PHP date() function docs, which would still be confusing for users?

Owen — Reply to this email directly or view it on GitHub.

[ringmaster]

On Tuesday, December 31, 2013 at 11:59 AM, Chris J. Davis wrote:

Well we could have a select that has a few sane defaults listed in Han readable. When you select one it passes the correct syntax to the form either in the text input or a hidden one.
That seems fine to start, but since we already will have to create a new control class for this, it might also be useful to dream up something that doesn't display a value that is different from the selected option (if you select the option "2013-12-31" then "Y-m-d" appears as the value - confusing) and allows even an advanced user to intelligently create a custom date format string. I know I don't memorize that crap, and end up having to refer to my cheat sheet anyway -- it would be neat if the control handles that for the user.

For example, imagine that the control let you choose from individual date format letters, describing each one and providing an example of their output in the drop down. When you choose one, it would add it to the format that is in the box (ala Select2's multiselect). The letters could then be deleted or reordered by dragging, and a real time demo could appear next to the input with the current datetime.

[chrisjdavis]

That sounds great, but is it over engineering a simple control? I am honestly asking, because I don’t know. It will set a precedent on how we deal with things, that we will need to adhere to elsewhere in the UI.

On Dec 31, 2013, at 11:11 AM, Owen Winkler notifications@github.com wrote:

On Tuesday, December 31, 2013 at 11:59 AM, Chris J. Davis wrote:

Well we could have a select that has a few sane defaults listed in Han readable. When you select one it passes the correct syntax to the form either in the text input or a hidden one. That seems fine to start, but since we already will have to create a new control class for this, it might also be useful to dream up something that doesn't display a value that is different from the selected option (if you select the option "2013-12-31" then "Y-m-d" appears as the value - confusing) and allows even an advanced user to intelligently create a custom date format string. I know I don't memorize that crap, and end up having to refer to my cheat sheet anyway -- it would be neat if the control handles that for the user.

For example, imagine that the control let you choose from individual date format letters, describing each one and providing an example of their output in the drop down. When you choose one, it would add it to the format that is in the box (ala Select2's multiselect). The letters could then be deleted or reordered by dragging, and a real time demo could appear next to the input with the current datetime. — Reply to this email directly or view it on GitHub.

[chrismeller]

I had the same reaction. Seems very neat, but overkill. As far as the precedent, it would be very similar to the Select2 setup for searching - it pre-populates Type, Status, etc. so I think it would fit in elsewhere.

And as long as @ringmaster thinks it would be cool and is motivated to work on it, I say we let him have at it.

[chrisjdavis]

I am not sure if that is a good idea anymore (if @ringmaster works on it) since he has been overloaded before with tasks that no one else wanted to do, but needed to be done. Know what I mean?

I would rather we come to a decision on the direction we want the UI of the admin to go. Then we can all have a hand in doing something about the mess that I left the admin in.

Oh and on that note, sorry about that. Life came crashing down around my shoulders and I couldn’t get any clearance to stay on task. I am working through things and will be refocused on Habari starting Jan 1 2014.

On Dec 31, 2013, at 12:31 PM, Chris Meller notifications@github.com wrote:

I had the same reaction. Seems very neat, but overkill. As far as the precedent, it would be very similar to the Select2 setup for searching - it pre-populates Type, Status, etc. so I think it would fit in elsewhere.

And as long as @ringmaster thinks it would be cool and is motivated to work on it, I say we let him have at it.

— Reply to this email directly or view it on GitHub.

[chrismeller]

This isn't a crucial feature by any means - not like he's rewriting FormUI or anything - so I don't see there being any pressure. It seemed like he had a passion to take this on when he suggested it, so I assumed he would be willing to work on it.

I don't want this to become another idea that someone is excited to work on that gets killed in committee by people who aren't.

[chrisjdavis]

Yep, me either. Just wanted to take a moment to reflect how we have handled these things in the past, and see if we wanted to try something different.

In the end, I am not going to stand in the way of work being done. :)

On Dec 31, 2013, at 12:41 PM, Chris Meller notifications@github.com wrote:

This isn't a crucial feature by any means - not like he's rewriting FormUI or anything - so I don't see there being any pressure. It seemed like he had a passion to take this on when he suggested it, so I assumed he would be willing to work on it.

I don't want this to become another idea that someone is excited to work on that gets killed in committee by people who aren't.

— Reply to this email directly or view it on GitHub.

[chrismeller]

I wasn't trying to appoint him to the task or stress him out. It was his idea, he seemed to have the spark of an idea, I thought he might want to work on it. Only he knows if he has time and mental bandwidth to handle it, you can't manage someone else's schedule for them.

Like I said - if he thinks it would be cool and is motivated to work on it, let him have at it.

[miklb]

Certainly what @ringmaster outlines would be the ideal situation. I did discover that on the user profile page there is a link to the php.net/date page, which was my basic suggestion for the options page. Probably wouldn't be worth adding if there are plans to build a nifty UI for it.

[ringmaster]

http://jsfiddle.net/CdZQc/7/

[chrismeller]

Ewww, jQuery UI! Well done, though.

[RandyWalker]

I'm not a fan of this because you don't get any hints until you start typing and you might type something wrong and have to delete what you just typed. What about something like OS X's custom date interface? You have all the elements and you drag them where you want them.

[ringmaster]

So first, thanks for the suggestion/screenshot.

Second, there are a couple of issues with this, not that it's insurmountable.

Something I think is a potential good idea is creating a type of FormControl that lets you pop up some kind of advanced editing interface. I'm not sure what this is yet, but it could be used for the media browser or other more complex controls.

Something I think is not the best idea is that if this interface contained the gamut of date() parameters that are available (presumably this is the greatest reason to have a reference at all -- an argument I can have more fully after I've sobered up from New Years ;) then this dialog would be 8 miles high.

There may be a reasonable compromise, but the main thing I'll point out right now is this: The jsfiddle code works and provides better date() utility than just a link to the PHP docs. So it's just a matter of fitting it into a new control until someone implements a FormControlTextButton that can display a form like this (with some clever and succinct way to access the excess of date() options) to serve as something better than the mere link.

[chrismeller]

I agree with it not popping up until you start typing, but that could be fixed. I think there may even be a jQuery UI config option for that. As proof of concepts go, though, I think it's an improvement on what we have now.

On an unrelated note, I forgot that OS X had settings for short / medium / long (ala Drupal)... As much as I hate that, I keep thinking of instances where we need something like it.

[miklb]

+1 to be working code and a better option than what we provide now. As to the size of an interface/pop-up, I think it could be reasonable to think that it wouldn't need ALL of the date() options, rather the most common for the user who would be using the pop-up. Allowing the option for advanced configuration of date() via standard keyboard input should suffice for the outlier options.

[Konzertheld]

This is a bit of a duplicate of #83.

[Konzertheld]

I read back all your discussion and wonder if there is any need to build a huge new control for something simple as date formatting. Here's how I see it: The regular user will 1) be confused because the default date format does not match the one used where he lives, and 2) change it to the one that is common where he lives. So I'd say it would be sufficient if we just set proper defaults and provided a bit of an explanation on how to use the PHP date syntax. Coming up with an own syntax selectable by UI (which seems to be what came up in this discussion) looks like re-inventing the wheel to me.

[Konzertheld]

Pushing this to 0.11 while assigning milestones to more issues as we 1) already have enough to do for 0.10 2) did not miss this before and 3) did not yet agree on how to solve it.