This is a blank open lab notebook, ready to be filled with your great science. Below, I'll guide you through what you need to do to get it up and running.
The general file structure may seem intimidating, but I assure you it's pretty straight-forward. Below, I provide a general idea about the purpose of each folder
Contains the html layouts that determine where your content goes. You most likely won't have to touch these, unless you want your lab notebook to exist as your personal site (you.github.io) instead of as a project page, which is how I've set this one up. Here's more information about the changes you'll need to make if you want the open labnotebook to be your personal website, and not a page thereof.
Similar to _layouts, _includes will contain html templates for the header and the sidebar of the website. I typically put anything "preamble-ly" into the head.html file, like links to fonts, or custom css files.
This folder contains all the css files for your open labnotebook. These control the styling, including color, font, etc. The only files you will most likely need to change are hyde.css and lanyon.css. These are two variations or themes to the blog, which can be viewed here. It is pretty easy to switch between themes.
This folder is designed to contain any posts which you want to embed R code chunks in. The file format is R markdown, which is discussed here and here, and lots of other places. It's pretty useful. Posts contained in this folder need to first be knit into markdown (.Rmd to .md), which you can do (currently manually, though this is clunky) with the render_post.R function that lives in the _knitr folder. You hand the function the file name (when you are in the _knitr folder as your working directory), and it will put the resulting markdown output into your _posts folder. If you don't feel like including embedded R code in your posts, or if you want to include R code, but only in syntax (markdown has this capability), just delete this folder.
This is where you will spend the majority of your time. Each post is an entry in your open lab notebook, and must be formatted with date, and post name (e.g. 2015-8-1-Post-Name.md). Within this folder, you can have a folder called _drafts, which are those posts that just aren't ready for the big time.
The config file is pretty important, but you shouldn't have to edit much of it. Just a couple of lines under the Setup heading. All those entries are pretty clear; paginate refers to how many posts to show on a page, and the base url is currently set to be /sampleNotebook, but will need to be changed to your repository name, before you push this to Github. Information on setting up your Github account, and an introduction to the version control platform can be found here
Pages live in the home directory of your notebook, and are written as simple markdown documents. In fact, the only difference between a page and a post apart from directory location, is the yaml header. The header of a post specifies that the layout (from the _layouts folder) is that of a post, while the layout for a page is layout: page. Pretty simple, right?
Okay. So you either downloaded, forked, or cloned the sampleNotebook branch (see here for a nice git tutorial), and now you'd like to deploy your science to Github, where it will actually be built and go from simple markdown to beautiful html. I'll go through the steps of at least forking, if not actually commiting and pushing changes below.
If you're on a Windows machine, git ships with a terminal emulator. If you're using a Mac, I have nothing for you, and I'm sorry. If you're on Linux, you already have used the terminal hopefully (ctrl + alt + t !!).
To clone just the branch containing the skeleton open lab notebook. You can also simply download the folder, and go from there.
git clone -b sampleNotebook https://github.com/taddallas/LabNotebook.gitTo be filled in
There are a lot of other bells and whistles that could be added, but my goal was just to offer a nice and simple open lab notebook template that is accessible to a broad range of folks. That being said, feel free to contribute functionality or to make some project aspects clearer by forking or filing an issue on the Github page.
Tad