6497 2011-03-14 11:04:00 -0700 Publication Date selection issues 2011-04-15 08:46:39 -0700 1 1 1 Unclassified OJS Submissions and Publishing 2.3.5 All All RESOLVED FIXED P3 normal --- 1 jmacgreg pkp-support alec bdgregg vgabler 23163 jmacgreg 2011-03-14 11:04:36 -0700 The Year option for the Date Published dropdowns (available for individual articles under Editing -> Scheduling, and for issues on the Issue Data page) only go back to 2001. There's a null option, which if chosen will use the year in the issue's Year identification field as the display value (eg. for citation_date, etc.). This is possibly confusing in a few ways: -- journals who publish content from before 2001 may wonder why there isn't a pre-2001 option; -- 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. -- 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. Is there any reason why we can't simply use the Issue Identification fields to set the issue's publication date? Editors would then be setting the date right the first time through, the UI would be a bit simpler, and Editors wouldn't have to figure out how to mark an issue as published before 2001. The article's submitted date (or whatever is used to populate DC.Date.dateSubmitted and DC.Date.modified) could still be set and tracked in the background invisibly. If that isn't an option, could we display the options to set the publication date before the issue is published, so that Editors won't overlook them? And additionally, it would be good to maybe have the year option go back to at least 1900, although I understand that this would create a somewhat cumbersome list. 23164 bdgregg 2011-03-14 11:09:50 -0700 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/ 23166 jmacgreg 2011-03-14 11:13:08 -0700 (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. 23167 bdgregg 2011-03-14 11:18:51 -0700 James, Understood. Next time then. ;-) 23177 alec 2011-03-14 13:42:28 -0700 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. 23185 jmacgreg 2011-03-14 15:00:26 -0700 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? 23207 alec 2011-03-15 17:40:03 -0700 > 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? 23503 jmacgreg 2011-04-07 10:46:43 -0700 (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. 23582 alec 2011-04-15 08:46:39 -0700 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).