Collab-Anno Daily Report 6/9/2020

Written by: Rajen Tandel

On Sunday I put together the basic contents of the homepage when not logged in. Today I will build out the interface for when the user is logged in. For now, I am working on the page for a registered teacher. He or she will be able to add students, upload PDF files and assign these to students. The students (or the student’s parent if a younger student) will receive an email when the teacher assigns the PDF. The student will then create an account. The dashboard will contain the student’s assignments. The annotations the student makes to the document will be saved via a save button that will be added to the PDF component. The teacher will be able to see the student’s annotations as they work.

Action items for today:

  1. The LoggedInTeacher component (name under construction).

Collab-Anno Daily Report 6–7–2020

Written by: Rajen Tandel

Yesterday I managed to get a basic registration and login form. Next step is to design the landing page. The landing page can be pretty simple.

It will include:

  1. An introduction to the application
  2. The login form
  3. A button for the registration form.
  4. A link to the github repo.

Easy enough to develop today. I haven’t written a detailed about yet so I’ll just be using some lorem ipsum text as a placeholder.

Collab-Anno Daily Report 6/6/2020

Written by: Rajen Tandel

Today I am going to clean up the code base and work on defining the flow of the application. Currently, all it does is take in a URL to and displays a PDF file. It also uses Socket.IO to create “rooms” specified by the PDF name. This is so that multiple users can annotate the document (the point of the application). The basic annotations, highlight and underline, are functional for now.

I am thinking the workflow will go as follows:

  1. A user (or teacher) will register for an account.
  2. Once logged in, the teacher will be able to upload PDFs.
  3. The teacher will be able to define “rooms” for certain students. If the teacher would like each student to annotate a document independently, he or she would create a separate room for each student.

This is where I will start this week. Today I will begin with the Login and Register forms.

Collab-Anno Update 6/2/2020

Written by: Rajen Tandel

After two years away from this project, I am going to continue working on it. Collab-Anno currently uses Socket.IO to allow multiple users to annotate a PDF file. It also creates rooms so that the annotations for a penguins.pdf file don’t spill over into a different pdf file.

Next Steps:

  1. User authentication
  2. Application workflow

User Authentication

There will be two options, create user and login.

The createUser will be a new form component which will take the user’s name, school name, and class name. Later, we will implement a way to distinguish users as admins/teachers or students with different permissions. For now, all users are considered equal.

I will implement this login page this week.

the moral machine – a walkthrough

Written by: Reece Adkins

This summer, I am working on a project that will be used as a educational tool for computing ethics. Exciting stuff. It actually is pretty sweet, and I'll detail that project in a later post.

Educational tools for computing ethics already exist; MIT made one called "The Moral Machine". They describe it as "a platform for gathering a human perspective on moral decisions made by machine intelligence, such as self driving cars." So, this tool is not only educating you on the decisions self driving cars may be expected to make, but also collecting your data as research in the process. In this post, I'm gonna judge scenarios in the moral machine and walk through my decision process.

If you have not completed MIT's Moral Machine yourself, please do so before reading the rest of this post. You can judge moral dilemmas here.

In each of the following scenarios, we will view a self driving car that is careening towards a cross walk and has suffered from a sudden brake failure. We will decide whether the car should continue straight or change lanes before entering the cross walk. The scenarios are randomized - you will not have the same ones I did. Also understand that there is no correct answers for these situations; all of the following is merely my personal opinion.

Scenario 1

I believe the car should swerve.
Here, if the car continues straight, it will kill 3 pedestrians in total - two men and an elderly woman. If the car swerves, it will crash in to a concrete barrier and kill the 3 passengers in the car - 2 boys and 1 girl.
Notice that whether or not the car decides to swerve, the same number of people are killed. The pivotal question here is, should the car protect the lives of the people inside it, or the lives of the pedestrians on the cross walk?
Because the pedestrians are abiding by the law and using the crosswalk as intended, I believe the car should swerve and hit the concrete barrier. I believe that when the passengers got in to the car, they assumed the risk of the car crashing and causing injury to them. The pedestrians have made no such decision and are merely crossing the road lawfully. As such, the car should swerve in my opinion.

 Scenario 2

I believe the car should not swerve.
Here, if the empty car continues straight, 2 pedestrians will be killed - an elderly woman and a baby. If the car swerves, it will kill 5 pedestrians - an elderly woman, a baby, a criminal, a large man, and a male athlete. Here, either decision results in loss of life, and the car is responsible either way (but what person is responsible for the loss of life since the car is empty?). As a result I believe the car should make a utilitarian decision and take the path that results in the least loss of life. I think the car should continue straight here, not swerve.

Scenario 3

I believe the car should not swerve.
This scenario is very similar to scenario 1; however, the pedestrians are breaking the law by crossing the street when their stoplight was red. By my logic in scenario 1, I believe the pedestrians are in the wrong here for breaking the law, so I think the car should continue straight and kill the pedestrians. Execution for jaywalking?! Ever heard of proportionality in punishment? Did I say the punishment fit the crime? Absolutely not. Someone has to die here, and the utilitarian argument doesn't make sense in my opinion because one party is breaking the law, and one is not. They assume the risk to be hit by a vehicle when they crossed the road on a red light.

Scenario 4

I believe the car should swerve.
This situation is identical to scenario 1, but the numbers have changed; there are more pedestrians than passengers. This does not change my argument, and I believe the car should swerve to hit the barrier.
I also am not taking the identities of these people in to account. In this scenario, a life is a life. I don't care if you're homeless or you're the president. You're equal in this scenario to me. Oh yeah Reece? What if your wife and kids were in the car?? Then you wouldn't assume everyone is so equal. Maybe you're right. But if I put my family in the car, I better know that the car is in working order. It's not these pedestrian's fault that my car didn't work properly.

Scenario 5

I believe the car should not swerve.
A lot of these situations are similar, with subtle fluctuations in the number of people. As in scenario 3, these pedestrians are breaking the law. They assume the risk, so the car continues forward.

Scenario 6

I believe that the car should not swerve.
Guess who is breaking the law again? Same logic as scenario 3 and scenario 5.

Scenario 7

I believe that the car should not swerve.
Okay, this one is interesting. Either the car strikes and kills four animals, or four people. While I said before I believe in the least loss of life when the car is choosing one lane over another, I am specifically referring to human life. How do I justify that? A domesticated pet does not have the societal worth that a human has. The loss of a human life will have a disproportional impact to other humans than the loss of a pet life would have. I am making a utilitarian argument in this scenario - arguing for the most good. There would be more pain and suffering for the families and friends of the dead humans than there would be for the owners of the dead pets.

 Scenario 8


I believe that the car should not swerve.
See my argument for scenario 3, scenario 5, and scenario 6. In this situation, the car either kills five younger people or five elderly people. The age of the person killed does not change the argument I have made for this scenario. But Reece, what if these elderly people feel so badly about the people that were killed, that they themselves die from depression? That is out of the scope of this scenario in my opinion.

Scenario 9

I believe that the car should swerve.
Either a legally crossing male doctor is killed, or an illegally crossing female doctor is killed. From the argument I have already made in scenario 3 and scenario 1, the female doctor should be the one who is killed.

Scenario 10

I believe that the car should swerve.
Same deal as the last scenario.

Scenario 11

I believe that the car should not swerve.
The elderly gentlemen is responsible for his own vehicle's error when all other parties are obeying the law.

Scenario 12

I believe that the car should not swerve.
This one is tricky, because my answer to this scenario breaks my previous arguments. Didn't the passengers assume the risk when they get in the car? Why do the helpless cats have to die? Because it is not ethical to choose an animal life over a human life ever in my opinion. My arguments only apply to human lives.

Scenario 13

I believe that the car should not swerve.
So here we have an equal loss of life whether the car swerves or not. For this decision, we must consider the fact that the car swerving is a choice. We are choosing to take the lives of group B instead of group A. Group A is currently in the lane that the car is already in, so making the choice to save them for group B would not be ethical in my opinion, since the loss of life is equivalent in either choice. We should only actively make the choice to swerve when there is an ethical argument to justify it. Here, there is not.

Understanding my Judgement

At the end of the activity, you have the option to better help MIT understand the decisions you made. I decided to do this. Here are the answers I provided:
  • Upholding the law does matter
  • Gender preference does not matter
  • Social value preference does not matter
  • Fitness preference does not matter
  • Protecting passengers matters slightly more than not (depending on situation)
  • Age preference does not matter
  • Saving more lives matters slightly more than not (depending on situation)
  • Avoiding intervention barely matters (only in situations where either choice results in an equivalent loss of life)
  • Humans matter more than animals always

Results

Here are the results that MIT's moral machine provided to me, and how they compare to the rest of the people who have completed the simulation.
Permanent link to my results

Reflection

The moral machine gives us a very interesting glimpse in to the decisions that software engineers are having to program in to self driving cars. While these situations will rarely (if ever) occur, someone still has to make a decision on what should happen if they occur. I think every situation should be considered independently, and there is no argument that works for every possible situation. I employed many different ethical frameworks (utilitarian, Kantian, ethics of care) across the various situations presented. While this scenario does resemble the trolley problem, I do not believe they are equivalent. There are many more factors in play here, and many more cooks in the kitchen.

What do you think of my answers? If you completed the moral machine, let me know how your answers differed from mine. This is a very interesting conversation to have, and I love that MIT has given us this tool to do so.

my origins in code

Written by: Reece Adkins

Most real geeks will scoff at you if you have HTML or CSS listed under programming languages on your résumé. Learn a real programming language, you simp. In all fairness, they're correct; HTML is really a markup language (along with things like XML and LaTeX). CSS is a "style sheet language", basically meaning that it is used to style and perfect the look of your HTML documents. I will have more on this distinction in later posts on this website.

Starting Out With HTML

For me, HTML was the first thing I had ever worked with that looked like code. Keep in mind, I never wrote a line of Java until my sophomore year of college. It didn't matter if I was actually writing actual computer instructions or algorithms with my HTML; I had no notion of what these things actually were. What mattered is that working with HTML made me feel like some sort of elite hacker 👨‍💻, or like I had transcended onto a higher plane of the internet 😇.

The first time I ever started using HTML was to add cool images and widgets to my MySpace page (circa 2007). There were websites that had lists of tacky gadgets, and you would just copy that code on to your page. So I would spend an hour tricking out my page with songs that I liked and cartoons that I enjoyed watching, and immediately send my 5th grade teacher a friend request.

Bulding My First Websites

Around the time I started high school, people I knew were building websites. I am a child of the age of the internet; as I grew, so did the web (I guess that's true for anyone in the last, like, 30 years). Friends of mine were building blogs and online communities (discussion forums and other sorts of pages) surrounding hobbies and activities that I enjoyed. This led me to start building websites of my own, and the beginnings of that were building blogs on WordPress or Blogger.

I used the wayback machine to find this blog I published in 2011 (I would've been 13 years old at the time of publishing). What I did is I took a pre-made blogger template that I found somewhere on the internet, and completely tricked it out. I did this many times for many different websites. Change the fonts, links, colors, styles, and locations of everything on the page. I'd continue tweaking it over weeks and months to get it exactly the way I wanted. Eventually, I would just end up deleting it and starting over, so no blog I ever made had more than a few posts.

Years later when I was a senior in high school (2014/2015), I was in an engineering specialty center. I wanted to be a mechanical or civil engineer. Senior year was rough, so I didn't actually end up getting the "seal" for finishing the program. The director of the program at the time took me on as a teacher's aide, and asked me if I would be interested in working on the website for the program. I said I would, and when I pulled it up, it was the worst looking website I had ever seen. Nobody there knew how to make a webpage, so I decided to build a new one from the ground up.
This was the website I had rolling after a month or so. Just a straight up, static, front-end only web page that was created solely with HTML and CSS. I used Adobe Dreamweaver to set up the basic layout, and did a lot of the formatting myself in the code.

Each day for that aide position, I would come in to the office and there would usually be a mound of papers for me to shred or file; after that, they would turn me loose to work on this website. I barely worked on it. Most of the time I spent in that office was procrastinating on homework by playing flash games and browsing the internet. Even so, people there were impressed by the website. A particularly difficult and stern teacher in that program told me right before graduation that I needed to do "Computers". Just "Computers". That was it.

This website is still used by that program as their official website. Exactly the same as the day I left. The only thing they changed is they updated the photos on the staff page for new teachers that have been hired since I left. It is still filled with embarrassing photos of my friends and I from sophomore and junior year of high school, and it continues to live on the internet as one of the first websites I ever built.

Rite of Passage

After starting in CS, I was never interested in being a web developer. I never found it interesting or compelling enough to be the direction I wanted to take my career in. A project I worked on last summer had me working with JavaScript, database tables, stored procedures, data persistence, browser cookies, networking, and a bunch of other web development tech. It was a true full-stack web application, and it helped me realize that web development is not about making those pretty word documents I was building in middle and high school. Web development is real, actual computer science.

So, this independent study will be like a rite of passage for me. It was building web pages that initially peaked my interest in learning how to program. People around me encouraged me to pursue CS after seeing web pages that I built. Even though I've been exposed to most of the topics I will cover in this class, I still have a lot to learn. There's something very satisfying about bringing my web development skills full circle as the last class I will ever take as a college undergraduate.

Ambiguity as a Resource for Design – a Review

Written by: bnjmnjackson

Reading – Ambiguity as a resource for design, by William Gaver, Jacob Beaver, and Steve Benford

Ambiguity is often seen as a quirk to be avoided, and for good reason. If your results are incomprehensible, then your research may be wasted, but ambiguity can also be used as a pointed tool, getting results much deeper than otherwise expected. When you want your research to be intriguing, thought provoking, and other buzzwords, it may be useful to implement strategies harnessing ambiguity. This paper talks about creating ambiguity in three ways. Ambiguity in information, contexts, and relationships.

Ambiguity in information sounds extremely counterproductive, but hiding some, and not all, of your information can force the interpreter to fill in the gaps in ways that are personal to them. If you’ve ever seen the Mona Lisa by Leonardo DaVinci, you will likely recognize that she does not have a clear expression. This is due to the softening of detail around the mouth and lips. As a result, the viewers are the ones that must interpret the expression themselves, a valuable intellectual task the artwork easily asks.

“Point out things without explaining why…”

Secondly, there is ambiguity of context. Take the idea of a phones ringtone. Straightforward and obvious to its purpose of letting you know someone wants your attention. However, it is just a sound, that can have a multitude of uses. Some mothers download a soothing, soft ringtone, and put the phone near a young child. Calling the phone turns it from an alert to a lullaby, something that phone manufacturers were clearly not anticipating. The ambiguity of the cell phone ringtone comes about in the context which it is used, either alert, or lullaby.

Lastly, there is ambiguity in relationships. Although similar to ambiguity of context, ambiguity of relationships has its uniqueness. The Home Health Monitor encapsulates this well. The Home Health Monitor is a device in a home that monitors and gives feedback on the home’s emotional, physical, and spiritual health using various sensors- ie. light, temperature, door-openings, or even window condensation or hair brush tempo. Oddly enough, however, the feedback is given in horoscopes, not raw data. Punchline- although it may not be clear to the user why specific things are being tracked, they will nevertheless respond in their own unique way, depending how they interpret their own relationship with the various things being tracked.

So as a whole, we can see that tactile ambiguity pointed at users can force them into situations asking them to fill in the gaps, allowing the researchers to likely learn more about the person(s) than if they simply asked pointed questions.



Another (More Modern) Look at a Use of Cultural Probes – How Does the Team make a Kit, Start to Finish.

Written by: bnjmnjackson

Reading: A Blog post by Catherine Legros on Medium.com

Catherine Legros, A student and design intern at the time of writing, has boiled probing down to 4 steps, which I think are quite accurate, and easy to follow and explain.

1: Conceptualizing ideas, and finding the right activities. We can put all the possible questions or concerns we have in a comprehensive list, and see how efficiently we can make overlapping probe tasks. We don’t want to have a single unique medium for each question/task we have, as that would lead to a large kit that may not feel grounded.

2: Design and instructions. How do we organize our tasks and mediums? We by now have all of our tasks, and likely most/all of our mediums, but we need to present it in a meaningful way. For example, a to-go bag with tasks and a placemat for at-home activities. Maybe some timer to keep the user engaged. That is, some way to say ‘this today, that tomorrow, this on the last day…’ The punchline – What do we want our audience to see?

3: Execution. Making the kits. Using materials that have a friendly connotation, and final kits that have been put together in some cohesive way. This will change based on your target audience and mediums/tasks.

4: Results. We know that this is a qualitative analysis, but there are some non-obvious helpful points. The results should be analyzed as a team, as for something as abstract as this, a single set of eyes may fixate on some point, or miss another. Be ready to have your ideas change. That’s okay, and probably expected.

But How Do I, the Designer, Go About Making a Probe?

Written by: bnjmnjackson

From Probetools.net

By now, we know all the buzzwords. A probe should be playful, open-ended, evocative and creative and should attempt to illicit responses that spark inspiration. But what does any of that mean to the designer?

It is impossible — and not in the spirit of the approach — to specify precisely how to create a successful Probe study.  We can offer a few tips, however, based on years of experience.

Probes are a glorified collection of tasks. It’s up to the designers to create both the tasks, and the medium(s) of response. Although these kits are bordering on an art form, we can still make some generalizations. We know that we want to keep tasks on-topic (say we’re working with internet usage, we don’t want to ask how often they go drag racing) but we also don’t want to be too direct, lest we lose a lot of creative space. Here’s some general good ideas for task inquiry:

~Ask obliquely related questions. Instead of What do you use the internet for? Try How do you gossip with friends?
~Use analogies. Try What kind of vacation spot would the internet be?
~Ask general questions. Try Computers. Blessing or a curse?
~If you want to get more specific, try indexical questions. ie. What did you use the internet for last weekend?

We can also get more specific into visual medias. Not only should we ask for things we’re curious about (obviously), we should also encourage those probed to point the cameras or whatnot in directions they wouldn’t have if we simply asked them to document their lives. While the answers to our inquiries are important, there is also a great value to unexpected details and textures uncovered.

Probes generally consist of 6-15 tasks. Having a variety of tasks can: (quote- Probetools)

  • can gather different kinds of information
  • tend to be more engaging for participants
  • play to volunteers’ strengths and interests
  • allow participants to choose which tasks to do
  • can vary in their degree of playfulness v. focus
  • allow some to fail without destroying the study

It should be noted in conclusion that, once again, this is not a scientific method. It’s a method of design, which is closer to an artistic study than a data-driven scientific one. We need to work with useful styles and themes, while staying fun and less-than-intimidating.

Cultural Probing Yields Subjective Data, and Attempting to Derive Otherwise is Likely a Waste of Time.

Written by: bnjmnjackson

Reading: The Value of Uncertainty – Gaver, W, Boucher, A, Pennington, S and Walker, B from Probetools.net

After acquiring a general knowledge of Cultural Probes, one may believe that it is foolish to intentionally receive data that cannot be quantitatively analyzed. Groups may try to send out their own probes, asking pointed, unambiguous questions, so the responses can be directly analyzed without breaking a sweat. And after Gaver’s team’s first study using these probes in the late 90s (see Cultural Probes), several groups did.

These teams are missing the point.

Let’s open right up with the basic reasons as to why this is. If we ask pointed questions, we likely already have a good idea as to the expected answer. But what about asking exploratory questions, and then attempting to “Scientifically” analyze the results? Solely analyzing probes as an average group of data will often lead to a more defined set of data, sure, but this data will likely be mediocre in it’s reflection of the group, and completely miss unusual ideas, which are often the most inspiring. Furthermore, only looking at responses that are justifiable further constrains the imaginative possibilities of the designers.

It is understandable that this may be rather different to what many are used to. We learn starting from high school biology about quantitative data and analysis, the Scientific Method, etc. So much so that it’s likely seen as “The way to do science” to many people. If you’ve never worked in a department that focuses on qualitative analysis, it may take some convincing to see it’s value… Here’s my attempt.

Five years after Gaver’s first successful use of Cultural Probes, he is now a part of another project. This time, he and his team are pursuing new technologies for the home. They once again decided to use probes to get an understanding of given homes. (Not houses in a material sense, but homes in a personal sense to their homeowners) Some examples of items in the probes this time were – Disposable cameras, and dream recorders. The cameras, once again came with requests. Most of these requests were extremely open-ended, or arguably bordering absurdity. Ranging from “The most uncomfortable place in your home” to “Something red.” The point is not only to see how these homeowners would respond to such requests, but also give the team glimpses into parts of the home that would may have been overlooked by the homeowner. At the very least, it confided to the homeowners that the team was not coming in with a specific goal, and that this probe was in no way a facade.

The dream recorders were cheap microphone devices with only a pull tab and an LED. When a participant awoke from a dream, they pulled the tab, and had 10 seconds to describe it before the device shut off. No editing or re-doing allowed. These were, unsurprisingly, extremely provocative, but also often summarized the participants’ lives in a few words.

“What is the point of deliberately confusing our volunteers and ourselves? Most fundamentally, it is to prevent ourselves from believing that we can look into their heads… it is impossible to arrive at comfortable conclusions about our volunteers’ lives or to stand back and regard them dispassionately.”

Gaver, W.W.

The probes gave the team a feel for the individuals they were working with, as the results were intensive and multilayered, and that was the whole goal from the start. There were many interesting jumping-off points from the photos, backed up by the personalities seen in the dream recorders. It’s clear to see that these probes would not have accomplished what they did if it were not for the encouraged subjectivity from the volunteers. As Gaver describes it,

“Probology [probe-methodology] is an approach [using probes to] encourage subjective engagement, empathetic interpretation, and a pervasive sense of uncertainty as positive values for design.”