I recently finished grad school and moved on to a real job at a real university, which means I’ve recently moved from having $0 of discretionary income to having approximately $10 of discretionary income each month. Through my time in grad school I survived off of the “free” tier of so many freemium products it’s not even funny. Evernote, Pocket, LastPass, Spotify, Dropbox, Github, and so many other products have the courtesy to offer me a free tier that allows me to use their services without breaking the bank. As a broke student, I appreciated and fully availed myself of those options. Now that I’m out of school, I feel a bit of an obligation to support those services that supported me so well during those lean times. Now comes the issue of cost, however. Most of these services offer a paid tier that gives a few extra bonus features. The question now comes to how much am I willing to pay. I wish I could afford to support all of the services that I love so much, but in glancing around, it’s just not possible.

The true impetus for this post comes from Pushbullet’s recent announcement of their paid tier, Pushbullet Pro. Pushbullet is one of those services I’ve been using pretty much since its creation. It allows me to push links and text back and forth between my phone and computer, and over the time it’s been around has added text messaging and universal copy-paste to its repertoire. With Pushbullet Pro, they have moved some of the previously free features into a paid tier subscription of $5/month or $40/year. Immediately outrage ensued from Pushbullet’s huge fanbase at reddit.com/r/Android and reddit.com/r/Pushbullet. Many have been crying for an opportunity to support the developers, but when the paid plan came out, most seemed to find it too expensive.

In a world of freemium and subscription services, how can a service know what to charge? Most (if not all) operate on elastic demand curves, so charging too much will lead people to seek alternatives, while charging too little may result in more paid customers, but potentially lower total revenue. I investigated the paid options for some of the services I would like to support, and here’s what I came up with:

And this is nowhere near a comprehensive list. If I were to pay for all of the services I would like to pay for, I’d be broke. And I would love to pay to support a lot of these services. However, how much I pay for each of these services and how much value each provides for me are extremely important.

This brings me to the question: how much should you charge for your service? Keeping in mind that your customers likely have a huge number of awesome sites and services with great paid options, how do you decide what price your service is worth to your customers? Here is where I believe Pushbullet made some crucial mistakes. Pushbullet hit a huge wall with their extremely loyal fanbase. Where did they go wrong? I believe Pushbullet made two big mistakes with the Pro service:

1. Removing previously free features to begin charging for them
2. Charging too much

Crippling the app

The first mistake was crippling the free version of the app in order to charge for it. Some may argue that this is necessary. Pushbullet as it existed prior to the introduction of Pro was really an amazing app that provided virtually everything its users wanted. How else would they get people to upgrade to a paid service than move certain features behind a paywall? This hit a nerve with a lot of fans.

Pushbullet isn’t the first service to begin charging for things that were once free. The New York Times has fought to find a way to charge users to read the news, on an Internet where information wants to be free. But Pushbullet hit hard because not only were they charging for something that was free, they were charging what seemed an exorbitant price for it.

Charging too much

As I mentioned before, pricing any service is difficult, especially in a space where you are really the only actor. Nobody else was providing cross-platform link-pushing, clipboard-sharing, and notification sharing the way Pushbullet does. These services were something users found valuable. But just how valuable was the issue.

When it comes to paying for services online, I believe there are two tiers: (1) the full-fledged application, and (2) the auxiliary service. Evernote, Spotify, and others like it fall into the full-fledged application category. $5-10 per month is a great price, because you use these services daily, and they perform in multiple parts of your life, or take the place of other things. Spotify takes the place of purchasing music, so paying $10/month feels like a great deal, because that’s less than the cost of buying 1 album per month. Evernote can take the place of several other premium note taking apps such as OneNote, and provides additional functionality by allowing clipping web pages and other things. So a $5/month (less, really, since you pay annually) is a fairly good price.

Other things, though, fall into more of an add-on service category. These are applications that add some functionality to things I already do. LastPass is a great example. Web browsers allow me to sync passwords already. LastPass makes that a bit more secure, and decouples it from a particular browser. Allowing me to take it mobile costs $1/month. It’s an add-on. Pocket is a service that I’m not willing to pay the premium price for. I can save pages to read later with bookmarks. I don’t need Pocket to read webpages; it just makes it more convenient. So paying $5/month is not worth it to me. PushBullet is in the same category.

I don’t need Pushbullet. I can text on my phone, or I can use Google Voice to text from my computer. I don’t need Pushbullet to share links between my phone and computer. I can use Google Keep to save a link, and it’s instantly available on any device. I don’t need Pushbullet to respond to notifications on my phone. I can open my phone for that. In short, all of Pushbullet’s functionality can be replicated with just a bit more work. So it falls into the category of an add-on or auxiliary service rather than a full-fledged application providing unique options.

In the end, pricing online services is tricky. It’s never easy to get people to pay for something that was previously free. But you have to take into consideration where your service fits into people’s lives. And how much value you are actually adding.

But here I am. I’ve got the blog deployment back up and running, and I can maybe see myself making time to write up some tutorials about things I run across. I’m working on creating a set of networking labs using Vagrant and Virtualbox, so maybe I’ll talk about some of the things I’ve learned from that. I’m sure I’ll also talk about the experience of moving from grad school to professorhood, but that’s still pretty new, so I’ll let things settle down a bit before I try to distill my thoughts.

Anyway, I’m back. I’m still alive. And moving sucks and I never want to do it again.

The article focuses on the differences in “efficiency” of LaTeX and Word when writing academic research articles. Authors Knauff and Nejasmic apparently have some sort of bone to pick with LaTeX users, because the entire article, but most especially the conclusions, have a very clear pro-Word bias. To add my voice to the article linked above, I wanted to express my frustration with a few aspects of the article that I found particularly poor.

Experimental Task

The researchers used a set of 30 minute document duplication tasks to measure efficiency between Word and LaTeX users. Experienced and novice users of LaTeX and Word were given a single page of a research article to reproduce in their preferred method, and were given 30 minutes to do so. Efficiency was measured in words typed, typographical errors, and formatting and other errors produced. The three types of task were (1) a plain text article, including a page header, (2) a shorter article with a table, and (3) a one-page article with several mathematical formulas. On both (1) and (2), Word users “outperformed” LaTeX users, while on the formula-filled page, LaTeX users redeemed themselves.

My immediate thought on reading about the task was to question how many hours of research are spent duplicating an existing document. Sure, I’ll freely admit that LaTeX is not as easy as Word when it comes to matching formatting rules. I spent several hours last spring creating a LaTeX template for the ICIS conference (here), and it was at times frustrating. Quickly and easily matching arbitrary formatting requirements is not where LaTeX shines.

But it’s also not what research is about. Matching formatting requirements for a journal is at times frustrating and time consuming, but it’s hardly what most of us think of when we think of writing a paper. Document organization, references, statistics, collaboration, version control (at least when collaborating, but even if not), and who knows what else are all much more important when creating a research paper. These (yes, even statistics with knitr) are where LaTeX and its magic shine through. I’ve written multiple times about the learning curve of LaTeX, but throughout it all I will continue to sing its praises, though maybe it’s just cognitive dissonance (more on that in a bit).

LaTeX’s big draw, and it’s main selling point to me, is that it separates the formatting of the document and the content of the document in a decent, logical way. About a year ago I was collaborating with a colleague preparing an article for submission to a conference. I’d bullied and badgered him into using LaTeX, and it was going really well. We were able to create the entire document and review it in a nice, double-spaced format. When it came time for submission, we found the conference’s LaTeX style, applied it to the document, and in about 15 seconds our entire document was reformatted to meet the requirements. We’d saved at least an hour, probably more, of battling with Word to reformat everything.

If a journal or conference provides both a LaTeX and Word template, there is absolutely no doubt in my mind that adapting an existing article to the formatting requirements would be easier in LaTeX than in Word. The benefit of the separation of content and formatting is that changing the formatting can be done independent of the content of the document.

So, in summary, the task was basically rigged (either intentionally or not) to favor Word. And it’s barely related to what writing a paper looks like.

Discussion and Conclusions

Woo-wee did the authors overreach with their conclusions. After seeing that Word users outperformed LaTeX users on the 30 minute sprint tasks, they took extensive creative liberty in extrapolating their findings. Here are the highlights:

• Because Word users outperformed LaTeX on all but the equation text, only journals that use equations should accept LaTeX formatted documents.
• LaTeX users were more satisfied about their experience creating a document, but only because they have cognitive dissonance and essentially lie to themselves about enjoying it to justify the time they have spent learning and using it.
• Tax dollars are spent supporting research, and some of those dollars pay to create LaTeX documents, and so are wasted because people aren’t using a more efficient document preparation system (i.e., Word) instead.
• Therefore, leading journals should ban LaTeX submissions in order to save researchers from themselves, and to save tax money.

Pretty strong claims for a single experiment with 40 participants. I guess the validity of their conclusions really hinges on the validity of their task as a proxy for research. I have made my opinion pretty clear: I think the experimental task stinks, is a Word-friendly, but LaTeX-nonfriendly task, and that it’s not a valid proxy for what doing research and writing a paper looks like. Given that, their conclusions are an even bigger stretch.

Suggestions for improvement

I understand that doing experiments is difficult, time consuming, and often frustrating. No experiment will perfectly mirror the real world environment it is attempting to represent. However, this paper has a few major shortcomings that prevent my recommending it for publication. The following are my suggestions for the authors:

• Find a new task. One that more closely mirrors actual research. Add in a few LaTeX-friendly items like a bibliography with a couple dozen citations. Or dealing with figures, tables, and cross-references when those things move around.
• Compare the ease of adapting an existing text to new requirements. That’s what research looks like when, say, a paper is rejected from one journal and must be submitted to a new one.
• Compare the different LaTeX tools. You mention in the article that the different tools are vastly different in capability. To quote: “Another characteristic of our study is that it is practically impossible to evaluate LaTeX without also evaluating the used editors.” You said it yourself. Do it.
• Please please please tone down your discussion section. I know it is tempting to extrapolate your findings to saving billions of dollars in wasted research time due to LaTeX, but the limitations of your current design simply don’t allow you to make those claims.

Just because, in this one task Word performs better does not mean that you can throw LaTeX out with the bath water.

• Setting Up
• Citations

Now that we’ve covered how to do create a document and how to add citations, the next major items we need to be able to put in a research manuscript are figures. First we’ll talk about differences between LaTeX and Word in how they handle figures. Then we’ll dig into how to include figures in our document.

Floats in LaTeX

When you have a desire to put a figure or table into a Word document, you throw it in. Then you keep working on the document, and all of a sudden you have a figure on a page by itself with a half-empty page before it. Or even better, the formatting of the document is completely screwed up, and you’ve got text going all over the place (these are all personal experiences). And heaven forbid you want to change a picture, or remove the table. Odds are that will break everything forever.

LaTeX handles things a bit differently. There are several ways to handle tables and figures, but the most commonly used is to place them in a “float” environment. This gives LaTeX the freedom to place them in the place it thinks is best to make your document look as clean as possible. No pain of half-empty pages, and no broken formatting. And the best part is that it places them automatically each time you compile the document. So if you add a paragraph of text above a figure, LaTeX will figure out how that affects the placement to make it look nice.

Figures in LaTeX

Hopefully that description helps you understand what LaTeX is doing when you tell it to place an image into your file. Now we’ll cover how to place an image, and some of the settings you can tweak to make it look nice.

The first thing to note is that, since LaTeX documents are stored in text, you are obviously not going to embed the image in the file. For our example, we’ll create a directory in the same directory as our .tex file and call it figs. Then we’ll point LaTeX to that directory using the following pair of commands in the preample:

\usepackage{graphicx}
\graphicspath { {figs/} }

The graphicx package gives us useful features for including graphics, and the \graphicspath command tells LaTeX where the figures are stored. You could omit the \graphicspath and just put the figures in the same directory with your .tex file, but things get cluttered that way. I find it best to keep them in a separate directory.

Now we’re all set up to add figures to our document. We just need some figures to add. LaTeX is pretty good about image formats, but I pretty much always use PNG for my figures and screenshots, so that’s what we’ll use now. For the example I’ll use this smiley face that I’ve saved to my figs folder and named smiley.png. When I want to include it in my document, I do so with the following code:

Let’s deconstruct what exactly we have here. First off, we start a figure environment. This environment is a floating environment, so it takes the arguments associated with floats. The arguments I’ve chosed to include are ht. The LaTeX wikibook page on figures has an excellent explanation of what all possible arguments are for floats. Like I mentioned above, LaTeX wants your document to look nice. To do that, it has to have some freedom in where to place your figures. These arguments tell LaTeX what your preferences are, and it does its best to accommodate those. The h argument says that you want this figure to appear approximately where you’ve placed it, if possible. t says that you would like it at the top of the page. LaTeX takes these preferences into account, but may override them if it determines it will have a negative effect on the appearance of your document. If placing it at the bottom of the page will result in a huge empty space, LaTeX won’t do it. If you want to tell LaTeX to put a document exactly where you tell it to, use the ! argument with another, such as h!.

Next we included the \centering command. This is not necessary unless you want your figures centered. I do, so I almost always include it. The next command is \includegraphics, which takes one value, the name of the image you want to include. Finally, we end the figure environment with \end{figure}.

If you compile the document, you’ll notice that the figure is ginormous. Often you will want to resize the image. If your default graphic is too large, you have several options for resizing. The first, and possibly most difficult is the scale argument, which would be used as follows:

\includegrpahics[scale=0.45]{smiley.png}

This shrinks the image to 0.45x its original size. You can also specify one dimension of the image and it will be proportionally scaled, like so:

\includegraphics[width=3in]{smiley.png}

We can even do fancy multiplication. If you want the graphic to be ½ the width of the text, just throw in:

\includegraphics[width=0.5\textwidth]{smiley.png}

This will give you a figure in your document. Of course, that’s rarely all you want to do. Good style dictates that each figure be given a caption. LaTeX provides a way to do that by including a \caption command inside the figure tags, like so:

\caption{This is our awesome smiley face}

Recompile the document and you will see that the caption has been added. If you put the \caption above the \includegraphics command, the caption will appear above the image in the document. If you put it below, it will appear below. LaTeX also numbers figures for you automatically, so if a new figure is inserted above, all subsequent figures will be renumbered appropriately.

Finally, you may also want to reference your figure in the text of your document. For this, LaTeX provides labels. These work similarly to Word’s cross-references, but they actually work and don’t break. You add a label (basically a name) to your figure like so:

\begin{figure}[ht]
  \centering
  \includegraphics[width=0.5\textwidth]{smiley.png}
  \caption{Prototype system for embodied agent condition} 
  \label{fig:agent}  % This is our new line
\end{figure}

The content of the label can be whatever you want, but I recommend using a useful name. Since you can also use labels with tables and other numbered items, you might want to include the “fig:” as part of the name as we did here. Now if you want to reference that figure in the text, you can simply use the label name to reference it. Put the following snippet into the document to see it in action:

This is me referencing Figure~\ref{fig:smile}.

The \ref automatically fills in the number of the image labeled fig:smile. That way when you add more figures or move things around, the reference in the text is always the same. I used the tilde ~ to provide a non-breaking space. This means that there will never be a line break between the word Figure and the figure number. It’s just a good idea to keep things looking nice.

So here is the complete LaTeX file demonstrating how to caption, label, reference, and resize your images:

And now you’ve got it. You have everything you need to make figures show up in your documents. It may not be as easy as adding them in Word, but it’s guaranteed to break a whole lot less often. If you want to do more, you can check out the LaTeX wiki’s guides to importing graphics and managing floats. Alternatively, leave a comment and I’d be happy to look into it. I’m always up for learning new things.

In Part 1 we covered the very basics of creating a document. With that you have basically everything you need to start writing your paper. Here’s a quick review of the basic commands:

1. \documentclass{article} is the first thing in your document, and it tells LaTeX you want to use the “article” style.
2. \title and \author give LaTeX the basic information about your paper to put in the Title area.
3. \begin{document} and \end{document} are the beginning and ending of the content of your paper. Anything before the \begin is part of the preamble.
4. \section, \subsection and \subsubsection are the commands to create section headers. That’s imporant for styling your document.

A quick reminder here: the beauty of LaTeX comes from not worrying about the formatting while you write your document. I used to think this was weird, since I have to think about it when I put in the \section or whatever other tags. But I was wrong. When you use a section tag, you are simply telling LaTeX what it is, not how it should look. The template, in this case article, takes care of the looks for you. It also makes changing the formatting of a document a much more consistent process than if you instead said “I want these 3 words to be 24pt font, bold, and with a 2 line break after.” Simply saying \section means you can change all section headers at the same time.

Citations

One of the big issues when writing a research paper is citation management. For this reason, about 150 tools exist to help researchers get through it. You can use EndNote, Mendeley, Qiqqa, Zotero, Word’s built-in (blech!), or a gajillion other citation management packages to take care of it for you. Some of them work better than others, but I have yet to find one that doesn’t break for sometimes silly reasons. Sometimes the bibliography isn’t right, sometimes citations aren’t quite right, and I have never found one that works well when collaborating with a bunch of people.

So, why not use LaTeX? As with all things LaTeX, it’s going to take a bit of work to learn, but in the long run, the payoff in terms of reduced headaches, panic attacks, and nights spent crying wondering why you can’t change the title of this article to Title Case will make it all worthwhile. So let’s get started.

Requirements

There are two basic requirements for citing papers in LaTeX: (1) a .bib file containing your references, and (2) the biblatex package. You can use other packages to do citations, but biblatex is robust, powerful, and easier to customize than the other common packages. I also recommend using the Biber program, but we can get by without that for now.

.bib File

So, the first thing you need is a .bib file that contains your references. Many programs will make this for you. For simplicity’s sake, let’s start out with Zotero. Zotero provides a relatively easy-to-use interface for creating references. It’s also free to use, and provides the ability to share libraries, which comes in handy when you’re collaborating with others. So download the Zotero program (standalone or the Firefox plugin) and create a few citations. I won’t go into detail how to do that here, but if you need help you can check out their tutorial on adding things to your Zotero library.

Once you have the citations created in Zotero, you can export them into a .bib file for use by BibLaTeX. To do this, highlight the citations you wish to export, then right-click and select “Export Items…”, select BibLaTeX from the drop-down menu, then click “OK” and select where you would like to place the file. You’ll want this file in the same directory as the .tex file we’ll create shortly. You can uncheck the boxes for Exporting Notes, Files, and Journal Abbreviations. The resulting file should look a bit like this:

Since it will mostly be automatically generated, I won’t go into too much detail on the formatting, but there are a few tips I’ve come across for making your bibliography generation as easy as possible:

1. Put article titles in Title Case. BibLaTeX can handle automatic de-captalization as required by formats like APA, but it cannot (at least that I’ve found) do capitalization for you. So make everything Title Case (initial caps) in your .bib file and you should be good to go.
2. Use {} when you need capitalization. Things like acronymns or company names in titles might get messed up when BibLaTeX is formatting a document. To force BibLaTeX to keep capitalization on a word, surround it with {}. If you notice from my example, NJ in the location of the second reference is surrounded as such {NJ}. That means that, no matter what happens, NJ will always appear as NJ, and never nj or Nj.
3. But don’t surround everything with {}. You could go crazy and surround entire titles with double-braces (Mendeley currently does this and it sucks. If you do that, the title will always be capitalized exactly as it is in your .bib file. But that means that BibLaTeX can’t automatically change the capitalization when the style requires it. For this reason, use {} only when you have to.

So now we’ve got our .bib file, and we’re ready to start citing things.

Your .tex File Preamble

So before we get to cite things in the document, we’ve got to tell LaTeX that we’re going to be doing some citations. So let’s look at what we need in the preamble.

It looks a lot like our basic preamble, with a couple small additions:

1. \usepackage[backend=bibtex,style=authoryear]{biblatex}. This tells LaTeX that we’ll be using the biblatex package to do our citations. It also tells it how we want them to be styled. As a social science researcher, I like to use author-year formats. Other options include numeric and alphabetic, if you’re into that kind of thing.
2. \addbibresource{library.bib}. This tells BibLaTeX where my references are stored. Inside the braces is the name of the .bib file we created above. As I said, this should go in the same directory as the .tex file we’re creating right now.

And that’s it. biblatex has a bunch of options to customize the way your citations and references section look, so if you want to tweak things to look just right, take a look at the biblatex documentation. Otherwise, let’s move on to how to actually cite things in our paper.

Citing Things in .tex

The most important thing to know when citing a paper from your .bib file is its cite key. That is the first string after the opening { of the reference. For example, the cite key for the first article in my .bib file is ackoff\_management\_1961. The cite key is how biblatex identifies which reference you are referring to.

Citing a paper is very simple and consistent. Biblatex offers just about every option you could need for citing, but all of them work the exact same way: \command{} with a list of cite keys inside the braces. Here are some of the commands, and what they do:

• \autocite{}. This will be your most used. This will create parenthetical citations if the style calls for it (like most author-year styles do), or include just the number if that’s what the style wants
• \textcite{}. This is another favorite. This one is used when you want the author(s)‘ name(s) in the body of your document. For example, if I wanted “Achoff (1961) said that…” in my paper, I could just used \textcite{ackoff\_management\_1961} said that.... This way if my citation style changes, the citation is always done correctly.
• \citeyear and \citeauthor can be used when you want to cite just the year or author, respectively.

There are dozens of other commands available in biblatex, but these are the most commonly used (in my experience).

At the end of your document, you probably want to print a bibliography or references section. This is done with the \printbibliography command.

So let’s look at an example, using the .bib from above as our bibliography. In this case, I’ve named it blog.bib.

You can see a couple things here that we haven’t talked about yet.

1. Multiple citations. Sometimes you need to cite a few papers at once. For that you can just use a comma to separate the cite keys. List them all in the same cite command and you’ll have them all together.
2. Leaving citations out. If you notice in my .bib file, I have a citation to a Bonini paper that does not appear anywhere in the .tex document. If a reference is not cited, it is left out of the reference section. This means that you can have one giant .bib file containing every reference to every paper you have ever seen, read, thought about, or heard of. It might make it a bit tougher to find what you’re looking for, but it won’t cause an explosion in your references section.

Well, I think that about covers it. You now have the tools you need to automatically generate a bibliography as you are writing your master works. Next time we’ll cover how to insert figures and, if you’re lucky, tables.

Continue to Part 3: Figures

Here are just a couple of the advantages of LaTeX:

1. Plain text source files. If something breaks, you only have to look through the plain text files to find and fix it. If something breaks in a Word document, you pretty much have to find an old version and then redo all your work.
2. Version control. Version control is commonly thought of for source code. Programmers use it to keep track of changes, so that if things break they have a working version to fall back on. The same thing goes for LaTeX documents. You can create versions of your document as you go along, which allows you to keep old versions around without having 65 copies of the draft in your working directory.

1. Table and Figure cross-references. Oh boy is this a great one. Word tries to do this, but inevitably when you move things around, the cross-references will break. With LaTeX you can simply use the \ref{} command to reference a table or figure by number. If the figures move around, the refs automatically update (like Word is supposed to).
2. Citation management. There are a plethora of tools available for citation management in Word. EndNote, Zotero, Mendeley, Qiqqa, and probably a million others. Many of these tools also work with LaTeX. But even more importantly, citations don’t break in LaTeX. Because it’s all in plain text, there’s nothing to break.
3. It’s just beautiful. Because LaTeX is a typesetting engine and not a word processor, it can do pretty things with your text like kerning (relevant xkcd) and figure placement in much better ways than Word.
4. Simple switching between formats. If you’ve set up your document correctly, you can switch between formats for different journals or publications extremely easily. That means that while you’re writing you can use one format, then bada-bing, bada-boom! you can transform it to a new format with the flip of a \documentclass switch. Maybe Word magicians can make it happen there, but I’ve never seen it.

And that’s just a few. Basically, LaTeX makes everything about creating a document for publication about 1.6 gazillion times better. Now, that’s not to say LaTeX is all peaches and cream. It has its downsides, too. Here are a few I’ve run into:

1. Conferences not accepting PDF. That’s a big bummer, and it pretty much means LaTeX is out. There are tools like pandoc and LaTeX2rtf to convert from LaTeX to RTF, which can then be converted to Word files, but in my experience it’s been more of a hassle than it’s worth. Too much of the formatting is lost in translation.
2. Steep learning curve. LaTeX is a typesetting engine with a lot of power. Unfortunately with that power comes a lot of extra gunk. It takes time to learn the ins and outs, and it takes some time to even get started. Once you get over the hump, you’ll wish you never had to use Word again, and you’ll wonder why you ever did. But until then, you’ll probably spend a lot of time with Google.
3. Collaborators may not want to learn. See downside #2.
4. You have to compile to see your changes in action. LaTeX is a bit funny, in that you often have compile a document 2 or 3 times to get the desired result. Each run is doing something different: finding references, converting references, fixing references, etc.

This post (and hopefully series of posts) will be designed to teach you the basics of how to use LaTeX to write an academic article. My goal is to start with the basics, then slowly build up to a full-fledged journal paper, complete with figures, tables, cross-references, citations, and anything else you might need. If you have requests, put them in the comments and I can try to address them in future posts.

Step 1: Downloading LaTeX

The first thing you will need to get is a LaTeX distribution. The most common are MiKTeX (for Windows) TeX Live (for Windows and *nix), and MacTeX (for Mac). Each of these comes with a package manager that will install packages that you need on the fly. I highly recommend you enable this option in whichever distribution you use, because it will make your work much simpler, especially when you are getting started and using a whole bunch of new packages.

Step 2: Creating your first article

Here I’ve created a .tex file containing everything you’ll need to get started. Create your own file ending in .tex, and make sure Windows isn’t automatically adding a .txt to it. You can do it in TeXworks, the MiKTeX bundled TeX editor, by pressing File –> New. I’m not sure what editor, if any, comes with TeXLive, so you’re on your own until someone comments to tell me.

The basic structure of a LaTeX document is as follows:

1. Preamble. This holds all of the package information, function definitions, and the documentclass.
   1. \documentclass{} tells LaTeX what kind of document you are creating. If you wanted to have chapters, you could use the report class. Since we are creating a basic article, we will use the article class.
   2. \title{This Is My First Document} tells LaTeX what the title of the document will be. This will be used in the \maketitle command below
   3. \author{Ryan Schuetzler} is where you’ll put your name.
2. The document environment is where the body of the document will reside. This encompasses everything between \begin{document} and \end{document}.
   1. \maketitle tells LaTeX to put the title of the document here. This is basically the header, and is defined by the documentclass
   2. \section{} \subsection{} and \subsubsection{} are the three levels of section headings available in LaTeX. They basically correspond to Heading 1, 2, and 3 in Word. If you want to go even deeper, you can use \paragraph{} and \subparagraph{}, but maybe you should first consider whether you really want to go that far down in headings.

In the document environment, paragraphs are separated by an empty line of text. You can put as many sentences as you want on one line, and LaTeX will automatically format them as a single paragraph. My preferred method, however, is to create new lines every ~80 characters. As long as they are all together, LaTeX will format them as one paragraph.

Step 3: Compile

Once you’ve created your .tex file, compile it with pdfLaTeX. I default in MiKTeX to using the pdfLaTeX+MakeIndex+BibTeX compilation, since that will usually run everything I need. Press the green button that looks like this:

Assuming that worked, you’re done! You have successfully compiled your first LaTeX article. And you have everything you need to begin creating a document of your own. Create your headers, add some text, and watch LaTeX work its magic. Don’t worry about the specifics of formatting for now. If you don’t like the section numbers, or the indentation of paragraphs, or the date in the title, that’s fine. All of that can be changed later, independent of the actual text you write. So get started!

Continue on to Part 2: Citations

That is why I love LaTeX. It has a pretty steep startup cost (in terms of time), but the benefits in longer documents or with fancier formatting are huge. I love the way a LaTeX document looks, and most importantly I love that if something is screwed up in my document, I can fix it. If something isn’t behaving how I want, I go back to the document and figure out what’s going on. I’m no longer at the mercy of Word’s formatter.

I’m currently preparing a few documents for submission to the International Conference on Information Systems (ICIS). The good folks at ICIS have allowed PDF submissions, which is unfortunately not true for some others. Unfortunately, they only provide the document specifications in a Word template. So I took this as an opportunity to expand my skills and achieve LaTeX ninja-hood. Rather than deal with Word’s template and its formatting issues, I decided to create a special document class for ICIS this year.

Currently it’s a work in progress, but it’s nearly complete. The only remaining task is to get bibtex to properly format citations. ICIS has elected to use the MISQ citation style rather than a standard style like Chicago or APA, so I’ll get to dig into the depths of bibtex to get those formatted correctly.

In the meantime, it’s a fully functioning template. Download it from Github at the link below, take it for a spin, and let me know if you run into any problems. Any bugs would just be further opportunity to learn about the details of LaTeX.

LaTeX ICIS template on Github

UPDATE: The MISQ citation format has been added. It has handled books, articles, proceedings, and collections that I’ve thrown at it. Please let me know if you find anything that breaks.

I chose Github for Windows because it’s easy to use and it’s pretty. Also, it works just as well with Bitbucket repositories as it does with Github repos. I use Bitbucket mostly because it lets me have as many private repos as I need for free. That way if I have information or stats that I don’t feel like sharing with the world just yet, I can keep them private.

As a newbie to Git myself, it was good for me to write these things down so I can understand what’s going on a little better. Also, I have never quite found a guide that explained how to actually collaborate in a way that made sense to me. Hopefully this will do the trick.

So here’s the guide. Feel free to use this for your own projects, or to introduce the git workflow to colleagues. I’ll probably add to this as I learn more and better understand common problems.

Setup

1. Download and install Github
2. Create Bitbucket account
3. Add Github SSH keys to Bitbucket account
4. Log into Bitbucket
5. Click your profile picture —> Manage account
6. From the left menu, select SSH Keys
7. Click the button to Import keys from Github
8. Clone the bitbucket repository to somewhere on your computer
9. Open the Git Shell installed by Github (or another one if you’d rather)
10. Navigate Unix-style (cd) to the directory you want the repository to be in. Actually do the directory above that. Git clone will create a directory for the repository. Don’t use the shared Dropbox folder. We don’t want multiple people committing to the same copy of the repository. That will cause problems.
11. Get the URL for the repository from Bitbucket
12. Type the command git clone repoURL [FOLDER NAME], replacing [FOLDER NAME] with the name you want to directory to have.
13. Add the repository to Github by opening the Github program and dragging the folder onto the window.
14. Boom! You now have copy of the project folder, all gitified and everything.

Editing stuff

Working with version control will be a little bit different from working with files in Dropbox or something. We’ll go into the process in depth here.

Getting started

The first step to keeping things clean and nice is to create the branch you will be working on.

1. Open Github for Windows and double-click the repository.

2. Make note of the sync status in the upper-right corner (red box). Also double-check the branch you are current on (blue box).

3. If your repository is out of date, meaning more updates have been posted to Bitbucket, you will see a blue down arrow next to the sync button. Press sync to pull down all changes.

4. It’s definitely best to not do your main work on the Master branch. This will be the definitive version, but while you’re working you can keep drafts in another branch to keep things from getting muddled if others are adding stuff. Create a branch by clicking the master button in the top right and entering the name of your branch. You can name it whatever you like, but either your name or the current feature you are working on are good names. Make it something understandable.

5. Now you’re set to work. You should have the most up-to-date stuff from the server, and your own branch to work on.

Commits while working

It is good VC practice to not only commit when you are done working, but in the middle as well. That way if you mess something up you can easily go back to where you were. Here are the steps you can take while you are working on a project.

1. Open the Github program.
2. Open the repository you are working on.
3. You will see a list of all files that have changed since you began working. Click the little arrow to the left of the filename to view the changes. Additions are highlighted in green, while deletions are highlighted in red. Changes to a line will show as the deletion of the old version and the addition of the new.
4. Select the files that you would like to commit. It’s best to combine changes that are doing the same thing to one commit, but separate unrelated changes to multiple files into several commits. \t1. If you’ve made a change you want to get rid of, you can discard the changes and revert to the last committed version of the file by right-clicking the file and choosing “Discard changes.” Be careful when doing this, as all of your changes to that file will be lost.
5. Type a commit message in the box on the left. This message should be a short description of the change, written in the imperative (e.g., “Fix bug” rather than “Fixed bug” or “Fixes bug.”
6. Type a longer description of the change in the box below if necessary. If the change can be summarized with just the commit message, that’s fine, but if you’re doing anything fancy, be sure to explain the change in the commit message.
7. If you want, you can publish your branch to Bitbucket by clicking the Publish button. You can also keep that branch to yourself if you’d rather not share. Since we’ll be merging our own changes into Master, there’s no need to push things up, but it can be helpful if you want somebody else to look at your branch.

Merging branches

Once you’ve finished changing things for this session, it’s time to merge your changes into the main branch. Since we all have access to do this in the main branch, we’ll go through how to do it here. You’ll only want to merge things that are working. If you merge changes to master that give error messages, that’s called “breaking the build,” and you owe the team lunch. Or something.

1. Make sure all your changes on your own branch have been committed or discarded.
2. Switch back to the master branch by clicking the branch button in the top right.
3. Re-sync any changes to the master branch to make sure any changes somebody else has made are synced to your computer.
4. Open the manage/merge menu from the branches menu.

1. Drag your branch to the first box in the “merge” area at the bottom.
2. Drag the master branch to the second box. master should appear in the blue box to the right.

1. Click “merge” to merge your changes.
2. Press the sync button to push your changes to the Bitbucket repository so everyone can see them.

Well, that should cover the simplest uses of git, Github, and Bitbucket. If we run into problems as the project progresses, I can update this guide as we figure out how to deal with them. This will be the first time for most of us using Git for any sort of collaboration, so it’ll be a learning adventure for all of us.

So as a new student of academia, I started looking for a good way to organize my files. Surely there must be a better system than storing random PDFs in whatever nonsensical names their publishers give them in a million places on my hard drive. That’s when I first discovered Mendeley. It was a dream come true.

Mendeley is a cross-platform software program for managing research. It can consolidate files into a single directory, manage metadata for each article, search the metadata, tag and highlight PDFs, and a whole bunch more. Additionally it can sync all that data to a BibTeX file for easy inclusion in a paper. On top of all this, it provides a cloud syncing functionality to keep your information consistent across devices.

After a few months with Mendeley I discovered Qiqqa. Qiqqa was sexy. Qiqqa was newer. Qiqqa had more features. Qiqqa could highlight with different colors. Qiqqa could OCR my documents to allow me to search ugly old PDFs. Qiqqa had neat brainstorming tools (that it turns out I never ever used). The biggest reason I switched is that I like software that is being actively developed, and Qiqqa was. Mendeley seemed to have stagnated, with no real new features in the months I’d been using it. Qiqqa had a new release every month with cool stuff that I could actually use.

But after spending almost 2 years as a Qiqqa user, I’m switching back. I was a Qiqqa Premium user for over a year, but when my premium subscription ran out, I felt it was time to move on. The interface felt too bloated. The features I loved (like multi-color highlights) were just not enough to keep me there. I also felt that in the years I’d been using it, Qiqqa had spent more time developing features I didn’t care about and added fewer and fewer things I did.

So I’m back with Mendeley now. UA has purchased a site license to give me extra storage and a few cool features. It’s still not perfect, but it’s good enough for free. In case Mendeley is listening, here are some killer features I want, in order of awesomeness:

• Get smarter about gathering metadata. I have to correct the data about 75% of the time.
• Make a Papers-esque ability to grab BibTeX keys from anywhere. Writing a paper in LaTeX and inserting citations could be seamlessly integrated with my synced BibTex file.
• Highlights should appear in the notes section
• Qiqqa’s hierarchical tags were pretty neat. The ability to drill down within a set of tagged documents is a cool feature.

So I started writing anyway. During my freshman year at BYU I had a strikingly similar experience as part of the writing class all students are required to take. We were assigned to write a narrative about some experience in our lives. With no more guidance than that, I sat a computer for a long time coming to the realization that nothing terribly interesting had ever happened to me.

So as I sat looking at the white page Word gave me, I just started writing about the assignment. I wrote about the story I started writing before realizing it was too boring. I wrote about the time I spent staring at the blank screen. I wrote about the inspiration to start writing about writing. And slowly but surely I filled the pages. That paper was the best grade I got in that class. I have my doubts that this will be the best blog post I ever write. I really hope not.

I learned something about myself that day. I learned that I really can’t stand a blank page. I’ve found the same over and over again with writing conference papers. Starting from scratch sucks. Getting those first few paragraphs written down is important for me, as it makes the whole experience seem less daunting.

Considering I restarted this blogging effort 3 days ago and I’m already struggling, I know this is going to be hard. But I also know it will be worth it.

Imagine you are the driver of a trolley that has gone out of control. Ahead of you is a split in the tracks, and you can send your trolley careening down either path. Down one path is a group of people crossing the track. Down the other is one man. You know that whichever path you choose, the people on the track will die. Which way should you go?

Clearly the answer is to go down the path with only one person. It is obviously better that only one person should die rather than five. Of course, it is through no fault of his that he will die. Wrong place, wrong time. That is all.

Of course, that isn’t much of an ethical dilemma. But what happens when we change the situation just a bit?

Imagine you are no longer the driver, but a bystander watching a runaway trolley careen down the tracks. You see it is heading for a group of five people who cannot get out of the way in time. They will die. You also see that there is a split in the path, and down the other path is only one man. You notice you are standing next to the switch. If you flip the switch, the trolley will change tracks and kill the one instead of the five. Should you flip the switch?

This one gets just a little bit harder? Again, it seems like the best choice would be to flip the switch, but it is not as easy a choice as in the first situation. But it really gets hairy when:

Imagine you are standing on a footbridge overlooking the trolley tracks. You see the train is out of control and going to kill the five people ahead of it on the tracks. Standing next to you is a rather large man wearing a huge camping backpack. By pushing this man onto the tracks, you could stop the train, thus saving the lives of the five innocent people who are on the track. Do you push the man onto the track?

BaBAM! What now? What is it about this change in the situation that has changed so drastically the way we think about the problem. In all three cases the choice seems simple: one life, or five? In any case the people who would die are innocent of any crime. They all just happen to be in the wrong place at the wrong time. In each case, some death was inevitable. So what makes them different?

This is a common ethical dilemma that we discussed recently in one of my courses. Let me know what you think. And of course, if you feel like learning more about the Trolley Problem, Wikipedia is a great place to start.

The same is true of my blog posts, and so I never wrote them. I'd have a half-baked idea for a post that was magically transformed into an eloquent, powerful, and moving post that would influence the lives of millions. Yeah, that's not gonna happen. But that's what my mind would do. So rather than be a mediocre blogger in real life, I was more content (but not really) to be inspirational in my head.

No longer. This blog post is one of my first on my journey to accept my imperfect real self. It isn't everything I imagined it would be in my head. It will probably be read by fewer than three people. But it is something I have written, and now it exists in the real world.

To quote Teddy Roosevelt:

It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat.

Inspired by recent posts on zenhabits.net and Svbtle, I've set a goal for myself to write every day. I have no doubt that this will be a challenging expedition, but a rewarding one. Not everything I post will be published here. Some of it I'm sure will be unfit to publish. Some days I'll spend my writing time working on research papers or proposals. But I really do hope that I can become a better writer simply by doing it more often.

So wish me luck as I begin this new journey. If you like, feel free to follow me on Lift.

After reading several articles about it from Lifehacker, and hearing recommendations from one of my friends here, I finally broke down and bought a digital copy of Getting Things Done This book and the GTD system have allowed me for the first time since I arrived at the University of Arizona to feel like I know what I need to get done and to have a plan to get there. I know, of course, that there is never really "done" in the life of an academic. Of course, there's not really "done" in any life. There are always more things to take on, more projects to complete.

I have tried to do lists in the past. I've been through many. I've tried productivity systems like Pomodoro, but to no avail. They helped me work, but I never really had a clear sense of what ****

Take the evernoteadd.bat script and place it anywhere you want. Replace my "_INBOX" with whatever default folder you want these notes to go to. Then simply create a Launchy action in Runner with this batch file as the program, and "$$" "$$" as the arguments. To create a new note from Launchy, type the name of the action you created, hit TAB, type the title of the note TAB text of the note RETURN.

Download the script

UPDATE: Thanks to StackOverflow, I figured out a way to make the script work without a temp file. I’ve updated the script accordingly

Enter focus@will, my favorite website for providing non-distracting music for reading, writing, and ‘rithmetic (or programming). Focus@will was created by a group of researchers at UCLA and designed specifically to help listeners achieve maximum productivity. The playlists created are designed around 100 minute cycles, shown to be the most productive way to organize work.

The biggest advantage focus@will has over competitors like Pandora and Spotify is that it has been designed to require little to no user input. Preselected categories of music are available, and that’s it. If you hear a song that’s too distracting just skip it and you’ll never hear it again. I had to do this with Stuff We Did from Pixar’s Up. Very good song, but I ended up thinking more about the song than the work, so it had to go. Also, at least for now, there are no ads.

If focus@will doesn’t fit your taste, you can also try musicForProgramming();. I found their tracks just a bit too distracting, but for others it might just fit the bill.

What do you listen to while you work?

In his article about blogging on Google+, Mike makes some really great points. It is very easy to share, connect, comment, and just generally interact with people on G+. Unfortunately, it's not (yet) designed to be a blogging platform.

The biggest limitation I felt when using Google+ as a blog is the inability to have true hyperlinks. Sure, you can have a bunch of links in a post, but URLs are ugly. Nobody wants to see the full URL of an Android application, or even of another Google+ post. So when composing a post, it is limited to the one link that G+ turns into a prettified link at the bottom.

Another issue I have with G+ blogging is the lack of permanence. I use my blog as a way to record things I learn, and hopefully to help others who may run into similar problems that I have. With Google+, I feel like anything older than the past 5 posts disappears. I know it's still there, but there's no easy way for me to get to it. A regular old blog lets me have tags, categories, and an archive. All things that I find useful for organizing my stored knowledge.

So, here I am back on Wordpress giving blogging another try. Maybe I'll stick with it, and maybe I won't. But I have given Google+ a fair shake, and it just didn't work out. At least not yet.

When I started to use my Android phone more, I looked for a podcast app that could match my favorite feature of Downcast: a priority playlist. After trying Pocket Casts, DoggCatcher, and Podkicker, I finally tried BeyondPod. And it nailed it!

For regular podcast listeners who don’t know what a priority playlist is, boy are you missing out. I’ll use my own example to illustrate what a beautiful thing this can be. Here goes:

The beauty of a smart playlist

I listen to 4 podcasts: (1) Wait Wait, Don’t Tell Me, (2) Car Talk, (3) Freakonomics, and (4) Stuff You Should Know. The first three come out with one episode per week. Stuff You Should Know (SYSK) has an archive of about 500 episodes, and I’ve listened to about 100 of them. I’m slowly working my way through the list. So my ideal listening scenario is to listen to new episodes from (1), (2), and (3), and then fill in the rest of my time with SYSK.

A smart playlist in BeyondPod will let me set this up automagically. When a new episode of any of my first three podcasts shows up, it is automatically downloaded and put at the top of the playlist. Once played, the episdode is removed from the playlist and deleted. For SYSK, I can tell BeyondPod that I want to listen to the 10 oldest, un”read” episodes. Each night, BP goes out and downloads enough episodes to fill my playlist.

It is truly a beautiful thing. I can configure the podcast playlist to automatically be created just how I want it. I haven’t actually opened the app in weeks because all of these things are taken care of by magic.

The best part is that the app comes with a free one week trial of the fully-functioning application. If you decide it doesn’t work for you, no loss. But if you do try it, I highly recommend you take the time to configure SmartPlay to fit your needs. You may, as I did, find that BeyondPod is perfect.

The beauty of Pocket is that it’s everywhere. The Chrome extension lets you click a button in the browser and save a page to read later. The Android (or iOS) app lets you save articles from Twitter, the web browser, or a million other apps. It keeps all your saved articles in a queue that you can read either in the app or on the website.

Another beauty of Pocket that beats the heck out of bookmarks is the Archive. I have a record of all the articles that I have saved to read, but it’s kept neatly out of sight. It also lets me tag articles so they can be all organized and stuff. I don’t use that feature much, but I can see how it would be useful.

So pretty much, if you are the kind of person who reads a lot of stories and articles online, look into Pocket. It’s the awesomesauce.

Enter f.lux, a software program designed to tone down the brightness of your computer at night. By changing the color contrast on your computer screen at night, f.lux helps your brain recognize that it is, in fact, nighttime. It does this by toning down the blue light emitted by the screen. This gives everything a slightly yellowish tone, similar to an incandescent lightbulb. The trick is that the blue light is secretly telling your brain it is still time to be awake. By toning that down, you will be more likely to follow a natural circadian rhythm.

The only time I really notice the color difference is when I am using my computer at sunset or sunrise when the color changes. I have f.lux to change the color in 20 seconds, which results in a pretty sudden change. There is an option to make the change a much more gradual 60 minutes. Once the change has been made, though, I rarely think about it. Sometimes I even notice the change and turn it off, only to turn it back on because I realize how glaring the bright white of the screen is.

F.lux is free for Windows, Mac, Linux, and for jailbroken iDevices. Download it now.