Two-page tutorial

From Writer's site

Jump to: navigation, search

Linux Format writer's templates

Two-page tutorial

Click here for the template in plain text


1 PURPOSE:
Our tutorials are the most popular part of the magazine. They should be clear, inspirational and project-based with a beginning and an end. Don't be afraid to inject your personality into the text: this is one of the few places in the magazine where we allow the author to refer to themselves as "I".

Before you submit your tutorial, please read it through and check it against this checklist:

  • Project-based
  • Has a clear stated aim at the start (using the title, standfirst and intro)
  • Meets that aim by the end
  • If possible, shows that end result visually
  • Active, direct and inspiring headline
  • Active, interesting box titles
  • Lots of entry points: pull quotes, boxes and images
  • Illustrations have colour - even grey grabs are well cropped or have coloured desktop surround
  • Well structured, split up and signposted

2 WORD COUNT:
Approximately 1,350 words, assuming two objects on the second page (images or boxes), plus footnotes. The compulsory Quick Tip box is additional and won't affect the word count, because it goes in the margin.

This word count refers to the body of the tutorial only, and does not refer to boxes, standfirsts and so on (see Pictures And Boxes, below).

About footnotes:

  • For tutorials in a series, the redesigned Linux Format uses long, page-wide footnotes to tell readers what was covered last month and what is coming up next month. These footnotes take up 35 words each. If you are writing a one-off tutorial, the layout won't include footnotes, and you can add a princely 70 words to your text.

A note about code:

  • The amount of code you include in the tutorial has a dramatic effect on word count, which makes it hard to be definitive about word counts.

For example, if the tutorial text contains no code at all, you will need 1,500 words of it to fill the two pages. But if nearly half of the tutorial text is code, which would represent the largest amount of code we'd accept in a tutorial, you will only need 1,200 words of it to fill the two pages.

3 LAYOUT:

  • If there's anything you need to point out to design and production staff, label it ///DESIGN NOTE/// and put it IN CAPS at the beginning of the text in square brackets, or at the relevant point in the body if it refers to something like an annotated pic or flow diagram.

It is possible to split up your tutorial into two parts, to make it easier for readers to follow. See Andy Channelle's First Steps tutorials for good examples of this. These parts should be structured as:

///MINI SECTION///
Part 1 [Then add a section heading]

  • If you would like to present your tutorial as a series of screengrabs and long captions, rather than as long narrative text with screengrabs on the side, please check with LXF staff and request a word count.

4 PICTURES AND BOXES:
You must provide one Quick Tip box, containing a single tip relating to the software and the tutorial in hand. The total word count can be 20-50 words. Just text, no images.

In addition, please provide at least two images and/or boxes.
Notes about images

  • Images should be colour, and 250 DPI. Screengrabs are best sent in PNG format.
  • Please crop all images yourself before submitting them, unless you mark otherwise.
  • All screengrabs should be named appropriately with something relevant to the article's title, numbered sequentially in the order they are to appear in the article if relevant, and all should have a proper caption.
  • Captions must be interesting. A good caption contains some titbit of information that has been held back from the body copy. Captions are also usually an appropriate place to exhibit a bit of wit, and it's encouraged!
  • If the images are screengrabs, please make them colour, PNG files and Linux grabs (it sounds obvious, but no Mac or Windows grabs please). If you can't avoid using images of the console, please try to use a colourful text editor or X terminal, and include some of the desktop's colourful background before you crop it.
  • Avoid grabs that have copyrighted images as your desktop wallpaper, or grabs that include images of your pets or children. Also avoid taking grabs of the Linux Format website.

Also consider submitting diagrams or charts. We can redraw them in-house.

The word count for boxes can vary depending on their size. Aim for about 100 words for a medium-sized box the width of a column. Ideas for boxes:

  • Grabs with their own commentary.
  • A small step-by-step guide.
  • A tabulated list of resources or instructions.
  • Essential system requirements.
  • Facts about the product.
  • Background information or history.
  • A mini project.

A large image or diagram takes up about 230 words. A small column-wide box or image takes up about 130 words. But these are accommodated for in the 1,350 word count. If you intend to do a very large box, please ask LXF for a revised tutorial body word count.


5 STRUCTURE:

///TOP BAR///
Tutorial Xxx
Where Xxx is the name of the series or, if it is a one-off tutorial, the name of the software/technology being used.

///TITLE///
Please enter the name of the software/technology being used, then a colon, followed by what the reader will do in the tutorial. eg
Security: Harden your passwords
Greasemonkey: Mod the web!
Inkscape: Design a web page

///STANDFIRST///
Part x: [If it is part of a series] followed by 15-20 words to introduce the tutorial and the author's name. Aim to get across what techniques the reader will learn or be using, and some enthusiasm about the project, and use humour if you like.

///ON THE DVD LOGO///
We try to put most free software used in tutorials on to the LXF coverdisc. Please contact the disc editor as soon as possible to let him know what you are reviewing and where the code is kept online so that he can take a look. Email mike.saunders@futurenet.co.uk.

///FOOTNOTES///
Use these if your tutorial is part of a series:
Last month xxxxx
eg Last month We built a kid-friendly desktop with restricted access and web filters.
Next month xxxx
eg Next month We'll bring in data from other sources and try queries and reports.

///END FOOTNOTES///

///OUR EXPERT BOX///
yourpic.png

If you have written for us recently, we probably have your biographical details already. If not, this is the place where you should write 25-30 words on your background, introducing yourself to the readers and letting them know why you are qualified to write this tutorial!
///END OUR EXPERT BOX///

///BODY COPY///
[Add tutorial copy here.]

Body copy notes:

  • Any code must be clearly tagged at the start with ///CODE/// and at the end with ///END CODE/// because we format it differently in the magazine. Any indents in code MUST be done with spaces, NOT tabs. A good rule-of-thumb replacement for tabs in pasted-in code is to use two spaces: the code is quite often displayed in quite narrow columns.

///CROSSHEAD///
A one-line title that:
a/ breaks up the dense text of the main body copy
b/ highlights an important point or a new section.
Aim to insert one or two cross-heads on every page.

///PIC///
yourfilename_number.jpg

///CAPTION///
10-20 words.

///PULL QUOTE///
An interesting quote of 10-15 words from your tutorial. If you can�t find one, don�t worry � our production staff will!

///COMPULSORY BOX///
///BOX TITLE///
Quick tip

///BOX BODY///
The text of your box.
///END QUICK TIP///

///OPTIONAL BOX///
Optional box notes:

  • If you include pics in a box, include their filename with a ///PIC/// tag, and a caption with a ///CAPTION/// tag, as you would in the body text.

///BOX TITLE///
This should make it clear what the box is about.
eg Resources

///BOX SUBHEAD///
This shouldn't be necessary unless the box title needs embellishing to make sense.

///BOX BODY///
The text of your box.

///BOX CROSSHEAD///
Only necessary for big boxes.

///END BOX///

///END BODY COPY///

Personal tools