Square Peg, Round Hole
Nason, Mike
Open Journal Systems has had a notable impact on academic publishing and open access. It's given scholars with short resources the ability to create and disseminate quality scholarship. It's also made it easier for many established publications to move into digital distribution. But, sometimes, OJS doesn't do what users might expect. Years of OJS use shows a variety of emergent uses from users thinking outside the box intended by its developers. Some of these changes are dramatic, unique one-offs. Some of these changes are common and sensible.This lightning talk looks to discuss the ways OJS users have taken the software outside the box, for better or worse, and suggests that we should learn from - and sometimes adapt to - these emergent behaviours.
 Right here. Hey. So my name is Mike Nason. I'm a Scholar Communications Librarian at the University of New Brunswick, and I'm also a publishing services associate with PKP. I'm here to talk about this broad idea of square pegs and round holes, or I think really it's mostly about a conversation since the tech and tools talk, but this is mostly about what people do, and they don't perceive themselves as having the tools to do things appropriately. So I guess in a way, I'm mostly referring to this as metadata abuse and what we can learn about it. I think that this is probably a good crowd to talk to. I know it, to me, it kind of goes without saying, but I think metadata is actually pretty important. And I think many of you do too. It helps people find research. It helps your research get found by folks. It helps expand the research. It's really what makes all of this stuff go, but a lot of people see metadata fields in a CMS or OJS or any other place as a place you can put chunks of information to make it appear in certain spaces on a website. So for example, I had a class when I was in library school, and one of my instructors one time told me that I should put a YouTube link in a DC subject field, because that would make a video appear on one part of the website. And I yelled at him, and he no longer liked me. But usually when we're talking to a lot of people who are writing scholarship, we're talking to people who often aren't writing XML. They're the kinds of people who, when they write a header or a title or a subject field, change the size of the font and bold it. They're not people who care about semantics. So it doesn't always work this way, and it ends up being a little problematic. We have two really great examples in OJS 2, and we're looking at kind of, there are obviously changes in 3. One is that the OJS 2 native ETD only has first and last name author fields. I guess there's a middle name too. First of all, this is sort of culturally insensitive. This presumes that everybody has a first and last name. That's probably not good. Secondly, it means that people write things like the editors as authors. Or under first name, the Canadian, and then last name, library association. So that generates a citation that says library association, the Canadian, which is really not appropriate. But I think what we've learned in dealing with people for a very long time is that they don't really care about what the citation looks like. They care about what the table of contents looks like. They're more worried about the look, because they came from a print world, and that's their priority. The other major one is that I believe that long-dend people don't have email, and they probably don't need to. And many of us have made up, I'm sure, fakeguyagmail.com. And that email just does exist, has many emails from people who have registered stuff in OJS. But the point is that there are a lot of people who manipulate and abuse metadata to make OJS do something that it doesn't currently do. Some of the examples we've seen in the hosting team include DOIs and titles, extraneous information in page number fields, people abusing metadata fields in the journal setup to add more keywords or a description than it appears at the top of the journal, multiple languages jammed into one locale field. That's a big problem. Thousands of probably fake, but sometimes I bet actually not as fake as intended email addresses. And one amazing one I saw the other day was actually an HTML table field embedded in an abstract field so that people could put all kinds of information, like keywords and DOIs and all this stuff in an abstract field. If you export that metadata, you have a giant mess on your hands, but it's because they perceive they're being missing content. What can we learn? I think a lot of things. My early relationship with Alex Mecher is that I would write him an email saying, OJS should do this. And he says, that's not the intended use of OJS. That's great. But it doesn't really matter to the people who just want that to happen anyway. I think that we need to worry a little bit less about trying to incentivize good metadata, because I think that's kind of like, if you're the kind of person from good metadata is important, you're also the same kind of person who would probably say, doing taxes is fun. But that's not, you can't incentivize that behavior in other people. So instead, we need to mitigate it. One of the conversations I had actually with Alex yesterday is I think that we should do things like decouple article metadata from the display and the table of contents. And he made a face that was like, oh, no. And I made a face that said, but that would solve a lot of problems for people who aren't getting what they want. I think one of the biggest issues that a lot of people aren't aware that OJS has different display options that might meet their needs. And like I say, in three, and I really don't want to undermine the work that's going on with the folks in the UI UX group, that a lot of the stuff in three has been taken care of. But these are longstanding issues where solutions for solving your display options are too buried. It might not be obvious to you that you can hide an author field. The other major issue is that the native DTD from 2.x is way too simplistic. We're recording metadata that isn't anywhere nearly granular enough for current demands. So I think what users are saying is easier, please. And clear takeaways are that we should probably move to Jets. Display options should be more transparent. And this is the takeaway for me. Seemingly oddball customizations made by users to solve seemingly unique issues should be carefully considered. I think that'll do it. See you all later. Thank you.
 Right here.  Hey.  So my name is Mike Nason.  I'm a Scholar Communications Librarian  at the University of New Brunswick,  and I'm also a publishing services associate with PKP.  I'm here to talk about this broad idea of square pegs  and round holes, or I think really it's mostly  about a conversation since the tech and tools talk,  but this is mostly about what people do,  and they don't perceive themselves as having the tools  to do things appropriately.  So I guess in a way, I'm mostly referring to this  as metadata abuse and what we can learn about it.  I think that this is probably a good crowd to talk to.  I know it, to me, it kind of goes without saying,  but I think metadata is actually pretty important.  And I think many of you do too.  It helps people find research.  It helps your research get found by folks.  It helps expand the research.  It's really what makes all of this stuff go,  but a lot of people see metadata fields in a CMS or OJS  or any other place as a place you can put chunks of information  to make it appear in certain spaces on a website.  So for example, I had a class when I was in library school,  and one of my instructors one time told me  that I should put a YouTube link in a DC subject field,  because that would make a video appear on one part  of the website.  And I yelled at him, and he no longer liked me.  But usually when we're talking to a lot of people  who are writing scholarship, we're talking to people  who often aren't writing XML.  They're the kinds of people who, when they write a header  or a title or a subject field, change the size of the font  and bold it.  They're not people who care about semantics.  So it doesn't always work this way,  and it ends up being a little problematic.  We have two really great examples in OJS 2,  and we're looking at kind of, there are obviously changes  in 3.  One is that the OJS 2 native ETD only  has first and last name author fields.  I guess there's a middle name too.  First of all, this is sort of culturally insensitive.  This presumes that everybody has a first and last name.  That's probably not good.  Secondly, it means that people write things  like the editors as authors.  Or under first name, the Canadian,  and then last name, library association.  So that generates a citation that says library association,  the Canadian, which is really not appropriate.  But I think what we've learned in dealing with people  for a very long time is that they don't really  care about what the citation looks like.  They care about what the table of contents looks like.  They're more worried about the look,  because they came from a print world,  and that's their priority.  The other major one is that I believe  that long-dend people don't have email,  and they probably don't need to.  And many of us have made up, I'm sure, fakeguyagmail.com.  And that email just does exist, has many emails  from people who have registered stuff in OJS.  But the point is that there are a lot of people  who manipulate and abuse metadata to make OJS do something  that it doesn't currently do.  Some of the examples we've seen in the hosting team  include DOIs and titles, extraneous information  in page number fields, people abusing metadata fields  in the journal setup to add more keywords or a description  than it appears at the top of the journal,  multiple languages jammed into one locale field.  That's a big problem.  Thousands of probably fake, but sometimes I bet actually not  as fake as intended email addresses.  And one amazing one I saw the other day  was actually an HTML table field embedded in an abstract field  so that people could put all kinds of information,  like keywords and DOIs and all this stuff in an abstract field.  If you export that metadata, you have a giant mess  on your hands, but it's because they perceive  they're being missing content.  What can we learn?  I think a lot of things.  My early relationship with Alex Mecher  is that I would write him an email saying, OJS should do this.  And he says, that's not the intended use of OJS.  That's great.  But it doesn't really matter to the people who just  want that to happen anyway.  I think that we need to worry a little bit less  about trying to incentivize good metadata,  because I think that's kind of like,  if you're the kind of person from good metadata is important,  you're also the same kind of person who would probably say,  doing taxes is fun.  But that's not, you can't incentivize that behavior  in other people.  So instead, we need to mitigate it.  One of the conversations I had actually with Alex yesterday  is I think that we should do things like decouple article  metadata from the display and the table of contents.  And he made a face that was like, oh, no.  And I made a face that said, but that  would solve a lot of problems for people who  aren't getting what they want.  I think one of the biggest issues that a lot of people  aren't aware that OJS has different display options that  might meet their needs.  And like I say, in three, and I really  don't want to undermine the work that's going on with the folks  in the UI UX group, that a lot of the stuff in three  has been taken care of.  But these are longstanding issues  where solutions for solving your display options  are too buried.  It might not be obvious to you that you  can hide an author field.  The other major issue is that the native DTD from 2.x  is way too simplistic.  We're recording metadata that isn't anywhere nearly granular  enough for current demands.  So I think what users are saying is easier, please.  And clear takeaways are that we should probably move to Jets.  Display options should be more transparent.  And this is the takeaway for me.  Seemingly oddball customizations made by users  to solve seemingly unique issues should be carefully considered.  I think that'll do it.  See you all later.  Thank you.
Square_Peg__Round_Hole_kz227BTAzKQ_0_419.png Square_Peg__Round_Hole_kz227BTAzKQ_420_2591.png Square_Peg__Round_Hole_kz227BTAzKQ_2592_3191.png Square_Peg__Round_Hole_kz227BTAzKQ_3192_3515.png Square_Peg__Round_Hole_kz227BTAzKQ_3516_7164.png
Right here. Hey. So my name is Mike Nason. I'm a Scholar Communications Librarian at the University of New Brunswick, and I'm also a publishing services associate with PKP. I'm here to talk about this broad idea of square pegs and round holes, or I think really it's mostly about a conversation since the tech and tools talk, but this is mostly about what people do, and they don't perceive themselves as having the tools to do things appropriately. So I guess in a way, I'm mostly referring to this as metadata abuse and what we can learn about it. I think that this is probably a good crowd to talk to. I know it, to me, it kind of goes without saying, but I think metadata is actually pretty important. And I think many of you do too. It helps people find research. It helps your research get found by folks. It helps expand the research. It's really what makes all of this stuff go, but a lot of people see metadata fields in a CMS or OJS or any other place as a place you can put chunks of information to make it appear in certain spaces on a website. So for example, I had a class when I was in library school, and one of my instructors one time told me that I should put a YouTube link in a DC subject field, because that would make a video appear on one part of the website. And I yelled at him, and he no longer liked me. But usually when we're talking to a lot of people who are writing scholarship, we're talking to people who often aren't writing XML. They're the kinds of people who, when they write a header or a title or a subject field, change the size of the font and bold it. They're not people who care about semantics. So it doesn't always work this way, and it ends up being a little problematic. We have two really great examples in OJS 2, and we're looking at kind of, there are obviously changes in 3. One is that the OJS 2 native ETD only has first and last name author fields. I guess there's a middle name too. First of all, this is sort of culturally insensitive. This presumes that everybody has a first and last name. That's probably not good. Secondly, it means that people write things like the editors as authors. Or under first name, the Canadian, and then last name, library association. So that generates a citation that says library association, the Canadian, which is really not appropriate. But I think what we've learned in dealing with people for a very long time is that they don't really care about what the citation looks like. They care about what the table of contents looks like. They're more worried about the look, because they came from a print world, and that's their priority. The other major one is that I believe that long-dend people don't have email, and they probably don't need to. And many of us have made up, I'm sure, fakeguyagmail.com. And that email just does exist, has many emails from people who have registered stuff in OJS. But the point is that there are a lot of people who manipulate and abuse metadata to make OJS do something that it doesn't currently do. Some of the examples we've seen in the hosting team include DOIs and titles, extraneous information in page number fields, people abusing metadata fields in the journal setup to add more keywords or a description than it appears at the top of the journal, multiple languages jammed into one locale field. That's a big problem. Thousands of probably fake, but sometimes I bet actually not as fake as intended email addresses. And one amazing one I saw the other day was actually an HTML table field embedded in an abstract field so that people could put all kinds of information, like keywords and DOIs and all this stuff in an abstract field. If you export that metadata, you have a giant mess on your hands, but it's because they perceive they're being missing content. What can we learn? I think a lot of things. My early relationship with Alex Mecher is that I would write him an email saying, OJS should do this. And he says, that's not the intended use of OJS. That's great. But it doesn't really matter to the people who just want that to happen anyway. I think that we need to worry a little bit less about trying to incentivize good metadata, because I think that's kind of like, if you're the kind of person from good metadata is important, you're also the same kind of person who would probably say, doing taxes is fun. But that's not, you can't incentivize that behavior in other people. So instead, we need to mitigate it. One of the conversations I had actually with Alex yesterday is I think that we should do things like decouple article metadata from the display and the table of contents. And he made a face that was like, oh, no. And I made a face that said, but that would solve a lot of problems for people who aren't getting what they want. I think one of the biggest issues that a lot of people aren't aware that OJS has different display options that might meet their needs. And like I say, in three, and I really don't want to undermine the work that's going on with the folks in the UI UX group, that a lot of the stuff in three has been taken care of. But these are longstanding issues where solutions for solving your display options are too buried. It might not be obvious to you that you can hide an author field. The other major issue is that the native DTD from 2.x is way too simplistic. We're recording metadata that isn't anywhere nearly granular enough for current demands. So I think what users are saying is easier, please. And clear takeaways are that we should probably move to Jets. Display options should be more transparent. And this is the takeaway for me. Seemingly oddball customizations made by users to solve seemingly unique issues should be carefully considered. I think that'll do it. See you all later. Thank you.
University of New Brunswick, and I'm also a publishing services associate with PKP. I'm here round holes, or I think really it's mostly about what we can learn about it. I think that this is on a website. So for example, I had a class when of people who are writing scholarship, we're exist, has many emails from people who have doesn't currently do. Some of the examples we've And he says, that's not the intended use of OJS. three has been taken care of. But these are what users are saying is easier, please. And clear takeaways are that we should probably move Seemingly oddball customizations made by users to