I’ve been sick for the days I wanted to do the poster, so it’s substantially lower in quality than I wanted it to be and I haven’t submitted it for printing yet. I intend to do so before noon tomorrow.

Also because of illness, I have no other progress to report. Timeline:

• Finish the poster tonight (R)
• Submit the poster for printing tomorrow (F)
• Revise the paper for the last time (S)
• Poster presentation (T)

Most of that is either on schedule or only slightly behind. The part of the project that will be set back most by this is the software component, which is in good enough shape that it is now lower priority than all of the other items.

I met with Charlie this morning. Due to feeling increasingly sick throughout the day I haven’t finished the poster as planned, but I know what needs to be added on Thursday – just a few hours of work on that day, print either that afternoon or first thing in the morning Friday.

Wanted to update to make that clear.

I hope that my only requirements in the final version relate to style and language: adding the appropriate academic structure, rephrasing sentences and paragraphs, maybe moving something here or there.

I hope not to need additional content, though it’s possible that some section will need an extra paragraph or two.

It’s certainly enough for the poster.

The paper was my project for the weekend. I had intended it to be the final version, in order to be done with it entirely before exams and other projects came due, but I will instead consider this version the second draft and submit it to that slot on Moodle.

More specific status of the paper:

• 6 pages, including references and charts
• Wording is still shabby. I’ve emphasized completing the page count and choosing the correct scope, and therefore left wording and flow problems to the final draft.
• I updated the flow diagram to include arrows and better logical grouping of objects and information.
• I incorporated examples of interface design from Apple and Nextdoor.
• I expanded the description of the software, its current state, and what it could become in the future.
• I expanded the section on the social significance of HCI and behavior changes.
• In the final version I will also revise the abstract, move sections around, and remove the cruft. The revision is the time to subtract, not add.

It’s a good second draft. It would be a bad final draft.

This week I will accomplish three things:

• Complete the final draft no later than Sunday night.
• Complete the basic software and clean up its git repository.
• Create the poster, lifting much of the content from the paper and building on a library template.

Looking forward to others’ presentations on Wednesday.

Notes post-presentation, including a few features I need to complete the base version of the code:

• Ran long but that’s fine.
• Need the URL’s input by the author to be written to file
• Need to choose start URL’s from a file
• Need to produce a randomized-choice start URL for the user
• (Database may add overhead, for now focusing on text files)

Now I’m putting the project down until this weekend, to get some other work done. This weekend I will complete the software and paper. If there’s time I’ll do the poster.

I am shortly going to complete the presentation for this class and a quiz for another, but I made massive progress today. It is not perfect but it has enough functionality for a demo tomorrow (though because it’s not perfect I’ll spend some time tomorrow afternoon practicing).

What it can do:

• works as a developer extension with basic functionality: has an icon, proper structure, several web files, and no privacy-compromising information
• logs messages to the JavaScript console (more verbose if the developer enables debug output)
• publicly accessible on gitlab

The core functionality deserves its own bullet points:

• on activation of the extension, start time is recorded
• on each new page, gets the URL
• compares the URL to each line in a file of acceptable stop URL’s
• if there’s a match, stop and send a message to the console with a timestamp of how long it took to get there

What I may still be able to do between now and tomorrow’s class but can’t guarantee:

• author inputs stop URL’s, those are written to a file by JavaScript for comparison
• start_time begins upon clicking the icon rather than upon activation (this should also change the icon in some way to show the state change)
• rename on gitlab so it isn’t known now and forever as “craig1617”

See my git commit messages here.

I’m not sure how much more work I’ll get done on this software this semester. I hope more, because it’s got a lot of promise and a good foundation, but I would be satisfied with this for purposes of the course grade given my other academic constraints.

I solved multiple issues just by walking through this diagram …

… and it’s not even complete, I suspect. Subject to examination tomorrow morning.

Progress relative to what I anticipated: basically good. Details:

• I process text from forms and can populate and reset those forms. I can open URL’s and produce timestamps (and therefore time intervals). The basics, in other words, are done.
• I know a whole basket of potential URL problems that will need to be solved in future iterations of the software.
• The page’s appearance is plain but not completely offensive.

The biggest problem is that it does not (to use my metric from yesterday) “work, start->finish.” I’m planning to spend tomorrow much like today, except more emphasis on coding and testing. I will produce my presentation in the evening and demo what I have (which I will consider the final version, for purposes of this course) on Wednesday.

Also here’s a silly throwback to when I was initially doodling that diagram in Jot! for the iPad.

Thanksgiving is over. I exercised my prerogative to take a break and did no work in the last week. I also chose to give my final presentation this week, so I have a firm timetable that prioritizes this project (both code and paper) for the next week.

To wit:

• Sunday, 11/27: Implement the basic JavaScript functions for submitting and processing URL’s; working on using Date.now() in JavaScript for time-stamping
• Monday, 11/28: Create an electronic and more detailed version of the flow diagram in the morning, make the code actually work, start->finish, in the afternoon
• Tuesday, 11/29: Ask Charlie questions in the morning; finish what’s left over; in the ideal world, I would spend the afternoon just getting the aesthetics right, but I suspect complications will lead to a fairly sparse interface (ironically, for an HCI project)
• Wednesday, 11/30: Final presentation, no further work on the software for this course anticipated
• Saturday and Sunday, 12/05 and 12/06: Finish the paper – read and write Saturday, revise Sunday, submit as soon as it’s available

There are a number of pitfalls I can foresee, and the reasons I would fall short of completion by Wednesday would most likely be because one of the following proved more complex than anticipated:

• Moving from a web tool to a Chrome extension
• Parsing URL’s
• Data collection and storage
• Timers
• Exception handling

In short, this week will be mostly devoted to this class (and the following two weeks will emphasize others).

I am spending today (Tuesday) writing the paper. I have now written all section and subsection headers that I need into it and started incorporating useful bits of the proposal as a baseline.

In an effort to produce a working version of the software, the following are my goals for the rest of the day:

• paper: fill out the sections and revise what already exists there
• software: complete a bit of php code to interface with PostgreSQL, write starting html, create flow diagram

This means that the following will be delayed for the second draft and the poster:

• paper: add content, specifically expanding the Related Works section
• poster: import content from paper, adjust form
• software: a complete working base case

The final version of the paper will be a revision of the second draft, in which I will remove cruft rather than add content. The software version as of December 12, when the second draft is due, will be the last version of the software I work on for grading purposes in this class.

I intend to work minimally over break, so what I complete this week is likely all I will complete before the return the following week.

I did a little more reading this weekend. Tomorrow (Monday) I’m occupied with meetings and classes, but I’m dedicating all day Tuesday to concluding my readings, completing the first draft, and (I hope) finishing iteration zero of the software.

Because of recent disruptions I am not keeping pace with my imagined progress from a few weeks ago, but Tuesday should catch me up enough that I can return from break and complete everything satisfactorily.

I didn’t accomplish anything the first few days of the week. Today I want to read some more sources and finalize the paper topic. I may start incorporating the survey paper into the draft, so I can start building up the page count.

Nothing new from this weekend. Today I’m considering the IO of the URL’s for the software and, if that goes well, writing the code to create the visual interface. I’ll outline the paper and gather final reading material tomorrow. At the end of the day tomorrow I’ll post a comprehensive update.

For the last couple of days I’ve been walking through a simple Chrome extension, HexTab, the source code of which is open and published on GitHub. The functionality is nothing like mine, but it has the virtues of …

• being simple and open-source
• relying on just a few JavaScript/HTML/CSS files and therefore being easily adaptable
• being well-organized (in contrast to a few others I’ve looked at)
• obeying the Chrome naming/organization guidelines to the best I understand them (it occurs to me that those guidelines may be worth mentioning in the HCI context as well as Apple’s)
• being complete enough to build from

I would like to start hollowing out this code soon, but I’m spending a while reading the code first.

Presentation went well today. No project updates, except that I’ve decided that I hope to complete a working software version by the end of November so I can focus on the paper during December. (This will not interfere with completing the first draft by class in two weeks.)

Accomplished since 10/28 post:

• Completed the IRB form, pending approval by Charlie (most likely it will need revised but could be submitted by class on Wednesday)
• Drew a design of the minimal version of the program, more comprehensive design pending

Next to work on:

• Augment the minimal design by class on Wednesday
• Produce the presentation for Wednesday’s class
• Resume research and reading, the bulk of which I will probably do late in the week
• Find JavaScript code for an existing (open-source) extension, save it, and hollow it out to serve as the foundation for the Chrome extension

Catching up after traveling last week, I focused mostly on procedural bits for the project: opening an Overleaf project for the paper and getting the formatting/section headers right, researching Chrome extensions, and drawing some diagrams (about which more later).

I will focus on building up the paper for the next week. I also need to complete the IRB form (I’m about halfway through now) and the software design, which I intend to do by the time of the next class. Again see here for detailed timeline.

Never done it before, but Google’s guide here is a good start.

I was traveling late last week with some Physics research students, so my accomplishments for this project this time around are sparser than in the past. I’ll sit down tomorrow or Thursday to sketch out a design on whiteboard for how the process should work.

It looks straightforward enough to get started. That’s good, both because in the short time available I can implement something and because, if I have to change to a webpage or the like, I will likely be able to preserve some of the design without having been too bogged down in details.

Some other notes:

• Thanks to hackathon-winning Earlham students Eli Ramthun and Flannery Currin for help getting started.
• I see we’re going to start posting project updates daily starting tomorrow, which should be valuable.

First, the documents.

• Presentation
• Proposal

The proposal outlines some research on HCI, in addition to a proposed browser extension (Chrome) to facilitate easier interface comparison tests on the scale of academic and independent developers. I will complete an IRB form and a (visual) sketch of the software logic for upload by the time of the next class.

Revised timeline, copied from the proposal:

I spent some time over break reading The Design of Everyday Things, the first work of popular literature on user design I’ve read for this project. I’m about a third of the way through – it’s a quick and illuminating read – and I’ll finish the relevant sections soon. Some of his insights will certainly be included in the final product.

I want to move onto Ralph Caplan and a bit from Tufte this week, then spend next week focusing on the software component.

Basic idea right now:

• October: design, read, annotate, brainstorm, pick algorithms/data structures/languages –> outline and program specs
• November: write and revise, implement –> complete paper, draft of the associated poster, working code base
• December: polish and present

There will of course be overlap.

Also, our gitlab group is set up and we should all have our individual project repos set up soon.

Couple of things:

• The paper: craig_literature_review
• The presentation: craig_presentation

As noted in my update of the annotated bibliography post, I had cited one paper incorrectly there. This mistake was corrected and has not been repeated in the literature review.

First, the annotated bibliography, the preliminary version submitted two days ago: craig_annotated_bibliography.

Second, I want to outline my general plan here. After a meeting with Charlie this week and carefully reading some of the more fundamental papers for the topic, I have greater clarity about the project.

My general plan, subject to – potentially major – modification as the class assignments are posted, is as follows (each date is a deadline):

• 10-01: Read all papers and complete an annotated bibliography which can be melded into a survey paper
• 10-04: Complete the survey paper (technically due 10-05)
• 11-01: Produce outline of the paper and high-level software design
• 12-01: Done with paper, poster content ready, have some software developed
• 12-?: Poster and presentation with the others who will not be at Earlham next semester
• Regular presentations as they come due

I graduate in December so my project is somewhat more limited in scope than those who will be here the full year, but I anticipate a complete paper and a decent initial version of a piece of software by the end.

UPDATE: The annotated bibliography included here has been updated to correct a citation. Wang 2013, not Wang 2011, is the correct citation for the Facebook study.

I’m primarily interested in human-computer interaction (HCI) and, extending the notion further, how the principles of computer science, when applied through software or social networks, produce changes in human behavior.

In general I’m drawing my thoughts from behavioral economics, network theory, research into user experience of software, and the general principles of software engineering and structuring information.

My three ideas on that general theme follow. Each contains a paragraph about the topic, a few areas of computer science that potentially relate to it, specific examples I’ve encountered, and some project possibilities. Nothing in the descriptions is final, comprehensive, or definitive, so change is not only possible but expected. It’s also not clear I have the CS in every one of these ideas, but they’re moving the right direction. The list is unordered.

Nudges as a strategy in application design and development

We know that small changes in an environment can cause dramatic changes in behavior. In the social sciences, research has shown that switching employee retirement accounts from opt-in to opt-out, for example, can dramatically increase the percentage of employees who enroll in the accounts. Application and web developers must always consider how their design decisions, from the surface layer to the data structure layer, impact the human experience of interacting with the application and its information.

Computer science topics: HCI, Application/Web Design, Software Development, UI/UX

Potential examples: nudge literature in behavioral economics, campaign web design to encourage donations (Obama and HRC in particular, NPR story), user experience elements, Apple design guidelines

Project possibilities: Test two app designs (a la A/B testing) to determine how behavior changes; website designed to demonstrate the principles in various ways in the service of some simple task (to-do list, search, etc.)

Group behavior on social media

Group behavior on social media and the filter bubble: Social media wants to keep you onsite and, if you move offsite, to do it by way of their site. Therefore they want you to stay, and in turn they give you what you want (think Facebook’s News Feed algorithm). The problem is that this breeds the dreaded filter bubble, in which epistemic closure takes over and only things you like or agree with ever have to come across your timeline. Is it possible to design systems to reduce this problem and therefore improve public understanding and social behavior?

Computer science topics: HCI, Network Theory, Information Architecture, Interface Design, UI/UX

Potential examples: Nextdoor and racial profiling, Twitter harassment and quality filtering algorithm, Facebook News Feed

Project possibilities: website or mobile app analyzing data mined from Twitter or Instagram

How humans understand data

Big data is confusing, and we use visualizations to reduce the confusion and potentially communicate a message. Some vis forms are better – more comprehensible, less misleading, nicer to look at – than others. Does this matter for how humans experience the information? This emphasizes explanatory as opposed to exploratory data science.

Computer science topics: HCI, Application/Web Design, Scientific Computing, Databases

Potential examples: Dozens of vis/comp modeling websites exist now, so NYT Upshot/538/Our World In Data all potentially valuable; Tufte and other researchers in the field have covered this extensively

Project possibilities: Data visualizations of various kinds, some interactive and some not (may build on some existing projects at ECCS for this)