Thursday, January 17, 2013

(Getting the Nexus 10)

Usually I blog about reading and writing, but occasionally I talk about tech. Today's tech topic is something that I actually did not want to buy: a tablet.

I've long resisted buying a tablet for myself. Tablets occupy a space between laptops (such as my Macbook Air) and smartphones (such as my Galaxy Nexus), and frankly, I didn't think that space was big enough to fill. The biggest reason would be to read Kindle books and PDFs, and I had something that would do that: A Kindle Touch (which I similarly resented when I bought it).

In fact, I like my Kindle Touch very much. No, I can't practically surf the Web on it, nor can I easily listen to music, nor can I watch movies. But I don't particularly care to do any of these things in a tablet form factor. I can read, and the e-ink screen is great for that function. Battery life lasts forever. And it's portable.

But the Kindle Touch is too small. I can read some PDFs on it, but not all, because the screen doesn't have enough real estate. I can't mark up PDFs. And the larger Kindle, the Kindle DX, is no longer sold. As I faced the prospect of spring classes with heavy PDF readings, as well as the prospect of traveling with either printed PDFs or PDFs on the Kindle that I could barely decipher, I sighed and decided that I had to buy a tablet.

Which one? The iPad was an obvious choice, and I'm quite familiar with it. I just don't like it. I don't like iOS.

So I made the hard decision to buy the Nexus 10. Not the Nexus 7, which is a good deal cheaper and more portable—I didn't think it would be big enough to display some PDFs—but the 10, which is roughly the size of the iPad. And once I bought it, I decided to use it for everything I could, not because I particularly wanted to, but because I wanted to get as much out of it as I could.

So here's the results:

  • The tablet is indeed good for reading and marking up PDFs. In fact, I now store my PDF library on Google Drive, so I can use the Drive app to find a PDF and touch it to bring it up. If I want to mark up a PDF, though, I have to save it locally.
  • In fact, Google Drive turns out to be very good on the tablet. I can make spot changes to documents without much trouble, and I can download them to the tablet for offline reading (but not editing). Drive has really improved the commenting function too.
  • The tablet's just okay for reading Kindle books, but I got tired of the glare and the big screen isn't an advantage; I prefer the Kindle Touch for this application. 
  • On the other hand, it's very good for scanned Google Play Books. For instance, I read Franz Boas' The Mind of Primitive Man (free from Google Play), a book I had been meaning to finish for a while. Annotations are easy.
  • Instagram pictures are way too big on the tablet.
  • The big winners are Google Calendar and Astrid (the to-do app where I currently manage my projects). I've managed both via my phone and laptop, but the tablet combines the advantages of both: a more portable form factor than the laptop, but a bigger screen than the phone. 
  • Web surfing and email are fine, but suffer from the current limitations of the mobile platform. I find myself turning to the phone first for light use.
  • Presentations would be a great application, but the tablet's video out is a micro HDMI, which doesn't seem to play well with VGA. If I can resolve this problem, I'll probably leave my laptop at home when I travel in March—not only is the tablet lighter, it doesn't need to be pulled out of the luggage when I go through security.
  • The tablet is okay for bringing up documents in meetings. But I have not tried to take notes on it; the screen can't accommodate fast enough typing.
Overall? I really resent having to have another screen in my life. But I do see definite applications for the tablet in my tech ecosystem, especially for travel. YMMV.

Wednesday, January 16, 2013

Writing :: Topsight

Spinuzzi, C. (2012). Topsight: A guide to studying, diagnosing, and fixing information flow in organizations. Austin: CreateSpace.

This is the seventh post in my series on writing documents, but it's also another entry on how I wrote and published Topsight. But the main focus is going to be on the writing process.

I've been kicking around the idea of writing a methodology book for a while. In fact, I've been teaching graduate and undergraduate versions of a field methods course since 2001, when I taught a graduate-level course on user-centered design at Texas Tech. Early on, I used Beyer and Holtzblatt's excellent book Contextual Design—even though I didn't agree with some of their recommendations, they did really groundbreaking work in terms of making field methods understandable to lay readers. 

Later, I started using my own Tracing Genres through Organizations in undergraduate classes, although I had to supplement it heavily with lectures and additional texts to make it usable. In particular, I had begun stringing together analytical constructs that had developed after TGTO, such as sociotechnical graphs, and I had to use lectures and extra texts to wedge these into a larger system of analysis. 

The other problem with TGTO is that although it's about methodology, it's not an introductory text; it doesn't teach students how to design a study, discuss research ethics, or describe the tips and tricks that I have developed for eliciting responses or getting people to buy into the study. In fact, few methodology books do this. And that's too bad! I've been conducting field studies since 1997, and in the process I have discovered several ways to ruin studies. I could tell students about these wrong moves in class, but I lacked a text to help them with pitching and conducting a field study—and I began to realize that most methodology books didn't go very far in this direction.

In the meantime, I began conducting some seminars on field methods along with longtime research partners Bill Hart-Davidson and Mark Zachry, as well as a solo seminar early this summer. At the end of the solo seminar, I came away convinced that I needed to write a book that would address all the issues above. This book, I realized, should
  • be written in a clear, engaging style
  • use common-sense, concrete examples and analogies
  • take people step-by-step through the process of designing, conducting, and analyzing a study—and turning it into concrete recommendations
  • provide clear terms and figures
The last point—"provide clear terms and figures"—was especially pressing. I was using unwieldy terms such as "Contradiction-Discoordination-Breakdown Tables," then shortening them with three-letter acronyms: CDBs, STGs, GEMs, CEMs, ASDs, ANDs, OTs. And my figures were done by hand in Google Draw. These confused people. And I didn't want them to be confused. So I had to develop clearer terms and figures.

As I've discussed, I decided to publish this book myself—a big decision, but one that allowed me to retain control over the book. That meant that I could set my own conversational style, using the contractions and Scooby Doo and Simpsons references that give the book its friendly tone (and that would likely be scrubbed out by an editor). I took full advantage of this freedom to create a methodology book that I would want to read and that I thought readers (from undergraduates to grad students to consultants) would enjoy. 

Writing in this style was hard at first; I had to keep pretending I was blogging so that I wouldn't drop parenthetical citations everywhere.

This decision also meant that I could work on an accelerated timetable. I worked on the manuscript part-time from July to November, using my existing materials as a starting point and soliciting feedback on the finished manuscript from people who were familiar with the methodology. That feedback loop was critical: self-publishing can mean posting work without review, but I knew it was critical to get knowledgeable people to tell me where I had gone wrong. They did, and they ended up changing the book for the better. 

The rest of the time, from November to yesterday, was production work. 

Perhaps it's because the production cycle was so short, but I am still excited about the book. I keep turning to different pages and getting excited about the information I was able to provide, information that I rarely see in other methodology books. Information such as 
  • how to introduce yourself to participants—and how to gently correct mischaracterizations of your study
  • how to put together an elevator pitch for your study
  • how to design a study at macro, meso, and micro levels, collecting both etic and emic data
  • how to systematically develop representations of the data, including activity systems and activity networks
  • how to write an interim report and a recommendation report based on the study
So: this writing route allowed me a lot of freedom. I wouldn't choose this route for every book—in fact, I'll soon be looking for a publisher for my next book project—but it was certainly worth doing, and it certainly resulted in a different writing experience from the others I've discussed in this series.

Tuesday, January 15, 2013

Topsight > Go buy my book!

I'm excited to announce that Topsight is available for purchase!

Currently you can buy one of two different versions:

Wow, that means that you can buy both the printed and the Kindle version for less than the list price of Tracing Genres through Organizations. Which you really should also buy. 

When the printed version propagates to, I'll update my Amazon author page. Until then, follow the links. And let me know what you think!

Monday, January 14, 2013

Topsight > The publishing process

It seems like forever since I first announced that I was planning to publish Topsight. But I get my final proof from Amazon CreateSpace in the mail tomorrow, and I've viewed a draft of the Kindle Direct Publishing version already. So I'm hoping that I can pull the trigger midweek—and I'll announce it here when I do.

While we wait, here's some observations about the self-publishing process. I've already talked about why I decided to self-publish this book; here, I'll talk about what the process looks like.

The printed book: Amazon CreateSpace
I chose to use Amazon CreateSpace (ACS) because Amazon has a great distribution network, because I already have an author page, and because self-publishing is simple there. ACS is a print-on-demand platform, which means that each book is individually printed. That means higher per-book printing costs, but I don't have to worry about volume; extra copies won't be sitting in warehouses waiting to be pulped.

ACS prints the book, but technically, I'm the publisher. That means that Amazon takes a percentage of each sale for printing and distribution, and I get the rest. In practical terms, I can set my own royalties. (But I'm setting the price fairly low so that everyone can enjoy Topsight.)

In practical terms, I supply ACS with two files:

  • A cover PDF
  • An interior PDF
ACS supplies Word templates for the interior, and also supplies design services for an extra fee. However, I opted to hire a graphic designer, copyeditor, and production person out of my own pocket to produce the print-ready PDF. I also rented Adobe InDesign (about $99 a month) to implement final changes by hand. These costs added up.

The designer and production person also developed the cover. ACS provides a specific formula for calculating the width of the spine, based on the paper you choose. 

The range of choices and services is impressive here. You can choose book formats as small as 5"x4" (the size I chose) or select a custom size; you can hire Amazon to design the cover and interior or do it yourself; you can use their Word templates. You can even hire them to do copyediting.

Once the PDFs were ready, I uploaded them and ACS automagically identified potential PDF errors. The cover went though fine, but I had to correct several errors involving headers and text that ran slightly into the margins. Each error was highlighted in the online view—I was impressed with how thoroughly error checking was handled and how easy it was to understand the errors.

After a few tries, I generated an error-free PDF and proceeded to the next step: a human being checked the document. It took less than 24 hours. 

At that point, I had the option to order a proof or just launch the thing. Although I was impatient, I ordered the proof (about $5) and paid a premium (about $25) to deliver it as soon as possible (5 days).

While awaiting the proof, I was guided through the pricing process. ACS gives several options here too, each of which might involve extra fees or affect royalties. Despite the extra cost, I opted for expanded distribution channels so that libraries and bookstores could order it ($25) and also opted to allow printing in different countries (a royalty fee). 

Once that was done, I was guided to Kindle Direct Publishing for the option of creating a Kindle book.

The Kindle book: Kindle Direct Publishing
Clicking a button transfers the cover and interior PDFs and metadata to Kindle Direct Publishing (KDP). KDP is a different animal. For one thing, you have different, more simplified formatting options. For another, you can't use the same ISBN (and you don't need an ISBN at all.) Third, distribution channels are more flexible because you're not moving paper around, just bits.

Two of these are headaches.

First, the formatting. Kindle books are modified, simplified HTML. That means that an InDesign file doesn't translate directly to Kindle. The easiest thing is to build a Word file, then convert it. In fact, if you read Kindle publishing guides, they claim that you have to convert the final version to HTML; fortunately this is no longer the case.

To handle the conversion, I did the following:
  1. Went into InDesign's Story Editor, copied the body, and pasted it into a Word file.
  2. Went into the Story Editor again to copy the front matter, then pasted it into the same Word file.
  3. Went through the entire InDesign document, identified all materials outside the main story (tables and figures), copied them into Preview, saved them as JPEGs (per the Kindle publishing guide), then placed them each into the Word file.
  4. Reformatted as appropriate, including deleting page numbers from the Table of Contents, List of Tables, and List of Figures.
  5. Discovered that the procedure for autogenerating TOC hyperlinks doesn't work on Word for Macintosh.
  6. Deleted all but the first level of the TOC, then hyperlinked these by hand.
I then uploaded the Word file to KDP. Within minutes, it gave me a preview on a simulated Kindle Fire screen. (You can switch orientation or simulate a Kindle HD, second-generation Kindle, Kindle Paperwhite, iPad, or iPhone screen.) I also downloaded a Kindle version to view on my Kindle and my Nexus 10. 

I'm glad I did, since I found some conversion errors. For instance, I discovered that I had to save the graphics at a higher resolution and set them to the proper size. On the whole, though, the process was tedious rather than challenging; I probably spent about six hours on the conversion.

It's worth noting that if I had used the ACS Word template, the conversion would have probably been even less painful. If I do this again, I'll probably go that route.

Once I was satisfied with the Kindle version, I was given the option to take 35% royalties (which would allow me to set any price) or 70% royalties (which limited me to charging $9.99 and was available only in some countries.) I tried various configurations, then set a price.

I'm also not entirely happy with how graphics render in the Kindle version, so I've made some of the graphics available from the book's website; I'll likely add more as I go.

Lessons learned
I'm really impressed with how easy it is to publish in both ACS and KDP. It's not for the faint of heart, and it involves more detail work than I like to do, but it has allowed me to turn out a book at relatively low cost, quickly, while retaining creative control. And that's been tremendously exciting.

What would I do differently next time? I would consider developing the PDF using one of the existing Word templates rather than InDesign. That's not because the product would look better—I think it wouldn't—but it would be quicker, easier, and cheaper to produce, as well as being easier to convert.

Overall, though, I'm very happy with the experience. Looking forward to seeing the proof.