From Serious Eats comes a push to Very Good Taste, which posted The Omnivore's Hundred ("a list of 100 things that I think every good omnivore should have tried at least once in their life").

If you don't recognize everything in the list, Wikipedia usually has the description. The goal is to try everything eventually, although you can cross out those things you plan on never trying.

From Very Good Taste:

1. Copy this list into your blog or journal, including these instructions.
2. Bold all the items you’ve eaten.
3. Cross out any items that you would never consider eating.
4. Optional extra: Post a comment here at www.verygoodtaste.co.uk linking to your results.

Here's my take on the VGT Omnivore’s Hundred:

1. Venison
2. Nettle tea
3. Huevos rancheros
4. Steak tartare
5. Crocodile (actually, I had alligator)
6. Black pudding
7. Cheese fondue
8. Carp
9. Borscht
10. Baba ghanoush
11. Calamari
12. Pho
13. PB&J sandwich
14. Aloo gobi
15. Hot dog from a street cart
16. Epoisses
17. Black truffle
18. Fruit wine made from something other than grapes
19. Steamed pork buns
20. Pistachio ice cream
21. Heirloom tomatoes
22. Fresh wild berries
23. Foie gras
24. Rice and beans
25. Brawn, or head cheese
26. Raw Scotch Bonnet pepper
27. Dulce de leche
28. Oysters
29. Baklava
30. Bagna cauda
31. Wasabi peas
32. Clam chowder in a sourdough bowl
33. Salted lassi
34. Sauerkraut
35. Root beer float
36. Cognac with a fat cigar
37. Clotted cream tea
38. Vodka jelly/Jell-O
39. Gumbo
40. Oxtail
41. Curried goat
42. Whole insects
43. Phaal
44. Goat’s milk
45. Malt whisky from a bottle worth £60/$120 or more
46. Fugu
47. Chicken tikka masala
48. Eel
49. Krispy Kreme original glazed doughnut
50. Sea urchin
51. Prickly pear
52. Umeboshi
53. Abalone
54. Paneer
55. McDonald’s Big Mac Meal (but not for years!)
56. Spaetzle
57. Dirty gin martini
58. Beer above 8% ABV
59. Poutine
60. Carob chips
61. S’mores
62. Sweetbreads
63. Kaolin
64. Currywurst
65. Durian
66. Frogs’ legs
67. Beignets, churros, elephant ears or funnel cake
68. Haggis
69. Fried plantain
70. Chitterlings, or andouillette
71. Gazpacho
72. Caviar and blini
73. Louche absinthe
74. Gjetost, or brunost
75. Roadkill
76. Baijiu
77. Hostess Fruit Pie
78. Snail
79. Lapsang souchong
80. Bellini
81. Tom yum
82. Eggs Benedict
83. Pocky
84. Tasting menu at a three-Michelin-star restaurant
85. Kobe beef
86. Hare
87. Goulash
88. Flowers
89. Horse
90. Criollo chocolate
91. Spam
92. Soft shell crab
93. Rose harissa
94. Catfish
95. Mole poblano
96. Bagel and lox
97. Lobster Thermidor
98. Polenta
99. Jamaican Blue Mountain coffee
100. Snake

So...how good an omnivore are you?

Jesper Johansson, Microsoft Windows Security MVP, recently took the time to fully disect a malware spam that he found in a blog comment. If you blog...or if you click links!...you'll want to read this article.

Q3 2008 is jam-packed with conferences that cover a variety of technical communication topics. Note that in some cases, the registration deadlines are coming soon!

• UA Conference - Europe 2008. 18 to 19 September 2008 in Edinburgh, Scotland. Produced by Matthew Ellison Consulting in association with WritersUA, this two-day conference includes topics about language, tools and methodologies, wikis, portals, and more.
• DocTrain EAST. 29 October to 1 November 2008 in Burlington, Mass, USA. This four-day conference, produced by Pubsnet, includes pre- and post-conference workshops that are included in the registration price. Topics include instructions on specific tool functionality and information on project management, content convergence, XML, and more.
• tcworld conference. 5 to 7 November 2008 in Wiesbaden, Germany. Produced by tekom, this conference draws the largest number of technical communicators. Topics include processes, localization and translation, tool instruction, XML, and much more.
• LavaCon, run by Jack Molisani in conjunction with Project Management Institute. 6-8 November 2008 in Honolulu, Hawaii, US. LavaCon includes proven best practices in the fields of technical communication and project management, presented in tracks. Topics include conflict resolution, XML and DITA, localization and translation, and more.

Good luck choosing :-)

Do you know (or know of) Michael Hughes? If you don't, you should. Mike has all sorts of credentials (if that matters to you)...he also has a wealth of knowledge about usability and writes a column for UXmatters.

And he just wrote a blog post (that I wished I'd written) about how he hates online user manuals that are distributed as PDFs, especially those that are formatted for printing.

If you're going to distribute an online PDF as a user's manual instead of one of the many appropriate online formats, then at least make it easy for your users. Follow Mike's tips: set them up for simplex printing, not duplex. Make the page numbers match up so that page 100 in the PDF uses 100 as the page number that's displayed. Get rid of the "book" overhead like front and back covers.

In addition, I'd add a few more:

• Don't use independent chapter numbering (where each chapter restarts from 1), unless your goal is to frustrate your users beyond belief. (Picture this: you open a PDF that's 300 pages long. You want to read the information in the last chapter before the appendices, which starts on page 6-1. As you look at the vertical scroll bar in the window, where do you think you should scroll to to find page 6-1? To the middle, maybe? To the end? What page number should you go to? Will you find 6-1 on page 100 of the PDF? Page 200? Page 295? Think of how much easier it would be to search for page 200 in a 300-page PDF, especially if page 200 is really the 200th page.)
• Forget "picture-perfect" layouts. I don't mean that you should not care at all, but if your company isn't going to be printing these PDFs for your customers, then relax your standards a little. Don't require that every page element is perfectly placed. If you're not careful, you'll spend more time fixing layout issues and using up the budget before the content is finalized.
• Put the "important but not a priority" stuff at the back. For example, copyright doesn't have to be at the front. Yes, copyright is important (see some of my other posts). But if a user is opening the PDF, it's typically not to read your copyright...it's to find the answer to a question. It's already a harder process than it needs to be because it's a PDF...moving this kind of content to the back makes it easier for the user.

(BTW, I find Mike very credible, even if he does provide quotes from The Gladiator. ;-))

Back in 1998, I defined topics as "'chunks' of information in a Help file that answer one question or provide focused, specific content." Ten years later, I typically use the same definition. However, there have been some changes in how those "chunks" are developed.

In the beginning, we mostly used Microsoft Word to create topics, where codes or styles in the doc file divided the output into topics. One topic in the Word file became one topic in the output. With the advent of HTML Help, we moved to HTML files, and what we saw in development was what we saw in the output. The best we could for reuse was using a topic in more than one place in the table of contents.

This was because most of us used file-based tools. But now we have more features. For example, snippets are included (or embedded) in the core topic. Variables let us define reusable bits of content (and sometimes we can override them when publishing). Build tags, conditional tags, and variants let us choose which topics are published. And when we publish, the file that we created in development becomes the file that is used for the output. (One exception would be those using Word for WinHelp, HTML, or HTML Help...but again, the topic that is defined in Word becomes the output topic.)

With XML, however, things are a little different. Topics in development may only be part of the topic that is published. For example, a topic may reference another topic. In development, you see the reference, and in the output, you see the topic.

And with XML and database tools, there's another level of differences. Topics are organized with maps or tables of contents. Different settings control if the individual topics in development will become individual topics in the output or if multiple topics in development will be merged to create only one topic in the output.

What I think we will be faced with is a terminology change. Sometimes I call topics in development "topic objects", as they may or may not be the final topic. These topic objects are still chunks of content, but now their content is determined by their reusability. (For great articles about reusability, see Michael Hughes' blog. He mostly focuses on DITA...after all, he works for IBM...the concepts can be used with any authoring tool.)

Do you use different terminology to explain the difference between topics in development and topics in the output? Do you think new terminology will help? Or will it just make this more confusing?

FrameUsers is dead. Again. Still. (I think.) For some reason, the fact that no one can access the site this week is causing consternation, yet as I understand it, the site hasn't been available for awhile.

To solve the problem, folks have been creating new user groups. Now, there's nothing wrong with user groups...I run several myself.

Thing is, a perfectly viable list is already available (and has been...it's not a new start-up).

So, if you need a place to talk about FrameMaker issues, visit OmniSystem's Free Framers group.

And for a more humerous take on this whole thing, visit TechCommDood's blog.