Microsoft Office now available for Android tablets

January 30th, 2015

Microsoft Office is now available for Android tablets, if you have a 7″ tablet or larger that’s running Android KitKat (4.4.x). You’ll need an Office 365 subscription to use all features. If you don’t have one, you can do basic editing for personal use.

I can’t test it myself as my 3-year-old Samsung Galaxy tablet is only running Android 4.0 and I don’t expect it will be updated any time soon, if at all. But from the teaser video on the Office Blog page, it looks like they got most of the core functionality working and with a touch interface.

We designed these apps to be unmistakably Office, while optimized for Android tablets. Customers will immediately feel familiar with the Office ribbon. Large touch points make it easy for even the fattest of fingers to navigate commands. External keyboards can be connected but certainly aren’t needed. Existing documents open and render beautifully and are accessible instantly from device to device via a roaming “most recently used” file list.

Within each app, we’ve prioritized the most important features for mobile scenarios. Word documents look beautiful, with text, images, footnotes, tables and charts all nicely formatted. You can review documents by tracking changes and adding comments, and then easily share your work. Excel spreadsheets bring raw data to life with support for formulas, charts, tables, PivotTables, sorting, filtering and comments. PowerPoint presentations look stunning when your ideas are expressed with full support for rich formatting and embedded video, transitions and animations. There’s even a handy format painter tool, built especially for touch.

Moving away from DITA

January 29th, 2015

If you’ve been reading this blog for a while, you probably know that I’ve been dabbling with DITA for some time. However, I’ve never seriously tried to adopt it for a project at work, simply because the setup and conversion effort is to great for me to attempt with the limited resources I have at hand (me and one other writer). I like the idea of DITA, topic types and structured authoring, and I’ve adopted some of the techniques for my projects, but I’m still using unstructured FrameMaker, Microsoft Word, and WebWorks ePublisher for most of my work.

in 10 reasons for moving away from DITA, Tom Johnson explains why he’s moving away from DITA after adopting it for his work. While DITA has a lot of good points, and he does describe them in the first part of his post, it isn’t a solution for everyone, and particularly not for API documentation, which is his major focus now.

One of the areas I’m focusing on is API documentation. Very few development shops have a DITA XML setup, in part because developers are involved in contributing, reviewing, and publishing the documentation that supports their APIs, SDKs, and other tools. Trying to shoehorn DITA into an API software shop is like trying to fit a size 6 shoe onto a professional basketball player’s foot — it simply doesn’t fit.
In my case, the biggest strike against DITA after the complexity of getting a DITA publishing workflow set up, is that it doesn’t integrate well with other systems. I have to work with a lot of content supplied by BAs, QA, and developers, and there’s no way they are ever going to adopt DITA. I have enough trouble getting people to use my templates.
A workflow using markdown and web-based tools seems much more realistic.

DITA 1.3 Overview

January 28th, 2015

Scriptorium has published an overview of what’s new in DITA 1.3. I haven’t been keeping up with DITA news recently so I don’t know if DITA 1.3 has officially been released. For me, the most interesting thing is the new troubleshooting topic type – it might offer a way of imposing order on the chaos of error messages and alerts that I have to document.

The new troubleshooting topic type is a specialization of the task topic type intended for troubleshooting steps, and consists of <condition>, <cause>, and <remedy> elements. You can use multiple cause/remedy pairs to provide a series of corrective actions for conditions that can have multiple causes.

The optional <tasktroubleshooting> and <steptroubleshooting> elements and trouble admonition type are used to provide quick, embedded troubleshooting within a topic. The DITA 1.3 specification recommends that these elements contain a condition, cause, and remedy.

Transferring ODT files between programs

January 27th, 2015

TechRepublic looks at how well OpenOffice ODF files transfer between Google Docs and Microsoft Word. As you might expect, there are issues, although nothing that couldn’t quickly be cleaned up, at least for short documents.

Fortunately, Google re-enabled support for ODF in December 2014. That means you can leverage the collaborative capabilities of Google Docs, Sheets, and Slides, then export your completed work to a file in an open, non-proprietary format.

The ideal document would be a file that works — and looks — the same in all applications. I tested how well an ODF file transfers information between Google Docs and Microsoft Word Online.

Spoiler alert: On balance, both Google Docs and Word Online handle ODT files reasonably well.

Unexpected Uses for Conditional Text

January 26th, 2015

I use conditional text a lot in my documents, both in FrameMaker, which has had the feature built in since its inception, and in Word, with aid of SmartDocs or WebWorks ePublisher. There are obvious reasons for using conditional text; for example, creating multiple documents that apply to different versions of a product. Less obvious ones include putting notes in a document about content that might need special attention; for example, something that might need to be reviewed by a specific developer before inclusion.

In Unexpected Uses for Conditional Text, Matt Mayerchak explores the use of conditional text in Adobe InDesign. While the illustrations in the article are specific to InDesign, the techniques he talks about are generally applicable to using conditional test in other programs.

nDesign’s conditional text feature is great for creating multiple versions of text, such as different languages, or switching between US and European prices in a catalog. But even if you don’t create documents that are released as multiple versions, there are other ways that conditional text can be very useful during production.

If you’ve ever had a filename like “2014_Catalog.FINAL.FINAL.FINAL_r3a_mm_cb_11.13.15.indd”, you actually DO work on multi-version documents. And conditional text can be very handy during the early stages of a project for inserting production notes into the text. You can place them right where you want them in the flowing text, make them stand out so they are easily spotted, and best of all, you can click one button to turn them all off and work on the layout as if they weren’t there. Here are a couple unexpected uses for Conditional Text.

My phone is now a slide rule

January 25th, 2015

Earlier this week I was thinking about all the different things my Samsung smart phone could do. Not counting pure Internet applications like IMDB or Cineplex, I came up with about thirty. Now I can add another one to the list – my phone is now a slide rule.

Slide Rule

A slide rule? What’s that, some of my younger readers may be asking. Wikipedia has a good, detailed explanation:

The slide rule, also known colloquially in the United States as a slipstick,[1] is a mechanical analog computer.[2][3][4][5][6] The slide rule is used primarily for multiplication and division, and also for functions such as roots, logarithms and trigonometry, but is not normally used for addition or subtraction. Though similar in name and appearance to a standard ruler, the slide rule is not ordinarily used for measuring length or drawing straight lines.

Slide rules come in a diverse range of styles and generally appear in a linear or circular form with a standardized set of markings (scales) essential to performing mathematical computations. Slide rules manufactured for specialized fields such as aviation or finance typically feature additional scales that aid in calculations common to those fields.

I took university math and physics courses before electronic calculators became a household item. We used slide rules for all our calculations to an accuracy of one decimal place. For anything that required more accuracy, we used one of the new and expensive desktop electronic calculators ($3.000 for a machine that had less power than a  modern $20 scientific calculator) or wrote a Fortran program and gave it to the guys in the glass room.

I really don’t need a slide rule; I have a couple of perfectly good and powerful scientific calculator apps on my phone. But it is cool to play with. And for quick estimations, a slide rule can be faster than an electronic calculator, especially one with a lot of buttons and little legends that nearsighted eyes can’t read.