We got our poster printed! It feels so nice to have that out of the way. We’re now just working on the oral presentation and the paper. Here’s what they look like right now:
Despite having so few days left, nothing really feels different. Maybe I’m just bad at sensing it, but I don’t notice any sort of dread regarding the end of the program. This could mean that it’ll be smooth sailing until I’m home, or that the end is just sneaking up on everyone. Or everyone else is drowning in emotions and I’m high, dry, and clueless. I guess we’ll see pretty soon.
I went to Cedar Rapids last weekend to visit an aunt, uncle, and 3 cousins that I used to see regularly. Unfortunately, I don’t feel like I have much in common with my cousins anymore.
We went to an 80s-themed pizza place that had probably 30 arcade machines and another 10 pinball machines. The next day we went on a hike by the Cedar River. Here are some pictures:
We did our user trials yesterday. It feels so good to be done with the website and finally have the material for the poster and paper. We need to turn in the poster by Monday 8am, so I need to focus on my portion of the poster creation and editing process.
Here are some pictures describing this week:
We need our website functional (enough) for human testers tomorrow. It’s definitely possible and we’ve made lots of progress today already, but I’m tempted to say that I don’t really have blogging time. Here’s a screenshot of the WIP interface right now:
Hackathons were originally events for working on personal hardware and software projects in an environment with food, few distractions, and people happy to help. More recently, they’ve become timed programming competitions. Until this weekend, I’d only tried the latter.
Previously, I’ve won several 24-hour competitions with Unity games. This time, with a non-competitive event (organized by Ilan, food provided by VRAC), I decided to try a project more focused on learning for those 6 hours on Sunday afternoon.
I wrote a C++ program for Ubuntu (run on a Raspberry Pi, but that doesn’t actually matter) that lets the user “paint” on the screen with the mouse without using a graphical environment. That’s probably more impressive than it sounds, so lemme try to explain some background.
The Linux kernel (a low-abstraction piece of the operating system that interfaces with hardware) keeps track of input devices and makes them available to programs that the user wants to run. There’s a “file” for each input device that describes what it’s doing. It’s a stream of information, really, that describes anything coming from the device. For example, pressing a key on the keyboard makes the keyboard tell the kernel that it was pressed, when it was pressed, and what key was pressed. All that info is dumped in the keyboard event stream for anything else to read. Similarly, the mouse reports a little blob of information whenever anything happens to it. That structured piece of data (called a data structure, or just struct) describes what just happened (horizontal movement, vertical movement, button press, button release), when it happened, and in the case of movement, how much. So really what this boils down to is that I need to read that stream of data and do something whenever some info comes in. How does that usually work? Does every program that uses a mouse need to do that?
In a typical graphical environment, there’s a program that runs in the background that watches the mouse. Since the mouse only directly reports relative motion, this program keeps track of an absolute position by adding the relative movements as they come in. This also means keeping track of the borders of the screen so the pointer is always visible. If a different program wants to know something about the mouse, it asks this background program where pointer is, which buttons are pressed, etc. What I wanted to do in this project is ignore all that and write my own input handler that isn’t bundled with a desktop environment. That’s an unusual thing to do, since nearly every use for a mouse requires a desktop and thus already has the mouse handler available.
The first problem that I needed to solve came up because if the program is waiting for mouse data to come in, that means it isn’t doing anything else. The whole program is frozen except when you move your mouse. What if you could tell part of the computer to watch that stream and another to use the data that the first part finds? That’s called threading. (Yes, there are other ways I could’ve done this, but I wanted to learn C++ threading, anyway.)
I’ve made threads in C# (and Python, too, I think) for watching information come in through the internet. It’s a similar situation where you have an asynchronous task that shouldn’t hold up everything else. The way that C# and C++ do threads are somewhat similar, but I didn’t have a new enough version of the C++ tools installed for the modern method to work properly (or at least that was my theory when I gave up after a few minutes). I instead learned C-style threading and made my program keep track of the mouse events that way. The thread waits for an even to come in, changes the position and state of a variable that represents the mouse, then goes back to waiting. Elsewhere in that program, I can read that variable and see the most up-to-date info about the mouse.
After getting the reading down, I had to actually do something with that data. In this case, I used it to move a cursor around the screen. I could’ve also used it to do something more complicated like rotate a 3D model or something like that, but I decided to keep it simple for now and focus on one challenge at a time. The end product lets you move a cursor with the mouse, left click to type “#” under the cursor, and right click to type a bunch of spaces in a square (which “erases” that part of the screen). That means you draw with a left click and erase with a right click, making for a simple paint program in a text-only environment!
So I think we’re at a point in our project where it makes sense to share some visuals. I threw together a sketch of what I was picturing a while ago and everybody agreed that it should work. We’ve been making steady progress toward this goal and realizing what kinds of changes make sense as we go.
At some point I might have a working prototype online (I’ll post a link at that point), but for now everything is running locally. We don’t actually need it to work on the internet, though, because we’re going to be controlling how our pilot study subjects access it, so we could just as easily have some strange custom setup on the device we hand them.
So my next step (after going to our weekly Thursday meeting) is to program a semi-physical model of how outdoor temperature affects indoor temperature. The controls exposed to the user will change factors such as thermal conductivity, wall thickness, surface area, incoming solar radiation, etc. and hopefully produce some semi-realistic graphs of temperature.
I just waded through the ridiculous amount of NOAA data to get some hourly temperatures throughout the summer in Des Moines a few years ago, so that should be a good starting point for the outside temperature. Next up: get an inside temperature from it.
The DataViz team has been working on the website for a while now (it’s really coming together!), but there are some other parts that we need to do, too. We need to have a paper ready for submission, a poster for the ISU-wide REU poster fair, and we need some real data from a pilot study (which is used in the paper and poster). Each of these things will take quite a bit of work, and we don’t really have that much time left. I don’t mean to say that we can’t do it or even that we’re discouraged, though.
By Thursday this week, we have to design a method of analyzing our testers. This is going to be a combination of screen recording, note-taking, surveying, and interviewing (before, during, and after the trial). I’ve never done something like this formally (though I’ve gotten informal play-tester feedback on some of my games), so it’s new yet familiar to me.
Anyway, in light of the timeline and our list of deliverables, we decided to make it a literal list. We’re now using Trello to emulate a sticky-notes-like organization scheme for keeping track of what’s being worked on and what’s left.
Here’s an interesting table (that we’ll likely need to use soon) of cost and energy consumption for various appliances: https://www.cityofames.org/government/departments-divisions-a-h/electric/the-energy-guy/household-appliance-energy-use
I’ll say up front that I didn’t take as many pictures this time around, so I didn’t have many to choose from when picking what to post.
I’m happy that I got to stay with my aunt, uncle, and cousins for the weekend, because I don’t see them very often. Most of the people I met knew somebody from my extended family, so it was fun to explain my connections to everyone involved. This was more a rare chance for a family get-together than a wedding for me, since I know the guests much better than the bride and groom, who are both friends of my family.
Logistics were pretty exciting. Angelica drove me down to Des Moines on Friday, where I got on a bus for 6 hours to Chicago. It only stopped twice. It had outlets and WiFi, but the internet connection was insufferably slow most of the time. Once in Chicago, I walked 15 minutes north to a train station, where I rode for around an hour further north to get to my great aunt’s house, where my brother, uncle, and his family were staying the night (they came down from my uncle’s house in Wisconsin). In the morning, we drove to Gary, Indiana to pick up my girlfriend from a train stop (she rode an hour and a half from Notre Dame). We then drove around 2.5 hours south to Indianapolis for the choir rehearsals, led by my uncle.
We stayed two nights in a friend’s house and left early Monday morning for a long drive to Chicago. From there, I got on a bus, my girlfriend got on a train (from Chicago this time instead of Gary, so 2.5 hours for her), and my brother got on a plane. My aunt, uncle, and their two kids drove a few more hours the rest of the way up to their house in Wisconsin. I wasn’t so lucky with the bus on the way back, though. Something was wrong with the circuitry (blown fuse? I’ll never know.) and that caused both the WiFi and the outlets to not work. Nobody was available to take me from Des Moines to Ames at the end, and there weren’t any reasonable priced and schedules buses, so I took an Uber for the last 40 minutes, which cost as much as a 6-hour bus ride.
Anyway, I’m back now! What a crazy pair of trips!
We actually got a lot done this week. Our application is taking shape (though not enough of a shape to be worth sharing). I’m happy with the organizational structure of this data visualization and I’m glad that it has continued to pan out as an extensible and easily-separable workflow. On Wednesday we went outside and took lots of pictures. Here is my favorite:
On Thursday, we heard an interesting lecture about some VR research. I’ve probably mentioned this before, but we were all expecting a much higher portion of VR research at the VR Applications Center. Jon Kelly is looking into how our bodies perceive motion when they don’t move. He’s doing this by investigating where people think they are after moving and rotating in a virtual environment, and by changing the way that they move. When you physically walk and turn, you keep a very good mental map of where you are. When you teleport (or other types of VR locomotion), you tend to be worse at keeping track of where you are.
I’ve also personally noticed difficulty in maintaining that mental map when you introduce enough axes of motion into the environment. I enjoy a video game in which you have complete freedom of movement inside a cave-like environment without a defined up direction. This means that you can translate and rotate along/around any axis. In addition to the control difficulty (which my quadcoper flying days certainly helped with), it’s really easy to get disoriented when there aren’t lots of landmarks involved, and that’s without even teleporting. I asked some questions about that research topic (which has applications in space stations) and learned that it’s a rather unexplored field.
I left early on Friday to get down to Des Moines in time for a bus to Chicago for the next wedding I was invited to sing at. Thank you, Angelica, for providing transportation!
I went home to Oregon for the weekend to sing at the wedding of one of my childhood friends. I also got to see my brother before he gets a job and moves out (he just graduated) and my dad before he joins my mom in Geneva next week (she’s at an internship at WHO). Anyway, here are some pictures:
This week is only 2 days for me. Wednesday is a holiday, we have Thursday off, and I’m gone for Friday through Monday for a wedding in Oregon. AJ, our newest team member, will also be gone on Friday. Hopefully we make it far enough in these two days to do some work independently until we’re in the same place again.
Monday, July 2
Today we welcomed our new team member: AJ. He should have a blog listing soon, but I’m not sure if he’s required to post. He’s an undergrad who’s done some research for one of the overseeing professors here at VRAC, so he’s familiar with a lot of the people (albeit not the REU students). He happens to fill some gaps in our team’s knowledge about web design.
I made some UI sketches that Jacklin loved, which closes out the majority of the pre-programming work. We should be able to get a solid start tomorrow!
Tuesday, July 3
Today was the first real work with AJ (and consequently the first work with a full team in over a week). We picked out some technologies to build our program with. We’re currently planning to make a React.js website with a clean separation between the user interface, backend, and data (this separation promotes better organization, extensibility, and task separation). Our first block of work will be divided into 3 parts; Victoria will make the visual layout of the first iteration of the interface, I will make the backend that handles how the user selection modifies the data, and AJ will do the tasks in the middle, like specifying which buttons call which functions and how the graph is generated from the backend-served data. For this pilot study, the data file isn’t very important. We only need to provide plausible information to measure how well the interface can teach people.
I’ll back up a bit, since not all of my readers at home know much about this project. We’re creating an interactive website that will let you see how various changes (decreasing the A/C target temperature, opening windows at night, upgrading your insulation, etc.) impact your indoor temperature during extreme climate events. The goal is to help marginalized populations get a better sense of how to handle these situations, but in a more individual way. Current efforts to do similar things instead focus on brochures, billboards, or other one-way communications which have proven to not be very effective. Our research question is basically, “does this interactive thing do a good job of teaching these climate concepts?” This requires two components: the interactive thing, and the means of measuring understanding. We’re focusing on the first piece right now, but we’ll get to the second one before the end of the summer.
Hey, look! It’s almost the end of June. I couldn’t decide between “A slow finish” and “A fast finish”. I can’t really tell which it was.
Thursday, June 28
The DataViz team is running out of things to do besides making an actual application. Thankfully, that means we’ll get to write some code soon. Unfortunately, that also means the selection of available tasks is currently rapidly decreasing. I enjoy the way that programming gives you so many ways to accomplish a goal. Writing a little formulaic snippet is quite different.
We had an interesting luncheon lecture about portable nanosensors for food safety, but I fear it has cemented my current distaste for bio-related topics. Computers are just so clean and logical that the world of bio just seems frustrating and arbitrary. I’m sure I’d have a different opinion if I started doing work in the field, though.
After work I went shopping with a few people and I got some produce (among many other things). It’s been too long since I had produce….
Friday, June 29
The day really flew by. I think Fridays usually go the other way, so that was surprising. We really just read through some of our grad student’s previous publications to look for edits that we should make to our own lit review. We also did some more interface planning for the eventual application.
Monday, June 25
We finished up with the shaders section of the deeper dive. (Reminder: shaders are programs for the graphical processing unit.) This mostly consisted of following a slideshow and copying code, but I happened to have enough baseline knowledge to figure out how everything works. When we reached the end of the class, I took it upon myself to write a shader that renders only horizontal slices of an object without modifying its geometry.
This view is a bit confusing, so I’ll break it down. There are two objects here. The grayscale teapot is in the front with thin slices. Behind it (and partially inside) is a pill-shaped thing. The thin light blue/gray lines show the shape of the object being passed to the shader (called a “mesh”). It’s up to the shader to figure out which pixels need to be what color to make the 3D object appear on the 2D screen. Sadly, if you haven’t written a shader, you have no reference for how much vector math is involved in this process.
In the afternoon class, we got a second, more in-depth tour of the C6: the 96-node, $6 million graphics cluster and VR room. If you can’t picture how 24 projectors can project onto 6 walls, this picture might help:
We made a small test scene in Unity using the plugin that allows the C6 master node to distribute the rendering and simulation to all 96 nodes. It was really neat to make a virtual world and then stand in it, all within in a few minutes (but I’m used to the concept from standard commodity VR systems)!
Tuesday, June 26
Today we talked about how to review a paper and practiced as a group. The DataViz group (well, we’re a pair now) wrote the “research area paragraph” which describes what our goal is and also how to measure success. It’s funny to me that we didn’t even know what we were researching until week 5. I understand that research is about solving open-ended problems, but this is more like getting to the airport before you know where you’re buying tickets to. It’s fundamentally different than that standard research uncertainty that Dr. Winer is so proud that we don’t have much experience with yet.
Speaking of Dr. Winer, (the associate director at VRAC and one of the two professors in charge of us,) we heard his career story over lunch. I’m still not used to hearing these full-career stories. It’s interesting how thoroughly different lives can be. I know that isn’t very profound, but that’s alright.
Wednesday, June 27
Today my deeper dive group worked on a mathematically-complex shader that doesn’t lend itself well to a succinct explanation. The end effect is that you can make an object appear to be cut along any arbitrary plane without actually affecting the geometry of the object. I also messed around a bit with some shaders that render 2D and 3D fractals and I rendered these:
I had a bad headache for most of the day. Made a few calls, including talking to my parents for the last time before my mom heads to Geneva for an internship at the World Health Organization. My dad will leave once his Visa gets approved; he’s staying behind to attend the wedding that I’m flying back for a weekend to sing at. I took a nap after the calls, but I just woke up nauseous instead of feeling better. I read a bit while I waited for that to clear (and it mostly did) before going to bed again for the night.
Thursday, June 21
We had a very nice presentation about interviews. I think the most important thing I learned is that 50% of the interviewer’s opinion is already formed in the first 30-60 seconds since meeting, and after 2 minutes it’s very unlikely they’ll changed their mind. I find that pretty disappointing. In that amount of time, you’re being judged on purely social things like small talk, eye contact, hand shakes, etc. instead of the skills you’ll actually bring to the table (including social skills). It’s a shame that human psychology puts more emphasis on those first-time skills that are seldom useful in the types of jobs I’m interested in.
Friday, June 22
Someone was let go today. They were the only person in both my research group and my deeper dive group. I can see why it happened, but I’m not sure that I agree that it did. The premise is that being consistently late is disruptive, but having them gone completely seems like it would be worse. I’m not worried about getting work done without them, so maybe not. I guess we’ll see.
Anyway, we threw a quick goodbye party in the evening before they left in the morning.
I think it’s been long enough that naming posts by day isn’t important anymore. This post is for the first half of week 4. Our extra scheduled events are on the decline, as planned:
This shift in scheduling means that there’s a lot less to talk about besides our actual (currently unpublished) work, and our “deeper dives”: small-group trainings on more specific topics. This year, the topics are 3D Printing, Unity Immersive, and Unity Shaders/C6. We’ll learn more about these and rank our top choices later.
On Monday, June 18 we had our first day of Unity courses. I’ve tried to teach Unity before, so I understand how difficult it is. I was impressed by the curriculum and I would’ve loved to have that when I was bumbling through the platform years ago. On the other hand, the “mess around until it makes sense” method that I used has provided me with a very in-depth understanding of how the pieces all fit together, so maybe it’s a draw.
Anyway, my experience in 24-hour coding competitions set me up to make a quick game during the instructional time. It’s a simple flight simulator where you get points for flying through randomly-placed rings and lose points for touching the ground.
Tuesday, June 19
I got invited to another wedding. It’ll be a stretch, but I might be able to attend both. One is for a childhood friend and the other is a family friend. One in Oregon and the other in Indiana. They’re also a week apart.
In the evening, my room put on some swing music and we danced a bit in the living room. Aidan can be a lead or a follow, so that worked out nicely. We’ll put on a lesson for the whole group at some point, so I guess this was just practice.
Wednesday, June 20
Not the best start to the day. It finally came off.
Neither the bike nor I were damaged (it didn’t break; it just wiggled off), but it did make me a few minutes late to work since I had to walk it home and grab Stephan’s bike (he usually takes the bus).
Today we did some more Unity training. I finished up my plane game and walked around helping others.
We heard some more in-depth descriptions of each of the Deeper Dive topics. Unity Immersive focuses on creating a virtual reality experience for Vive, Oculus, or mobile VR with a focus on interaction paradigms. 3D Printing involves learning how printers work and making some common things like math models or small replacement parts. Unity Shaders/C6 is about programming GPUs (graphical processing units) and a $6 million virtual reality room.
I’m in the last one, since I have some experience in the other topics. I’m happy to have the opportunity to learn GPU programming, since it’s something that I’ve been meaning to teach myself for quite a while now. I’m very comfortable with the low-level design and operation of CPUs, but I only know the high-level operation of a GPU. Hopefully it’ll be the right environment to get some of my long-standing questions answered!
Saturday, June 18
I returned to the bike co-op to try to fix the bike issues that have been creeping up. The biggest issue is that the left crank squeaks with every revolution and even wobbles a little. I ended up taking the whole bottom bracket apart and cleaning it out, replacing a shot bearing, and lubricating everything.
It worked for a bit, but the squeak slowly returned and then the wobble with it. I just hope the crank doesn’t fall off at a bad time. (Is there a good time?)
Sunday was pretty normal. My roommates didn’t leave their rooms until at least noon, so I had a nice morning without them.
Thursday, June 14
Rain again! It was quite the thunderstorm. Woke me up several times, hours before my alarm. It was also alarmingly dark. I checked the time on two devices just to make sure. I learned my lesson last time it rained, so I preemptively wore flip-flops and took the bus.
At VRAC we attended a very interesting lecture on decision trees, Bayesian Networks, and AI explainability.
Friday, June 15
Today was mostly Maya. I learned how to do some basic manipulations and how to import standard assets. I made this beautiful scene to demonstrate some of those things that I learned:
Overall, I still prefer Blender to Maya.
Monday, June 11 through Wednesday, June 13
Alright, I’m combining a few days since I’m behind and the number of scheduled events is decreasing (and therefore the number of things to write about, also).
On Monday, I had a good time going for a bike ride by myself. I asked a few other people, but nobody else had time or wanted to. It turned into an opportunity to explore and think, but also to notice that my bike still has some issues to work out on Saturday when a small group will return to the bike co-op. Specifically, the left crank arm doesn’t sit right in the bottom bracket and causes some squeaking and wiggling.
On Tuesday, I (and the rest of the DataViz team) doubled down on finding papers for the literature review. It’s a very slow process and very much a crap shoot. We had a brief meeting with our grad student toward the end of the day in which we learned that our ill-defined project may get a goal soon! We were also reminded that our professor will be leaving for a few weeks to take a train across Siberia to see the World Cup (but another professor will stand in during that time to provide guidance). After the work day was over, I rock climbed for a bit. Biking sounded fun, but I might have overdone it yesterday. Also if the crank falls off, I would want to be on or near campus.
We had another small group meeting on Wednesday. Next up: finish up the lit review with an exhaustive search to see if anyone else is doing research into the impact of data visualizations on marginalized individuals’ decision making (and no, we’re alone). We were also assigned the next set of tasks: write a few paragraphs about the problem area and literature review. We still don’t know exactly what our project is (or its use-case), but that’s coming by Friday.
Days 12 and 13
Saturday, June 9
Ropes course. It was several hours of physical activity and group dynamics. I don’t think we’d had any opportunities for full-group teamwork, since we mostly work in our groups of 3. Finally having all 12 working on the same thing was exciting. Lots of fun, but I was also happy when I could be alone again.
Sunday, June 10
We left for the bike co-op in the afternoon and built ourselves some bikes. Mine didn’t take too much work: the brakes weren’t tensioned properly, the kickstand needed to be replaced, and the chain was rusty. I discovered later that the crank is a bit loose, but I don’t think it’ll be an issue. I’ll take it back to the co-op next weekend anyway, though.
Friday, June 8
Next up: visualize more than one question. A “select all that apply” question is basically just a set of yes/no questions. I have a way to visualize that now, but what about a set of multiple choice questions? After some brainstorming, this ended up as the rough goal:
I spent the next few hours working on this new challenge. It requires a new Shadron program for graphics and a new C++ program for reading and counting data. It turns out that counting second degree relationships is kind of a pain! I ended up needing 5 nested for-loops to count through each pair of nodes: question A, option A, question B, option B, and survey responder. “Options” are the choices that the participant has (T/F, abc, abcdef, etc.) for each question. In that picture above, options are grouped into questions by each straight line. At this point I hadn’t settled on how to show the counts of how many people chose each single option, but you can see how many people chose each pair of options by the thickness of the line connecting them.
I ended up working way past 5:00 and nearly to midnight since I was having so much fun putting this together. Here’s the final product comparing 2 questions, then another comparing 3 and then 4 questions:
As I was writing this program, it felt natural to represent each individual option as a circle of varying diameter like in the last visualization. As always, everything is adjustable. I didn’t go through the trouble to label everything (since this is just another proof-of-concept), but it still came from real survey data. Just like the last one, this is designed for data scientists and not the public.
Thursday, June 7
Quite a work day! I already had the visualization code done for the first project, but all that it does is render shapes of variable size at variable locations (actually pretty much everything is variable). It still has to get those numbers from somewhere. I wrote a companion program in C++ to sift through the data and count the primary and secondary data relationships to plug into the visualizer. Even after that, though, it’s just an image. To turn it into a useful tool for a data scientist, it needs labeling. I added text by hand to say what each node represents and to label each node and edge with how many responses it represents. Here’s the result:
It’s important to note that this isn’t designed for public consumption. The use-case here is for researchers to explore a set of data to look for trends or surprising relationships. (For example, everyone who uses a space heater also wears extra clothing in the winter.) As such, this visualization needs to be easy to use, and not necessarily easy to learn.
I worked with Ilan a bit while evaluating different options for presentation methods and behind-the-scenes organization, so thank you for that!
Also someone pulled the fire alarm a few hours after we learned where to evacuate to. Suspicious…
We have an assignment to find 3 things with bad interfaces or interactions. Here is what I found:
iPad and Apple Pencil
To start, $100 is too much for a stylus. After you pay that much, you expect some fabulous integration and quality. I can’t speak to the quality, but the integration is lacking. To charge the Pencil, you remove the cap and plug it in. This leaves the cap loose and easy to lose and provides the perfect lever arm to torque the plug off the end of the Pencil. If you want to use the iPad while the pencil is charging, you’re forced to hold it awkwardly so you don’t damage its port or the attached Pencil, and you must stay cognizant of the expensive rod sticking out of the bottom whenever you pick it up or put it down. Also, since the iPad only has one port, you can’t charge the iPad while charging the Pencil. To sum it up, Apple forces their users to change how they use their devices (in a negative way) to accommodate an add-on that’s supposed to improve the experience.
It was funny to see how many people walked up to this door, stood for a moment, only then read the sign, and then flailed a bit until it opened. I also saw people who watched the door, saw that it didn’t open, then walked to the front of the bus instead. In general, the second door on a bus opens when the driver wants it to, but here the driver had to give instructions to people to supplement the sub-par labeling. You shouldn’t need a sign on a door, and if you do, it should at least be larger! The warning signs covering public spaces probably exacerbate the issue, since we’re used to seeing “CAUTION” and skipping the details (including how to open the door, in this case).
Bob Pelletier’s Website
Setting aside the visuals, this website seems to just be a list of links to websites of interest. With that in mind, I would expect the links to be easy to look through so you can find the website you’re looking for. Sadly, this is not the case. They aren’t even alphabetized. I do appreciate the difference in color between the link and the description, and I like that the text is all legible (many websites from this time had tiled or animated backgrounds that made the text hard to read). A visitor could use the browser’s “find” feature to search through the document for the topics they’re looking for, but I think that represents a failure in web design; many users don’t know that browsers can search pages, and would be stuck scrolling through the long list.
I’m lumping these together since my Tuesday post ended up pretty short.
Tuesday, June 5
We started with the “Craft of Research” class, where we addressed the reasons behind literature reviews and the questions behind our research. We talked about the ISU Institutional Review Board (and IRBs in general).
We attended a lunch lecture about biofuels and globalization by Mark Wright. He discussed the history of biofuels, world-wide energy sources, and predictions for the future. We asked about his work here at ISU and learned about the ongoing energy and biofuel projects and ISU’s leading position in the global biofuel research space.
Next, we (DataViz) had a meeting with our professor (Dr. Dorneich) and graduate student (Jacklin) about our lit review progress and our next mini task: make some visualizations to help researchers understand the results of a survey on household energy use. This will take some careful thinking, since we’re coming up with something new. We spent the rest of the day working on that, getting our pictures taken, blogging, eating, and sleeping.
Wednesday, June 6
Another C++ class in the morning. It gave me an opportunity to help people and some extra time to wake up.
We (DataViz) had a short meeting with Jacklin where we clarified some objectives and got feedback on a visualization we’ve been brainstorming on the whiteboard. After that, I started programming a way to create that visualization.
We (REU) left for lunch and made a stop at the administrative building to pick up our first paychecks. After making it back to the lab, I blogged and worked some more on the DataViz code.
To briefly summarize what we’ve been doing, I’ll give an example. Let’s say you give out a survey asking people to “select all that apply” from a short list. How do you visualize the results? If you make a simple bar chart showing the frequency of each option, you lose all of the relational data; you can no longer tell if , for example, most people who chose option 1 also chose option 3, but people who chose option 2 tend to only select that one. We set out to (partially) solve that problem with a graph (in the mathematical sense, as in “graph theory”). Nodes on the graph represent options and have an associated weight that corresponds to how many chose that option. Edges have a weight that represents the number of responses that chose both of the options it connects. The weight is visualized as a diameter or thickness.
We had part two of the C++ lesson next, which I hurried through so I could keep working on the DataViz code. I finished the part that uses numbers to create a picture, but it doesn’t find those numbers from the data. I need a second program that finds the prevalence of each option and pair so that I can use those numbers to make the final figure. Here’s an example with a 6-part “select all that apply” question using random numbers instead of real data, since I don’t have a way to sift through real data yet:
This lets us quickly see that everyone who selected the one represented in the lower right also selected the one in the upper left (since the widths of the circle and line are equal). We can also see that the one in the lower left was fairly popular, yet uncommon to see at the same time as the one in the upper right. I think my progress on programming this is going quite well and it’s nice to have some tangible progress on the overall mini project this week.
Anyway, it rained really hard when we went home today. Lots of lightning and wind and even some hail. I suspect my shoes will be drying for a few days. Thankfully, nothing got water damage. I heard a few complaints about pain from the hail, though.
Once home, I ate, blogged, and played a game (Jamestown) with all of my roommates.
Monday, June 4
We started the day with a short C++ lesson (all review for me), then 3 hours of unscheduled time. I used that time to catch up on my blog and find papers for the DataViz (my research group focusing on data visualization) literature review. We went out for lunch and found a university food truck standing in for a closed dining center.
When we returned, I went to continue blogging when I saw that all of my posts disappeared! I asked my coworkers if they had seen anything like it, but I seem to be alone. I sent an email to the VRAC IT team and got a prompt and confused reply.
We had a second C++ class (another review session) and then I did some more DataViz lit review. I went to the apartment, called home, and played some games with Ahmed and Stephan before doing a bit of school work and going to bed.
Days 5 and 6
Saturday, June 2
I woke up, cooked a box pancake (so cheap!), did some homework (my home institution isn’t done with the term yet) and did some more blogging.
We went to Summerfest, walked around long enough to see that we aren’t the target audience, and wandered Ames/campus a bit on the way to the gym. Nearly everybody was there playing Volleyball, Badminton, Basketball, and eventually I pulled Inshira and Stephan off to boulder.
We headed back the the apartment briefly before heading upstairs to the girls’ room for some card games including Uno, Spot It, Gavitt’s Stock Exchange, Egyptian Rat Screw, BS, and Spoons. We went to bed late, but the group only shrank from 11 to 8 (out of 12) by the end.
Sunday, June 3
Typical Sunday morning followed by… lots of ants! We improvised a solution with cleaning supplies, and several hours later it’s still looking like they’re gone (update: new scouts…). I did a bit more school work, then went to the water park with Aidan, Kira, Victoria, Ohana, and Leila. We had a lot of fun on the slides, lazy river, and diving board. The weather was a bad mix of cold when wet and hot when dry, but it didn’t take away from the fun.
We got back, made food, then went upstairs for another game night. Not quite as good of a turnout as last time, but still over half of us. We had a great time and went to bed at a much more reasonable time for work in the morning.
Friday, June 1
We started the day by taking Myers-Briggs tests and then discussing the unscientific qualities of that categorization system. After looking through some research papers, we concluded that it isn’t a good idea to base any decisions on the results. After that discussion, we heard a presentation by an engineering librarian about what resources the campus library has to offer, how to search for published papers, and who to ask for help.
We took a VRAC technology tour next, which really means trying on some headsets and looking around/demoing the C6. I’m pretty familiar with where the industry is right now in terms of head-mounted displays, so the headsets just offered me the fun of watching other people’s first times. The C6, a nearly-unique room-size virtual reality device, might’ve brought up more questions than it answered. The idea is that you stand in a 10x10x10 ft. box that feels like it’s made of glass. Each side has several projectors to put a 3D image on that wall with the perspective dynamically changed according to the position the head tracking system reports. The largest limitation is that it can only create the illusion for one person at a time. If your head isn’t tracked, the perspectives are wrong (proportional to your distance from the head that is tracked) and it breaks your sense of presence in the virtual environment. I’m curious about a few of the design decisions, because it seems like the whole setup could be built for a tiny fraction of the price we heard, but it might just be a product of how old it is.
We went to a high-calorie sports bar for lunch, blogged for half an hour, then went to ARG (Affinity Research Group) training. This recurring class focuses on providing tools for diverse groups to work well together. At the end of that, we got into our research groups and discussed milestones and meeting times.
We went to one of the gyms on campus, got properly registered, and toured the facility. I hung around at the end and bouldered with Aidan for a little while before heading to the apartment and calling home.
Thursday, May 31
We got our internet usernames (NetIDs) for logging into integrated services like email and WordPress. It took a while to get everyone through the process; there were quite a few hiccups and the VRAC IT team stood by to help.
We heard short presentations from each of the four research leads explaining our projects for the next 10 weeks. I think we were all a bit disappointed to hear that, despite being in the VRAC, none of our projects inherently include VR, and two of them (Biosensors and TIMELI) simply cannot.
After group presentations, the 12 of us split off into our research groups and followed our mentors to their respective labs. Victoria, Ohana, and I went to Black Engineering with Dr. Dorneich and Jacklin Stonewall (a graduate student in his lab). I was pleased to see flight sim hardware and a Vive tracking system set up, but we also might not use any of it.
The biggest takeaway I got from the DataViz small group meeting is that this project is incredibly squishy. We’re looking to solve a vague problem, then evaluate the result with vague metrics. It’s up to us to do a literature review and define the goal and the metrics, but that seems to be the norm in the research world. It’s a very big change from the standard school project method, where you’re handed specific requirements and have no say in what you’re doing (only how).
Next, we went out to lunch with those same small research groups. We went to a burrito place and talked a little more about our backgrounds. After eating, we returned to the lab and took a survey before starting our first class: Craft of Research.
We learned some basics about why, what, who, etc. in the research world. As an exercise, we answered some questions about our individual projects, like who will benefit from it or what readers will already know before reading the paper.
So far, no signs of homesickness.
Wednesday, May 30
We started the day at 8am and walked to Howe Hall, where the VRAC is. We ate a modest breakfast, signed some paperwork, and did a pre-program assessment, all in the conference room. After all that (about 2 hours), we toured Howe Hall.
After leaving Howe Hall, we took a campus tour and got our ID cards along the way. We talked about the places where we can eat and then went to West Street Deli for sandwiches.
After lunch, we returned to Howe for more activities and orientation. At around 3:30, we headed back to the apartments on our own and had some trouble finding building 43 among the maze. Once inside, I filled out the Inventory and Condition form, which involved testing everything that moves and checking every surface for damage.
Once that was out of the way, I called friends and family at home (one is at another REU, actually!) and then talked to Stephan extensively about number theory until bed time.
Tuesday, May 29
The first thing I noticed when I stepped out of the airport was the humidity. I’m from Corvallis, Oregon, and humidity is never a concern. I grew up in Iowa, so the weather was a harsh reminder of a part of the Midwest I don’t miss!
We loaded our luggage into the two SUVs waiting for us in the parking lot and drove up to Ames. Angelica, our driver, is a graduate student at the VRAC. She pointed out landmarks like the gold dome of the state capitol building in Des Moines.
Our first stop on campus was the administrative building for Frederiksen Court. We signed some paperwork, got our keys, and walked over to our respective apartment buildings.