Contribution guidelines to ease Flayrah's editing bottleneck
Stories go through several editing steps before publication on Flayrah. Image thumbnailing, layout, copyediting, linking, fact-checking, tagging – these take over half an hour for all but the most trivial stories, and that's assuming no substantive editing is required.
Flayrah's editors have limited time, and few are both qualified and willing to become one. Stories have often languished in the queue because we don't want to risk work which may not yet meet our standards. But not publishing work in a timely fashion is a problem, too.
As such, we're releasing contribution guidelines for Flayrah, in an attempt to decrease the work required by editors prior to publication.
These guidelines provide largely technical advice, specific to our house style. There are many guides on writing great news, features or reviews; on using data, and on style in general. Contributors are encouraged to seek them out, and to consult examples of good journalism elsewhere.
Our guide is also a work in progress, subject to changes and clarifications, so check the link to it on the submission page occasionally. For contributors, following the guidelines is optional; but doing so will facilitate the timely publication of your work, and that of others.
About the author
GreenReaper (Laurence Parry) — read stories — contact (login required)a developer, editor and Kai Norn from London, United Kingdom, interested in wikis and computers
Small fuzzy creature who likes cheese & carrots. Founder of WikiFur, lead admin of Inkbunny, and Editor-in-Chief of Flayrah.
Comments
I've been trying to help more the last couple of weeks by publishing a few of the stories on the backlog. Unfortunately my ability to assist in this manner is hampered on a couple of fronts. First, my employer blocks two of the sites most frequently linked by Flayrah, which severely hampers my ability to validate links or provide new ones, which is a part of the process of editing and vetting stories for publication. Second, if a story has images that should be hosted locally, I won't touch it. I tried to edit/publish one of those a while back, and was so boggled and confused by the manner of copying images to a local file that I've been afraid to do anything with them ever since. Fred Patten's submissions nearly always include such images, and more than half of the stories currently on the backlog were submitted by him.
I'm not sure what can be done about the link issue - I presume you're trying to use a work laptop at home? I'd suggest only using a personal device for fan work; you never know what you'll run into . . .
The image uploader is a little clunky, but the process should be relatively brief:
One thing that can catch you out is clicking the upload button before a large directory has loaded, in which case it'll end up wherever you were before - most likely, the directory above. You can delete it, of course. Also, beware uploading an image, deleting it, and uploading a different one with the same name, as you'll probably end up seeing a cached version.
For various reasons, all images displayed in stories should be uploaded to Flayrah (links may go elsewhere if necessary for copyright purposes, though most images will be uploaded). Part of the task of editing is validating this, and creating thumbnails where required.
Of course, actually getting a file can be a serious hassle. Sometimes it's as simple as right-click/save image as..., but for Amazon I tend to open up a Kindle/regular "look inside" and use the browser's inspection tools to see what URL it's using for the cover image, then open that in a new tab and download it. An image downloader browser extension/add-on may be a more appropriate method for most users.
You can create thumbnails from uploaded images via the resize button. It's not ideal as you don't have control over the output quality. However, it may be easier than downloading the image, opening it in image software, resizing it, saving it, and re-uploading it.
Layout usually takes me the most time. I'm very picky: I go back and forth between the resize dialog in my image editor and the story, trying out different thumbnail sizes by adjusting the tag's width/height to see which will fit the text best.
These guidelines are just the first step into making Flayrah into a proper multi-editor site. I need to set up a system so that we don't end up with two people editing the same story; and to get the forums working again, so editors and contributors can discuss issues.
Okay, I pulled up one of Fred's oldest reviews from the backlog (it's been waiting there since 5/30/13), cleaned it up, and posted it. I think it ended up taking me more than an hour, and I even skipped a couple of steps I've routinely done with other articles. Let me know if I did anything wrong with the image handling.
And yes, in my earlier post I was referring to looking at Flayrah during my lull moments at work. When I'm at home I have more other things to distract me from working on Flayrah articles.
Thanks for taking the time! Here's the revisions I made (original, revised), and explanations in rough order of importance:
Images should be offset from the text with margins
We don't use much white space at Flayrah, but a little is a good thing. For right-aligned images, style=margin-left:5px is good. For left-align, I've been moving towards margin-right:8px. Preview and see how it looks. If there's an awkward word hanging at the end of a line, replace the space after it with (non-breaking space) to move it to the next.
You need to set Input format to Full HTML for margins (or any styling) to work. It's not there by default for security purposes.
This is also the point to select a cutoff for the lede ("Split summary at cursor"), and to adjust the size of images, while preserving good flow. Consider shifting them up a line, and/or using top/bottom margins to adjust for awkward gaps.
Images should be thumbnailed, not just resized
With images, we have a few conflicting issues:
Resizing an image by setting the width and/or height only solves the first of these. Instead, we create a thumbnail of the image at a lower resolution - solving 1 and 2 - and link that to the full-size image to meet 3 and 4. You can still use an image tag with width to figure out what size to use, but be sure you don't forget to replace the src after creating the thumbnail.
You can create thumbnails with the resize button in the upload dialog - leave "create a new image" checked, enter the width you decided, leave height blank, and tab to height to have it auto-fill. Or, resize the original on your computer and upload it as well. The latter becomes necessary if you also want to crop the image to remove cruft or highlight a particular section.
Both width and height should be set explicitly on images
Not setting both attributes mean browsers have to load the image and then reflow the page afterwards. It also makes it hard for bots (and Flayrah itself) to figure out what images to use in a summary.
If you're using thumbnails as above, this shouldn't be a problem; the image dialog shows both. If you have to use the original (say, it's a small change and the source is highly compressed), you can still use the dialog, just don't create the thumbnail.
There should ideally be at least one image with a display size greater than 280x150
The largest image image will be used on Twitter as part of a large image card. Otherwise, you get a small square image next to the title, which usually doesn't look as good. The algorithm picks the largest image based on width X height as set in the image tag. If the image is linked, it'll use the linked image (but doesn't know its size; a big picture with a small thumb won't be picked).
The largest image is not always the first image in the story - it can be hard to fit a large image into the lede. In dronon's recent review, it picked the last image. In this case, I felt the abstract cover was a central image and beneficial to display at a high resolution due to its detail, so I chose to increase its size and so caused the algorithm to pick it.
If no images are this big, but there are YouTube or Vimeo links/embeds, it'll use the first of those.
Images should have descriptive alt attribute text (and title attribute if necessary)
The alt tag provides information about an image for those who cannot see it or who have chosen not to load it. This includes bot like Google Image Search. We want people looking for images to find them on Flayrah because they may be interested in the story.
If there's no need for a visible caption, but you have a comment for the curious to explain the image, you can use the title attribute. This'll popup on mouseover in most browsers. In this case they are all self-explanatory, so no titles.
(Having a visible caption means using a div with float:left/right and width attributes, rather than aligning the image. You can then add a newline inside the div and add italicised caption text. I've added an example to the guidelines.)
Amazon.com links should have ?tag=flayrah-20 at the end; all products should be linked
This means we get money! It's less than $10 a month, but it helps with the server bills. You can shorten it to something like http://www.amazon.com/dp/0441240860?tag=flayrah-20 (just check that it loads).
An author may not provide links for all works. Here I added one for Treaty Planet. (I also linked the cover references.)
Works should be announced on Twitter when published
Tweets don't just happen for regular stories like they do for newsbytes - you have to tick the Tweet box when publishing.
Page numbers on quotes (including the parentheses around them) should be enclosed in <small>
This is just a stylistic thing. You may also need to use in place of a regular space in-between "p./pgs." and the page number if it's near the end of a line, otherwise you can end up with the number on a new line by itself.
If this doesn't show up, you probably didn't select "Full HTML" input type yet.
There should be a single space after image tags (or their links) when followed by text
This is because the alt text might be turned into actual text (especially by bots), in which case it could run up against the following text. For example, you might get "Crisis at DoonaThis book is..." in a Google News description.
Images references and links to Flayrah should not use scheme ("http:" or "https:"), but start with //
Flayrah can be accessed via https: as well as http:. https: is slightly slower, but use of http: means people monitoring a network (say, at work) can see both the addresses of the pages and images you are accessing, the content itself, and your login credentials.
If a secure connection is maintained, they can only see the server IP address, which may be shared by other sites, like WikiFur. (Although, the page will also be in your browser history; it's best to assume work computers are fully monitored.)
If you have a http: image on a https: page, either the browser won't load the image, or it leaks the file accessed to watchers. Either way, it'll complain. Take out the scheme, and it'll use whatever the user accessed the page with. Same for links.
This also applies to links (and embeds) from WikiFur, Wikipedia, YouTube, Vimeo, and other sites accessible both ways.
HTML character entities such as ‘/” and – should be replaced with the actual characters
This doesn't affect the visible output, but it's slightly faster for readers to load and makes it easier to find things that need editing. Personally, I preview the page and then copy the story text to notepad, using successive find-and-replaces to convert each entity (I'm already doing this to convert http://www.flayrah.com to //www.flayrah.com), but a tool might be faster.
Now - is it reasonable to expect one person to do all this? Perhaps not. Sometimes I only get partway. You can always do what you have time for, and leave the rest to another editor. Whether you publish the article in the interim depends on its urgency. While the issues above are mostly stylistic, a story should not be published without copyediting or fact-checking - and features often require substantive editing as well.
Question about the Newsbytes archives, noting this line:
"In interviews or lists of newsbytes, use the format Name: to attribute paragraphs. Leave it out for consecutive paragraphs by the same person."
Uh, that's not how I've been doing it, which looks something like this:
GreenReaper: To correct the "bad research" comment: JM was talking about articles published since the one in question.
crossaffliction: Apparently, Princess Luna went and got herself banished to the International Space Station this time.
crossaffliction: Guardians of the Galaxy #1 was the fourth best-selling comic book issue of 2013. [Review here.]
crossaffliction: What happens to a Toad reintroduced into movie franchise prequel? He’s recast, apparently.
However, that implies you'd like me to write it this way next time:
GreenReaper: To correct the "bad research" comment: JM was talking about articles published since the one in question.
crossaffliction: Apparently, Princess Luna went and got herself banished to the International Space Station this time.
Guardians of the Galaxy #1 was the fourth best-selling comic book issue of 2013. [Review here.]
What happens to a Toad reintroduced into movie franchise prequel? He’s recast, apparently.
Which is really actually less work for me, as I currently manually write in the bold tags each time, so just deleting them is easier. The only objection would be continuity wise, really.
(Also, I plan on keeping the guide open when submitting in the future.)
Hmmm. I must admit, I was thinking only of interviews when adding that last bit.
For newsbytes, I think it's clearer to have them separately attributed, unless . . .
What we could do is to turn it into a table. That might be more compact and also look better. It would be a bit more work.
Guardians of the Galaxy #1 was the fourth best-selling comic book issue of 2013. [Review here.]
What happens to a Toad reintroduced into movie franchise prequel? He’s recast, apparently.
Generation of such a table cries out for automation. For now it might be better to go with the original format.
I'm surprised you don't just select a bunch of newsbytes in the sidebar and use View source to get the HTML, though.
Then you wouldn't have to make many modifications at all, other than removing duplicate links on usernames and checking schemes.
Post new comment