hit counter

I'm currently working on a DPhil in HCT at the University of Sussex. This section of the website is for an on-going 'learning diary', for me to write my thoughts and notes on various courses and my thesis.

Entries in thesis (2)

Monday
Feb182013

Thesis tech 2 - BibTeX

I'm already pretty comfortable with the workflow I outlined in Thesis tech, so the next step was looking at how to reference. LaTeX and BibTeX obviously play well together, but I've been using Mendeley to store all of my references. At this stage I don't really want to swap and use BibTeX, plus the import features on Mendeley are really handy. 

Fortunately for me, Mendeley will actually export to BibTex, creating a different .bib file for each collection in my stash! This handy post on the Mendeley blog told me all I needed to know, sort of. Sadly when I looked the pictures were down, so I couldn't follow step by step. The only small problem is that you can't seem to control which collections are exported. But that's tiny. So I've created a Mendeley collection called "bib" (because that was the name of the file in the template, it's as good as any!). Anything I want to cite will get added to that collection, and the exported bib file gets updated. 

What I'm doing is exporting them to a separate folder, then copying my bib.bib file (heh, silly name) into one happy thesis folder. I figure there is slightly less chance of accidentally overwriting them then. 

The next challenge was how to actually reference them in my LaTeX document. This seems to be slightly more convoluted. Fortunately, this post from CUED (blast from my past!) gave me nice simple instructions. Being on a mac makes running BibTeX as easy as opening up a terminal and typing "bibtex {filename}". 

It has added to the number of lines in my included files that I need to comment in and out if I want to compile a chapter separately. I'm up to 6 lines now:

\documentclass[a4paper,11pt]{report}
\usepackage{natbib}
\bibliographystyle{apalike}
\begin{document}

My text goes here

\bibliography{bib}
\end{document}

That's still not too painful.

I still have tables and figures to sort out, so I'll update as I sort those (however I do that!). For now though, this approach is still working for me.

Monday
Feb042013

Thesis tech

I started trying to write my thesis.

That sounds pretty big and scary right there, especially as I only have half my data at the moment. Still, half my data means I can write a good chunk of thesis, and there's no time like the present to get going.

This means that I sat down and thought about what tech I want to use, given my "writing process" (ha!). I know I like to have a choice of writing locations, and I like using IAWriter on my iPad. I know I don't particularly get on with Scrivener (still not entirely sure why, I think it's the formatting difficulties as much as anything else). I also know I don't want to work on one looooooooong document. I want to be able to send individual chapters to my supervisor, and deal with the responses in a single place (again, I had problems doing this with Scrivener). I also know that my supervisor likes to read and comment on PDFs on her iPad.

What I've finally hit upon is the following: 

  • I'm going old skool, and learning LaTeX. I'm used to HTML and CSS, how hard can this markup be? (Actually, as I've started already "not very" seems to be the answer.)
  • I have an unofficial LaTeX template, and I'm creating separate tex files for each chapter. I add a start and end bit to each document that I can comment out when I want to compile the entire thesis, or leave in to compile each chapter. It's 3 lines.
  • I'm sticking that in a Dropbox folder. Instant backup, plus easy access in IAWriter.
  • And in GoodReader, so when I've compiled on my desktop I can instantly get access to the finished PDF on my iPad to show someone, or email it on if needs be.

This seems to be working for me so far (although granted I'm only 3 pages in). It separates out the writing from the look - I can stick in the markup knowing that it will look ok eventually, and it's semantic enough for me to read it in text form. Equally, reading back and editing seems to be best done from a compiled version. I'm a programmer, I'm used to that kind of set up.

I was sort of thinking I'd wind up testing this on one of the main sections, having seen advice to leave the intro and conclusion to the end. But my supervisor actually suggested starting with the intro, because that kind of sets the framework for what you're doing throughout. You can always go back and edit if your analysis doesn't match. The conclusion should end up mirroring the intro, apparently. We'll see when I get there! I don't imagine for a minute that the rest will be done in order.

Today I used my setup to write up until a meeting with my supervisor, take the latest version in to talk about, get feedback and go back to writing on my desktop almost seamlessly. Fingers crossed it continues to be (technologically speaking) that straightforward throughout!