Archive for March, 2014

h1

Word: Change caption numbering from sequential to chapter numbering

March 31, 2014

Scenario:

  • You have a Word document that uses outline numbering for each chapter/section heading (e.g. 1.1, 1.2, 2.4.3 etc.).
  • You have table and figure captions in this document that are numbered in two long sequences — one for tables, one for figures (e.g. Table 1 through 53; Figure 1 through 26).
  • You want to convert the caption number sequences from a single number sequence to a separate sequence in each chapter/section (e.g. Table 3.2 for the second table in chapter 3).
  • You want to do this because your document is long and readers can’t easily find the tables/figures they want as numbers like Table 34 are meaningless unless you find the table captions before/after ‘Table 34’. By changing the numbering sequence to include the chapter numbers, your readers will have guideposts to aid their search — if they are in Section 5, they will know that Table 3.2 is back in Section 3 and is the second table in that section.
  • Ultimately, you want to help your readers find the information they want as quickly as possible.

Prerequisites:

This set of steps ONLY works if you use automated outline numbering for your heading styles. This post does not describe how to set that up (instead see the links in this post: https://cybertext.wordpress.com/2008/09/23/word-2007-outline-numbering/).

***************

There are three main steps in this procedure — updating the table and figure caption numbering, then updating any cross-references that refer to these tables (including any List of Tables of List of Figures you’ve inserted).

Step 1: Update the caption numbering for tables

  1. Place your cursor in front of ANY automated caption number for ANY table.
    chapter_num_captions01
  2. Go to the References tab and click Insert Caption to open the Caption dialog box.
    chapter_num_captions02
  3. Change the Label to Table.
  4. Click Numbering to open the Caption Numbering dialog box.
    chapter_num_captions03
  5. Select the Include Chapter Numbering check box.
  6. Optional: Change the Separator. It’s unlikely you’ll need to change the Format or the Style, so leave those as they are.
    chapter_num_captions04
  7. Click OK to close the Caption Numbering dialog box. Doing this automatically updates ALL table caption numbers in the document.
    chapter_num_captions05
  8. Click Close to close the Caption dialog box.

Step 2: Update the caption numbering for figures

  1. Place your cursor in front of ANY automated caption number for ANY figure.
    chapter_num_captions06
  2. Go to the References tab and click Insert Caption to open the Caption dialog box.
  3. Change the Label to Figure.
  4. Click Numbering to open the Caption Numbering dialog box.
    chapter_num_captions07
  5. Select the Include Chapter Numbering check box.
  6. Optional: Change the Separator. It’s unlikely you’ll need to change the Format or the Style, so leave those as they are.
    chapter_num_captions08
  7. Click OK to close the Caption Numbering dialog box. Doing this automatically updates ALL figure caption numbers in the document.
    chapter_num_captions09
  8. Click Close to close the Caption dialog box.

Step 3: Update all the cross-references to the figures and tables throughout the document

  1. Press Ctrl+A to select the entire document.
  2. Right-click and select Update Field.
  3. If you’re asked about updating the Table of Contents, select Update entire table, then click OK.
    chapter_num_captions10
  4. If you’re asked about updating the Table of Figures, select Update entire table, then click OK. You might be asked about this twice if you have both a list of tables and a list of figures.

When finished, all your cross-references should now reflect the new numbering sequences. NOTE: Sometimes you have to repeat these steps and update a second time to get them to all update correctly.

chapter_num_captions11

See also:

[Links last checked March 2014]

h1

Oops!

March 24, 2014

I think they meant ‘FreeSpirit’ like the rest of the copy… (and yes, ‘fat quarters’ are legitimate things that quilters know well).

Business Marketing 101: Employ a proofreader/editor!

free_spirit

h1

Functional design

March 19, 2014

Some things are just too sensible for words, and you wonder why no-one thought of them before.

Here are some I came across during my recent trip to the US.

IMG_4404

A wall hair dryer in a hotel bathroom with an LED nightlight incorporated into the holder — perfect for 3 am trips to the toilet in the dark! The LED light stayed on all the time the hair dryer was plugged in.

IMAG1810

I’ve seen this before, but its usefulness was really brought home this trip as I travelled with my tablet, which needs charging fairly regularly. Having a power outlet sensibly located on the base of the bedside light avoided all sorts of hunting and crawling about under the bed (often to no avail) looking for a spare outlet.

IMAG1809

At last! Recognition that business travellers actually do work in their rooms, and that kids with multiple devices need places to plug them in, and if necessary, project their games on to the in-room TV screen. This panel next to the desk in my room at the Renaissance in Palm Springs had FOUR power outlets for charging all your devices (and they were oriented in different directions to suit odd plugs), as well as LAN, HDMI, audio ports etc.

h1

More milestones… Four million views!

March 18, 2014

Sometime in the past two weeks while I was in the US attending and speaking at the annual WritersUA conference, the number of views on this blog ticked over past four million!

four_millionCompared to the exponential increase in the early years, the number of views per month seems to be plateauing. I’m fine with that; after all, some 100,000 views per month is nothing to be sneezed at and not too bad for a lone writer/editor living in regional Western Australia. And even though I don’t write posts nearly as often as I did in the first years, I still get some four to five thousand visits on an average business day.

My posts must be helping someone somewhere…

See also:

[Link last checked March 2014]

h1

Word: Jump back to a link

March 17, 2014

If you Ctrl+click on an automated cross-reference to jump to the target location in your Word document, did you know that you can go back to your previous location by pressing Alt+left arrow key?

And if you’ve jumped to several cross-reference locations one after the other, pressing the Alt+left arrow key multiple times will take you back through the cross-references you clicked in reverse order.

BONUS: Pressing Alt+right arrow key straight after you’ve pressed Alt+left arrow will take you back to the previous location!

Super quick and easy, but another of Word’s ‘hidden’ keyboard shortcuts.

alt_left_arrow

[Thanks to Paula R for sharing this with me]

See also:

h1

Avoid ‘due to’ where possible

March 14, 2014

Some terms—such as ‘due to’—are imprecise and can have multiple meanings.

Does ‘due to’ mean:

  • as a result of/resulting from
  • as a consequence of
  • because of
  • caused by
  • owing to
  • attributable to
  • based on
  • since
  • payable to
  • supposed to (as in ‘due to arrive at 10 am’)

or something else?

When you use ‘due to’ you are asking the reader to figure out what the cause/effect relationship is, instead of stating that relationship clearly and precisely. If the reader has to stop and substitute possible meanings for ‘due to’, they may not select the meaning you intended. As the author, it’s your responsibility to be clear as to what you mean, and, in most cases, that means using a more precise term than ‘due to’.

Quick tip

A quick tip is to substitute ‘due to’ with one of the options listed above and see what works best without adding, removing, or rearranging words. Here are some simple examples:

  • My sore back was due to sitting poorly. ⇒ My sore back was caused by sitting poorly. (this substitution works, as might ‘a result of’ and ‘a consequence of’)
  • I missed the bus due to the rain. ⇒ I missed the bus caused by the rain. (this substitution doesn’t work is it implies that the bus was caused by the rain)
  • I missed the bus due to the rain. ⇒ I missed the bus because of the rain. (this works)

Acknowledgements:

See also:

[Links last checked March 2014; based on a Writing Tip I wrote for my work colleagues]

h1

WritersUA 2014: Day 3: Thursday 6 March

March 7, 2014

Writing for global audiences (Barbara Jungwirth)

Only 500 million people speak English as native language; about 850 million speak it as a second language.

Approaches:

  • controlled/simplified English (very restrictive)
  • global English (more flexible).

Using tables/charts may make info easier to interpret/understand.

In general, short sentences/paragraphs are easier to understand.

Be consistent – use same term for the same thing.

Avoid non standard speaking or usage – e.g. lead a meeting, not chair a meeting (‘chair’ has multiple meanings).

Abbreviations and acronyms are awkward for all.

Avoid unclear antecedents, e.g. ‘it’.

Don’t remove ‘that’ as it helps non native English speakers.

Avoid complex tenses, e.g. has been executing vs executed.

Avoid gerunds: e.g. specifying vs that specifies

Consider cultural issues, especially avoid humour, sports, popular culture, religion, politics, any level of profanity. Date/time and measurements.

Watch for different levels of relationships between writer and reader, e.g. ‘you’ might not be appropriate.

Watch for differing interpretations of visual cues (e.g. STOP sign is not the same shape in all countries)

Don’t assume all users can read your document using bandwidth etc. that you experience.

Use standard fonts as you can’t assume that users computer systems are similar to yours.

Techniques for maximising content reuse (Andrew Becraft)

Many different ways for doing reuse.

Biggest misconception: equating single sourcing with reuse. Reuse can flow into single sourcing but that’s not essential.

Planning for reuse: need a strategy, think about info architecture, decide level of reuse required.

How big should you chunk content? Can be too big, or too small. Should not chunk everything as too unmanageable. What if ‘OK’ chunk actually should be ‘Submit’ or ‘Apply’ in some instances?

Lack of context can mean the chunk is used in the wrong setting, or is translated incorrectly.

Focus reuse on smallest contextually meaningful unit.

Good chunks: topics, tables, figures, lists, steps, alert text.

Content snippets need to be able to be found within the authoring tool too. Organise into folders, files/objects, meaningful IDs for the file/object. Meaningful hierarchy.

Don’t rely on file/topic level reuse alone. It’s too big a level.

Don’t chunk content smaller than a paragraph.

Responsive Web design in user assistance (Tony Self)

Every website needs to be redesigned to give a good experience for those reading on small or large devices.

People on mobile devices want the full experience.

Principle is that one website can be viewed on multiple devices and in multiple orientations.

Tony provided and explained an extensive glossary of terms related to responsive Web design.

User Agent: determines what browser version is used, and whether desktop, mobile etc. Stupid to try to develop different websites for different devices as too many and too many new developments

Media Query: CSS idea beefed up in CSS3.

Viewport: size of the viewing window

Adaptive Layout: trying to solve same problem as responsive web design; uses JavaScript. Design for the least capable device

Progressive Enhancement: opposite of graceful degradation (which is design for the most capable device); progressive enhancement has a different starting point i.e. the least-capable device; relates to ‘mobile first’ approach

Mobile first + responsive web design is best combination. Uses these three principles:

  • flexible, grid-based layouts
  • flexible images and media
  • media queries.

Mobile First: design for mobile first then adapt for larger devices. Lack of space forces you to think about what’s critical info.

Breakpoints: point in the layout where the media query kicks in and the layout changes/adapts/responds. Set these based on device capability, not device itself.

Media Types: e.g. screen, TV, etc.

CSS link in HTML: Tony showed example code for this.

Chrome emulation mode: use for testing; found under Tools > Developer Tools, then open ‘drawer’ and go to Emulate tab, choose device.

Fluid images: users figure and figure caption elements in HTML5

****************

I presented a session on ‘Clear, Concise, Consistent: Reducing User Confusion’

****************

Practical HTML5/CSS3 for real writers (Dave Gash)

HTML5 is still in development and not finished, but some features are still useful and available right now.

HTML5 is a bunch of things, not one thing. Lots aren’t applicable to most content writers. Semantic structural elements are the most applicable — e.g. article, aside, nav, header, section etc. Tag names are semantic and make sense. Many can be nested how you want them to be.

Just using the tags doesn’t work – you still have to style the tags. Use CSS3. Some of the CSS3 features may include rounded corners, drop caps, etc.

HTML5 is much simpler to code. Many divs and classes can be replaced with semantic tags.

Trends in mobile user assistance (Joe Welinske)

Things are changing very fast.

Overlays for UA are quite popular in mobile apps.

How much do you need to put in literal representations of hands/devices? May diminish over time, as instructions for using the mouse has diminished/disappeared over time.

Optional tutorials leading to embedded help can be fairly effective. Just cover main issues, top one or two only.

Opportunity for us to bring what we know to the mobile app arena.

Tablets provide enough screen real estate for UA similar to desktop. But tablet apps are part of ecosystem that has grown up from phone apps, not down from desktops.

If designing for a small device, do all your writing in a space that’s no bigger than the device.

Use media queries to sniff out the device being used.

**********

See also:

 

h1

WritersUA 2014: Day 2: Wednesday 5 March

March 6, 2014

Techniques for creating UI text based on user reading patterns (Linda Lior)

Most of what users read today is inline/online, which is non linear, instructive, proactive, reactive, designed for interaction, and part of a workflow.

Think about target users and how they will use the software.

Various research methods have been used to see how users view and use a screen, such as eye tracking, mouse and keystroke tracking.

These days, eye tracking doesn’t require bulky equipment.

Eye tracking shows first glance, gaze duration, visual direction, scan patterns, and search patterns. Results: Users scan page/screen looking for key info, not reading word for word.

Mouse tracking: correlates well with eye tracking studies; use sites/apps like www.mouseflow.com for real-time tracking.

Based on research these assumptions can be made:

  • users read from top to bottom
  • F pattern
  • bottom right rarely used
  • read keywords then scan further for more information
  • read bullets more than text blocks
  • once they think they have the info they’ll move away.

Right-to-left readers do the same but in the opposite direction.

Therefore, important info should be arranged so that users can get that information as quickly as possible.

How do we apply research for creating effective info experience?

  • use top left corner for key info
  • guide user through workflow
  • make text easier to scan
  • chunk info into small bites
  • visual proximity matters….

If the process is linear, use wizards, landing pages, callouts.

User-first instructions: mobile, visual, and painless (Eric Doster, ifixit.com – repair manuals)

Business created in college dorm. Started with printed laptop repair manuals. Decided to put content online for free. Now about 8% of content is created by users.

Repair 2.0 – learn from the world, not manuals, courses; e.g. YouTube, Google, ifixit (http://www.ifixit.com/)

ifixit has a tech writing program (http://edu.ifixit.com) and a tech writing handbook (http://www.dozuki.com/tech_writing).

Tech writing fundamentals we’ve learned:

  • know the process – do it yourself before you can help others
  • be concise
  • be clear
  • be stylish
  • be targeted (know the user)
  • be visual – show how
  • be organised (outlines, lists, tasks)
  • be sensible about legal info – don’t front load with legal info, put safety info at point of danger
  • be everywhere (PDF, mobile)
  • be evolving (edit thoroughly, get feedback).

Dozuki (http://www.dozuki.com/): platform for writing instructions for ifixit, and for translation. Has mobile access.

Use gamification to gain reputation and link this to incentives (for contributors).

Process for dealing with unknowns – things for which there are no answers at the moment.

Please, don’t squeeze the layout! Let it respond (John Daigle)

Can’t keep up with browser and device explosion/wars. And other devices such as those in cars, Google Glass etc.

More and more text being dumped online without thought as to what devices they will be displayed on. Use of ‘progressive disclosure’ on small devices.

Technical and content issues – economy of content, flatten navigation, easy way to get home/previous/next, simplified search, progressive disclosure.

HTML5/CSS3 sweet spot for responsive design?

Key features of responsive Web design:

  • fluid grid (relative units such as %)
  • flexible images (relative units)
  • media queries.

RoboHelp 11 can do responsive design; can skin each output easily; and can preview output in a simulator. Can also select command verb for the output file, e.g. select, tap, click, etc. (Stored as a variable?)

Adobe Edge Inspect – application that works on wireless principle so can see effect of changes in devices at time make the change (do you still have to buy all the devices?)

Making the leap to structured authoring (Tom Magliery)

Structured authoring with XML.

Pay more attention to creating structure (still have to craft words), architecting for reuse, minimalisation, expanded style guides (some tools will enforce some of these for you).

Reviewing remains the same no matter which way you go.

Traditional authoring: authoring tool to output. XML way: authoring tool, XML mark up and style sheets, publishing system, output.
With XML, you are producing input (into the publishing process) not output.

Content management: reusable components, links, graphics, topics and maps (DITA).

New tools will be required. How much tool do you need? Feature/price trade-offs. Training/customisation costs. Content management tools will also be required at some stage; can be very expensive and take a long time to implement. Publishing system will also be required; range in capability and cost; some are hybrid environments; may be included in authoring/content management tools.

Legacy content conversion: costs can be very high whether do it internally or externally. Will need to assess what legacy content gets converted or not.

Some tools will remain the same – e.g. controlled language/terminology, translation, graphics

*********

(There were six time slots today, but for two of them none of the presentations inspired me, so I played hooky with a friend and we hung out in the pool with our friend Pina Colada for that time.)

See also:

h1

WritersUA 2014: Day 1: Tuesday 4 March

March 5, 2014

NOTE: All my conference posts are written on my tablet so formatting and typos may abound. I’ll fix them up as best I can,  but some fixes will have to wait until I get home.

Topic length and granularity (Matthew Ellison)

Key principles of John Carroll’s minimalism: modular, task based, get user up and running ASAP, make use of prior knowledge, guided exploration.

What can we learn from blogs and wikis: have set a trend for expected article length and attention span online (Tom Johnson); blog posts should be 300+ words for SEO purposes, ideally about 500 words; Wikipedia had guidance on article size – not too big or too small!

What is a topic? Chunk of info presented to the user – ‘article’ with a beginning and an end; building block /snippet that can join with others to make a complete article.

What is a topic? One idea? Supports one task? Answers a question? Shortest effective piece of communication?

Agreed definition: standalone piece of content. Self-contained cluster of chunks of info, each of which depends on the others for context, on a single theme, with an overall narrative flow. An example only makes sense in the context of the topic – it is rarely standalone.

Put hyperlinks (e.g. mini TOC) at beginning of topic (‘above the fold’) not at end – better for accessibility and screen readers. Always add related topic links and think them through – do not automate! Navigation aids help user get full scope of length of topic.

Google, Microsoft, and Adobe now call help topics ‘articles’

Trade-offs between long and short topics.

Narrative not suitable for reuse; shorter topics have more potential for reuse.

How long should a topic be? IT DEPENDS!

Intuitive UI design (Everett McKay)

Intuitive UI shouldn’t need doco or training.

Intuitive UI features:

  • Discoverable
  • Affordances
  • Predictable
  • Responsive
  • Efficient
  • Forgiving
  • Explorable.

Consistency is really important for intuitive UI (and for writing too!)

‘Users shouldn’t have to experiment to understand the interaction.’ Showed a digital shower controller? In a wet environment? I’m not sure that’s a good idea!

New Blackberry doesn’t have a back or home button. Even sales staff don’t know how to use the device once they get in a couple of layers.

Not everything has to be intuitive. Some things can be ‘strategically unintuitive’. For example, unintuitive UIs can be used for advanced, infrequent, optional commands, shortcuts. But there is a cost for these.

Levels of intuitiveness:

  • Intuitive
  • Usable
  • Unusable

User testing: Do it for the harder stuff; should find the easier stuff internally and fix first

Use streamlined cognitive walkthrough to evaluate intuitiveness of design. Always have someone not familiar with app when doing streamlined cognitive walk through

Consistency is key!

Creating audience-centric documentation using Author-It (Hamish Blunck)

Hamish used images of a snake devouring crocodile as example of consuming in small chunks suitable for audience. Clever!

Case study for audience-centric approach to doco; multiple geographic states, multiple roles.

Look at the big ticket items, and strike a balance between segmenting doco and overdoing it.

Various tools can create variants (as they are called in Author-It). Content swaps happen when you publish.

Plan for variants, decide base content, keep number of variants to a minimum to avoid confusion.

Base variant decisions on published output NOT on how you organise objects, taxonomy, metadata.

Good example of using variants for an organisation’s doco based on state and role, including SharePoint integration.

Help content for all – responsive HTML (Kevin Siegel)

This was most disappointing session of the day for me and I left after 15 mins. The speaker was fine, but the focus was entirely on RoboHelp, which I didn’t expect from the title of the session, but the worst was the demonstration that the speaker started 10 minutes into his session. The lighting in the room was very yellow (not his fault!), which made the slides look very odd, especially the grays, and the resolution was such that the fonts on the screen were very blurred and so small they could not be read, even from the 5th row where I sat. The speaker indicated at the start of the demo that the demo would take up the rest of the session, so I left as it was impossible to see what he was doing.

10 tips towards template tranquility (Bernard Aschwanden)

This was the best session I attended all day. It was fast paced and covered a lot of ground, but he offered some very practical tips for both Word and FrameMaker, a remarkable achievement in the time allotted. Everyone learned at least one thing from this session that they could implement immediately.

*********

See also:

h1

WritersUA 2014: Pre-conference workshops

March 4, 2014

NOTE: All my conference posts are written on my tablet so formatting and typos may abound. I’ll fix them up as best I can, but some fixes will have to wait until I get home.

Applying cognitive techniques to user assistance (UA) (Ray Gallon)

Agenda indicated this would be quite an academic session… deductive reasoning, Gestalt, constructionism etc.

Deduce from one task how to do another. We often forget this when creating UA.

Gestalt… Stable precepts in a noisy world. e.g. face in bathroom sink furniture (taps = eyes, spigot = nose, drain = mouth). Seeing the whole then dig into the component parts. The whole is other than the sum of its parts.

Reification: seeing something that isn’t really there as we make intuitive connections. We fill in the blank spaces to see something that’s not there.

John Carroll – we learn better if not everything is stated /there. Too much info is often overkill. By users learning themselves, they retain info better. Fine line between leaving stuff out and frustrating the user.

Gestalt grouping principles: proximity; similarity

James Gibson’s idea of affordance.

Individuals reject complexity and unfamiliarity to make sense of the noise. As they gain info, they will add complexity etc. How do we make it attractive for our users to do that?

Constructivism – learning comes from doing. Self-directed learners acquire and act on new knowledge. Do we do this for our users? Internet often gives us advanced info without the preceding knowledge, so while you get the knowledge, you are not an expert.

How do we make our UA facilitating to help the user learn what to do?

Learning is an active and SOCIAL process. We communicate with a computer as though it’s a person… We even yell at it!

We collaborate to arrive at shared understanding.

Experience is more important than taxonomy. In traditional static documentation, the product gives meaning to the docs. The doc cannot standalone without the product. For software, we can embed UA within the product. People learn best by doing and making connections to the process.

Is memorising a procedure necessary for competence?

How do we learn concepts by doing? Embed procedural UA directly into the interface; embed simple concepts directly into the UA.

‘religion of minimalism’

What happens when we learn by doing? We remember independent self-contained scripts (e.g. restaurant, airplane, clothing store) that have commonalities.

Learners who can generalise from one context to another learn better. Give users hooks that allow them to connect different bits of info. Connections = networks.

UI is communication (Everett McKay)

Seemed to be a promotion for his book (UI is Communication), at least initially and at the end. BTW, the book looked good — he passed it around for us to leaf through.

His PPT slides were very dense and he spoke very quickly so I’ll have to wait to get the PPT before I can summarise it accurately.

Had some excellent examples.

***********

See also: