I just had a crazy idea, put it out there for discussion, certainly not expecting any immediate action, even if people like it we'll want to stew on it for a while.
One of the most time consuming and annoying parts of editing the journal is getting things into HTML and editing the HTML without WordPress messing it up, etc.
* What if we required authors to submit in markdown (basically plaintext with some pretty easy to remember conventions for indicating headers, lists, links, embedded images, etc) * Then we just entered the markdown in WordPress * Profit!
## Disadvantages
* We wouldn't be able to use fancy custom HTML anymore. This has some pro's in enforcing consistency, but also some obvious cons. * We'd probably have to give up on the COinS, which I think would actually be fine. Some years on, COinS has not really caught on, I'm not sure it provides a benefit commensurate to the effort it takes us, and we usually don't manage to do it right anyway. Few of our articles include links to non-open-access literature anyway. * On the other hand, we can't give up code syntax highlighting. Not sure if WP markdown plugins would play nice with the syntax highlighter plugin, but they might. * We'd have to figure out how to conveniently do notes/references too, especially for articles that want the (Smith 2000) style to be most readable. * Not sure how we'd get things like our formatted captions on figures to work right, or center-aligned figures, etc.
So there'd be some challenges. But I suspect they could be overcome. And I think it would make our jobs so much easier, take out the most annoying and least rewarding thing editors spend time on. And, hey, forcing the limitation to the subset of HTML that markdown can represent would make an article-to-PDF converter a lot easier too.
## Note
This email is, as you may have guessed, in markdown.
Markdown was one of the first text syntaxes I used (in a Moveable Type blog I had 8 or so years ago) and it is still a fine markup language. I think it _can_ coexist with raw HTML (at least my Moveable Type blog could, through a post-specific setting), but probably not with the WYSIWYG editor. Something to keep in mind.
Barring technical complications, however, one concern might be people's comfort level using the markup syntax approach. That seems to be the crux of people's resistance to using wikis. How much of a problem will editors find it to convert a formatted word processing document to Markdown?
Another concern is the ability to track changes. One of the articles I edited this year was originally submitted in a text markup syntax (Textile, I think). I eventually converted it to Word and coordinated further edits with the authors that way. If we had a way to track changes and share them with the authors using Wordpress, that would have addressed that problem very nicely. This is true regardless of whether we decide to go with Markdown or not. Our current editing paradigm is not to enter the article into Wordpress until most of the changes have been made, which mitigates the problem somewhat.
These are devil's advocate objections though. If others like the idea, we should definitely explore it.
On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind <rochk...@jhu.edu> wrote: > I just had a crazy idea, put it out there for discussion, certainly not > expecting any immediate action, even if people like it we'll want to stew on > it for a while.
> One of the most time consuming and annoying parts of editing the journal is > getting things into HTML and editing the HTML without WordPress messing it > up, etc.
> * What if we required authors to submit in markdown (basically plaintext > with some pretty easy to remember conventions for indicating headers, lists, > links, embedded images, etc) > * Then we just entered the markdown in WordPress > * Profit!
> ## Disadvantages
> * We wouldn't be able to use fancy custom HTML anymore. This has some > pro's in enforcing consistency, but also some obvious cons. > * We'd probably have to give up on the COinS, which I think would actually > be fine. Some years on, COinS has not really caught on, I'm not sure it > provides a benefit commensurate to the effort it takes us, and we usually > don't manage to do it right anyway. Few of our articles include links to > non-open-access literature anyway. > * On the other hand, we can't give up code syntax highlighting. Not sure if > WP markdown plugins would play nice with the syntax highlighter plugin, but > they might. > * We'd have to figure out how to conveniently do notes/references too, > especially for articles that want the (Smith 2000) style to be most > readable. > * Not sure how we'd get things like our formatted captions on figures to > work right, or center-aligned figures, etc.
> So there'd be some challenges. But I suspect they could be overcome. And I > think it would make our jobs so much easier, take out the most annoying and > least rewarding thing editors spend time on. And, hey, forcing the > limitation to the subset of HTML that markdown can represent would make an > article-to-PDF converter a lot easier too.
> ## Note
> This email is, as you may have guessed, in markdown.
> -- > You received this message because you are subscribed to the Google Groups > "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com. > To unsubscribe from this group, send email to > c4lj-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/c4lj-discuss?hl=en.
Yeah, track changes, I dunno. I don't like our current 'solution' for track changes, passing around Word documents, but don't know of a better solution, markdown or not. (And we don't require authors to submit in Word or be able to open a Word file now, in fact).
I wonder if there's a WordPress plugin that puts your posts in a code versioning system of some kind and lets you look at histories/diffs? Maybe that'd be the solution there -- which WOULD work better with markdown. With HTML, you're likely to get a lot of diffs that are just fixes to HTML syntax and structure and formatting rather than actual content.
Markdown (or textile) are SO easy to use, that I personally don't see a problem with requiring authors to use it. We are a technical journal after all. (It looks like there may be some textile WP plugins too, so it could be textile instead of markdown. Depends on if ANY of these plugins, textile or markdown, are stable, mature, and flexible/powerful enough for our use, which I'm not sure).
But I'm not looking for any immediate action on this, it's really just food for thought. I'd like to come up with SOME better way of handling our workflow. (While still being focused on HTML as our primary delivery, not PDF. When I think 'troubles with workflow', I think , gee, let's see what OJS does -- but they seem to punt on HTML entry/editing workflow problems, instead focusing on PDFs as the primary delivery. Which is not where any of us want to go.)
________________________________ From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] on behalf of Tom Keays [tomke...@gmail.com] Sent: Thursday, July 21, 2011 9:52 PM To: c4lj-discuss@googlegroups.com Subject: Re: [c4lj] markdown?
Markdown was one of the first text syntaxes I used (in a Moveable Type blog I had 8 or so years ago) and it is still a fine markup language. I think it _can_ coexist with raw HTML (at least my Moveable Type blog could, through a post-specific setting), but probably not with the WYSIWYG editor. Something to keep in mind.
Barring technical complications, however, one concern might be people's comfort level using the markup syntax approach. That seems to be the crux of people's resistance to using wikis. How much of a problem will editors find it to convert a formatted word processing document to Markdown?
Another concern is the ability to track changes. One of the articles I edited this year was originally submitted in a text markup syntax (Textile, I think). I eventually converted it to Word and coordinated further edits with the authors that way. If we had a way to track changes and share them with the authors using Wordpress, that would have addressed that problem very nicely. This is true regardless of whether we decide to go with Markdown or not. Our current editing paradigm is not to enter the article into Wordpress until most of the changes have been made, which mitigates the problem somewhat.
These are devil's advocate objections though. If others like the idea, we should definitely explore it.
Tom
On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind <rochk...@jhu.edu<mailto:rochk...@jhu.edu>> wrote:
I just had a crazy idea, put it out there for discussion, certainly not expecting any immediate action, even if people like it we'll want to stew on it for a while.
One of the most time consuming and annoying parts of editing the journal is getting things into HTML and editing the HTML without WordPress messing it up, etc.
* What if we required authors to submit in markdown (basically plaintext with some pretty easy to remember conventions for indicating headers, lists, links, embedded images, etc) * Then we just entered the markdown in WordPress * Profit!
## Disadvantages
* We wouldn't be able to use fancy custom HTML anymore. This has some pro's in enforcing consistency, but also some obvious cons. * We'd probably have to give up on the COinS, which I think would actually be fine. Some years on, COinS has not really caught on, I'm not sure it provides a benefit commensurate to the effort it takes us, and we usually don't manage to do it right anyway. Few of our articles include links to non-open-access literature anyway. * On the other hand, we can't give up code syntax highlighting. Not sure if WP markdown plugins would play nice with the syntax highlighter plugin, but they might. * We'd have to figure out how to conveniently do notes/references too, especially for articles that want the (Smith 2000) style to be most readable. * Not sure how we'd get things like our formatted captions on figures to work right, or center-aligned figures, etc.
So there'd be some challenges. But I suspect they could be overcome. And I think it would make our jobs so much easier, take out the most annoying and least rewarding thing editors spend time on. And, hey, forcing the limitation to the subset of HTML that markdown can represent would make an article-to-PDF converter a lot easier too.
## Note
This email is, as you may have guessed, in markdown.
-- You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. To post to this group, send email to c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com>. To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com<mailto:c4lj-discuss%2Bunsubscribe @googlegroups.com>. For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
-- You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. To post to this group, send email to c4lj-discuss@googlegroups.com. To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
One thing I like about C4LJ is the low barrier for entry for authors to get their content out. Even though this might not be all that hard to do, it potentially takes authors out of their normal writing workflow. Authors may also have already written something up in another format before deciding to submit to us. I think there are some parallels with the citation format discussion. I could go for an option or suggestion, but don't think I'd like to see it made a requirement.
On Fri, Jul 22, 2011 at 8:34 AM, Jonathan Rochkind <rochk...@jhu.edu> wrote: > Yeah, track changes, I dunno. I don't like our current 'solution' for track changes, passing around Word documents, but don't know of a better solution, markdown or not. (And we don't require authors to submit in Word or be able to open a Word file now, in fact).
> I wonder if there's a WordPress plugin that puts your posts in a code versioning system of some kind and lets you look at histories/diffs? Maybe that'd be the solution there -- which WOULD work better with markdown. With HTML, you're likely to get a lot of diffs that are just fixes to HTML syntax and structure and formatting rather than actual content.
> Markdown (or textile) are SO easy to use, that I personally don't see a problem with requiring authors to use it. We are a technical journal after all. (It looks like there may be some textile WP plugins too, so it could be textile instead of markdown. Depends on if ANY of these plugins, textile or markdown, are stable, mature, and flexible/powerful enough for our use, which I'm not sure).
> But I'm not looking for any immediate action on this, it's really just food for thought. I'd like to come up with SOME better way of handling our workflow. (While still being focused on HTML as our primary delivery, not PDF. When I think 'troubles with workflow', I think , gee, let's see what OJS does -- but they seem to punt on HTML entry/editing workflow problems, instead focusing on PDFs as the primary delivery. Which is not where any of us want to go.)
> ________________________________ > From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] on behalf of Tom Keays [tomke...@gmail.com] > Sent: Thursday, July 21, 2011 9:52 PM > To: c4lj-discuss@googlegroups.com > Subject: Re: [c4lj] markdown?
> Markdown was one of the first text syntaxes I used (in a Moveable Type blog I had 8 or so years ago) and it is still a fine markup language. I think it _can_ coexist with raw HTML (at least my Moveable Type blog could, through a post-specific setting), but probably not with the WYSIWYG editor. Something to keep in mind.
> Barring technical complications, however, one concern might be people's comfort level using the markup syntax approach. That seems to be the crux of people's resistance to using wikis. How much of a problem will editors find it to convert a formatted word processing document to Markdown?
> Another concern is the ability to track changes. One of the articles I edited this year was originally submitted in a text markup syntax (Textile, I think). I eventually converted it to Word and coordinated further edits with the authors that way. If we had a way to track changes and share them with the authors using Wordpress, that would have addressed that problem very nicely. This is true regardless of whether we decide to go with Markdown or not. Our current editing paradigm is not to enter the article into Wordpress until most of the changes have been made, which mitigates the problem somewhat.
> These are devil's advocate objections though. If others like the idea, we should definitely explore it.
> Tom
> On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind <rochk...@jhu.edu<mailto:rochk...@jhu.edu>> wrote: > I just had a crazy idea, put it out there for discussion, certainly not expecting any immediate action, even if people like it we'll want to stew on it for a while.
> One of the most time consuming and annoying parts of editing the journal is getting things into HTML and editing the HTML without WordPress messing it up, etc.
> * What if we required authors to submit in markdown (basically plaintext with some pretty easy to remember conventions for indicating headers, lists, links, embedded images, etc) > * Then we just entered the markdown in WordPress > * Profit!
> ## Disadvantages
> * We wouldn't be able to use fancy custom HTML anymore. This has some pro's in enforcing consistency, but also some obvious cons. > * We'd probably have to give up on the COinS, which I think would actually be fine. Some years on, COinS has not really caught on, I'm not sure it provides a benefit commensurate to the effort it takes us, and we usually don't manage to do it right anyway. Few of our articles include links to non-open-access literature anyway. > * On the other hand, we can't give up code syntax highlighting. Not sure if WP markdown plugins would play nice with the syntax highlighter plugin, but they might. > * We'd have to figure out how to conveniently do notes/references too, especially for articles that want the (Smith 2000) style to be most readable. > * Not sure how we'd get things like our formatted captions on figures to work right, or center-aligned figures, etc.
> So there'd be some challenges. But I suspect they could be overcome. And I think it would make our jobs so much easier, take out the most annoying and least rewarding thing editors spend time on. And, hey, forcing the limitation to the subset of HTML that markdown can represent would make an article-to-PDF converter a lot easier too.
> ## Note
> This email is, as you may have guessed, in markdown.
> -- > You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com>. > To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com<mailto:c4lj-discuss%2Bunsubscribe @googlegroups.com>. > For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com. > To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com. > To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
Well, even if we allow authors to submit however they want, I suppose we could copy and paste as PLAIN TEXT (rather than HTML) and apply markdown/textile ourselves, which I think would still be a lot less annoying work than trying to get it entered in into WP in HTML. ________________________________________ From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] on behalf of Kelley McGrath [kmc...@gmail.com] Sent: Friday, July 22, 2011 12:21 PM To: c4lj-discuss@googlegroups.com Subject: Re: [c4lj] markdown?
One thing I like about C4LJ is the low barrier for entry for authors to get their content out. Even though this might not be all that hard to do, it potentially takes authors out of their normal writing workflow. Authors may also have already written something up in another format before deciding to submit to us. I think there are some parallels with the citation format discussion. I could go for an option or suggestion, but don't think I'd like to see it made a requirement.
On Fri, Jul 22, 2011 at 8:34 AM, Jonathan Rochkind <rochk...@jhu.edu> wrote: > Yeah, track changes, I dunno. I don't like our current 'solution' for track changes, passing around Word documents, but don't know of a better solution, markdown or not. (And we don't require authors to submit in Word or be able to open a Word file now, in fact).
> I wonder if there's a WordPress plugin that puts your posts in a code versioning system of some kind and lets you look at histories/diffs? Maybe that'd be the solution there -- which WOULD work better with markdown. With HTML, you're likely to get a lot of diffs that are just fixes to HTML syntax and structure and formatting rather than actual content.
> Markdown (or textile) are SO easy to use, that I personally don't see a problem with requiring authors to use it. We are a technical journal after all. (It looks like there may be some textile WP plugins too, so it could be textile instead of markdown. Depends on if ANY of these plugins, textile or markdown, are stable, mature, and flexible/powerful enough for our use, which I'm not sure).
> But I'm not looking for any immediate action on this, it's really just food for thought. I'd like to come up with SOME better way of handling our workflow. (While still being focused on HTML as our primary delivery, not PDF. When I think 'troubles with workflow', I think , gee, let's see what OJS does -- but they seem to punt on HTML entry/editing workflow problems, instead focusing on PDFs as the primary delivery. Which is not where any of us want to go.)
> ________________________________ > From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] on behalf of Tom Keays [tomke...@gmail.com] > Sent: Thursday, July 21, 2011 9:52 PM > To: c4lj-discuss@googlegroups.com > Subject: Re: [c4lj] markdown?
> Markdown was one of the first text syntaxes I used (in a Moveable Type blog I had 8 or so years ago) and it is still a fine markup language. I think it _can_ coexist with raw HTML (at least my Moveable Type blog could, through a post-specific setting), but probably not with the WYSIWYG editor. Something to keep in mind.
> Barring technical complications, however, one concern might be people's comfort level using the markup syntax approach. That seems to be the crux of people's resistance to using wikis. How much of a problem will editors find it to convert a formatted word processing document to Markdown?
> Another concern is the ability to track changes. One of the articles I edited this year was originally submitted in a text markup syntax (Textile, I think). I eventually converted it to Word and coordinated further edits with the authors that way. If we had a way to track changes and share them with the authors using Wordpress, that would have addressed that problem very nicely. This is true regardless of whether we decide to go with Markdown or not. Our current editing paradigm is not to enter the article into Wordpress until most of the changes have been made, which mitigates the problem somewhat.
> These are devil's advocate objections though. If others like the idea, we should definitely explore it.
> Tom
> On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind <rochk...@jhu.edu<mailto:rochk...@jhu.edu>> wrote: > I just had a crazy idea, put it out there for discussion, certainly not expecting any immediate action, even if people like it we'll want to stew on it for a while.
> One of the most time consuming and annoying parts of editing the journal is getting things into HTML and editing the HTML without WordPress messing it up, etc.
> * What if we required authors to submit in markdown (basically plaintext with some pretty easy to remember conventions for indicating headers, lists, links, embedded images, etc) > * Then we just entered the markdown in WordPress > * Profit!
> ## Disadvantages
> * We wouldn't be able to use fancy custom HTML anymore. This has some pro's in enforcing consistency, but also some obvious cons. > * We'd probably have to give up on the COinS, which I think would actually be fine. Some years on, COinS has not really caught on, I'm not sure it provides a benefit commensurate to the effort it takes us, and we usually don't manage to do it right anyway. Few of our articles include links to non-open-access literature anyway. > * On the other hand, we can't give up code syntax highlighting. Not sure if WP markdown plugins would play nice with the syntax highlighter plugin, but they might. > * We'd have to figure out how to conveniently do notes/references too, especially for articles that want the (Smith 2000) style to be most readable. > * Not sure how we'd get things like our formatted captions on figures to work right, or center-aligned figures, etc.
> So there'd be some challenges. But I suspect they could be overcome. And I think it would make our jobs so much easier, take out the most annoying and least rewarding thing editors spend time on. And, hey, forcing the limitation to the subset of HTML that markdown can represent would make an article-to-PDF converter a lot easier too.
> ## Note
> This email is, as you may have guessed, in markdown.
> -- > You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com>. > To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com<mailto:c4lj-discuss%2Bunsubscribe @googlegroups.com>. > For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com. > To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com. > To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
-- You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. To post to this group, send email to c4lj-discuss@googlegroups.com. To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind <rochk...@jhu.edu>wrote:
> Yeah, track changes, I dunno. I don't like our current 'solution' for track > changes, passing around Word documents, but don't know of a better solution, > markdown or not. (And we don't require authors to submit in Word or be able > to open a Word file now, in fact).
Wordpress itself keeps a version history for each article, but it isn't a track changes system by any means. Plus, only the editors can see the versions; we can't share them with the authors in the current set up.
One thing that occurred to me awhile back is that we could set up a separate private Wordpress instance where article drafts are composed and edited. In this scenario, (regardless of whether we settle on a Markdown plugin approach or not) the Wordpress instance would be enabled with the DigressIt plugin [1] (the successor to CommentPress [2]) which would allow editors and authors to comment, section by section, on passages in the article. Depending on how it was set up, it could even allow authors and editors to collaboratively edit the article itself. This doesn't really address Kelley's concern about not taking "authors out of their normal writing workflow" though. I'm also not sure what happens to the section comments if you move sections around in the posting; it was a problem in CommentPress, I know.
Another problem, and the main reason I haven't proposed the idea before, is DigressIt treats individual posts as chapters in a single work ("work" here being the entire blog; see some of the examples [3]). Because it indexes posts as they're published, there's no real way to keep articles private from anyone who has access to this editing area. Authors could see all the articles underway, even articles that might not end up being published. That would be awkward, at the very least.
However, in our current scenario, draft articles in Wordpress are not indexed and are not viewable unless you have logged in (authors are given a read-only login for this purpose). That approach might work in a DigressIt powered system too but I haven't played around with it enough to conceptualize it further.
Another approach entirely might be just to compose and edit the draft articles in a wiki -- ideally using the same markup syntax that the Wordpress blog uses. Wikis generally have robust versioning systems built-in, but tracking changes in a given passage is still a tedious, iterative process -- you have to step through all the various versions until you see the change appear.
We could also give each author their own login (rather than the shared login) earlier in the process, and give them access to their draft article (but not other articles), if that would help with any of these ideas, and if it's easy to do in WP, which I think it should be. ________________________________ From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] on behalf of Tom Keays [tomke...@gmail.com] Sent: Friday, July 22, 2011 12:32 PM To: c4lj-discuss@googlegroups.com Subject: Re: [c4lj] markdown?
On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind <rochk...@jhu.edu<mailto:rochk...@jhu.edu>> wrote:
Yeah, track changes, I dunno. I don't like our current 'solution' for track changes, passing around Word documents, but don't know of a better solution, markdown or not. (And we don't require authors to submit in Word or be able to open a Word file now, in fact).
Wordpress itself keeps a version history for each article, but it isn't a track changes system by any means. Plus, only the editors can see the versions; we can't share them with the authors in the current set up.
One thing that occurred to me awhile back is that we could set up a separate private Wordpress instance where article drafts are composed and edited. In this scenario, (regardless of whether we settle on a Markdown plugin approach or not) the Wordpress instance would be enabled with the DigressIt plugin [1] (the successor to CommentPress [2]) which would allow editors and authors to comment, section by section, on passages in the article. Depending on how it was set up, it could even allow authors and editors to collaboratively edit the article itself. This doesn't really address Kelley's concern about not taking "authors out of their normal writing workflow" though. I'm also not sure what happens to the section comments if you move sections around in the posting; it was a problem in CommentPress, I know.
Another problem, and the main reason I haven't proposed the idea before, is DigressIt treats individual posts as chapters in a single work ("work" here being the entire blog; see some of the examples [3]). Because it indexes posts as they're published, there's no real way to keep articles private from anyone who has access to this editing area. Authors could see all the articles underway, even articles that might not end up being published. That would be awkward, at the very least.
However, in our current scenario, draft articles in Wordpress are not indexed and are not viewable unless you have logged in (authors are given a read-only login for this purpose). That approach might work in a DigressIt powered system too but I haven't played around with it enough to conceptualize it further.
Another approach entirely might be just to compose and edit the draft articles in a wiki -- ideally using the same markup syntax that the Wordpress blog uses. Wikis generally have robust versioning systems built-in, but tracking changes in a given passage is still a tedious, iterative process -- you have to step through all the various versions until you see the change appear.
Tom
-- You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. To post to this group, send email to c4lj-discuss@googlegroups.com. To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
On Fri, Jul 22, 2011 at 12:31 PM, Jonathan Rochkind <rochk...@jhu.edu>wrote:
> Well, even if we allow authors to submit however they want, I suppose we > could copy and paste as PLAIN TEXT (rather than HTML) and apply > markdown/textile ourselves, which I think would still be a lot less annoying > work than trying to get it entered in into WP in HTML
FWIW, I already do that anyway. Because I use the HTML editor (not the WYSIWYG editor), I actually do my edits in a separate text file and upload them to Wordpress as I go along. The main worry here is that another editor will fix something and I'll come along unknowing and undo it.
Yeah, wouldn't fix that problem, but for me at least it would make it easier for me to be doing my conversion/edits in markdown instead of HTML. ________________________________ From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] on behalf of Tom Keays [tomke...@gmail.com] Sent: Friday, July 22, 2011 12:35 PM To: c4lj-discuss@googlegroups.com Subject: Re: [c4lj] markdown?
On Fri, Jul 22, 2011 at 12:31 PM, Jonathan Rochkind <rochk...@jhu.edu<mailto:rochk...@jhu.edu>> wrote:
Well, even if we allow authors to submit however they want, I suppose we could copy and paste as PLAIN TEXT (rather than HTML) and apply markdown/textile ourselves, which I think would still be a lot less annoying work than trying to get it entered in into WP in HTML
FWIW, I already do that anyway. Because I use the HTML editor (not the WYSIWYG editor), I actually do my edits in a separate text file and upload them to Wordpress as I go along. The main worry here is that another editor will fix something and I'll come along unknowing and undo it.
Tom
-- You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. To post to this group, send email to c4lj-discuss@googlegroups.com. To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
I have actually been pretty happy with the copy from Word plug-in, although it may be that I may have articles with less complicated layout issues and I am certainly a less discerning consumer of HTML.
On Fri, Jul 22, 2011 at 9:35 AM, Tom Keays <tomke...@gmail.com> wrote: > On Fri, Jul 22, 2011 at 12:31 PM, Jonathan Rochkind <rochk...@jhu.edu> > wrote:
>> Well, even if we allow authors to submit however they want, I suppose we >> could copy and paste as PLAIN TEXT (rather than HTML) and apply >> markdown/textile ourselves, which I think would still be a lot less annoying >> work than trying to get it entered in into WP in HTML
> FWIW, I already do that anyway. Because I use the HTML editor (not the > WYSIWYG editor), I actually do my edits in a separate text file and upload > them to Wordpress as I go along. The main worry here is that another editor > will fix something and I'll come along unknowing and undo it.
> Tom
> -- > You received this message because you are subscribed to the Google Groups > "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com. > To unsubscribe from this group, send email to > c4lj-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/c4lj-discuss?hl=en.
On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind <rochk...@jhu.edu> wrote: > Yeah, track changes, I dunno. I don't like our current 'solution' for track changes, passing around Word documents, but don't know of a better solution, markdown or not. (And we don't require authors to submit in Word or be able to open a Word file now, in fact).
> I wonder if there's a WordPress plugin that puts your posts in a code versioning system of some kind and lets you look at histories/diffs? Maybe that'd be the solution there -- which WOULD work better with markdown. With HTML, you're likely to get a lot of diffs that are just fixes to HTML syntax and structure and formatting rather than actual content.
The article I edited for issue 13 (From ISIS to CouchDB) was handled in a DVCS (Mercurial, hosted at bitbucket.org, because that's where Luciano had it set up). I must say, it made for a great workflow that I would love to repeat. Not all authors would be comfortable working in version control, and I appreciate our flexibility in handling whatever the author brings to us, but my ideal would be Markdown articles in a Git repo. Could we at least encourage that somehow?
> Markdown (or textile) are SO easy to use, that I personally don't see a problem with requiring authors to use it. We are a technical journal after all. (It looks like there may be some textile WP plugins too, so it could be textile instead of markdown. Depends on if ANY of these plugins, textile or markdown, are stable, mature, and flexible/powerful enough for our use, which I'm not sure).
> But I'm not looking for any immediate action on this, it's really just food for thought. I'd like to come up with SOME better way of handling our workflow. (While still being focused on HTML as our primary delivery, not PDF. When I think 'troubles with workflow', I think , gee, let's see what OJS does -- but they seem to punt on HTML entry/editing workflow problems, instead focusing on PDFs as the primary delivery. Which is not where any of us want to go.)
> ________________________________ > From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] on behalf of Tom Keays [tomke...@gmail.com] > Sent: Thursday, July 21, 2011 9:52 PM > To: c4lj-discuss@googlegroups.com > Subject: Re: [c4lj] markdown?
> Markdown was one of the first text syntaxes I used (in a Moveable Type blog I had 8 or so years ago) and it is still a fine markup language. I think it _can_ coexist with raw HTML (at least my Moveable Type blog could, through a post-specific setting), but probably not with the WYSIWYG editor. Something to keep in mind.
> Barring technical complications, however, one concern might be people's comfort level using the markup syntax approach. That seems to be the crux of people's resistance to using wikis. How much of a problem will editors find it to convert a formatted word processing document to Markdown?
> Another concern is the ability to track changes. One of the articles I edited this year was originally submitted in a text markup syntax (Textile, I think). I eventually converted it to Word and coordinated further edits with the authors that way. If we had a way to track changes and share them with the authors using Wordpress, that would have addressed that problem very nicely. This is true regardless of whether we decide to go with Markdown or not. Our current editing paradigm is not to enter the article into Wordpress until most of the changes have been made, which mitigates the problem somewhat.
> These are devil's advocate objections though. If others like the idea, we should definitely explore it.
> Tom
> On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind <rochk...@jhu.edu<mailto:rochk...@jhu.edu>> wrote: > I just had a crazy idea, put it out there for discussion, certainly not expecting any immediate action, even if people like it we'll want to stew on it for a while.
> One of the most time consuming and annoying parts of editing the journal is getting things into HTML and editing the HTML without WordPress messing it up, etc.
> * What if we required authors to submit in markdown (basically plaintext with some pretty easy to remember conventions for indicating headers, lists, links, embedded images, etc) > * Then we just entered the markdown in WordPress > * Profit!
> ## Disadvantages
> * We wouldn't be able to use fancy custom HTML anymore. This has some pro's in enforcing consistency, but also some obvious cons. > * We'd probably have to give up on the COinS, which I think would actually be fine. Some years on, COinS has not really caught on, I'm not sure it provides a benefit commensurate to the effort it takes us, and we usually don't manage to do it right anyway. Few of our articles include links to non-open-access literature anyway. > * On the other hand, we can't give up code syntax highlighting. Not sure if WP markdown plugins would play nice with the syntax highlighter plugin, but they might. > * We'd have to figure out how to conveniently do notes/references too, especially for articles that want the (Smith 2000) style to be most readable. > * Not sure how we'd get things like our formatted captions on figures to work right, or center-aligned figures, etc.
> So there'd be some challenges. But I suspect they could be overcome. And I think it would make our jobs so much easier, take out the most annoying and least rewarding thing editors spend time on. And, hey, forcing the limitation to the subset of HTML that markdown can represent would make an article-to-PDF converter a lot easier too.
> ## Note
> This email is, as you may have guessed, in markdown.
> -- > You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com>. > To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com<mailto:c4lj-discuss%2Bunsubscribe @googlegroups.com>. > For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com. > To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com. > To unsubscribe from this group, send email to c4lj-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/c4lj-discuss?hl=en.
On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell <gsf...@gmail.com> wrote: > On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind <rochk...@jhu.edu> > wrote: > > Yeah, track changes, I dunno. I don't like our current 'solution' for > track changes, passing around Word documents, but don't know of a better > solution, markdown or not. (And we don't require authors to submit in Word > or be able to open a Word file now, in fact).
> > I wonder if there's a WordPress plugin that puts your posts in a code > versioning system of some kind and lets you look at histories/diffs? Maybe > that'd be the solution there -- which WOULD work better with markdown. With > HTML, you're likely to get a lot of diffs that are just fixes to HTML syntax > and structure and formatting rather than actual content.
> The article I edited for issue 13 (From ISIS to CouchDB) was handled > in a DVCS (Mercurial, hosted at bitbucket.org, because that's where > Luciano had it set up). I must say, it made for a great workflow that > I would love to repeat. Not all authors would be comfortable working > in version control, and I appreciate our flexibility in handling > whatever the author brings to us, but my ideal would be Markdown > articles in a Git repo. Could we at least encourage that somehow?
> > Markdown (or textile) are SO easy to use, that I personally don't see a > problem with requiring authors to use it. We are a technical journal after > all. (It looks like there may be some textile WP plugins too, so it could be > textile instead of markdown. Depends on if ANY of these plugins, textile or > markdown, are stable, mature, and flexible/powerful enough for our use, > which I'm not sure).
> > But I'm not looking for any immediate action on this, it's really just > food for thought. I'd like to come up with SOME better way of handling our > workflow. (While still being focused on HTML as our primary delivery, not > PDF. When I think 'troubles with workflow', I think , gee, let's see what > OJS does -- but they seem to punt on HTML entry/editing workflow problems, > instead focusing on PDFs as the primary delivery. Which is not where any of > us want to go.)
> > ________________________________ > > From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] on > behalf of Tom Keays [tomke...@gmail.com] > > Sent: Thursday, July 21, 2011 9:52 PM > > To: c4lj-discuss@googlegroups.com > > Subject: Re: [c4lj] markdown?
> > Markdown was one of the first text syntaxes I used (in a Moveable Type > blog I had 8 or so years ago) and it is still a fine markup language. I > think it _can_ coexist with raw HTML (at least my Moveable Type blog could, > through a post-specific setting), but probably not with the WYSIWYG editor. > Something to keep in mind.
> > Barring technical complications, however, one concern might be people's > comfort level using the markup syntax approach. That seems to be the crux of > people's resistance to using wikis. How much of a problem will editors find > it to convert a formatted word processing document to Markdown?
> > Another concern is the ability to track changes. One of the articles I > edited this year was originally submitted in a text markup syntax (Textile, > I think). I eventually converted it to Word and coordinated further edits > with the authors that way. If we had a way to track changes and share them > with the authors using Wordpress, that would have addressed that problem > very nicely. This is true regardless of whether we decide to go with > Markdown or not. Our current editing paradigm is not to enter the article > into Wordpress until most of the changes have been made, which mitigates the > problem somewhat.
> > These are devil's advocate objections though. If others like the idea, we > should definitely explore it.
> > Tom
> > On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind <rochk...@jhu.edu > <mailto:rochk...@jhu.edu>> wrote: > > I just had a crazy idea, put it out there for discussion, certainly not > expecting any immediate action, even if people like it we'll want to stew on > it for a while.
> > One of the most time consuming and annoying parts of editing the journal > is getting things into HTML and editing the HTML without WordPress messing > it up, etc.
> > * What if we required authors to submit in markdown (basically plaintext > with some pretty easy to remember conventions for indicating headers, lists, > links, embedded images, etc) > > * Then we just entered the markdown in WordPress > > * Profit!
> > ## Disadvantages
> > * We wouldn't be able to use fancy custom HTML anymore. This has some > pro's in enforcing consistency, but also some obvious cons. > > * We'd probably have to give up on the COinS, which I think would > actually be fine. Some years on, COinS has not really caught on, I'm not > sure it provides a benefit commensurate to the effort it takes us, and we > usually don't manage to do it right anyway. Few of our articles include > links to non-open-access literature anyway. > > * On the other hand, we can't give up code syntax highlighting. Not sure > if WP markdown plugins would play nice with the syntax highlighter plugin, > but they might. > > * We'd have to figure out how to conveniently do notes/references too, > especially for articles that want the (Smith 2000) style to be most > readable. > > * Not sure how we'd get things like our formatted captions on figures to > work right, or center-aligned figures, etc.
> > So there'd be some challenges. But I suspect they could be overcome. And > I think it would make our jobs so much easier, take out the most annoying > and least rewarding thing editors spend time on. And, hey, forcing the > limitation to the subset of HTML that markdown can represent would make an > article-to-PDF converter a lot easier too.
> > ## Note
> > This email is, as you may have guessed, in markdown.
> > -- > > You received this message because you are subscribed to the Google Groups > "Code4Lib Journal-discuss" group. > > To post to this group, send email to c4lj-discuss@googlegroups.com > <mailto:c4lj-discuss@googlegroups.com>. > > To unsubscribe from this group, send email to > c4lj-discuss+unsubscribe@googlegroups.com<mailto: > c4lj-discuss%2Bunsubscribe@googlegroups.com>. > > For more options, visit this group at > http://groups.google.com/group/c4lj-discuss?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups > "Code4Lib Journal-discuss" group. > > To post to this group, send email to c4lj-discuss@googlegroups.com. > > To unsubscribe from this group, send email to > c4lj-discuss+unsubscribe@googlegroups.com. > > For more options, visit this group at > http://groups.google.com/group/c4lj-discuss?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups > "Code4Lib Journal-discuss" group. > > To post to this group, send email to c4lj-discuss@googlegroups.com. > > To unsubscribe from this group, send email to > c4lj-discuss+unsubscribe@googlegroups.com. > > For more options, visit this group at > http://groups.google.com/group/c4lj-discuss?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com. > To unsubscribe from this group, send email to > c4lj-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/c4lj-discuss?hl=en.
On Sun, Jul 24, 2011 at 11:06 AM, Jodi Schneider <jschnei...@pobox.com> wrote: > That's really interesting, Gabe. How did you handle comments and > suggestions?
I think we just handled larger editorial suggestions via email, though I could see using issues or commit comments for that purpose. That's assuming the use of Github -- we could use another ticketing/issue system as well.
> It would be useful to see this repository if it's public, to get ideas.
> On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell <gsf...@gmail.com> wrote:
>> On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind <rochk...@jhu.edu> >> wrote: >> > Yeah, track changes, I dunno. I don't like our current 'solution' for >> > track changes, passing around Word documents, but don't know of a better >> > solution, markdown or not. (And we don't require authors to submit in Word >> > or be able to open a Word file now, in fact).
>> > I wonder if there's a WordPress plugin that puts your posts in a code >> > versioning system of some kind and lets you look at histories/diffs? Maybe >> > that'd be the solution there -- which WOULD work better with markdown. With >> > HTML, you're likely to get a lot of diffs that are just fixes to HTML syntax >> > and structure and formatting rather than actual content.
>> The article I edited for issue 13 (From ISIS to CouchDB) was handled >> in a DVCS (Mercurial, hosted at bitbucket.org, because that's where >> Luciano had it set up). I must say, it made for a great workflow that >> I would love to repeat. Not all authors would be comfortable working >> in version control, and I appreciate our flexibility in handling >> whatever the author brings to us, but my ideal would be Markdown >> articles in a Git repo. Could we at least encourage that somehow?
>> > Markdown (or textile) are SO easy to use, that I personally don't see a >> > problem with requiring authors to use it. We are a technical journal after >> > all. (It looks like there may be some textile WP plugins too, so it could be >> > textile instead of markdown. Depends on if ANY of these plugins, textile or >> > markdown, are stable, mature, and flexible/powerful enough for our use, >> > which I'm not sure).
>> > But I'm not looking for any immediate action on this, it's really just >> > food for thought. I'd like to come up with SOME better way of handling our >> > workflow. (While still being focused on HTML as our primary delivery, not >> > PDF. When I think 'troubles with workflow', I think , gee, let's see what >> > OJS does -- but they seem to punt on HTML entry/editing workflow problems, >> > instead focusing on PDFs as the primary delivery. Which is not where any of >> > us want to go.)
>> > ________________________________ >> > From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] on >> > behalf of Tom Keays [tomke...@gmail.com] >> > Sent: Thursday, July 21, 2011 9:52 PM >> > To: c4lj-discuss@googlegroups.com >> > Subject: Re: [c4lj] markdown?
>> > Markdown was one of the first text syntaxes I used (in a Moveable Type >> > blog I had 8 or so years ago) and it is still a fine markup language. I >> > think it _can_ coexist with raw HTML (at least my Moveable Type blog could, >> > through a post-specific setting), but probably not with the WYSIWYG editor. >> > Something to keep in mind.
>> > Barring technical complications, however, one concern might be people's >> > comfort level using the markup syntax approach. That seems to be the crux of >> > people's resistance to using wikis. How much of a problem will editors find >> > it to convert a formatted word processing document to Markdown?
>> > Another concern is the ability to track changes. One of the articles I >> > edited this year was originally submitted in a text markup syntax (Textile, >> > I think). I eventually converted it to Word and coordinated further edits >> > with the authors that way. If we had a way to track changes and share them >> > with the authors using Wordpress, that would have addressed that problem >> > very nicely. This is true regardless of whether we decide to go with >> > Markdown or not. Our current editing paradigm is not to enter the article >> > into Wordpress until most of the changes have been made, which mitigates the >> > problem somewhat.
>> > These are devil's advocate objections though. If others like the idea, >> > we should definitely explore it.
>> > Tom
>> > On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind >> > <rochk...@jhu.edu<mailto:rochk...@jhu.edu>> wrote: >> > I just had a crazy idea, put it out there for discussion, certainly not >> > expecting any immediate action, even if people like it we'll want to stew on >> > it for a while.
>> > One of the most time consuming and annoying parts of editing the journal >> > is getting things into HTML and editing the HTML without WordPress messing >> > it up, etc.
>> > * What if we required authors to submit in markdown (basically plaintext >> > with some pretty easy to remember conventions for indicating headers, lists, >> > links, embedded images, etc) >> > * Then we just entered the markdown in WordPress >> > * Profit!
>> > ## Disadvantages
>> > * We wouldn't be able to use fancy custom HTML anymore. This has some >> > pro's in enforcing consistency, but also some obvious cons. >> > * We'd probably have to give up on the COinS, which I think would >> > actually be fine. Some years on, COinS has not really caught on, I'm not >> > sure it provides a benefit commensurate to the effort it takes us, and we >> > usually don't manage to do it right anyway. Few of our articles include >> > links to non-open-access literature anyway. >> > * On the other hand, we can't give up code syntax highlighting. Not sure >> > if WP markdown plugins would play nice with the syntax highlighter plugin, >> > but they might. >> > * We'd have to figure out how to conveniently do notes/references too, >> > especially for articles that want the (Smith 2000) style to be most >> > readable. >> > * Not sure how we'd get things like our formatted captions on figures to >> > work right, or center-aligned figures, etc.
>> > So there'd be some challenges. But I suspect they could be overcome. And >> > I think it would make our jobs so much easier, take out the most annoying >> > and least rewarding thing editors spend time on. And, hey, forcing the >> > limitation to the subset of HTML that markdown can represent would make an >> > article-to-PDF converter a lot easier too.
>> > ## Note
>> > This email is, as you may have guessed, in markdown.
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Code4Lib Journal-discuss" group. >> > To post to this group, send email to >> > c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com>. >> > To unsubscribe from this group, send email to >> > c4lj-discuss+unsubscribe@googlegroups.com<mailto:c4lj-discuss%2Bunsubscribe @googlegroups.com>. >> > For more options, visit this group at >> > http://groups.google.com/group/c4lj-discuss?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Code4Lib Journal-discuss" group. >> > To post to this group, send email to c4lj-discuss@googlegroups.com. >> > To unsubscribe from this group, send email to >> > c4lj-discuss+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/c4lj-discuss?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Code4Lib Journal-discuss" group. >> > To post to this group, send email to c4lj-discuss@googlegroups.com. >> > To unsubscribe from this group, send email to >> > c4lj-discuss+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/c4lj-discuss?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "Code4Lib Journal-discuss" group. >> To post to this group, send email to c4lj-discuss@googlegroups.com. >> To unsubscribe from this group, send email to >> c4lj-discuss+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/c4lj-discuss?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com. > To unsubscribe from this group, send email to > c4lj-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/c4lj-discuss?hl=en.
On Sun, Jul 24, 2011 at 6:06 PM, Gabriel Farrell <gsf...@gmail.com> wrote: > On Sun, Jul 24, 2011 at 11:06 AM, Jodi Schneider <jschnei...@pobox.com> > wrote: > > That's really interesting, Gabe. How did you handle comments and > > suggestions?
> I think we just handled larger editorial suggestions via email, though > I could see using issues or commit comments for that purpose. That's > assuming the use of Github -- we could use another ticketing/issue > system as well.
> > It would be useful to see this repository if it's public, to get ideas.
> > On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell <gsf...@gmail.com> > wrote:
> >> On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind <rochk...@jhu.edu> > >> wrote: > >> > Yeah, track changes, I dunno. I don't like our current 'solution' for > >> > track changes, passing around Word documents, but don't know of a > better > >> > solution, markdown or not. (And we don't require authors to submit in > Word > >> > or be able to open a Word file now, in fact).
> >> > I wonder if there's a WordPress plugin that puts your posts in a code > >> > versioning system of some kind and lets you look at histories/diffs? > Maybe > >> > that'd be the solution there -- which WOULD work better with markdown. > With > >> > HTML, you're likely to get a lot of diffs that are just fixes to HTML > syntax > >> > and structure and formatting rather than actual content.
> >> The article I edited for issue 13 (From ISIS to CouchDB) was handled > >> in a DVCS (Mercurial, hosted at bitbucket.org, because that's where > >> Luciano had it set up). I must say, it made for a great workflow that > >> I would love to repeat. Not all authors would be comfortable working > >> in version control, and I appreciate our flexibility in handling > >> whatever the author brings to us, but my ideal would be Markdown > >> articles in a Git repo. Could we at least encourage that somehow?
> >> > Markdown (or textile) are SO easy to use, that I personally don't see > a > >> > problem with requiring authors to use it. We are a technical journal > after > >> > all. (It looks like there may be some textile WP plugins too, so it > could be > >> > textile instead of markdown. Depends on if ANY of these plugins, > textile or > >> > markdown, are stable, mature, and flexible/powerful enough for our > use, > >> > which I'm not sure).
> >> > But I'm not looking for any immediate action on this, it's really just > >> > food for thought. I'd like to come up with SOME better way of handling > our > >> > workflow. (While still being focused on HTML as our primary delivery, > not > >> > PDF. When I think 'troubles with workflow', I think , gee, let's see > what > >> > OJS does -- but they seem to punt on HTML entry/editing workflow > problems, > >> > instead focusing on PDFs as the primary delivery. Which is not where > any of > >> > us want to go.)
> >> > ________________________________ > >> > From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] > on > >> > behalf of Tom Keays [tomke...@gmail.com] > >> > Sent: Thursday, July 21, 2011 9:52 PM > >> > To: c4lj-discuss@googlegroups.com > >> > Subject: Re: [c4lj] markdown?
> >> > Markdown was one of the first text syntaxes I used (in a Moveable Type > >> > blog I had 8 or so years ago) and it is still a fine markup language. > I > >> > think it _can_ coexist with raw HTML (at least my Moveable Type blog > could, > >> > through a post-specific setting), but probably not with the WYSIWYG > editor. > >> > Something to keep in mind.
> >> > Barring technical complications, however, one concern might be > people's > >> > comfort level using the markup syntax approach. That seems to be the > crux of > >> > people's resistance to using wikis. How much of a problem will editors > find > >> > it to convert a formatted word processing document to Markdown?
> >> > Another concern is the ability to track changes. One of the articles I > >> > edited this year was originally submitted in a text markup syntax > (Textile, > >> > I think). I eventually converted it to Word and coordinated further > edits > >> > with the authors that way. If we had a way to track changes and share > them > >> > with the authors using Wordpress, that would have addressed that > problem > >> > very nicely. This is true regardless of whether we decide to go with > >> > Markdown or not. Our current editing paradigm is not to enter the > article > >> > into Wordpress until most of the changes have been made, which > mitigates the > >> > problem somewhat.
> >> > These are devil's advocate objections though. If others like the idea, > >> > we should definitely explore it.
> >> > Tom
> >> > On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind > >> > <rochk...@jhu.edu<mailto:rochk...@jhu.edu>> wrote: > >> > I just had a crazy idea, put it out there for discussion, certainly > not > >> > expecting any immediate action, even if people like it we'll want to > stew on > >> > it for a while.
> >> > One of the most time consuming and annoying parts of editing the > journal > >> > is getting things into HTML and editing the HTML without WordPress > messing > >> > it up, etc.
> >> > * What if we required authors to submit in markdown (basically > plaintext > >> > with some pretty easy to remember conventions for indicating headers, > lists, > >> > links, embedded images, etc) > >> > * Then we just entered the markdown in WordPress > >> > * Profit!
> >> > ## Disadvantages
> >> > * We wouldn't be able to use fancy custom HTML anymore. This has some > >> > pro's in enforcing consistency, but also some obvious cons. > >> > * We'd probably have to give up on the COinS, which I think would > >> > actually be fine. Some years on, COinS has not really caught on, I'm > not > >> > sure it provides a benefit commensurate to the effort it takes us, and > we > >> > usually don't manage to do it right anyway. Few of our articles > include > >> > links to non-open-access literature anyway. > >> > * On the other hand, we can't give up code syntax highlighting. Not > sure > >> > if WP markdown plugins would play nice with the syntax highlighter > plugin, > >> > but they might. > >> > * We'd have to figure out how to conveniently do notes/references too, > >> > especially for articles that want the (Smith 2000) style to be most > >> > readable. > >> > * Not sure how we'd get things like our formatted captions on figures > to > >> > work right, or center-aligned figures, etc.
> >> > So there'd be some challenges. But I suspect they could be overcome. > And > >> > I think it would make our jobs so much easier, take out the most > annoying > >> > and least rewarding thing editors spend time on. And, hey, forcing the > >> > limitation to the subset of HTML that markdown can represent would > make an > >> > article-to-PDF converter a lot easier too.
> >> > ## Note
> >> > This email is, as you may have guessed, in markdown.
> >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "Code4Lib Journal-discuss" group. > >> > To post to this group, send email to > >> > c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com>. > >> > To unsubscribe from this group, send email to > >> > c4lj-discuss+unsubscribe@googlegroups.com<mailto: > c4lj-discuss%2Bunsubscribe@googlegroups.com>. > >> > For more options, visit this group at > >> > http://groups.google.com/group/c4lj-discuss?hl=en.
> >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "Code4Lib Journal-discuss" group. > >> > To post to this group, send email to c4lj-discuss@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > c4lj-discuss+unsubscribe@googlegroups.com. > >> > For more options, visit this group at > >> > http://groups.google.com/group/c4lj-discuss?hl=en.
> >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "Code4Lib Journal-discuss" group. > >> > To post to this group, send email to c4lj-discuss@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > c4lj-discuss+unsubscribe@googlegroups.com. > >> > For more options, visit this group at > >> > http://groups.google.com/group/c4lj-discuss?hl=en.
> >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Code4Lib Journal-discuss" group. > >> To post to this group, send email to c4lj-discuss@googlegroups.com. > >> To unsubscribe from this group, send email to > >> c4lj-discuss+unsubscribe@googlegroups.com. > >> For more options, visit this group at > >> http://groups.google.com/group/c4lj-discuss?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups > > "Code4Lib Journal-discuss" group. > > To post to this group, send email to c4lj-discuss@googlegroups.com. > > To unsubscribe from this group, send email to > > c4lj-discuss+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/c4lj-discuss?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "Code4Lib Journal-discuss" group. > To post to this group, send email to c4lj-discuss@googlegroups.com. > To unsubscribe from this group, send email to
Hmm, one road block is that I think most authors wouldn't want their initial drafts -- and especially comments/revisions back and forth between editors and author -- to be public.
I'm not sure if there's a free/cheap revision control system that also has a good web interface including editing text in a browser. Otherwise it's an interesting idea. I haven't looked at Mecurial/bitbucket, but Github gives you an in browser 'edit' button (just an HTML text box, no graphical wysiwyg or anything), and also renders markdown (or textile, or a couple others) after you save, in the browser. You wouldn't even have to know you were using a revision control system. But it'd be public.
________________________________ From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] on behalf of Jodi Schneider [jschnei...@pobox.com] Sent: Sunday, July 24, 2011 2:33 PM To: c4lj-discuss@googlegroups.com Subject: Re: [c4lj] markdown?
On Sun, Jul 24, 2011 at 6:06 PM, Gabriel Farrell <gsf...@gmail.com<mailto:gsf...@gmail.com>> wrote:
On Sun, Jul 24, 2011 at 11:06 AM, Jodi Schneider <jschnei...@pobox.com<mailto:jschnei...@pobox.com>> wrote:
> That's really interesting, Gabe. How did you handle comments and > suggestions?
I think we just handled larger editorial suggestions via email, though I could see using issues or commit comments for that purpose. That's assuming the use of Github -- we could use another ticketing/issue system as well.
> It would be useful to see this repository if it's public, to get ideas.
> On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell <gsf...@gmail.com<mailto:gsf...@gmail.com>> wrote:
>> On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind <rochk...@jhu.edu<mailto:rochk...@jhu.edu>> >> wrote: >> > Yeah, track changes, I dunno. I don't like our current 'solution' for >> > track changes, passing around Word documents, but don't know of a better >> > solution, markdown or not. (And we don't require authors to submit in Word >> > or be able to open a Word file now, in fact).
>> > I wonder if there's a WordPress plugin that puts your posts in a code >> > versioning system of some kind and lets you look at histories/diffs? Maybe >> > that'd be the solution there -- which WOULD work better with markdown. With >> > HTML, you're likely to get a lot of diffs that are just fixes to HTML syntax >> > and structure and formatting rather than actual content.
>> The article I edited for issue 13 (From ISIS to CouchDB) was handled >> in a DVCS (Mercurial, hosted at bitbucket.org<http://bitbucket.org>, because that's where >> Luciano had it set up). I must say, it made for a great workflow that >> I would love to repeat. Not all authors would be comfortable working >> in version control, and I appreciate our flexibility in handling >> whatever the author brings to us, but my ideal would be Markdown >> articles in a Git repo. Could we at least encourage that somehow?
>> > Markdown (or textile) are SO easy to use, that I personally don't see a >> > problem with requiring authors to use it. We are a technical journal after >> > all. (It looks like there may be some textile WP plugins too, so it could be >> > textile instead of markdown. Depends on if ANY of these plugins, textile or >> > markdown, are stable, mature, and flexible/powerful enough for our use, >> > which I'm not sure).
>> > But I'm not looking for any immediate action on this, it's really just >> > food for thought. I'd like to come up with SOME better way of handling our >> > workflow. (While still being focused on HTML as our primary delivery, not >> > PDF. When I think 'troubles with workflow', I think , gee, let's see what >> > OJS does -- but they seem to punt on HTML entry/editing workflow problems, >> > instead focusing on PDFs as the primary delivery. Which is not where any of >> > us want to go.)
>> > ________________________________ >> > From: c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com> [c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com>] on >> > behalf of Tom Keays [tomke...@gmail.com<mailto:tomke...@gmail.com>] >> > Sent: Thursday, July 21, 2011 9:52 PM >> > To: c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com> >> > Subject: Re: [c4lj] markdown?
>> > Markdown was one of the first text syntaxes I used (in a Moveable Type >> > blog I had 8 or so years ago) and it is still a fine markup language. I >> > think it _can_ coexist with raw HTML (at least my Moveable Type blog could, >> > through a post-specific setting), but probably not with the WYSIWYG editor. >> > Something to keep in mind.
>> > Barring technical complications, however, one concern might be people's >> > comfort level using the markup syntax approach. That seems to be the crux of >> > people's resistance to using wikis. How much of a problem will editors find >> > it to convert a formatted word processing document to Markdown?
>> > Another concern is the ability to track changes. One of the articles I >> > edited this year was originally submitted in a text markup syntax (Textile, >> > I think). I eventually converted it to Word and coordinated further edits >> > with the authors that way. If we had a way to track changes and share them >> > with the authors using Wordpress, that would have addressed that problem >> > very nicely. This is true regardless of whether we decide to go with >> > Markdown or not. Our current editing paradigm is not to enter the article >> > into Wordpress until most of the changes have been made, which mitigates the >> > problem somewhat.
>> > These are devil's advocate objections though. If others like the idea, >> > we should definitely explore it.
>> > Tom
>> > On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind >> > <rochk...@jhu.edu<mailto:rochk...@jhu.edu><mailto:rochk...@jhu.edu<mailto:rochk...@jhu.edu>>> wrote: >> > I just had a crazy idea, put it out there for discussion, certainly not >> > expecting any immediate action, even if people like it we'll want to stew on >> > it for a while.
>> > One of the most time consuming and annoying parts of editing the journal >> > is getting things into HTML and editing the HTML without WordPress messing >> > it up, etc.
>> > * What if we required authors to submit in markdown (basically plaintext >> > with some pretty easy to remember conventions for indicating headers, lists, >> > links, embedded images, etc) >> > * Then we just entered the markdown in WordPress >> > * Profit!
>> > ## Disadvantages
>> > * We wouldn't be able to use fancy custom HTML anymore. This has some >> > pro's in enforcing consistency, but also some obvious cons. >> > * We'd probably have to give up on the COinS, which I think would >> > actually be fine. Some years on, COinS has not really caught on, I'm not >> > sure it provides a benefit commensurate to the effort it takes us, and we >> > usually don't manage to do it right anyway. Few of our articles include >> > links to non-open-access literature anyway. >> > * On the other hand, we can't give up code syntax highlighting. Not sure >> > if WP markdown plugins would play nice with the syntax highlighter plugin, >> > but they might. >> > * We'd have to figure out how to conveniently do notes/references too, >> > especially for articles that want the (Smith 2000) style to be most >> > readable. >> > * Not sure how we'd get things like our formatted captions on figures to >> > work right, or center-aligned figures, etc.
>> > So there'd be some challenges. But I suspect they could be overcome. And >> > I think it would make our jobs so much easier, take out the most annoying >> > and least rewarding thing editors spend time on. And, hey, forcing the >> > limitation to the subset of HTML that markdown can represent would make an >> > article-to-PDF converter a lot easier too.
>> > ## Note
>> > This email is, as you may have guessed, in markdown.
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Code4Lib Journal-discuss" group. >> > To post to this group, send email to >> > c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com><mailto: c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com>>. >> > To unsubscribe from this group, send email to >> > c4lj-discuss+unsubscribe@googlegroups.com<mailto:c4lj-discuss%2Bunsubscribe @googlegroups.com><mailto:c4lj-discuss%2Bunsubscribe@googlegroups.com<mailt o:c4lj-discuss%252Bunsubscribe@googlegroups.com>>. >> > For more options, visit this group at >> > http://groups.google.com/group/c4lj-discuss?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Code4Lib Journal-discuss" group. >> > To post to this group, send email to c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com>. >> > To unsubscribe from this group, send email to >> > c4lj-discuss+unsubscribe@googlegroups.com<mailto:c4lj-discuss%2Bunsubscribe @googlegroups.com>. >> > For more options, visit this group at >> > http://groups.google.com/group/c4lj-discuss?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Code4Lib Journal-discuss" group. >> > To post to this group, send email to c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com>. >> > To unsubscribe from this group, send email to
That's an interesting approach and one I could see working with our current workflow. It does mean manually updating Wordpress when edits are accepted, but that's not really a big problem. I like the idea of being able to share it with the authors.
Can you clarify: you would recommend Github over Bitbucket for this purpose because it handles commenting better?
Also, I noticed that all the text was hard-wrapped to 80 characters. Is line wrapping required or just your preference? When I have edited my articles in a text editor, I only put hard returns at the end of paragraphs.
On Sun, Jul 24, 2011 at 1:06 PM, Gabriel Farrell <gsf...@gmail.com> wrote: > On Sun, Jul 24, 2011 at 11:06 AM, Jodi Schneider <jschnei...@pobox.com> > wrote: > > That's really interesting, Gabe. How did you handle comments and > > suggestions?
> I think we just handled larger editorial suggestions via email, though > I could see using issues or commit comments for that purpose. That's > assuming the use of Github -- we could use another ticketing/issue > system as well.
> > It would be useful to see this repository if it's public, to get ideas.
> > On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell <gsf...@gmail.com> > wrote:
> >> On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind <rochk...@jhu.edu> > >> wrote: > >> > Yeah, track changes, I dunno. I don't like our current 'solution' for > >> > track changes, passing around Word documents, but don't know of a > better > >> > solution, markdown or not. (And we don't require authors to submit in > Word > >> > or be able to open a Word file now, in fact).
> >> > I wonder if there's a WordPress plugin that puts your posts in a code > >> > versioning system of some kind and lets you look at histories/diffs? > Maybe > >> > that'd be the solution there -- which WOULD work better with markdown. > With > >> > HTML, you're likely to get a lot of diffs that are just fixes to HTML > syntax > >> > and structure and formatting rather than actual content.
> >> The article I edited for issue 13 (From ISIS to CouchDB) was handled > >> in a DVCS (Mercurial, hosted at bitbucket.org, because that's where > >> Luciano had it set up). I must say, it made for a great workflow that > >> I would love to repeat. Not all authors would be comfortable working > >> in version control, and I appreciate our flexibility in handling > >> whatever the author brings to us, but my ideal would be Markdown > >> articles in a Git repo. Could we at least encourage that somehow?
> >> > Markdown (or textile) are SO easy to use, that I personally don't see > a > >> > problem with requiring authors to use it. We are a technical journal > after > >> > all. (It looks like there may be some textile WP plugins too, so it > could be > >> > textile instead of markdown. Depends on if ANY of these plugins, > textile or > >> > markdown, are stable, mature, and flexible/powerful enough for our > use, > >> > which I'm not sure).
> >> > But I'm not looking for any immediate action on this, it's really just > >> > food for thought. I'd like to come up with SOME better way of handling > our > >> > workflow. (While still being focused on HTML as our primary delivery, > not > >> > PDF. When I think 'troubles with workflow', I think , gee, let's see > what > >> > OJS does -- but they seem to punt on HTML entry/editing workflow > problems, > >> > instead focusing on PDFs as the primary delivery. Which is not where > any of > >> > us want to go.)
> >> > ________________________________ > >> > From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] > on > >> > behalf of Tom Keays [tomke...@gmail.com] > >> > Sent: Thursday, July 21, 2011 9:52 PM > >> > To: c4lj-discuss@googlegroups.com > >> > Subject: Re: [c4lj] markdown?
> >> > Markdown was one of the first text syntaxes I used (in a Moveable Type > >> > blog I had 8 or so years ago) and it is still a fine markup language. > I > >> > think it _can_ coexist with raw HTML (at least my Moveable Type blog > could, > >> > through a post-specific setting), but probably not with the WYSIWYG > editor. > >> > Something to keep in mind.
> >> > Barring technical complications, however, one concern might be > people's > >> > comfort level using the markup syntax approach. That seems to be the > crux of > >> > people's resistance to using wikis. How much of a problem will editors > find > >> > it to convert a formatted word processing document to Markdown?
> >> > Another concern is the ability to track changes. One of the articles I > >> > edited this year was originally submitted in a text markup syntax > (Textile, > >> > I think). I eventually converted it to Word and coordinated further > edits > >> > with the authors that way. If we had a way to track changes and share > them > >> > with the authors using Wordpress, that would have addressed that > problem > >> > very nicely. This is true regardless of whether we decide to go with > >> > Markdown or not. Our current editing paradigm is not to enter the > article > >> > into Wordpress until most of the changes have been made, which > mitigates the > >> > problem somewhat.
> >> > These are devil's advocate objections though. If others like the idea, > >> > we should definitely explore it.
> >> > Tom
> >> > On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind > >> > <rochk...@jhu.edu<mailto:rochk...@jhu.edu>> wrote: > >> > I just had a crazy idea, put it out there for discussion, certainly > not > >> > expecting any immediate action, even if people like it we'll want to > stew on > >> > it for a while.
> >> > One of the most time consuming and annoying parts of editing the > journal > >> > is getting things into HTML and editing the HTML without WordPress > messing > >> > it up, etc.
> >> > * What if we required authors to submit in markdown (basically > plaintext > >> > with some pretty easy to remember conventions for indicating headers, > lists, > >> > links, embedded images, etc) > >> > * Then we just entered the markdown in WordPress > >> > * Profit!
> >> > ## Disadvantages
> >> > * We wouldn't be able to use fancy custom HTML anymore. This has some > >> > pro's in enforcing consistency, but also some obvious cons. > >> > * We'd probably have to give up on the COinS, which I think would > >> > actually be fine. Some years on, COinS has not really caught on, I'm > not > >> > sure it provides a benefit commensurate to the effort it takes us, and > we > >> > usually don't manage to do it right anyway. Few of our articles > include > >> > links to non-open-access literature anyway. > >> > * On the other hand, we can't give up code syntax highlighting. Not > sure > >> > if WP markdown plugins would play nice with the syntax highlighter > plugin, > >> > but they might. > >> > * We'd have to figure out how to conveniently do notes/references too, > >> > especially for articles that want the (Smith 2000) style to be most > >> > readable. > >> > * Not sure how we'd get things like our formatted captions on figures > to > >> > work right, or center-aligned figures, etc.
> >> > So there'd be some challenges. But I suspect they could be overcome. > And > >> > I think it would make our jobs so much easier, take out the most > annoying > >> > and least rewarding thing editors spend time on. And, hey, forcing the > >> > limitation to the subset of HTML that markdown can represent would > make an > >> > article-to-PDF converter a lot easier too.
> >> > ## Note
> >> > This email is, as you may have guessed, in markdown.
> >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "Code4Lib Journal-discuss" group. > >> > To post to this group, send email to > >> > c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com>. > >> > To unsubscribe from this group, send email to > >> > c4lj-discuss+unsubscribe@googlegroups.com<mailto: > c4lj-discuss%2Bunsubscribe@googlegroups.com>. > >> > For more options, visit this group at > >> > http://groups.google.com/group/c4lj-discuss?hl=en.
> >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "Code4Lib Journal-discuss" group. > >> > To post to this group, send email to c4lj-discuss@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > c4lj-discuss+unsubscribe@googlegroups.com. > >> > For more options, visit this group at > >> > http://groups.google.com/group/c4lj-discuss?hl=en.
> >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "Code4Lib Journal-discuss" group. > >> > To post to this group, send email to c4lj-discuss@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > c4lj-discuss+unsubscribe@googlegroups.com. > >> > For more options, visit this group at > >> > http://groups.google.com/group/c4lj-discuss?hl=en.
> >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Code4Lib Journal-discuss" group. > >> To post to this group, send email to c4lj-discuss@googlegroups.com. > >> To unsubscribe from this group, send email to > >> c4lj-discuss+unsubscribe@googlegroups.com. > >> For more options, visit this group at > >> http://groups.google.com/group/c4lj-discuss?hl=en.
> > -- > > You received this message because you are subscribed to
On Mon, Jul 25, 2011 at 9:31 AM, Jonathan Rochkind <rochk...@jhu.edu> wrote: > Hmm, one road block is that I think most authors wouldn't want their > initial drafts -- and especially comments/revisions back and forth between > editors and author -- to be public.
> I'm not sure if there's a free/cheap revision control system that also has > a good web interface including editing text in a browser. Otherwise it's an > interesting idea. I haven't looked at Mecurial/bitbucket, but Github gives > you an in browser 'edit' button (just an HTML text box, no graphical wysiwyg > or anything), and also renders markdown (or textile, or a couple others) > after you save, in the browser. You wouldn't even have to know you were > using a revision control system. But it'd be public.
> ________________________________ > From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] on > behalf of Jodi Schneider [jschnei...@pobox.com] > Sent: Sunday, July 24, 2011 2:33 PM > To: c4lj-discuss@googlegroups.com > Subject: Re: [c4lj] markdown?
> On Sun, Jul 24, 2011 at 6:06 PM, Gabriel Farrell <gsf...@gmail.com<mailto: > gsf...@gmail.com>> wrote: > On Sun, Jul 24, 2011 at 11:06 AM, Jodi Schneider <jschnei...@pobox.com > <mailto:jschnei...@pobox.com>> wrote: > > That's really interesting, Gabe. How did you handle comments and > > suggestions?
> I think we just handled larger editorial suggestions via email, though > I could see using issues or commit comments for that purpose. That's > assuming the use of Github -- we could use another ticketing/issue > system as well.
> > It would be useful to see this repository if it's public, to get ideas.
> > On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell <gsf...@gmail.com > <mailto:gsf...@gmail.com>> wrote:
> >> On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind <rochk...@jhu.edu > <mailto:rochk...@jhu.edu>> > >> wrote: > >> > Yeah, track changes, I dunno. I don't like our current 'solution' for > >> > track changes, passing around Word documents, but don't know of a > better > >> > solution, markdown or not. (And we don't require authors to submit in > Word > >> > or be able to open a Word file now, in fact).
> >> > I wonder if there's a WordPress plugin that puts your posts in a code > >> > versioning system of some kind and lets you look at histories/diffs? > Maybe > >> > that'd be the solution there -- which WOULD work better with markdown. > With > >> > HTML, you're likely to get a lot of diffs that are just fixes to HTML > syntax > >> > and structure and formatting rather than actual content.
> >> The article I edited for issue 13 (From ISIS to CouchDB) was handled > >> in a DVCS (Mercurial, hosted at bitbucket.org<http://bitbucket.org>, > because that's where > >> Luciano had it set up). I must say, it made for a great workflow that > >> I would love to repeat. Not all authors would be comfortable working > >> in version control, and I appreciate our flexibility in handling > >> whatever the author brings to us, but my ideal would be Markdown > >> articles in a Git repo. Could we at least encourage that somehow?
> >> > Markdown (or textile) are SO easy to use, that I personally don't see > a > >> > problem with requiring authors to use it. We are a technical journal > after > >> > all. (It looks like there may be some textile WP plugins too, so it > could be > >> > textile instead of markdown. Depends on if ANY of these plugins, > textile or > >> > markdown, are stable, mature, and flexible/powerful enough for our > use, > >> > which I'm not sure).
> >> > But I'm not looking for any immediate action on this, it's really just > >> > food for thought. I'd like to come up with SOME better way of handling > our > >> > workflow. (While still being focused on HTML as our primary delivery, > not > >> > PDF. When I think 'troubles with workflow', I think , gee, let's see > what > >> > OJS does -- but they seem to punt on HTML entry/editing workflow > problems, > >> > instead focusing on PDFs as the primary delivery. Which is not where > any of > >> > us want to go.)
> >> > ________________________________ > >> > From: c4lj-discuss@googlegroups.com<mailto: > c4lj-discuss@googlegroups.com> [c4lj-discuss@googlegroups.com<mailto: > c4lj-discuss@googlegroups.com>] on > >> > behalf of Tom Keays [tomke...@gmail.com<mailto:tomke...@gmail.com>] > >> > Sent: Thursday, July 21, 2011 9:52 PM > >> > To: c4lj-discuss@googlegroups.com<mailto: > c4lj-discuss@googlegroups.com> > >> > Subject: Re: [c4lj] markdown?
> >> > Markdown was one of the first text syntaxes I used (in a Moveable Type > >> > blog I had 8 or so years ago) and it is still a fine markup language. > I > >> > think it _can_ coexist with raw HTML (at least my Moveable Type blog > could, > >> > through a post-specific setting), but probably not with the WYSIWYG > editor. > >> > Something to keep in mind.
> >> > Barring technical complications, however, one concern might be > people's > >> > comfort level using the markup syntax approach. That seems to be the > crux of > >> > people's resistance to using wikis. How much of a problem will editors > find > >> > it to convert a formatted word processing document to Markdown?
> >> > Another concern is the ability to track changes. One of the articles I > >> > edited this year was originally submitted in a text markup syntax > (Textile, > >> > I think). I eventually converted it to Word and coordinated further > edits > >> > with the authors that way. If we had a way to track changes and share > them > >> > with the authors using Wordpress, that would have addressed that > problem > >> > very nicely. This is true regardless of whether we decide to go with > >> > Markdown or not. Our current editing paradigm is not to enter the > article > >> > into Wordpress until most of the changes have been made, which > mitigates the > >> > problem somewhat.
> >> > These are devil's advocate objections though. If others like the idea, > >> > we should definitely explore it.
> >> > Tom
> >> > On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind > >> > <rochk...@jhu.edu<mailto:rochk...@jhu.edu><mailto:rochk...@jhu.edu > <mailto:rochk...@jhu.edu>>> wrote: > >> > I just had a crazy idea, put it out there for discussion, certainly > not > >> > expecting any immediate action, even if people like it we'll want to > stew on > >> > it for a while.
> >> > One of the most time consuming and annoying parts of editing the > journal > >> > is getting things into HTML and editing the HTML without WordPress > messing > >> > it up, etc.
> >> > * What if we required authors to submit in markdown (basically > plaintext > >> > with some pretty easy to remember conventions for indicating headers, > lists, > >> > links, embedded images, etc) > >> > * Then we just entered the markdown in WordPress > >> > * Profit!
> >> > ## Disadvantages
> >> > * We wouldn't be able to use fancy custom HTML anymore. This has some > >> > pro's in enforcing consistency, but also some obvious cons. > >> > * We'd probably have to give up on the COinS, which I think would > >> > actually be fine. Some years on, COinS has not really caught on, I'm > not > >> > sure it provides a benefit commensurate to the effort it takes us, and > we > >> > usually don't manage to do it right anyway. Few of our articles > include > >> > links to non-open-access literature anyway. > >> > * On the other hand, we can't give up code syntax highlighting. Not > sure > >> > if WP markdown plugins would play nice with the syntax highlighter > plugin, > >> > but they might. > >> > * We'd have to figure out how to conveniently do notes/references too, > >> > especially for articles that want the (Smith 2000) style to be most > >> > readable. > >> > * Not sure how we'd get things like our formatted captions on figures > to > >> > work right, or center-aligned figures, etc.
> >> > So there'd be some challenges. But I suspect they could be overcome. > And > >> > I think it would make our jobs so much easier, take out the most > annoying > >> > and least rewarding thing editors spend time on. And, hey, forcing the > >> > limitation to the subset of HTML that markdown can represent would > make an > >> > article-to-PDF converter a lot easier too.
> >> > ## Note
> >> > This email is, as you may have guessed, in markdown.
> >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "Code4Lib Journal-discuss" group. > >> > To post to this group, send email to > >> > c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com > ><mailto:c4lj-discuss@googlegroups.com<mailto: > c4lj-discuss@googlegroups.com>>. > >> > To unsubscribe from this group, send email to > >> > c4lj-discuss+unsubscribe@googlegroups.com<mailto: > c4lj-discuss%2Bunsubscribe@googlegroups.com><mailto: > c4lj-discuss%2Bunsubscribe@googlegroups.com<mailto: > c4lj-discuss%252Bunsubscribe@googlegroups.com>>. > >> > For more options, visit this group at > >> > http://groups.google.com/group/c4lj-discuss?hl=en.
This is a very interesting thread. I think I've now edited articles in 4 different ways:
* traditional MS-Word w/ Track Changes * Open Office Word w/ highlighted changes and comments * Google Docs with editing privileges shared by the author * Rich Text File, which I copied into MS-Word, edited via Track Changes, and then saved to PDF to send back to author
I. myself, don't feel inconvenienced by another of those paths, and I've only had minor problems copy/pasting into the Visual tab of WordPress.
I have the hardest time getting images and code snipped in and formatted properly to fit.
Otherwise, I'm inclined to say the process isn't broken, so why fix it. But I won't stand opposed to more efficiencies.
> That's an interesting approach and one I could see working with our > current workflow. It does mean manually updating Wordpress when edits > are accepted, but that's not really a big problem. I like the idea of > being able to share it with the authors.
> Can you clarify: you would recommend Github over Bitbucket for this > purpose because it handles commenting better?
> Also, I noticed that all the text was hard-wrapped to 80 characters. Is > line wrapping required or just your preference? When I have edited my > articles in a text editor, I only put hard returns at the end of > paragraphs.
> Tom
> On Sun, Jul 24, 2011 at 1:06 PM, Gabriel Farrell <gsf...@gmail.com > <mailto:gsf...@gmail.com>> wrote:
> On Sun, Jul 24, 2011 at 11:06 AM, Jodi Schneider > <jschnei...@pobox.com <mailto:jschnei...@pobox.com>> wrote: > > That's really interesting, Gabe. How did you handle comments and > > suggestions?
> I think we just handled larger editorial suggestions via email, though > I could see using issues or commit comments for that purpose. That's > assuming the use of Github -- we could use another ticketing/issue > system as well.
> > It would be useful to see this repository if it's public, to get > ideas.
> > On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell > <gsf...@gmail.com <mailto:gsf...@gmail.com>> wrote:
> >> On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind > <rochk...@jhu.edu <mailto:rochk...@jhu.edu>> > >> wrote: > >> > Yeah, track changes, I dunno. I don't like our current > 'solution' for > >> > track changes, passing around Word documents, but don't know > of a better > >> > solution, markdown or not. (And we don't require authors to > submit in Word > >> > or be able to open a Word file now, in fact).
> >> > I wonder if there's a WordPress plugin that puts your posts in > a code > >> > versioning system of some kind and lets you look at > histories/diffs? Maybe > >> > that'd be the solution there -- which WOULD work better with > markdown. With > >> > HTML, you're likely to get a lot of diffs that are just fixes > to HTML syntax > >> > and structure and formatting rather than actual content.
> >> The article I edited for issue 13 (From ISIS to CouchDB) was handled > >> in a DVCS (Mercurial, hosted at bitbucket.org > <http://bitbucket.org>, because that's where > >> Luciano had it set up). I must say, it made for a great workflow > that > >> I would love to repeat. Not all authors would be comfortable working > >> in version control, and I appreciate our flexibility in handling > >> whatever the author brings to us, but my ideal would be Markdown > >> articles in a Git repo. Could we at least encourage that somehow?
> >> > Markdown (or textile) are SO easy to use, that I personally > don't see a > >> > problem with requiring authors to use it. We are a technical > journal after > >> > all. (It looks like there may be some textile WP plugins too, > so it could be > >> > textile instead of markdown. Depends on if ANY of these > plugins, textile or > >> > markdown, are stable, mature, and flexible/powerful enough for > our use, > >> > which I'm not sure).
> >> > But I'm not looking for any immediate action on this, it's > really just > >> > food for thought. I'd like to come up with SOME better way of > handling our > >> > workflow. (While still being focused on HTML as our primary > delivery, not > >> > PDF. When I think 'troubles with workflow', I think , gee, > let's see what > >> > OJS does -- but they seem to punt on HTML entry/editing > workflow problems, > >> > instead focusing on PDFs as the primary delivery. Which is > not where any of > >> > us want to go.)
> >> > ________________________________ > >> > From: c4lj-discuss@googlegroups.com > <mailto:c4lj-discuss@googlegroups.com> > [c4lj-discuss@googlegroups.com > <mailto:c4lj-discuss@googlegroups.com>] on > >> > behalf of Tom Keays [tomke...@gmail.com > <mailto:tomke...@gmail.com>] > >> > Sent: Thursday, July 21, 2011 9:52 PM > >> > To: c4lj-discuss@googlegroups.com > <mailto:c4lj-discuss@googlegroups.com> > >> > Subject: Re: [c4lj] markdown?
> >> > Markdown was one of the first text syntaxes I used (in a > Moveable Type > >> > blog I had 8 or so years ago) and it is still a fine markup > language. I > >> > think it _can_ coexist with raw HTML (at least my Moveable > Type blog could, > >> > through a post-specific setting), but probably not with the > WYSIWYG editor. > >> > Something to keep in mind.
> >> > Barring technical complications, however, one concern might be > people's > >> > comfort level using the markup syntax approach. That seems to > be the crux of > >> > people's resistance to using wikis. How much of a problem will > editors find > >> > it to convert a formatted word processing document to Markdown?
> >> > Another concern is the ability to track changes. One of the > articles I > >> > edited this year was originally submitted in a text markup > syntax (Textile, > >> > I think). I eventually converted it to Word and coordinated > further edits > >> > with the authors that way. If we had a way to track changes > and share them > >> > with the authors using Wordpress, that would have addressed > that problem > >> > very nicely. This is true regardless of whether we decide to > go with > >> > Markdown or not. Our current editing paradigm is not to enter > the article > >> > into Wordpress until most of the changes have been made, which > mitigates the > >> > problem somewhat.
> >> > These are devil's advocate objections though. If others like > the idea, > >> > we should definitely explore it.
> >> > Tom
> >> > On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind > >> > <rochk...@jhu.edu > <mailto:rochk...@jhu.edu><mailto:rochk...@jhu.edu > <mailto:rochk...@jhu.edu>>> wrote: > >> > I just had a crazy idea, put it out there for discussion, > certainly not > >> > expecting any immediate action, even if people like it we'll > want to stew on > >> > it for a while.
> >> > One of the most time consuming and annoying parts of editing > the journal > >> > is getting things into HTML and editing the HTML without > WordPress messing > >> > it up, etc.
> >> > * What if we required authors to submit in markdown (basically > plaintext > >> > with some pretty easy to remember conventions for indicating > headers, lists, > >> > links, embedded images, etc) > >> > * Then we just entered the markdown in WordPress > >> > * Profit!
> >> > ## Disadvantages
> >> > * We wouldn't be able to use fancy custom HTML anymore. This > has some > >> > pro's in enforcing consistency, but also some obvious cons. > >> > * We'd probably have to give up on the COinS, which I think would > >> > actually be fine. Some years on, COinS has not really caught > on, I'm not > >> > sure it provides a benefit commensurate to the effort it takes > us, and we > >> > usually don't manage to do it right anyway. Few of our > articles include > >> > links to non-open-access literature anyway. > >> > * On the other hand, we can't give up code syntax > highlighting. Not sure > >> > if WP markdown plugins would play nice with the syntax > highlighter plugin, > >> > but they might. > >> > * We'd have to figure out how to conveniently do > notes/references too, > >> > especially for articles that want the (Smith 2000) style to be > most > >> > readable. > >> > * Not sure how we'd get things like our formatted captions on > figures to > >> > work right, or center-aligned figures, etc.
> >> > So there'd be some challenges. But I suspect they could be > overcome. And > >> > I think it would make our jobs so much easier, take out the > most annoying > >> > and least rewarding thing editors spend time on. And, hey, > forcing the > >> > limitation
We're obviously not going to be able to require that all authors/editors have OSX.
But what I was thinking was that if we used github (which I'm still not entirely sold on), some people could get by with just the github _web_ interface, which is available to everyone. github (a particular git host, with their own web interface) lets you edit text through the web, look at diffs and commit histories, and it renders markdown and textile too. If we were going to use github for workflow, I think we'd have to come up with a workflow so that the functions avaialble through the web interface are sufficient for the authors end of workflow, and ideally for the editors as well. (I don't know if you can merge/pull through the web interface).
> On Mon, Jul 25, 2011 at 9:31 AM, Jonathan Rochkind <rochk...@jhu.edu > <mailto:rochk...@jhu.edu>> wrote:
> Hmm, one road block is that I think most authors wouldn't want > their initial drafts -- and especially comments/revisions back and > forth between editors and author -- to be public.
> I'm not sure if there's a free/cheap revision control system that > also has a good web interface including editing text in a browser. > Otherwise it's an interesting idea. I haven't looked at > Mecurial/bitbucket, but Github gives you an in browser 'edit' > button (just an HTML text box, no graphical wysiwyg or anything), > and also renders markdown (or textile, or a couple others) after > you save, in the browser. You wouldn't even have to know you were > using a revision control system. But it'd be public.
> ________________________________ > From: c4lj-discuss@googlegroups.com > <mailto:c4lj-discuss@googlegroups.com> > [c4lj-discuss@googlegroups.com > <mailto:c4lj-discuss@googlegroups.com>] on behalf of Jodi > Schneider [jschnei...@pobox.com <mailto:jschnei...@pobox.com>] > Sent: Sunday, July 24, 2011 2:33 PM > To: c4lj-discuss@googlegroups.com > <mailto:c4lj-discuss@googlegroups.com> > Subject: Re: [c4lj] markdown?
> On Sun, Jul 24, 2011 at 6:06 PM, Gabriel Farrell <gsf...@gmail.com > <mailto:gsf...@gmail.com><mailto:gsf...@gmail.com > <mailto:gsf...@gmail.com>>> wrote: > On Sun, Jul 24, 2011 at 11:06 AM, Jodi Schneider > <jschnei...@pobox.com > <mailto:jschnei...@pobox.com><mailto:jschnei...@pobox.com > <mailto:jschnei...@pobox.com>>> wrote: > > That's really interesting, Gabe. How did you handle comments and > > suggestions?
> I think we just handled larger editorial suggestions via email, though > I could see using issues or commit comments for that purpose. That's > assuming the use of Github -- we could use another ticketing/issue > system as well.
> > It would be useful to see this repository if it's public, to get > ideas.
> > On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell > <gsf...@gmail.com > <mailto:gsf...@gmail.com><mailto:gsf...@gmail.com > <mailto:gsf...@gmail.com>>> wrote:
> >> On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind > <rochk...@jhu.edu > <mailto:rochk...@jhu.edu><mailto:rochk...@jhu.edu > <mailto:rochk...@jhu.edu>>> > >> wrote: > >> > Yeah, track changes, I dunno. I don't like our current > 'solution' for > >> > track changes, passing around Word documents, but don't know > of a better > >> > solution, markdown or not. (And we don't require authors to > submit in Word > >> > or be able to open a Word file now, in fact).
> >> > I wonder if there's a WordPress plugin that puts your posts > in a code > >> > versioning system of some kind and lets you look at > histories/diffs? Maybe > >> > that'd be the solution there -- which WOULD work better with > markdown. With > >> > HTML, you're likely to get a lot of diffs that are just fixes > to HTML syntax > >> > and structure and formatting rather than actual content.
> >> The article I edited for issue 13 (From ISIS to CouchDB) was > handled > >> in a DVCS (Mercurial, hosted at bitbucket.org > <http://bitbucket.org><http://bitbucket.org>, because that's where > >> Luciano had it set up). I must say, it made for a great > workflow that > >> I would love to repeat. Not all authors would be comfortable > working > >> in version control, and I appreciate our flexibility in handling > >> whatever the author brings to us, but my ideal would be Markdown > >> articles in a Git repo. Could we at least encourage that somehow?
> >> > Markdown (or textile) are SO easy to use, that I personally > don't see a > >> > problem with requiring authors to use it. We are a technical > journal after > >> > all. (It looks like there may be some textile WP plugins too, > so it could be > >> > textile instead of markdown. Depends on if ANY of these > plugins, textile or > >> > markdown, are stable, mature, and flexible/powerful enough > for our use, > >> > which I'm not sure).
> >> > But I'm not looking for any immediate action on this, it's > really just > >> > food for thought. I'd like to come up with SOME better way of > handling our > >> > workflow. (While still being focused on HTML as our primary > delivery, not > >> > PDF. When I think 'troubles with workflow', I think , gee, > let's see what > >> > OJS does -- but they seem to punt on HTML entry/editing > workflow problems, > >> > instead focusing on PDFs as the primary delivery. Which is > not where any of > >> > us want to go.)
> >> > Markdown was one of the first text syntaxes I used (in a > Moveable Type > >> > blog I had 8 or so years ago) and it is still a fine markup > language. I > >> > think it _can_ coexist with raw HTML (at least my Moveable > Type blog could, > >> > through a post-specific setting), but probably not with the > WYSIWYG editor. > >> > Something to keep in mind.
> >> > Barring technical complications, however, one concern might > be people's > >> > comfort level using the markup syntax approach. That seems to > be the crux of > >> > people's resistance to using wikis. How much of a problem > will editors find > >> > it to convert a formatted word processing document to Markdown?
> >> > Another concern is the ability to track changes. One of the > articles I > >> > edited this year was originally submitted in a text markup > syntax (Textile, > >> > I think). I eventually converted it to Word and coordinated > further edits > >> > with the authors that way. If we had a way to track changes > and share them > >> > with the authors using Wordpress, that would have addressed > that problem > >> > very nicely. This is true regardless of whether we decide to > go with > >> > Markdown or not. Our current editing paradigm is not to enter > the article > >> > into Wordpress until most of the changes have been made, > which mitigates the > >> > problem somewhat.
> >> > These are devil's advocate objections though. If others like > the idea, > >> > we should definitely explore it.
> >> > Tom
> >> > On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind > >> > <rochk...@jhu.edu > <mailto:rochk...@jhu.edu><mailto:rochk...@jhu.edu > <mailto:rochk...@jhu.edu>><mailto:rochk...@jhu.edu > <mailto:rochk...@jhu.edu><mailto:rochk...@jhu.edu > <mailto:rochk...@jhu.edu>>>> wrote: > >> > I just had a crazy idea, put it out there for discussion, > certainly not > >> > expecting any immediate action, even if people like it we'll > want to stew on > >> > it for a while.
> >> > One of the most time consuming and annoying parts of editing > the journal > >> > is getting things into HTML and editing the HTML without > WordPress messing > >> > it up, etc.
> >> > Lately I've been using various "mostly plaintext but with > conventions > >> > that can be formatted into html" formats, such as > >> > [markdown](http://daringfireball.net/projects/markdown/syntax),
I wonder what the HTML source looks like for everyone that thinks they have had no problems copying/pasting from WordPress to Word. I'm thinking there's a good chance it's pretty awful, with extra divs and spans all over the place, "font" tags, possibly "font" tags instead of headers, etc.
It might be painful for me because I try to avoid this and have good HTML.
Does this matter, ugly HTML? I am not sure; terrible HTML will certainly make an attempt at converting to PDF much harder; my intutions as a programmer is that it will make other unexpected things we want to do later harder too, but maybe caring about good HTML is just a programmer being anal and not really neccesary.
> This is a very interesting thread. I think I've now edited articles > in 4 different ways:
> * traditional MS-Word w/ Track Changes > * Open Office Word w/ highlighted changes and comments > * Google Docs with editing privileges shared by the author > * Rich Text File, which I copied into MS-Word, edited via Track > Changes, and then saved to PDF to send back to author
> I. myself, don't feel inconvenienced by another of those paths, and > I've only had minor problems copy/pasting into the Visual tab of > WordPress.
> I have the hardest time getting images and code snipped in and > formatted properly to fit.
> Otherwise, I'm inclined to say the process isn't broken, so why fix > it. But I won't stand opposed to more efficiencies.
> Tim M
> On 7/25/11 9:32 AM, Tom Keays wrote: >> That's an interesting approach and one I could see working with our >> current workflow. It does mean manually updating Wordpress when edits >> are accepted, but that's not really a big problem. I like the idea of >> being able to share it with the authors.
>> Can you clarify: you would recommend Github over Bitbucket for this >> purpose because it handles commenting better?
>> Also, I noticed that all the text was hard-wrapped to 80 characters. Is >> line wrapping required or just your preference? When I have edited my >> articles in a text editor, I only put hard returns at the end of >> paragraphs.
>> Tom
>> On Sun, Jul 24, 2011 at 1:06 PM, Gabriel Farrell <gsf...@gmail.com >> <mailto:gsf...@gmail.com>> wrote:
>> On Sun, Jul 24, 2011 at 11:06 AM, Jodi Schneider >> <jschnei...@pobox.com <mailto:jschnei...@pobox.com>> wrote: >> > That's really interesting, Gabe. How did you handle comments and >> > suggestions?
>> I think we just handled larger editorial suggestions via email, >> though >> I could see using issues or commit comments for that purpose. That's >> assuming the use of Github -- we could use another ticketing/issue >> system as well.
>> > It would be useful to see this repository if it's public, to get >> ideas.
>> > On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell >> <gsf...@gmail.com <mailto:gsf...@gmail.com>> wrote:
>> >> On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind >> <rochk...@jhu.edu <mailto:rochk...@jhu.edu>> >> >> wrote: >> >> > Yeah, track changes, I dunno. I don't like our current >> 'solution' for >> >> > track changes, passing around Word documents, but don't know >> of a better >> >> > solution, markdown or not. (And we don't require authors to >> submit in Word >> >> > or be able to open a Word file now, in fact).
>> >> > I wonder if there's a WordPress plugin that puts your posts in >> a code >> >> > versioning system of some kind and lets you look at >> histories/diffs? Maybe >> >> > that'd be the solution there -- which WOULD work better with >> markdown. With >> >> > HTML, you're likely to get a lot of diffs that are just fixes >> to HTML syntax >> >> > and structure and formatting rather than actual content.
>> >> The article I edited for issue 13 (From ISIS to CouchDB) was handled >> >> in a DVCS (Mercurial, hosted at bitbucket.org >> <http://bitbucket.org>, because that's where >> >> Luciano had it set up). I must say, it made for a great workflow >> that >> >> I would love to repeat. Not all authors would be comfortable working >> >> in version control, and I appreciate our flexibility in handling >> >> whatever the author brings to us, but my ideal would be Markdown >> >> articles in a Git repo. Could we at least encourage that somehow?
>> >> > Markdown (or textile) are SO easy to use, that I personally >> don't see a >> >> > problem with requiring authors to use it. We are a technical >> journal after >> >> > all. (It looks like there may be some textile WP plugins too, >> so it could be >> >> > textile instead of markdown. Depends on if ANY of these >> plugins, textile or >> >> > markdown, are stable, mature, and flexible/powerful enough for >> our use, >> >> > which I'm not sure).
>> >> > But I'm not looking for any immediate action on this, it's >> really just >> >> > food for thought. I'd like to come up with SOME better way of >> handling our >> >> > workflow. (While still being focused on HTML as our primary >> delivery, not >> >> > PDF. When I think 'troubles with workflow', I think , gee, >> let's see what >> >> > OJS does -- but they seem to punt on HTML entry/editing >> workflow problems, >> >> > instead focusing on PDFs as the primary delivery. Which is >> not where any of >> >> > us want to go.)
>> >> > ________________________________ >> >> > From: c4lj-discuss@googlegroups.com >> <mailto:c4lj-discuss@googlegroups.com> >> [c4lj-discuss@googlegroups.com >> <mailto:c4lj-discuss@googlegroups.com>] on >> >> > behalf of Tom Keays [tomke...@gmail.com >> <mailto:tomke...@gmail.com>] >> >> > Sent: Thursday, July 21, 2011 9:52 PM >> >> > To: c4lj-discuss@googlegroups.com >> <mailto:c4lj-discuss@googlegroups.com> >> >> > Subject: Re: [c4lj] markdown?
>> >> > Markdown was one of the first text syntaxes I used (in a >> Moveable Type >> >> > blog I had 8 or so years ago) and it is still a fine markup >> language. I >> >> > think it _can_ coexist with raw HTML (at least my Moveable >> Type blog could, >> >> > through a post-specific setting), but probably not with the >> WYSIWYG editor. >> >> > Something to keep in mind.
>> >> > Barring technical complications, however, one concern might be >> people's >> >> > comfort level using the markup syntax approach. That seems to >> be the crux of >> >> > people's resistance to using wikis. How much of a problem will >> editors find >> >> > it to convert a formatted word processing document to Markdown?
>> >> > Another concern is the ability to track changes. One of the >> articles I >> >> > edited this year was originally submitted in a text markup >> syntax (Textile, >> >> > I think). I eventually converted it to Word and coordinated >> further edits >> >> > with the authors that way. If we had a way to track changes >> and share them >> >> > with the authors using Wordpress, that would have addressed >> that problem >> >> > very nicely. This is true regardless of whether we decide to >> go with >> >> > Markdown or not. Our current editing paradigm is not to enter >> the article >> >> > into Wordpress until most of the changes have been made, which >> mitigates the >> >> > problem somewhat.
>> >> > These are devil's advocate objections though. If others like >> the idea, >> >> > we should definitely explore it.
>> >> > Tom
>> >> > On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind >> >> > <rochk...@jhu.edu >> <mailto:rochk...@jhu.edu><mailto:rochk...@jhu.edu >> <mailto:rochk...@jhu.edu>>> wrote: >> >> > I just had a crazy idea, put it out there for discussion, >> certainly not >> >> > expecting any immediate action, even if people like it we'll >> want to stew on >> >> > it for a while.
>> >> > One of the most time consuming and annoying parts of editing >> the journal >> >> > is getting things into HTML and editing the HTML without >> WordPress messing >> >> > it up, etc.
>> >> > * What if we required authors to submit in markdown (basically >> plaintext >> >> > with some pretty easy to remember conventions for indicating >> headers, lists, >> >> > links, embedded images, etc) >> >> > * Then we just entered the markdown in WordPress >> >> > * Profit!
>> >> > ## Disadvantages
>> >> > * We wouldn't be able to use fancy custom HTML anymore. This >> has some >> >> > pro's in enforcing consistency, but also some obvious cons. >> >> > * We'd probably have to give up on the COinS, which I think would >> >> > actually be fine. Some years on, COinS has not really caught >> on, I'm not >> >> > sure it provides a benefit commensurate to the effort it takes >> us, and we >> >> > usually don't manage to do it right anyway. Few of our >> articles include >> >> > links to non-open-access literature anyway. >> >> > * On the other hand, we can't give up code syntax >> highlighting. Not sure >> >> > if WP markdown plugins would play nice with the syntax >> highlighter plugin, >> >> > but they might. >> >> > * We'd have to figure out how to conveniently do >> notes/references too, >> >> > especially for articles that want the (Smith 2000) style to be >> most >> >> > readable. >> >> > * Not sure how we'd get things like our formatted captions
On Mon, Jul 25, 2011 at 7:11 AM, Jonathan Rochkind <rochk...@jhu.edu> wrote: > I wonder what the HTML source looks like for everyone that thinks they have > had no problems copying/pasting from WordPress to Word. I'm thinking > there's a good chance it's pretty awful, with extra divs and spans all over > the place, "font" tags, possibly "font" tags instead of headers, etc.
> It might be painful for me because I try to avoid this and have good HTML.
> Does this matter, ugly HTML? I am not sure; terrible HTML will certainly > make an attempt at converting to PDF much harder; my intutions as a > programmer is that it will make other unexpected things we want to do later > harder too, but maybe caring about good HTML is just a programmer being anal > and not really neccesary.
> Jonathan
> On 7/25/2011 10:07 AM, Tim McGeary wrote:
>> This is a very interesting thread. I think I've now edited articles in 4 >> different ways:
>> * traditional MS-Word w/ Track Changes >> * Open Office Word w/ highlighted changes and comments >> * Google Docs with editing privileges shared by the author >> * Rich Text File, which I copied into MS-Word, edited via Track Changes, >> and then saved to PDF to send back to author
>> I. myself, don't feel inconvenienced by another of those paths, and I've >> only had minor problems copy/pasting into the Visual tab of WordPress.
>> I have the hardest time getting images and code snipped in and formatted >> properly to fit.
>> Otherwise, I'm inclined to say the process isn't broken, so why fix it. >> But I won't stand opposed to more efficiencies.
>> Tim M
>> On 7/25/11 9:32 AM, Tom Keays wrote:
>>> That's an interesting approach and one I could see working with our >>> current workflow. It does mean manually updating Wordpress when edits >>> are accepted, but that's not really a big problem. I like the idea of >>> being able to share it with the authors.
>>> Can you clarify: you would recommend Github over Bitbucket for this >>> purpose because it handles commenting better?
>>> Also, I noticed that all the text was hard-wrapped to 80 characters. Is >>> line wrapping required or just your preference? When I have edited my >>> articles in a text editor, I only put hard returns at the end of >>> paragraphs.
>>> Tom
>>> On Sun, Jul 24, 2011 at 1:06 PM, Gabriel Farrell <gsf...@gmail.com >>> <mailto:gsf...@gmail.com>> wrote:
>>> On Sun, Jul 24, 2011 at 11:06 AM, Jodi Schneider >>> <jschnei...@pobox.com <mailto:jschnei...@pobox.com>> wrote: >>> > That's really interesting, Gabe. How did you handle comments and >>> > suggestions?
>>> I think we just handled larger editorial suggestions via email, though >>> I could see using issues or commit comments for that purpose. That's >>> assuming the use of Github -- we could use another ticketing/issue >>> system as well.
>>> > It would be useful to see this repository if it's public, to get >>> ideas.
>>> > On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell >>> <gsf...@gmail.com <mailto:gsf...@gmail.com>> wrote:
>>> >> On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind >>> <rochk...@jhu.edu <mailto:rochk...@jhu.edu>> >>> >> wrote: >>> >> > Yeah, track changes, I dunno. I don't like our current >>> 'solution' for >>> >> > track changes, passing around Word documents, but don't know >>> of a better >>> >> > solution, markdown or not. (And we don't require authors to >>> submit in Word >>> >> > or be able to open a Word file now, in fact).
>>> >> > I wonder if there's a WordPress plugin that puts your posts in >>> a code >>> >> > versioning system of some kind and lets you look at >>> histories/diffs? Maybe >>> >> > that'd be the solution there -- which WOULD work better with >>> markdown. With >>> >> > HTML, you're likely to get a lot of diffs that are just fixes >>> to HTML syntax >>> >> > and structure and formatting rather than actual content.
>>> >> The article I edited for issue 13 (From ISIS to CouchDB) was handled >>> >> in a DVCS (Mercurial, hosted at bitbucket.org >>> <http://bitbucket.org>, because that's where >>> >> Luciano had it set up). I must say, it made for a great workflow >>> that >>> >> I would love to repeat. Not all authors would be comfortable working >>> >> in version control, and I appreciate our flexibility in handling >>> >> whatever the author brings to us, but my ideal would be Markdown >>> >> articles in a Git repo. Could we at least encourage that somehow?
>>> >> > Markdown (or textile) are SO easy to use, that I personally >>> don't see a >>> >> > problem with requiring authors to use it. We are a technical >>> journal after >>> >> > all. (It looks like there may be some textile WP plugins too, >>> so it could be >>> >> > textile instead of markdown. Depends on if ANY of these >>> plugins, textile or >>> >> > markdown, are stable, mature, and flexible/powerful enough for >>> our use, >>> >> > which I'm not sure).
>>> >> > But I'm not looking for any immediate action on this, it's >>> really just >>> >> > food for thought. I'd like to come up with SOME better way of >>> handling our >>> >> > workflow. (While still being focused on HTML as our primary >>> delivery, not >>> >> > PDF. When I think 'troubles with workflow', I think , gee, >>> let's see what >>> >> > OJS does -- but they seem to punt on HTML entry/editing >>> workflow problems, >>> >> > instead focusing on PDFs as the primary delivery. Which is >>> not where any of >>> >> > us want to go.)
>>> >> > ________________________________ >>> >> > From: c4lj-discuss@googlegroups.com >>> <mailto:c4lj-discuss@googlegroups.com> >>> [c4lj-discuss@googlegroups.com >>> <mailto:c4lj-discuss@googlegroups.com>] on >>> >> > behalf of Tom Keays [tomke...@gmail.com >>> <mailto:tomke...@gmail.com>] >>> >> > Sent: Thursday, July 21, 2011 9:52 PM >>> >> > To: c4lj-discuss@googlegroups.com >>> <mailto:c4lj-discuss@googlegroups.com> >>> >> > Subject: Re: [c4lj] markdown?
>>> >> > Markdown was one of the first text syntaxes I used (in a >>> Moveable Type >>> >> > blog I had 8 or so years ago) and it is still a fine markup >>> language. I >>> >> > think it _can_ coexist with raw HTML (at least my Moveable >>> Type blog could, >>> >> > through a post-specific setting), but probably not with the >>> WYSIWYG editor. >>> >> > Something to keep in mind.
>>> >> > Barring technical complications, however, one concern might be >>> people's >>> >> > comfort level using the markup syntax approach. That seems to >>> be the crux of >>> >> > people's resistance to using wikis. How much of a problem will >>> editors find >>> >> > it to convert a formatted word processing document to Markdown?
>>> >> > Another concern is the ability to track changes. One of the >>> articles I >>> >> > edited this year was originally submitted in a text markup >>> syntax (Textile, >>> >> > I think). I eventually converted it to Word and coordinated >>> further edits >>> >> > with the authors that way. If we had a way to track changes >>> and share them >>> >> > with the authors using Wordpress, that would have addressed >>> that problem >>> >> > very nicely. This is true regardless of whether we decide to >>> go with >>> >> > Markdown or not. Our current editing paradigm is not to enter >>> the article >>> >> > into Wordpress until most of the changes have been made, which >>> mitigates the >>> >> > problem somewhat.
>>> >> > These are devil's advocate objections though. If others like >>> the idea, >>> >> > we should definitely explore it.
>>> >> > Tom
>>> >> > On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind >>> >> > <rochk...@jhu.edu >>> <mailto:rochk...@jhu.edu><mailto:rochk...@jhu.edu >>> <mailto:rochk...@jhu.edu>>> wrote: >>> >> > I just had a crazy idea, put it out there for discussion, >>> certainly not >>> >> > expecting any immediate action, even if people like it we'll >>> want to stew on >>> >> > it for a while.
>>> >> > One of the most time consuming and annoying parts of editing >>> the journal >>> >> > is getting things into HTML and editing the HTML without >>> WordPress messing >>> >> > it up, etc.
>>> >> > * What if we required authors to submit in markdown (basically >>> plaintext >>> >> > with some pretty easy to remember conventions for indicating >>> headers, lists, >>> >> > links, embedded images, etc) >>> >> > * Then we just entered the markdown in WordPress >>> >> > * Profit!
>>> >> > ## Disadvantages
>>> >> > * We wouldn't be able to use fancy custom HTML anymore. This >>> has some >>> >> > pro's in enforcing consistency, but also some obvious cons. >>> >> > * We'd probably have to give up on the COinS, which I think would >>> >> > actually be fine. Some years on, COinS has not really caught >>> on, I'm not >>> >> > sure it provides a benefit commensurate to the effort it takes >>> us, and we >>> >> > usually don't manage to do it right anyway. Few of our >>> articles include
On Mon, Jul 25, 2011 at 9:32 AM, Tom Keays <tomke...@gmail.com> wrote: > That's an interesting approach and one I could see working with our current > workflow. It does mean manually updating Wordpress when edits are accepted, > but that's not really a big problem. I like the idea of being able to share > it with the authors.
> Can you clarify: you would recommend Github over Bitbucket for this purpose > because it handles commenting better?
Github is generally better than Bitbucket -- cleaner interface, more features, bigger community, more ongoing development, etc.
> Also, I noticed that all the text was hard-wrapped to 80 characters. Is line > wrapping required or just your preference? When I have edited my articles in > a text editor, I only put hard returns at the end of paragraphs.
Both Luciano and I were used to hard-wrapped text. It's easier to edit in Vim, and line-by-line changes are easier to track in a diff. You can see in the repo that he even wrote a small script to unwrap the text for WordPress, since it likes to insert a <br> whenever it's given the opportunity (a minor annoyance).
> On Sun, Jul 24, 2011 at 1:06 PM, Gabriel Farrell <gsf...@gmail.com> wrote:
>> On Sun, Jul 24, 2011 at 11:06 AM, Jodi Schneider <jschnei...@pobox.com> >> wrote: >> > That's really interesting, Gabe. How did you handle comments and >> > suggestions?
>> I think we just handled larger editorial suggestions via email, though >> I could see using issues or commit comments for that purpose. That's >> assuming the use of Github -- we could use another ticketing/issue >> system as well.
>> > It would be useful to see this repository if it's public, to get ideas.
>> > On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell <gsf...@gmail.com> >> > wrote:
>> >> On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind <rochk...@jhu.edu> >> >> wrote: >> >> > Yeah, track changes, I dunno. I don't like our current 'solution' for >> >> > track changes, passing around Word documents, but don't know of a >> >> > better >> >> > solution, markdown or not. (And we don't require authors to submit in >> >> > Word >> >> > or be able to open a Word file now, in fact).
>> >> > I wonder if there's a WordPress plugin that puts your posts in a code >> >> > versioning system of some kind and lets you look at histories/diffs? >> >> > Maybe >> >> > that'd be the solution there -- which WOULD work better with >> >> > markdown. With >> >> > HTML, you're likely to get a lot of diffs that are just fixes to HTML >> >> > syntax >> >> > and structure and formatting rather than actual content.
>> >> The article I edited for issue 13 (From ISIS to CouchDB) was handled >> >> in a DVCS (Mercurial, hosted at bitbucket.org, because that's where >> >> Luciano had it set up). I must say, it made for a great workflow that >> >> I would love to repeat. Not all authors would be comfortable working >> >> in version control, and I appreciate our flexibility in handling >> >> whatever the author brings to us, but my ideal would be Markdown >> >> articles in a Git repo. Could we at least encourage that somehow?
>> >> > Markdown (or textile) are SO easy to use, that I personally don't see >> >> > a >> >> > problem with requiring authors to use it. We are a technical journal >> >> > after >> >> > all. (It looks like there may be some textile WP plugins too, so it >> >> > could be >> >> > textile instead of markdown. Depends on if ANY of these plugins, >> >> > textile or >> >> > markdown, are stable, mature, and flexible/powerful enough for our >> >> > use, >> >> > which I'm not sure).
>> >> > But I'm not looking for any immediate action on this, it's really >> >> > just >> >> > food for thought. I'd like to come up with SOME better way of >> >> > handling our >> >> > workflow. (While still being focused on HTML as our primary delivery, >> >> > not >> >> > PDF. When I think 'troubles with workflow', I think , gee, let's see >> >> > what >> >> > OJS does -- but they seem to punt on HTML entry/editing workflow >> >> > problems, >> >> > instead focusing on PDFs as the primary delivery. Which is not where >> >> > any of >> >> > us want to go.)
>> >> > ________________________________ >> >> > From: c4lj-discuss@googlegroups.com [c4lj-discuss@googlegroups.com] >> >> > on >> >> > behalf of Tom Keays [tomke...@gmail.com] >> >> > Sent: Thursday, July 21, 2011 9:52 PM >> >> > To: c4lj-discuss@googlegroups.com >> >> > Subject: Re: [c4lj] markdown?
>> >> > Markdown was one of the first text syntaxes I used (in a Moveable >> >> > Type >> >> > blog I had 8 or so years ago) and it is still a fine markup language. >> >> > I >> >> > think it _can_ coexist with raw HTML (at least my Moveable Type blog >> >> > could, >> >> > through a post-specific setting), but probably not with the WYSIWYG >> >> > editor. >> >> > Something to keep in mind.
>> >> > Barring technical complications, however, one concern might be >> >> > people's >> >> > comfort level using the markup syntax approach. That seems to be the >> >> > crux of >> >> > people's resistance to using wikis. How much of a problem will >> >> > editors find >> >> > it to convert a formatted word processing document to Markdown?
>> >> > Another concern is the ability to track changes. One of the articles >> >> > I >> >> > edited this year was originally submitted in a text markup syntax >> >> > (Textile, >> >> > I think). I eventually converted it to Word and coordinated further >> >> > edits >> >> > with the authors that way. If we had a way to track changes and share >> >> > them >> >> > with the authors using Wordpress, that would have addressed that >> >> > problem >> >> > very nicely. This is true regardless of whether we decide to go with >> >> > Markdown or not. Our current editing paradigm is not to enter the >> >> > article >> >> > into Wordpress until most of the changes have been made, which >> >> > mitigates the >> >> > problem somewhat.
>> >> > These are devil's advocate objections though. If others like the >> >> > idea, >> >> > we should definitely explore it.
>> >> > Tom
>> >> > On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind >> >> > <rochk...@jhu.edu<mailto:rochk...@jhu.edu>> wrote: >> >> > I just had a crazy idea, put it out there for discussion, certainly >> >> > not >> >> > expecting any immediate action, even if people like it we'll want to >> >> > stew on >> >> > it for a while.
>> >> > One of the most time consuming and annoying parts of editing the >> >> > journal >> >> > is getting things into HTML and editing the HTML without WordPress >> >> > messing >> >> > it up, etc.
>> >> > * What if we required authors to submit in markdown (basically >> >> > plaintext >> >> > with some pretty easy to remember conventions for indicating headers, >> >> > lists, >> >> > links, embedded images, etc) >> >> > * Then we just entered the markdown in WordPress >> >> > * Profit!
>> >> > ## Disadvantages
>> >> > * We wouldn't be able to use fancy custom HTML anymore. This has >> >> > some >> >> > pro's in enforcing consistency, but also some obvious cons. >> >> > * We'd probably have to give up on the COinS, which I think would >> >> > actually be fine. Some years on, COinS has not really caught on, I'm >> >> > not >> >> > sure it provides a benefit commensurate to the effort it takes us, >> >> > and we >> >> > usually don't manage to do it right anyway. Few of our articles >> >> > include >> >> > links to non-open-access literature anyway. >> >> > * On the other hand, we can't give up code syntax highlighting. Not >> >> > sure >> >> > if WP markdown plugins would play nice with the syntax highlighter >> >> > plugin, >> >> > but they might. >> >> > * We'd have to figure out how to conveniently do notes/references >> >> > too, >> >> > especially for articles that want the (Smith 2000) style to be most >> >> > readable. >> >> > * Not sure how we'd get things like our formatted captions on figures >> >> > to >> >> > work right, or center-aligned figures, etc.
>> >> > So there'd be some challenges. But I suspect they could be overcome. >> >> > And >> >> > I think it would make our jobs so much easier, take out the most >> >> > annoying >> >> > and least rewarding thing editors spend time on. And, hey, forcing >> >> > the >> >> > limitation to the subset of HTML that markdown can represent would >> >> > make an >> >> > article-to-PDF converter a lot easier too.
>> >> > ## Note
>> >> > This email is, as you may have guessed, in markdown.
>> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups "Code4Lib Journal-discuss" group. >> >> > To post to this group, send email to >> >> > c4lj-discuss@googlegroups.com<mailto:c4lj-discuss@googlegroups.com>. >> >> > To unsubscribe from this group, send email to
>> >> > c4lj-discuss+unsubscribe@googlegroups.com<mailto:c4lj-discuss%2Bunsubscribe @googlegroups.com>. >> >> > For more options, visit this group at >> >> > http://groups.google.com/group/c4lj-discuss?hl=en.
>> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups "Code4Lib Journal-discuss" group. >> >> > To post to this group, send email to c4lj-discuss@googlegroups.com. >> >> > To unsubscribe from this group, send email to
On Mon, Jul 25, 2011 at 12:10 PM, Gabriel Farrell <gsf...@gmail.com> wrote: > Both Luciano and I were used to hard-wrapped text. It's easier to edit > in Vim, and line-by-line changes are easier to track in a diff. You > can see in the repo that he even wrote a small script to unwrap the > text for WordPress, since it likes to insert a <br> whenever it's > given the opportunity (a minor annoyance).
> This is a very interesting thread. I think I've now edited articles in > 4 different ways:
> * traditional MS-Word w/ Track Changes > * Open Office Word w/ highlighted changes and comments > * Google Docs with editing privileges shared by the author > * Rich Text File, which I copied into MS-Word, edited via Track Changes, > and then saved to PDF to send back to author
> I. myself, don't feel inconvenienced by another of those paths, and I've > only had minor problems copy/pasting into the Visual tab of WordPress.
> I have the hardest time getting images and code snipped in and formatted > properly to fit.
> Otherwise, I'm inclined to say the process isn't broken, so why fix it. > But I won't stand opposed to more efficiencies.
> Tim M
> On 7/25/11 9:32 AM, Tom Keays wrote: >> That's an interesting approach and one I could see working with our >> current workflow. It does mean manually updating Wordpress when edits >> are accepted, but that's not really a big problem. I like the idea of >> being able to share it with the authors.
>> Can you clarify: you would recommend Github over Bitbucket for this >> purpose because it handles commenting better?
>> Also, I noticed that all the text was hard-wrapped to 80 characters. Is >> line wrapping required or just your preference? When I have edited my >> articles in a text editor, I only put hard returns at the end of >> paragraphs.
>> Tom
>> On Sun, Jul 24, 2011 at 1:06 PM, Gabriel Farrell <gsf...@gmail.com >> <mailto:gsf...@gmail.com>> wrote:
>> On Sun, Jul 24, 2011 at 11:06 AM, Jodi Schneider >> <jschnei...@pobox.com <mailto:jschnei...@pobox.com>> wrote: >>> That's really interesting, Gabe. How did you handle comments and >>> suggestions?
>> I think we just handled larger editorial suggestions via email, though >> I could see using issues or commit comments for that purpose. That's >> assuming the use of Github -- we could use another ticketing/issue >> system as well.
>>> It would be useful to see this repository if it's public, to get >> ideas.
>>> On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell >> <gsf...@gmail.com <mailto:gsf...@gmail.com>> wrote:
>>>> On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind >> <rochk...@jhu.edu <mailto:rochk...@jhu.edu>> >>>> wrote: >>>>> Yeah, track changes, I dunno. I don't like our current >> 'solution' for >>>>> track changes, passing around Word documents, but don't know >> of a better >>>>> solution, markdown or not. (And we don't require authors to >> submit in Word >>>>> or be able to open a Word file now, in fact).
>>>>> I wonder if there's a WordPress plugin that puts your posts in >> a code >>>>> versioning system of some kind and lets you look at >> histories/diffs? Maybe >>>>> that'd be the solution there -- which WOULD work better with >> markdown. With >>>>> HTML, you're likely to get a lot of diffs that are just fixes >> to HTML syntax >>>>> and structure and formatting rather than actual content.
>>>> The article I edited for issue 13 (From ISIS to CouchDB) was handled >>>> in a DVCS (Mercurial, hosted at bitbucket.org >> <http://bitbucket.org>, because that's where >>>> Luciano had it set up). I must say, it made for a great workflow >> that >>>> I would love to repeat. Not all authors would be comfortable working >>>> in version control, and I appreciate our flexibility in handling >>>> whatever the author brings to us, but my ideal would be Markdown >>>> articles in a Git repo. Could we at least encourage that somehow?
>>>>> Markdown (or textile) are SO easy to use, that I personally >> don't see a >>>>> problem with requiring authors to use it. We are a technical >> journal after >>>>> all. (It looks like there may be some textile WP plugins too, >> so it could be >>>>> textile instead of markdown. Depends on if ANY of these >> plugins, textile or >>>>> markdown, are stable, mature, and flexible/powerful enough for >> our use, >>>>> which I'm not sure).
>>>>> But I'm not looking for any immediate action on this, it's >> really just >>>>> food for thought. I'd like to come up with SOME better way of >> handling our >>>>> workflow. (While still being focused on HTML as our primary >> delivery, not >>>>> PDF. When I think 'troubles with workflow', I think , gee, >> let's see what >>>>> OJS does -- but they seem to punt on HTML entry/editing >> workflow problems, >>>>> instead focusing on PDFs as the primary delivery. Which is >> not where any of >>>>> us want to go.)
>>>>> ________________________________ >>>>> From: c4lj-discuss@googlegroups.com >> <mailto:c4lj-discuss@googlegroups.com> >> [c4lj-discuss@googlegroups.com >> <mailto:c4lj-discuss@googlegroups.com>] on >>>>> behalf of Tom Keays [tomke...@gmail.com >> <mailto:tomke...@gmail.com>] >>>>> Sent: Thursday, July 21, 2011 9:52 PM >>>>> To: c4lj-discuss@googlegroups.com >> <mailto:c4lj-discuss@googlegroups.com> >>>>> Subject: Re: [c4lj] markdown?
>>>>> Markdown was one of the first text syntaxes I used (in a >> Moveable Type >>>>> blog I had 8 or so years ago) and it is still a fine markup >> language. I >>>>> think it _can_ coexist with raw HTML (at least my Moveable >> Type blog could, >>>>> through a post-specific setting), but probably not with the >> WYSIWYG editor. >>>>> Something to keep in mind.
>>>>> Barring technical complications, however, one concern might be >> people's >>>>> comfort level using the markup syntax approach. That seems to >> be the crux of >>>>> people's resistance to using wikis. How much of a problem will >> editors find >>>>> it to convert a formatted word processing document to Markdown?
>>>>> Another concern is the ability to track changes. One of the >> articles I >>>>> edited this year was originally submitted in a text markup >> syntax (Textile, >>>>> I think). I eventually converted it to Word and coordinated >> further edits >>>>> with the authors that way. If we had a way to track changes >> and share them >>>>> with the authors using Wordpress, that would have addressed >> that problem >>>>> very nicely. This is true regardless of whether we decide to >> go with >>>>> Markdown or not. Our current editing paradigm is not to enter >> the article >>>>> into Wordpress until most of the changes have been made, which >> mitigates the >>>>> problem somewhat.
>>>>> These are devil's advocate objections though. If others like >> the idea, >>>>> we should definitely explore it.
>>>>> Tom
>>>>> On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind >>>>> <rochk...@jhu.edu >> <mailto:rochk...@jhu.edu><mailto:rochk...@jhu.edu >> <mailto:rochk...@jhu.edu>>> wrote: >>>>> I just had a crazy idea, put it out there for discussion, >> certainly not >>>>> expecting any immediate action, even if people like it we'll >> want to stew on >>>>> it for a while.
>>>>> One of the most time consuming and annoying parts of editing >> the journal >>>>> is getting things into HTML and editing the HTML without >> WordPress messing >>>>> it up, etc.
>>>>> * What if we required authors to submit in markdown (basically >> plaintext >>>>> with some pretty easy to remember conventions for indicating >> headers, lists, >>>>> links, embedded images, etc) >>>>> * Then we just entered the markdown in WordPress >>>>> * Profit!
>>>>> ## Disadvantages
>>>>> * We wouldn't be able to use fancy custom HTML anymore. This >> has some >>>>> pro's in enforcing consistency, but also some obvious cons. >>>>> * We'd probably have to give up on the COinS, which I think would >>>>> actually be fine. Some years on, COinS has not really caught >> on, I'm not >>>>> sure it provides a benefit commensurate to the effort it takes >> us, and we >>>>> usually don't manage to do it right anyway. Few of our >> articles include >>>>> links to non-open-access literature anyway. >>>>> * On the other hand, we can't give up code syntax >> highlighting. Not sure >>>>> if WP markdown plugins would play nice with the syntax >> highlighter plugin, >>>>> but they might. >>>>> * We'd have to figure out how to conveniently do >> notes/references too, >>>>> especially for articles that want the (Smith 2000) style to be >> most >>>>> readable. >>>>> * Not sure how we'd get things like our formatted captions on >> figures to >>>>> work right, or center-aligned figures, etc.
>>>>> So there'd be some challenges. But I suspect they could be >> overcome. And >>>>> I think it would make our jobs so much easier, take out the >> most annoying >>>>> and least rewarding thing editors spend time on. And, hey, >> forcing the >>>>> limitation to the subset of HTML that markdown can represent >> would make an >>>>> article-to-PDF converter a lot easier too.
>>>>> ## Note
>>>>> This email is, as you may have guessed, in markdown.
>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Code4Lib Journal-discuss" group. >>>>> To post to this group, send email to >>>>> c4lj-discuss@googlegroups.com >> <mailto:c4lj-discuss@googlegroups.com><mailto:c4lj-discuss@googlegroups.com
I agree with Tim as well. While I tend to encourage authors away from Word, since I usually work on computers without Word installed, I'm happy to accommodate various formats and workflows. Keeps things interesting.
Going forward, I'll probably suggest Github, and if the author is comfortable with version control, plain text, and public drafts, then great. If not, no biggie.
If we could allow for Markdown input in addition to our current methods, I'd be in favor of that.
On Mon, Jul 25, 2011 at 12:24 PM, Tod Olson <t...@uchicago.edu> wrote: > Tim pretty much sums up my feelings on the topic.
> -Tod
> On Jul 25, 2011, at 9:07 AM, Tim McGeary wrote:
>> This is a very interesting thread. I think I've now edited articles in >> 4 different ways:
>> * traditional MS-Word w/ Track Changes >> * Open Office Word w/ highlighted changes and comments >> * Google Docs with editing privileges shared by the author >> * Rich Text File, which I copied into MS-Word, edited via Track Changes, >> and then saved to PDF to send back to author
>> I. myself, don't feel inconvenienced by another of those paths, and I've >> only had minor problems copy/pasting into the Visual tab of WordPress.
>> I have the hardest time getting images and code snipped in and formatted >> properly to fit.
>> Otherwise, I'm inclined to say the process isn't broken, so why fix it. >> But I won't stand opposed to more efficiencies.
>> Tim M
>> On 7/25/11 9:32 AM, Tom Keays wrote: >>> That's an interesting approach and one I could see working with our >>> current workflow. It does mean manually updating Wordpress when edits >>> are accepted, but that's not really a big problem. I like the idea of >>> being able to share it with the authors.
>>> Can you clarify: you would recommend Github over Bitbucket for this >>> purpose because it handles commenting better?
>>> Also, I noticed that all the text was hard-wrapped to 80 characters. Is >>> line wrapping required or just your preference? When I have edited my >>> articles in a text editor, I only put hard returns at the end of >>> paragraphs.
>>> Tom
>>> On Sun, Jul 24, 2011 at 1:06 PM, Gabriel Farrell <gsf...@gmail.com >>> <mailto:gsf...@gmail.com>> wrote:
>>> On Sun, Jul 24, 2011 at 11:06 AM, Jodi Schneider >>> <jschnei...@pobox.com <mailto:jschnei...@pobox.com>> wrote: >>>> That's really interesting, Gabe. How did you handle comments and >>>> suggestions?
>>> I think we just handled larger editorial suggestions via email, though >>> I could see using issues or commit comments for that purpose. That's >>> assuming the use of Github -- we could use another ticketing/issue >>> system as well.
>>>> It would be useful to see this repository if it's public, to get >>> ideas.
>>>> On Sun, Jul 24, 2011 at 3:37 PM, Gabriel Farrell >>> <gsf...@gmail.com <mailto:gsf...@gmail.com>> wrote:
>>>>> On Fri, Jul 22, 2011 at 11:34 AM, Jonathan Rochkind >>> <rochk...@jhu.edu <mailto:rochk...@jhu.edu>> >>>>> wrote: >>>>>> Yeah, track changes, I dunno. I don't like our current >>> 'solution' for >>>>>> track changes, passing around Word documents, but don't know >>> of a better >>>>>> solution, markdown or not. (And we don't require authors to >>> submit in Word >>>>>> or be able to open a Word file now, in fact).
>>>>>> I wonder if there's a WordPress plugin that puts your posts in >>> a code >>>>>> versioning system of some kind and lets you look at >>> histories/diffs? Maybe >>>>>> that'd be the solution there -- which WOULD work better with >>> markdown. With >>>>>> HTML, you're likely to get a lot of diffs that are just fixes >>> to HTML syntax >>>>>> and structure and formatting rather than actual content.
>>>>> The article I edited for issue 13 (From ISIS to CouchDB) was handled >>>>> in a DVCS (Mercurial, hosted at bitbucket.org >>> <http://bitbucket.org>, because that's where >>>>> Luciano had it set up). I must say, it made for a great workflow >>> that >>>>> I would love to repeat. Not all authors would be comfortable working >>>>> in version control, and I appreciate our flexibility in handling >>>>> whatever the author brings to us, but my ideal would be Markdown >>>>> articles in a Git repo. Could we at least encourage that somehow?
>>>>>> Markdown (or textile) are SO easy to use, that I personally >>> don't see a >>>>>> problem with requiring authors to use it. We are a technical >>> journal after >>>>>> all. (It looks like there may be some textile WP plugins too, >>> so it could be >>>>>> textile instead of markdown. Depends on if ANY of these >>> plugins, textile or >>>>>> markdown, are stable, mature, and flexible/powerful enough for >>> our use, >>>>>> which I'm not sure).
>>>>>> But I'm not looking for any immediate action on this, it's >>> really just >>>>>> food for thought. I'd like to come up with SOME better way of >>> handling our >>>>>> workflow. (While still being focused on HTML as our primary >>> delivery, not >>>>>> PDF. When I think 'troubles with workflow', I think , gee, >>> let's see what >>>>>> OJS does -- but they seem to punt on HTML entry/editing >>> workflow problems, >>>>>> instead focusing on PDFs as the primary delivery. Which is >>> not where any of >>>>>> us want to go.)
>>>>>> ________________________________ >>>>>> From: c4lj-discuss@googlegroups.com >>> <mailto:c4lj-discuss@googlegroups.com> >>> [c4lj-discuss@googlegroups.com >>> <mailto:c4lj-discuss@googlegroups.com>] on >>>>>> behalf of Tom Keays [tomke...@gmail.com >>> <mailto:tomke...@gmail.com>] >>>>>> Sent: Thursday, July 21, 2011 9:52 PM >>>>>> To: c4lj-discuss@googlegroups.com >>> <mailto:c4lj-discuss@googlegroups.com> >>>>>> Subject: Re: [c4lj] markdown?
>>>>>> Markdown was one of the first text syntaxes I used (in a >>> Moveable Type >>>>>> blog I had 8 or so years ago) and it is still a fine markup >>> language. I >>>>>> think it _can_ coexist with raw HTML (at least my Moveable >>> Type blog could, >>>>>> through a post-specific setting), but probably not with the >>> WYSIWYG editor. >>>>>> Something to keep in mind.
>>>>>> Barring technical complications, however, one concern might be >>> people's >>>>>> comfort level using the markup syntax approach. That seems to >>> be the crux of >>>>>> people's resistance to using wikis. How much of a problem will >>> editors find >>>>>> it to convert a formatted word processing document to Markdown?
>>>>>> Another concern is the ability to track changes. One of the >>> articles I >>>>>> edited this year was originally submitted in a text markup >>> syntax (Textile, >>>>>> I think). I eventually converted it to Word and coordinated >>> further edits >>>>>> with the authors that way. If we had a way to track changes >>> and share them >>>>>> with the authors using Wordpress, that would have addressed >>> that problem >>>>>> very nicely. This is true regardless of whether we decide to >>> go with >>>>>> Markdown or not. Our current editing paradigm is not to enter >>> the article >>>>>> into Wordpress until most of the changes have been made, which >>> mitigates the >>>>>> problem somewhat.
>>>>>> These are devil's advocate objections though. If others like >>> the idea, >>>>>> we should definitely explore it.
>>>>>> Tom
>>>>>> On Thu, Jul 21, 2011 at 8:19 PM, Jonathan Rochkind >>>>>> <rochk...@jhu.edu >>> <mailto:rochk...@jhu.edu><mailto:rochk...@jhu.edu >>> <mailto:rochk...@jhu.edu>>> wrote: >>>>>> I just had a crazy idea, put it out there for discussion, >>> certainly not >>>>>> expecting any immediate action, even if people like it we'll >>> want to stew on >>>>>> it for a while.
>>>>>> One of the most time consuming and annoying parts of editing >>> the journal >>>>>> is getting things into HTML and editing the HTML without >>> WordPress messing >>>>>> it up, etc.
>>>>>> * What if we required authors to submit in markdown (basically >>> plaintext >>>>>> with some pretty easy to remember conventions for indicating >>> headers, lists, >>>>>> links, embedded images, etc) >>>>>> * Then we just entered the markdown in WordPress >>>>>> * Profit!
>>>>>> ## Disadvantages
>>>>>> * We wouldn't be able to use fancy custom HTML anymore. This >>> has some >>>>>> pro's in enforcing consistency, but also some obvious cons. >>>>>> * We'd probably have to give up on the COinS, which I think would >>>>>> actually be fine. Some years on, COinS has not really caught >>> on, I'm not >>>>>> sure it provides a benefit commensurate to the effort it takes >>> us, and we >>>>>> usually don't manage to do it right anyway. Few of our >>> articles include >>>>>> links to non-open-access literature anyway. >>>>>> * On the other hand, we can't give up code syntax >>> highlighting. Not sure >>>>>> if WP markdown plugins would play nice with the syntax >>> highlighter plugin, >>>>>> but they might. >>>>>> * We'd have to figure out how to conveniently do >>> notes/references too, >>>>>> especially for articles that want the (Smith 2000) style to be >>> most >>>>>> readable. >>>>>> * Not sure how we'd get things
