Bug 6497

James,

Just a thought - instead of having a drop downs for the date, how about a calendar selection tool similar to something like the following: http://www.mattkruse.com/javascript/calendarpopup/

(In reply to comment #1)
> James,
> 
> Just a thought - instead of having a drop downs for the date, how about a
> calendar selection tool similar to something like the following:
> http://www.mattkruse.com/javascript/calendarpopup/

Hi Brian, 

I think that'd be a good idea, but will likely have to wait until another version -- for the 2.3.5 release of OJS we're focussing only on stability/bugfix issues, and a new calendar function falls out of scope.

James,

Understood.  Next time then.  ;-)

James, following up on the description (and thanks, all, for the scrutiny on this):

-- journals who publish content from before 2001 may wonder why there isn't a
pre-2001 option;

We currently have a ten-years-behind, two-years-forward policy in a number parts of the UI. To select an older publication date, it's a little clunky: you need to choose an early date, and then you'll have access to the ten years prior. This shouldn't be considered part of a good workflow for entering back-issues, obviously, though we certainly could improve. Any suggestions? A system-wide baseline date in the config file...?

-- editors will likely not assume that choosing the null option will fall back
to the Year identification value, and may even assume that choosing the null
option will "unpublish" the issue.

See below.

-- Specific to the Issue Data page: there are now two places to set the
publication date: in the Identification section as free-form fields, and again
for the issue status. However, the second option isn't seen until after the
issue is published (and only if/when the Editor returns to the Issue Data
page), and may be overlooked by Editors. 

Agreed that it's not currently ideal, but the combo of fields does cover two purposes: 1) the date for the sake of issue identification, in the age-old volume/number/year pattern, and 2) generating born-digital content with workflow data. For volume/number/year, we have only the Year for granularity. For the workflow, we have the exact date and time of publication. The only I can think of mixing the two granularities without poisoning data (i.e. assuming January 1st for a year, or truncating an exact date to just a year) is to keep both fields, and fall back on the coarser value when the finer one isn't available.

If we got rid of the issue date-published, then we would have to truncate dates to a year (or bend over backwards trying to implement flexible granularities); if we got rid of the issue year, importers would invent dates for back-issue imports.

Hi Alec, 

> -- journals who publish content from before 2001 may wonder why there isn't a
> pre-2001 option;
> 
> We currently have a ten-years-behind, two-years-forward policy in a number
> parts of the UI. To select an older publication date, it's a little clunky: you
> need to choose an early date, and then you'll have access to the ten years
> prior. This shouldn't be considered part of a good workflow for entering
> back-issues, obviously, though we certainly could improve. Any suggestions? A
> system-wide baseline date in the config file...?

That's a good question.  Could we add the option to the config file under the [interface] section, and then submit a bug for OJS 2.3.x to remind us to add something to Journal Setup Step 1.9 advising that those folks who will be publishing back issues older than n years should set the config variable. (Similar to our notes re: allow_envelope_sender, etc.) 

Otherwise, setting it to display the last 100 years now, and moving to a jQuery-type selector as Brian suggests in the future, might best serve the most people easiest right now. The only argument against this is that having a 100-year list might be too annoying for some users. In that case, what about defaulting to 100 years, but still having it configurable in the config file as you suggest? 
 
> -- editors will likely not assume that choosing the null option will fall back
> to the Year identification value, and may even assume that choosing the null
> option will "unpublish" the issue.
> 
> See below.
> 
> -- Specific to the Issue Data page: there are now two places to set the
> publication date: in the Identification section as free-form fields, and again
> for the issue status. However, the second option isn't seen until after the
> issue is published (and only if/when the Editor returns to the Issue Data
> page), and may be overlooked by Editors. 
> 
> Agreed that it's not currently ideal, but the combo of fields does cover two
> purposes: 1) the date for the sake of issue identification, in the age-old
> volume/number/year pattern, and 2) generating born-digital content with
> workflow data. For volume/number/year, we have only the Year for granularity.
> For the workflow, we have the exact date and time of publication. The only I
> can think of mixing the two granularities without poisoning data (i.e. assuming
> January 1st for a year, or truncating an exact date to just a year) is to keep
> both fields, and fall back on the coarser value when the finer one isn't
> available.
> 
> If we got rid of the issue date-published, then we would have to truncate dates
> to a year (or bend over backwards trying to implement flexible granularities);
> if we got rid of the issue year, importers would invent dates for back-issue
> imports.

OK, gotcha. I think this is something we can safely go with now and improve over time. Is there any way, though, to have the issue publication dropdowns visible/possibly editable before the issue is published, just so that Editors know the option is there?

> OK, gotcha. I think this is something we can safely go with now and improve
> over time. Is there any way, though, to have the issue publication dropdowns
> visible/possibly editable before the issue is published, just so that Editors
> know the option is there?

Hmm, I experimented with this a little and couldn't find anything satisfactory that doesn't involve new locale keys. The problem is the buttons:

[Save] [Publish Issue]

I tried options like...

[Save] [Publish Issue] [Year] [Month] [Day]

[Save] [Publish Issue] Published: [Year] [Month] [Day]

...but those imply that the Save button somehow interacts with the date fields.

On the other hand, this is also confusing:
[Save]
[Publish Issue] [Year] [Month] [Day]

...likewise for...

[Save]
[Publish Issue] Published: [Year] [Month] [Day]

Any ideas?

(In reply to comment #6)
> > OK, gotcha. I think this is something we can safely go with now and improve
> > over time. Is there any way, though, to have the issue publication dropdowns
> > visible/possibly editable before the issue is published, just so that Editors
> > know the option is there?
> 
> Hmm, I experimented with this a little and couldn't find anything satisfactory
> that doesn't involve new locale keys. The problem is the buttons:
> 
> [Save] [Publish Issue]
> 
> I tried options like...
> 
> [Save] [Publish Issue] [Year] [Month] [Day]
> 
> [Save] [Publish Issue] Published: [Year] [Month] [Day]
> 
> ...but those imply that the Save button somehow interacts with the date fields.
> 
> On the other hand, this is also confusing:
> [Save]
> [Publish Issue] [Year] [Month] [Day]
> 
> ...likewise for...
> 
> [Save]
> [Publish Issue] Published: [Year] [Month] [Day]
> 
> Any ideas?

Alec, I agree that there's no good way to handle this without adding new locale keys. I think we should go ahead with the fix as is, and look at working it to make more sense for the next release.

Considering good for now. May choose to revisit date entry UI options later, when we have more flexibility e.g. around locale keys (= for a major release).