gmoe
commented
6 years ago I'm gonna chuck my two Jekyll examples in, since they're both pretty applicable to the podcast website:
Learning DSP – Repository
This is less-covered feature of Jekyll, but here I'm creating my site by sourcing from a bunch of JSON files contained in the _data directory. Only the Submission Guidelines is kept as a Markdown file. For a basic run-down: I would start looking in the _layouts directory which contains the template for how the JSON should be made into web content (specifically here). Those directory names are important to Jekyll in terms of where it should look for things to build the site, generally things prepended with underscores are Jekyll-specific.
My Resume/Blog-thing - Repository
In this example most of the content lives in _posts, with the exception of the resume which is in a YAML file in the _data directory. You'll probably wind up using this kind of structure since you're writing Markdown rather than JSON or YAML, just remember that info like SoundCloud embedded content IDs can stow away in the front matter at the beginning of every post. There's also the _sass directory, which contains SCSS which is an intermediate language for CSS. I highly recommend learning it, because writing vanilla CSS is really painful for large-scale websites like this.
In C Web App - Repository
This is an edge-case, but if you decide to use something other than Jekyll or start using Jekyll plugins that are unsupported by GitHub you'll have to go down this route. The master git branch contains the source code for the site, while the gh-pages branch contains the assembled versions of the website which GitHub serves to users when they visit the site. Deploying updates to the public site is accomplished by creating a fresh build of the site locally then copying the build into the gh-pages branch. All of this is described in the package.json scripts, where npm run will run another defined script and browserify, node-sass, gh-pages etc. are all of the Node libraries doing their part. I've essentially rolled my own Jekyll by combining these Node libraries! Doing this (using Node or the mentioned libraries) is not a requirement if you're using Jekyll or some other static web generator, you can still automate the deployment by writing a script that performs the same functions as the gh-pages library I'm using.
Hope these are helpful, I can dive into more detail or clarify things if need be. Good luck!
Initial Musings:
As I near the final weeks of my second semester in the DH program at Loyola, I have a couple of answered questions I think I considered too basic to ask when the time was right. Don't get me wrong, the wealth of knowledge I have gained about the inner-workings of computers and techy things has grown exponentially since I got here in August, but I think there are still a couple gaps in my ability to conceptualize all the work that goes into creating a website or digital tool. I'm trying to fix that though! And that's why I'm writing up this post today. So I took COMP 125 in the Fall which introduces the never-before-coder to the wonderful world of Processing which is basically Java in a friendlier environment. Great! Super! Had a lot of fun with that, but I have almost no clue how any of the code I was writing translates into the backbone and structure of a website. My intuition tells me that all those shapes and conditionals that we were writing fall under hierarchical branches that generate either static or animated pages, and I don't think I'll get kicked out of Loyola for making a guess like that ;) but I'm on a quest to understand it all just a little bit better so I'm going to try to look at the code for a few sites and see if any of it makes sense to me. STAY TUNED
Looking at Jekyll sites:
GitHub Pages has tons of resources for people who want to run their websites on octo-cat power. I came across this list of GitHub Pages Examples which contains many MORE lists of lists of lists...and you get the picture. From there I got to the Jekyll list of sites which is where I played around for a bit because I know Becca is envisioning the Plain.txt site being generated with a Jekyll framework. What I discovered there is a ton more variability than I ever expected. Many of the sites are very static, kind of plain, not too exciting (most of these are personal blogs or portfolios so I wasn't expecting whistles and bells) but there were a couple that sort of made my jaw drop with the amount of detail and animation they incorporated. (One site in particular made me laugh because it was described as this guy's personal portfolio but when you open it it's just the word YOLK in the middle of a frantically flashing and folding background animation and leads no where beyond that.) There were others that strayed away from the mundane and actually filled out a bit like I'm used to seeing in the worldwide web (here's an example of one I think strikes a good balance between being super-plain and ridiculously over exaggerated). I guess what I mean by that is many of the CMS's I've used in the past give that professional, stylized, seamlessly animated feel without cultivating the talents of the individual programmer or user designing the site. They are glossy and attractive but require little to no skill to bring into existence, which is why I realize many of the sites on that list don't zig or zag or try to give you a seizure when you open them (I'm calling you out YOLK!). They are simple because programming a website requires a lot of skill, time, and money, and that's fine because bells and whistles are only great if the content is great. There's no one set way to do any of this, but there's plenty of examples out there to inspire us along the way. I think the main things I've taken away from going through this list are that (a) if we take our time we can actually make the more complicated elements of our design happen and (b) there are so many fantastic examples with open source code to look at and learn from.