Un gran titular puede ser la diferencia entre tener tu artículo de libre reimpresión publicado una vez (en su propio website…) y tenerlo publicado cientos, si no miles, de veces en Internet.
Sin duda, el contenido tiene que valga la pena; tiene que ser útil, informativo y no sólo un spiel venta. Y no se puede negar que un artículo bien escrito puede ser muy convincente. Pero si el titular no corta, el artículo no tienen una posibilidad. El mejor artículo del mundo nunca verán la luz del día sin un titular efectivo.
Ahora más que nunca, las presentaciones de artículo necesitan un buen titular. Pero no es sólo el lector que tiene que preocuparse. De hecho, el lector es secundario. A la hora de reimprimir titulares de artículo, su principal objetivo debe ser el editor.
Puede que los requisitos de un buen titular no han cambiado con los años, pero que tienen. A diferencia de titulares de periódicos tradicionales, revistas, etc., que dirigen a sólo el lector, la presentación de artículo en línea titulares de destino primero el editor y, a continuación, el lector.
¿Cómo se escribe un titular de una editorial en línea? Aquí hay unos Consejo…
1) Estado su dominio No importa lo que su negocio, puede estar seguro de que potenciales editores de tu artículo se inunda de información cada día. Imaginar a hipotético 'editor Pete'. Es el webmaster de un sitio alto de PR. Recibe cada día cientos de peticiones de artículo. Además, las explotaciones sitios de presentación artículo (también conocido como 'artículo bancos', "sitios de envío de artículo", "libre de reimpresión de sitios") para artículos de forma regular. Porque muchas de las presentaciones de artículo que ve son spam o no relación, editor Pete es rápido despedir a cualquier cosa que no es inmediatamente – y obviamente: relevantes para su sitio Web. Así que asegúrese de que su titular señala el tema general de la presentación del artículo, no sólo el tema exacto.
2) Su argumento de que cada sitio Web tiene un programa del Estado. Ya sea vender, persuadir o informar, siempre hay un ángulo. Cuando nuestro amigo editor Pete mira gratis reimpresión contenido para su sitio Web, que quiere algo que complementa su programa. Si es la venta de abonos de jardín, él no quiere un artículo sobre los males de fertilizantes químicos. Tampoco quiere un artículo exponiendo las virtudes de abono orgánico. Quiere un artículo promover el valor de fertilizante químico de jardín. Si eso es lo que trata el artículo, asegúrese de que el titular le permite saber.
3) No hacer promesas vacías pueden trabajar Sensationalized titulares en los medios tradicionales, pero no son tan eficaces en las presentaciones de artículo en línea. Pocas cosas frustran una editorial en línea más que ser atraídos en por un titular prometedor que resulta para ser nada más que aire caliente. Para los editores que se toman el tiempo para filtrar cuidadosamente el contenido antes de publicar, titulares vacíos no son más que tiempo wasters. Para los editores que son un poco menos meticulosos, titulares vacíos como resultado en un sitio que se caracteriza por contenido Inconexo, contradictoria, de baja calidad. De cualquier manera, el editor no está impresionado, así que seguro el título de tu artículo es pertinente (y validados por) el cuerpo de tu artículo.
4) Ponte en los zapatos del editor siempre pensar en maneras de facilitar el trabajo del editor. Es así de simple. Brainstorm 5, 10, 20 titulares, luego de ponerse en posición de publisher y pedir que uno podría hacer. Es el mejor titular por su envío de artículo.
5) Pensar en los lectores de su editor que editores desean artículos que los lectores se abrirán. Pero recuerda, el sitio Web de su editor puede atender a un distinto tipo de lector al sitio Web. Cada vez que usted encuentra pensando en su público secundario (el lector), asegúrese de que está pensando no los lectores de la Editorial: su propio. Que se establecieron, puede continuar con foco en consideraciones de titular de la audiencia regular como hacer el titular atención-obtener, dirigidos y beneficiarse por.
Conclusión Con la aparición de la presentación de artículo como una gran forma de generar un ranking del motor de búsqueda alta y la proliferación asociada de spam de presentación del artículo, el titular del derecho es más importante que nunca. Lo importante para recordar es que debe afrontar un guardián, y que necesita satisfacer sus necesidades en primer lugar.
Siguiendo todos los centrados en publisher Consejos anteriores, no sólo verá tu artículo publicado muchas veces más, también verá que lo publicado en los sitios Web más pertinente. Esto ayudará a su ranking (como vínculos de sitios pertinentes están siempre lo mejor) y el tráfico de click-thru (porque el público será más pertinente).
Encabezando feliz!
Reimpresión artículo titulares: el lector es secundario
Gran escritura técnica: La espada de doble filo de la experiencia del lector
Keywords:
Technical writing user manual instruction document assumptions experience
Article Body:
Overview
When we write User Documents we rely on our Reader's/User's experience to simplify our work. This can cause problems for the Reader. This article will discuss the effects of Reader experience and how to minimize the negative effects of incompatible experience, and how to handle the writer's assumptions about the Reader.
Writer's Benefits: Relying on Reader Experience
When we write, we rely on our Reader's experience to give us a "starting point" for our User Document. Often we make hidden assumptions about our Reader's experience.
Here are some examples where relying on our Reader's experience makes things easy (and causes problems) for us as writers:
Example: Using a Computer's Mouse
In writing User Documentation for Graphical User Interface-based computer products (such as the Windows or Mac User interface), we assume that the the Reader knows how to use a mouse to click on items, drag, etc. This saves much background writing.
Example: Cooking: How to Measure Ingredients; Terms
Cook books save space by (usually correctly) assuming that a Reader can perform basic cooking operations (such as measuring ingredients), and terms (such as puree or slice).
Example: Common Acronyms
We rely on "common" acronyms such as AM and PM to simplify our writing lives. However, many Readers use a 24 hour clock, and thus AM and PM are meaningless to them.
Beware of any acronyms that you assume that your Reader knows. It is best to define acronyms in line (perhaps in parentheses) when they are first presented in that part of the User Document.
You cannot define them only the first time they appear in the User Document. This assumes -- incorrectly -- that Users read your User Document from start to finish.
Problems Writers Cause When Assuming User Experience
Our assumptions as writers can get us into trouble.
Example: Unfamiliar Words
Here's a gardening example: Acme's (a fictitious company) Illustrated Guide to Gardening in Canada (1979) makes an incorrect assumption about its Readers:
In one of their definitions they use a term, "the axil of a leaf" to define another term. "Axil of a leaf" is not listed in the book’s index, and there is no glossary in the book. Clearly this book assumes that the Reader understands the term "the axil of a leaf." I don’t, and am therefore unhappy with the presentation.
Solution: Provide a glossary of gardening terms or a reference to a page in the book where the term is defined.
Example: Assuming Students' Experience
Here is an example where an (unstated) assumption by a training company rendered one of their courses useless.
In order to do the exercises in a computer programming course, students had to be able to use an editor (a simple word processor) to program the system. The only editor available on the course machines was a UNIX editor known as vi.
Unfortunately, the students were not told that they needed to use the vi editor. The course presenters assumed that the students knew vi. The students did not, and they spent half the course time trying to learn and deal with vi.
The hidden assumption by the training company resulted in a failed learning experience (the students never needed to use vi again). It wasted two days of the four-day course time.
Don't Present Assumptions in a Sneaky Way
If the training company had said that, "We train on UNIX systems," then they leave a way out for themselves when they disappoint students who do not know the vi editor. When confronted, the company could respond with, "We told you it was a UNIX system. You should know that vi is the editor available on that system."
This sneaky statement of the assumption is foolish. It will result in a lose-lose situation.
The Bottom Line
As writers, we to make assumptions about our Reader's experience. However, if you make assumptions, then make sure that you tell the Reader what you assume about him/her.
Think about the assumptions that you make about your Reader. Are these assumptions valid (that is, can you really expect your Readers to meet your assumptions)? If there is any doubt in your mind, include information explaining the terms and procedures that you assume.
Make sure that when you state assumptions, that you present them in a way that the Reader (student) can understand what the assumption means to them. Don't be sneaky about presenting the assumptions.
User Experience Can Cause Trouble for Writers
Your Reader's experience can cause confusion. Here are some examples:
Example: Shampoo/Conditioner Product
One of my favorite examples is a combined hair shampoo and conditioner product. If a User has experience with the separate products, then their experience is to:
* Shampoo: Wet thenhair. Massage shampoo into the hair, then rinse it out.
* Conditioner: Wash the hair. Massage conditioner into the wet hair, leave in the hair for two or three minutes, then rinse it out.
The problem arises with the combined product. Should the User leave the product in the hair for two or three minutes (as done with the conditioner), or rinse it immediately (as done with the shampoo)?
The User Document (product label) for a combined shampoo-conditioner should tell the User how to use the two-in-one product. Most such labels do not.
Example: Words Used in Unexpected Ways
Your writing can set the expectations of the Reader, resulting in confusion when words are used unexpectedly.
An article in the Technology Section (of a newspaper on June 10, 2004, page B14) described, "How the little guy can back up computer data". The article was about computers. When I came to the sentence: "Let's face it: backups are boring and a hassle to boot." I wondered about the phrase "to boot."
In computer jargon, "boot" is the process where the computer starts up ("lifts itself by its bootstraps"...by a program originally called a "bootstrap loader"). Does the author's quote about "hassle to boot" mean that if I do backups, then my computer will be slower ("boring") and require more work from me to start up ("hassle to boot")?
The use of the phrase "to boot" is inappropriate in this article, given that "to boot" has multiple meanings. The author used it as slang for "in addition to." Since the article was about computers, I thought of the computer meaning of "to boot." The sentence would be less confusing if the author left out "to boot," as: "Let's face it: backups are boring and a hassle." We'll return to this example shortly.
Example: Functional Fixedness
An object's function is fixed in a person's mind. For example, a hammer's function is to pound things. Experiments have demonstrated that people have a hard time using a hammer for an unusual function, such as a paperweight, a prop, or a lever. This is called functional fixedness.
Functional fixedness can limit the usefulness of your product. Your User Document should attempt to overcome functional fixedness. Perhaps this example will show how critical I am of User Documents.
I have a wrist global positioning satellite (GPS) device that keeps track of my long walks. Sweaters and heavy coats, needed for walking in the winter, make it difficult to wear the GPS device on the wrist. But it is a WRIST device. Functional fixedness arises, causing me struggle to use the GPS on my wrist. But it turns out that the GPS works well when used in a pocket.
The GPS User Document should mention this (obvious?) capability, thus reducing the functional fixedness associated with the WRIST GPS. In my defense: I am not sure that putting the wrist GPS in a pocket is more obvious than using a hammer as a paperweight.
Example: Humor
Humor relies on:
. a subtle knowledge of the language (for example a pun)
. or a knowledge of an event (perhaps a current event or entertainment event)
on which the humor is based. Here's an example, from an old joke:
"You're so funny, you should be on a stage. There's one leaving in 15 minutes."
This joke relies on the Reader's knowing the two meanings of "stage": (1) a place for performing, and (2) transportation used in the western United States in the 1800's. Most Readers might not know the second meaning, rendering the humor a confusing waste of words.
Earlier we examined the sentence: "Let's face it: backups are boring and a hassle to boot." The author used the phrase "to boot" as some form of folksy talk or humor. It confused the Reader.
Eliminate Humor from Your User Document
. Humor will only confuse Users who do not understand it.
. Humor is difficult, if not impossible, to translate into other languages.
I suggest that you use a writing style that is informal and conversational, but with no attempts at humor. Remove attempts at humor when you review and revise your writing.
If you want to write humor, do it elsewhere (you should be on a stage). User Documents are no place to practice your humor.
The Bottom Line
Assumptions
Be careful about what you assume about your Reader. When in doubt whether or not a Reader knows something:
. State your assumptions about your Reader
State the assumptions in a way that the Reader can relate to
. When in doubt, add the information that you assume, or
. Tell your Reader where to find the assumed information
By providing or pointing to this assumed information, you increase your audience
Readers' Experience
Be aware of how your Reader's experience influences how he/she interprets your User Document or uses your product. If necessary add material to your User Document to counter your Reader's incompatible experience.