Submittable Status Changes (a primer)

There are a few different statuses offered by Submittable to the reader as they go through the review process.

The mostly obvious ones are “withdrawn”, “accepted” and “declined”. These three are pretty clear. “Accepted” appears in green, and “declined” in red to further the point, but with each the word is sufficient.

The trouble comes with the first ones you see: “received” and “in progress”. Specifically that “in progress” one causes much confusion.

“Received” for the most part is self explanatory. The confusion comes with the how, when and why it changes to “in progress”. For the most part, this change in the status offers little to no real information to the writer, and I would prefer it to be removed all together.

Here are the things that cause that change:

  1. Voting on the submission
  2. Leaving a note
  3. Changing the editor assignment (does not require opening the submission)
  4. Opening for editing (does not require opening the submission)
  5. Adding a tag (does not require opening the submission)

Things that do NOT change the status change:

  1. Opening the submission
  2. Reading the story
  3. Forming an opinion on the story

In other words, the editors and readers can interact with your submission and the status won’t change at all. Or, in the case of changing editorial assignments, cause it to change to “in progress” without even opening it.

That means your status can go from “received” to “accepted” without ever seeing “in progress”. It also means it can go to “in progress” without anyone ever looking at it. Either way, the status is offering not much to the writer other than confusion.

The more you know…. star swoosh

WordPress Twenty Sixteen Child Theme

A quick nerdy post that may help someone in the future. I wanted to modify the WordPress Twenty Sixteen Theme for this site to change the fonts and then add some classes to handle some new features.

(like this nifty Amazon preview on the Extrospections page)

The layout of the css file isn’t the easiest to change, so I had to pull out all the classes that had the font-family properties and arrange them together.

Below is a skeleton for your child theme’s css. The first set is to change the two predominate fonts, the serif and san-serif choices. The next are the @media calls, if you’d like to add to (as I did) or alter the behavior as the site transitions from desktop to mobile.

/*
 Theme Name:  
 Theme URI: 
 Description:  Twenty Sixteen Child Theme
 Author:   
 Author URI:   
 Template:     twentysixteen
 Version:      1.0.0
 License:      GNU General Public License v2 or later
 License URI:  http://www.gnu.org/licenses/gpl-2.0.html
 Tags:         
 Text Domain:  twenty-sixteen-child
*/

/*Typography*/

/*Serif  */
body,
button,
input,
select,
textarea {

/* change font family here */

}

/*Sans-Serif*/
.tagcloud a,
.site-title,
.entry-title,
.entry-footer,
.sticky-post,
.page-title,
.page-links,
.comments-title,
.comment-reply-title,
.comment-metadata,
.pingback .edit-link,
.comment-reply-link,
.comment-form label,
.no-comments,
.widecolumn label,
.widecolumn .mu_register label  {

/* change font family here */

}

/* Media levels in Twenty Sixteen */

/**
 * 14.1 - >= 710px
 */

@media screen and (min-width: 44.375em) {

} /* media 710px */

/**
 * 14.2 - >= 783px
 */

@media screen and (min-width: 48.9375em) {

} /* media 738px */

/**
 * 14.3 - >= 910px
 */

@media screen and (min-width: 56.875em) {

} /* media 910px */

/**
 * 14.4 - >= 985px
 */

@media screen and (min-width: 61.5625em) {

} /* media 985px */

Plain Text Story Formatting, Part Two

This is the nerdy one. I talked previously about how I use plain text to write these days, but left the final formatting out of that discussion.

The fact is you can do formatting in this manner as well, you don’t need to copy paste into Word. There are a few things you will need, however: Some basic HTML / CSS knowledge; a program called Pandoc and comfort with the command line; and an app called Marked.

To start, this is Macintosh centric, as that is what I have. Pandoc will work on Windows and Linux too, which is good, as it is very useful. Marked, however, is just for the Mac. While I suspect there are Windows and Linux equivalents, I can’t speak to how they work.

First lets look at Marked and take about what it does. When I write, I used a syntax called markdown. It uses things asterisks to designate italics and bold, pound signs (hashtags…) for headings, etc. It is very simple, and since for the most part the only real thing we use in fiction is italics and possibly headers, there are very few things to remember.

Now, in principle what Marked does is similar to what your browser does when you look at a web site. Websites are just text files as well, but when the browser gets it, it renders it into a webpage. Marked does the same thing with your markdown syntax.

So instead of *this* it looks like this, which is what you wanted.

Now Marked also has a large collection of style sheets. This lets you change how your file will look, and hey, one of them is even standard manuscript format. That’s nice.

With a simple click your story is all formatted, ready to go. Need it changed? Marked comes with 9 pre-set style sheets, and since they are just CSS, making your own (or tweaking what is there) is quite easy.

It isn’t an editor. You will need to still open up your text file in whatever application you were writing in (I may have suggested Byword once or twice…) to change things.

But, for those following along at home, you may have question. When I talked about my story format, I had all of these other sections, like Notes and Characters in my file. What happens to those sections?

The nice part about markdown is that it is open to HTML as well. We will take the “comment” tag from HTML and fix this right up. As you recall, the layout I use looks like this:

Title: (title here)
Author: (my name)

To-Do

Summary

Characters

Locations

Notes

Story

Archive

Now, we will add comment tags, which look like this:

<!--
comments go here
and you can’t see them
-->

Which, when rendered in HTML, looks like this:

(That was a programming joke.)

So, what do we do? We enclose the parts that we don’t want to show in the final version in those comment tags, like this:

<!--
Title: (title here)
Author: (my name)

# To-Do

# Summary

# Characters

# Locations

# Notes

# Story
-->
# Title
## By Me

Once upon a *time*...

~fin~
<!--
# Archive
-->

And, since we don’t show comments, Marked passes over all of that. All we will get is:

Title

By Me

Once upon a time

~fin~

Thus, allowing me to keep all that information where I want it: in the file with the story itself, AND also have a well formatted document. (that other stuff is still there, if you looked at the source code of this post you would see it)

Marked lets you change the CSS if you want, so you can adjust fonts, spacings, indents, etc. Simply export from Marked to quite a few formats, like DOCX, PDF, and RTF

Pandoc

Pandoc provides a more versatile set of tools for those comfortable with the command line. For me, the feature I use the most is converting files into ebooks. Pandoc will convert my mess above into a full epub with a table of contents.

It makes it quite easy to add things as well. So if your file was mystory.txt and you had a bio.txt file of your well crafted biography, you can make an ebook like this:

pandoc -o mystory.epub mystory.txt bio.txt 

Simple, no? The -o tag is for output file name, which is in this case mystory.epub. Pandoc can tell what the file is by the extension, but you can also designate, like this:

pandoc -o mystory.epub  mystory.txt bio.txt -t markdown -s

Now, if you want to be more hands on, you can be. Pandoc lets you change the stylesheets, set a cover, add in the metadata.

You can do something similar with DOCX files. If you make a Word file that is formatted the way you want yours to be, Pandoc will use the same styles for your file. like this:

pandoc -o mystory.docx mystory.txt bio.txt --reference-docx=myotherstory.docx

And now your new mystory.docx file will have the same styles as myotherstory.docx has.

And this is just a drop of what Pandoc can do. If you need a quick powerful tool to convert files, this one is worth looking at.

Why?

Why? why do this? Why not just have piles of Word documents? All of this was spawned from the need to have so many different file formats for one story. The story starts off any way you want, but once complete, you will need an ebook, a PDF, a print version, Kindle one, etc.

And then you find one mistake, and now have to make sure you fix it in all of those.

I’m in the process of incorporating this structure into the creation of LampLight as well, allowing me to format once, and produce four files at the push of a button. (well, a few because I have to type, but still).

It also allows for greater control over the epub output, and mades it easier to spin updates if needed.

But the important part–important to me, that is–is the file format. As plain text, I know those story files can always be opened up. The work done to format, to clean up the files, to make these things will not be lost simply because a new version of some other software comes out.

And that, the future proofing of these files, is worth the extra effort.