Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adapt OMP catalog management into OJS for continuous publication #1407

Closed
stranack opened this issue Apr 21, 2016 · 14 comments
Closed

Adapt OMP catalog management into OJS for continuous publication #1407

stranack opened this issue Apr 21, 2016 · 14 comments
Labels
Hosting Bug reports and feature requests from Publishing Services's hosted clients.

Comments

@stranack
Copy link

Providing the option in OJS 3 (or 3.1) to treat articles like stand-alone items (like books in OMP), catalog management could allow for a continuous publication option as well as give us some interesting content display choices on the journal home page.

Featured Articles, Spotlights, New Releases would all apply well in this scenario. Journals could also add major themes as categories or even create a volume or issue category.

@asmecher
Copy link
Member

From @stranack, #1397 (comment):

For continuous publishing, categories (as in OMP) could serve a useful purpose in OJS 3. Journals could use a feature much like the Catalogue to organize and display articles on the home page, and in categorized lists. I think it is at least worth considering, even for 3.1.

@NateWr
Copy link
Member

NateWr commented May 13, 2016

I'd like to see "Sections" used for categorizing articles for continuous publishing, instead of adding a new Categories system. Any reservations there?

In terms of the UI for continuous publishing, I'd love to see us accomplish the user-facing side of this by simply removing one element in the submission metadata modal. The Publication Date could then be a "scheduled posting" so it will just go live at that date:

selection_044

Should we peg this issue against a milestone so that it's not lost?

@asmecher
Copy link
Member

Nate, I like that proposal. Nice and simple.

Some journals will probably want to use both continuous publishing and issues -- effectively there would be a pool of articles without issues that would build up somewhere, and get periodically reshuffled into issues -- so rather than forcing JMs into one track or the other we might...

  • Disentangle the selection of an issue from the publishing action for an article. Currently scheduling an article into an issue either publishes the article (if the issue is published) or delegates control over publishing the issue (if the issue is unpublished).
  • Make the association of published articles and issues optional in the back end. This will take some vetting of 3rd-party formats (e.g. OAI, export plugins, etc.) to ensure that they can handle articles without issues.
  • Add setup options for the front end permitting a mix of presentations... (Perhaps this would be better done as e.g. a continuous-publication theme rather than adding lots of permutations?)
    • Enable/disable browse by issue tools (e.g. Archive listing of issues)
    • Enable/disable continuous publication presentation (on the homepage? Or would this e.g. replace the Archive page?)

@NateWr
Copy link
Member

NateWr commented May 16, 2016

I think that we'll have a few homepage options in the default theme which allow a JM to kind of choose how they present their publishing schedule. For instance, I'm hoping that we'll have options to display the latest issue and/or a list of latest articles, and journals can choose what they want to prioritize.

This may not be a 3.0 thing, but I raised some of this in that email I sent out about homepage blocks.

Either way, I'm very much a fan of the idea of having a theme that's geared more directly towards continuous-publication. That's obviously a post-3.0 thing, but it makes a lot of sense to treat the frontend very differently for that model.

@amandastevens
Copy link
Collaborator

It would also be great if editors of journals published on a rolling basis could have more control over when to send notifications of a newly published issue or article. If an issue is published and then articles gradually added to it, the notification can only go out when the issue is initially published or if the editor un-publishes and re-publishes it.

@amandastevens amandastevens added the Hosting Bug reports and feature requests from Publishing Services's hosted clients. label Sep 27, 2018
@asmecher
Copy link
Member

asmecher commented Oct 4, 2018

We've recently been discussing using OMP's "categories" tools for organizing special collections (e.g. based on theme).

@NateWr
Copy link
Member

NateWr commented Oct 5, 2018

I think using OMP's categories could work. Let's think about them as broadly as possible, as nothing more than an arbitrary collection, to which any meaning can be given.

  • Themes could have an option to "show collection on homepage in X slot" and that could mean: the latest X from that collection, the top X from that collection, etc.
  • Sidebar blocks could be created with manually curated lists of collections. So I could have one block which lists "theme" collections, one which lists "area" collections, etc.
  • Each collection archive could have a custom template if desired.

This raises some questions:

  1. How will we display on an article's landing page it's inclusion in a collection? It seems to me like we would need some concept of a collection "type" to do this effectively, eg:

Area: Latin America
Theme: indigenous artwork

Otherwise our only out-of-the-box display option will be something like this:

This article is included in the following: Latin America, indigenous artwork

  1. In what ways does this overlap with metadata, and should it interact with metadata? Does an article's inclusion in a collection constitute metadata? My sense is that people are typically drawn to what they can see and browse, and that means editors may focus on these categories and neglect the article metadata. If editors are focused on creating all this customized browsing data, should we instead be encouraging them to accomplish what they want by creating metadata that's part of the article's wider distribution? Would it make sense to make our metadata provision more robust, and tie the collections feature-set to that?

@mlafl
Copy link

mlafl commented Oct 29, 2018

I'll just add that, while for some journals, being able to define a collection type would probably be useful, at CA we're just envisioning one type. The question about metadata is an interesting one: just a reminder, though, that we'll be grouping previously published articles into collections and so it would be a question of updating metadata for those articles, rather than including it in initial distribution.

Also, in terms of showing a collection on the journal's homepage, we would want to display a teaser from the intro text and possibly an image, rather than the latest or top article to be included in the collection. The idea (on the homepage) is to present the collection as a unit, rather than calling attention to its constituent articles.

@ajnyga
Copy link
Collaborator

ajnyga commented Oct 31, 2018

There are many issues here that discuss the continuous publication model (one of the oldest issues here #382) and/or things connected to it. I am finding it hard to follow what kind of selections are being made.

This is a major feature in OJS and connected to many things in the system (versioning, preprints, ahead-of-print features, DOIs, DOAJ registration and other metadata exports, OAI-PMH etc.). Maybe a clear roadmap of the planned features would be a good idea at some point before actual coding starts to happen?

@asmecher
Copy link
Member

Agreed, @ajnyga. I suggest hiving off the discussion of curated collections (categories in OMP) to #4158. I'll have a look through other Continuous Publication related issues and bring them together in a project, or else link and close the others if one is a clear leader.

@mlafl
Copy link

mlafl commented Oct 31, 2018

Sorry, all, didn't mean to fork the thread in a different direction!

@asmecher
Copy link
Member

Not at all, @mlafl, we're constantly in the process of re-organizing this crazy thing.

@mfelczak
Copy link
Member

Just wanted to add a +1 to provide editors with more control over when to send notifications for newly published issues or articles. We have received requests from hosted journals that would like to send a new notification each time a new article is added to an existing, continuous publishing issue.

@NateWr
Copy link
Member

NateWr commented Jul 25, 2022

It seems like there are a lot of different proposals embedded in this one. I'm going to close this for now. If you feel some part of this is still important, please consider making a proposal in the feature request category of our community forum.

@NateWr NateWr closed this as completed Jul 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Hosting Bug reports and feature requests from Publishing Services's hosted clients.
Projects
Development

No branches or pull requests

7 participants