This week we’re moving beyond the maps and into (soon to be) charted territory. We’ve chosen to play around with XCharts, which is a javascript library for what else — charts — that works alongside the d3 library. Though we’re not sure how deep we’ll be able to delve into the scripts, I think it will be a good starting off point. It took a few hours to figure out how things are set up and the basics of manipulating the style, which was hindered by a few errors on XChart’s quick startup instructions page. I had to do some “Google mining” to find out that XCharts is still incompatible with d3’s newest version 3, which XCharts fails to mention on their page. Linking to d3.v2.min.js instead of d3.v3 seemed to do the trick; though I must admit that at this stage in my skill level, most of my successes are pretty much based on luck and trying what seems to be the same thing over and over 😉 Another frustrating thing is that their documentation and examples pages are honestly not really that helpful unless you know quite a bit about javascript. It’s all a little over the heads of us at the field school, which is why we’ve chosen to all work on these charts at the same time so we can figure it out together.

So far I’m happy with the look and the basic data of XCharts, but trying to overlay multiple series and to implement background “time periods” with rectangles is proving frustrating. Also, the need to input the data array into the html document directly is pretty time-consuming. We’ll see how they all turn out in the end. Since we have a lot of data spread out over the 20th century, most of our charts will be line graphs, but we also have a few subject graphs that we’ll be experimenting to see what we can make that will best represent the data we have. We may have to leave XCharts and turn to another tool for those if we don’t like how things turn out. This seems to be the testing phase of the project as we try to uncover the best visualization we can build.

For the past 4 days we have been developing and planning our final project. It has been an experience to say the least. Trying to find agreement between 10 people who have really never designed a project before has been an interesting and enlightening process for me. And it has to be completely finished in only 2 weeks!!

I honestly must admit that I’ve never been a member of a team like this. I hate team projects normally. I’m accustomed to choosing my own ideas and following them to my precise specifications, whether that be in a class paper, a semester project, or my senior thesis. And I spent all of grade school and high school being that one kid who runs things. College has kind of trained of that out of me since professors are pretty quick to tell you your ideas are just plain wrong. But I’ve mostly only worked on individual projects, so I still controlled my own ideas. The field school is a totally different animal.

We have to work with other people. It’s impossible to control this project individually — not only is it too big to do alone but  to do so would be to its detriment, as we each have different skills and interests. This is one of the main reasons why I’m drawn to digital humanities and one of the main reasons that I am sometimes reluctant. Learning to contribute, to delegate, and to give productive feedback are all critically important skills that are not typically taught or practiced in college courses. But they are required in the digital humanities.

This is all a new kind of experience for me, but I think I and the rest of the team are adjusting well. Our entire team has been doing a great job planning and designing this project, and I think it come together to be something pretty cool. Get excited.

This week the field school dove into the wonderful world of Bootstrap. I’ve played around with a few templates before, but I knew much less html, CSS, and javascript than I do now. It’s really great that Twitter and their developers released their code so other people can play with it. I particularly liked Bootstrap because I think front-end webpage design is one of the most important pieces to a project. Yes, the data and the database and the underlying programming has to work — and work well — but I am of the belief that no one is going to want to use a site that looks terrible. I myself have quit playing games (regardless of the story) and abandoned websites (no matter how useful the content) when I couldn’t stand the design. If I don’t like the way it looks, I won’t use it. Bootstrap helps website and project developers solve at least the basic problems of design when they don’t have more advanced knowledge to do it themselves.

Modifying a template is so much easier than trying to write “from the ground-up.” I tried the latter a few weeks ago, and while I think I can say it wasn’t ugly — it definitely wasn’t smooth, beautiful, or giving off the appearance of being created by anyone with real skill. But Bootstrap makes it pretty simple to modify the html and CSS to alter the appearance of the site, so long as you understand the basics of programming. And honestly, even if I wanted to create a brand new site without the underlying Bootstrap, I think it would be easier for me to start from Bootstrap and just continue altering it until it became completely different and mine — because I like to see how the code I’m writing is actually changing things and that’s much harder to see when writing from scratch.

The only issue I have with Bootstrap is that it is so popular and I’ve started noticing it throughout the web, particularly on the list of example projects that Ethan has shared with us. And yes, I know it’s kind of snobbish to say I don’t want people to know I’ve used Bootstrap when I did use Bootstrap — but isn’t it a good goal to aim to make my use of Bootstrap less obvious? That would mean I’m writing code of my own, right? An important element of artistic design is to produce something unique and beautiful. I just wish I was talented enough to do that, but until then I’ll just build off Bootstrap and hope no one notices.