I would like to remind everyone that many blog posts are now drafted in public at https://meta.wikimedia.org/wiki/Wikimedia_Blog/Drafts . Pre-publication copyedits or comments on better structuring etc. are welcome there, so don't feel restricted to posting armchair advice on mailing lists ;) For example, the Flow post discussed below (I agree with Florence's points btw) was up at https://meta.wikimedia.org/wiki/Wikimedia_Blog/Drafts/Help_us_design_our_next-generation_discussion_system before it was posted on the blog.
This is a great thread with a lot of good points, and of course in the blog team we already routinely use many of them when reviewing and editing posts, often pointing authors to https://meta.wikimedia.org/wiki/Wikimedia_Blog/Guidelines (e.g. "Try to use the Inverted pyramid structure, so that people get the heart of the story from the beginning. / Use a strong lead sentence/paragraph that explains the most salient and important point of your story up front.") On Wed, May 22, 2013 at 8:39 AM, Florence Devouard <[email protected]> wrote: > Hi > > My main suggestion (valid for all posts, technical or not) would be to start > with a clearly identified cap as summary. And put an extra effort so that > this cap is written in simple and straightforward message. > > In that regards, this post is pretty good generally > http://blog.wikimedia.org/2013/05/20/flow-next-generation-discussion-system/ > > It gives a nice summary of the content of the post. It can be translated > easily. It provides information. The cap summary at the top could be even > better identified though. > > > On the other hand, this one > http://blog.wikimedia.org/2013/04/08/intro-to-the-statistics-of-ab-testing-with-wikimedia-fundraising-banners/ > is quite "technical" in nature as well, but though very interesting, it > fails to pass the "summary" state. > The little paragraph at the top is not a summary of the post, but a text > putting the post in context. > I think this post would benefit from a two lines summary of the content of > the post itself. > Its design is 1) context, 2) development 3) conclusion. > > One of the problems non English speakers face is that they are slower to > identify the "important" points. Stumbling over difficult words and jargon > is obviously not helping. A hard text will need to be read more than one > time to just "get the idea" > > In this situation, it is very helpful to rather write in the following way > 1) summary of the entire post with context, arguments and quick conclusion > 2) expanded context > 3) expanding on argument a > 4) expanding on argument b > 5) expanding on argument c > 6) full conclusion > > 1) should be short sentences, simple sentences and as little jargon as > possible > 2-6 can be more complex and detailed and links should be added to provided > additional context and explanation of jargon. > > The only drawback of this solution is that the author will feel frustrated > if he wants to develop a story and use surprise/discovery effects. But there > are many benefits to counter balance this loss. > > Flo > > PS: who will point out though that the tech posts on the wikimedia blog are > actually quite good generally. > > > > On 5/22/13 11:44 AM, Federico Leva (Nemo) wrote: >> >> Quim Gil, 21/05/2013 23:15: >>> >>> [...] Good journalism is mostly about a lead paragraph for the masses >>> followed >>> by an increasingly dense body text (aka the 5 Ws and the inverted >>> pyramid). You can adapt and change these rules at will, as long as you >>> are aware of them. >>> >>> Paying more editorial attention to the title and the lead will allow >>> more room for complex terminology down in the body text. And this >>> applies to technical posts just as much as to other posts about other >>> expert fields for librarians, translators, lawyers, educators... >>> >>> https://en.wikipedia.org/wiki/5_Ws >>> https://en.wikipedia.org/wiki/Inverted_pyramid >> >> >> I agree that this is more useful, with the caveats by Lodewijk. >> As for our English texts, aside from jargon, their main deficiency >> is IMHO usually in not considering language diversity. The issue is very >> apparent in our requests for translations: often, you have very "simple" >> and short sentences which are translated in a way that reverses their >> meaning upside down. An article or pronoun implicit in English, if >> misunderstood by a native speaker of a language where the article or >> pronoun matters, is enough to spoil an entire text. What to do? >> 1) Some time ago I added some short leaflets here, but more and better >> resources are needed: >> http://meta.wikimedia.org/wiki/Writing_clearly#Advice_from_the_experts >> 2) An automatical service we'd benefit from is one which takes a text >> and highlights all idiomatic expressions (which may be obvious in USA >> English but mean the opposite in UK English or just nothing for most >> people), formal/literary expressions (which may mean nothing for most >> native speakers and at the same time be obvious for speakers of another >> language more closely related to them) etc. >> Let me also add that – personally – I have no problems reading and >> understanding sentences spanning multiple pages, if they were written by >> Proust (who always has a reason), but I have big problems understanding >> texts which lack coherency and focus. English texts composed by many >> scattered short sentences, without conjunctions and other sentence >> connectors, are for me very painful to read. However, it seems most >> people prefer to have many small concepts and to connect the dots >> themselves to get the figure as they can. >> >> Nemo >> >> _______________________________________________ >> Wikimedia-l mailing list >> [email protected] >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l > > > > > _______________________________________________ > Wikimedia-l mailing list > [email protected] > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB _______________________________________________ Wikimedia-l mailing list [email protected] Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
