Tips for PPers Trying for DU

From DPWiki
Jump to navigation Jump to search

This Wiki page has been created to serve as a summary of tips from PPVers to PPers striving for Direct Upload access. It was inspired by this forum thread, which basically asked the question:

As a PPVer, how would you finish this sentence? “I wish that PPers who are trying to reach DU status would….”

Several useful replies have been posted, and they have been collected and reorganised for this Wiki page.

Do Things Thoroughly

Run all required checks

Run all required checks, maybe even twice, right before submitting your project for PPV. After making the last amendments, after adding the TN, and certainly after making any last-minute changes in the HTML to make it look better. Check each individual gutcheck warning, each spell-check flag, and make sure the HTML validates for markup, CSS, and links.

Be thorough, consistent and systematic

Don't try to finalise everything in the text in one pass. You won't succeed, no matter how good you think you are at multitasking. Rather, split up the process into distinct steps and go through them one after the other. Don't let other tasks distract you, or if they do, restart the task you were just working on after dealing with the other things.

Keep written notes of what remains to be done, what has been done, and what needs to be decided (e.g., retaining or discarding variant spellings).

Make sure all your files match

Make sure that the contents of the text and HTML versions match. Work on one version to make all the checks, spelling, etc., and only when you have one complete file that needs no more corrections, save off the files for the other versions. If you correct something in one of your versions later on, go back to all of the other versions right away and apply that same correction to them.

The ppcomp utility, accessed through the Post-Processing Workbench, can be used to highlight differences between the text file and the HTML file.

Know the Resources

Read the Guidelines/FAQs

For information on pretty much all aspects of Post-Processing, see the Post-Processing FAQ.

If you want to know which types of things your PPVer will be looking at, check out the PPV Guidelines. They're not a secret, and knowing them can help a lot with reaching DU!

Post-Processing Advice is a pretty good summary of the resources available in the Wiki. There's some great stuff in there, so don't hesitate to look around a bit!

Get a PP Mentor

If you haven't yet, try PP Mentoring! A PP Mentor is a dedicated, experienced PPer who can help you with All Things PP. Services range from helping to install tools, answering questions, pointing to relevant information and documentation, to holding your hand through your first project(s). Whichever learning style suits you best, a PP Mentor can probably help point you at the right resources.

Experience shows that PPers with PP Mentors usually reach DU faster than those without.

Ask questions and get feedback

There are different learning styles, and some people want to figure out everything on their own—but at some point there will be something you wonder about, or you can't find a good answer for in the Wiki or the forums. Please, even if you are shy, do ask your question, so the PPVer doesn't have to answer the unasked one during PPV. You can use the No Dumb Questions thread for that, or ask one of our PP Mentors in private.

Get all the feedback you can before uploading for PPV, whether through Smooth-Reading or the various forum threads or whatever else you can think of. This is an open book exam: We don't expect anybody to know everything, knowing where to get help is plenty enough.

Don't hesitate to “steal” from finished projects

Look for solutions or ideas in projects that have already been posted to PG. Many projects share uncommon features; “uncommon” does usually not imply that those features have never occurred before. There's a tremendous amount of work out there, with solutions for all kinds of issues. Use finished projects to your benefit instead of re-inventing the wheel when it's not necessary.

Write your own checklist

Either start from the Guiguts checklist, from another PPer's personal checklist, or from scratch; and then whenever you get PPV feedback, add checks for the errors that were found to your checklist. Make sure that for each subsequent project, you specifically check for any previous errors; that way, you won't annoy the PPVers by making the same mistakes over and over again, and you will gain DU access so much faster.

If your PPVer points out something to you that you don't know how to find, ask. Your PPVer might be able to point you at additional tools or resources that you don't know yet.

Know and Explain Your Reasoning

Don't become fixated on creating a facsimile

As a PPer, you have a certain amount of freedom when deciding on the final format of a book. You don't have to exactly reproduce the layout as printed, and trying to do so too hard often causes problems. It's better if your e-books display well on a variety of devices at varying aspect ratios, and, if possible, auto-convert gracefully into new formats without loss of quality.

More generally, learn about semantic markup as opposed to visual markup, and code flexibly in HTML and other formats that support semantics. Don't misuse structures because they happen to duplicate the printed book's typography. (Example: Don't code varying type sizes on a title page as multi-level headings.)

Some more tips on coding practices for better e-book accessibility (and, more generally, usability) can be found in our collection of Accessibility Recipes.

Don't over-correct the original text

Be aware that [** notes] may give bad advice. Sometimes, you will come across older spellings like “Shakspear”, “despatch”, “vender”, “inclose”, etc. Sometimes they're obscure words, but if you fix the one that's [**noted], you're likely to miss others, or change “inclose”, but not “inclosure”, “inclosed”, and “inclosing”.

Yes, fix obvious typesetting errors, such as misplaced quotes, missing or transposed letters—but be skeptical of other changes, especially if the word appears more than once in the text. For example, “preception” means a previous thought, and may not be a typo for “perception”.

If possible, get access to the online OED through your local library, or use other online dictionaries that include older words.

Let the PPVer know what you have done, and why

If anything unusual occurred in the project that needed some non-standard or non-guideline-covered action, put a note in the upload comments to inform your PPVer. They might otherwise wonder why you've decided to handle something in a “strange” way, and it will save both of you time—and potentially confusion or frustration—if you tell them about any unusual features right from the start.

Take Your Time

Don't rush things

Make sure you run all required checks before first submitting the project, so that it won't have to be returned to you by the PPVer. When you think you've finished, put the project away for a day or so, then come back to it as though you were the PPVer and go through all of the checks again. If you do the checks carefully and don't find anything, then your PPVer is unlikely to find anything either.

Rushing any of the checks usually just means you will get the project back, and will have to run your checks again—which wastes both your and your PPVer's time.

Be patient with yourself

PPing is complex and multi-faceted. It takes time to learn how to use existing tools and to develop good work habits. Don't overextend yourself by choosing overly-difficult projects or by taking on too many projects at once.

PPing is a craft that takes time to learn, and earning DU status is not a race. Try to do your work well and enjoy it, and you will get there!