Writing Problem: Me, Myself, and UI


Learn about user interfaces and apply your knowledge toward predicting the future.

Academic Honesty

This course’s philosophy on academic honesty is best stated as "be reasonable." The course recognizes that interactions with classmates and others can facilitate mastery of the course’s material. However, there remains a line between enlisting the help of another and submitting the work of another. This policy characterizes both sides of that line.

The essence of all work that you submit to this course must be your own. Collaboration on problems is not permitted (unless explicitly stated otherwise) except to the extent that you may ask classmates and others for help so long as that help does not reduce to another doing your work for you. Generally speaking, when asking for help, you may show your code or writing to others, but you may not view theirs, so long as you and they respect this policy’s other constraints. Collaboration on quizzes and tests is not permitted at all. Collaboration on the final project is permitted to the extent prescribed by its specification.

Below are rules of thumb that (inexhaustively) characterize acts that the course considers reasonable and not reasonable. If in doubt as to whether some act is reasonable, do not commit it until you solicit and receive approval in writing from your instructor. If a violation of this policy is suspected and confirmed, your instructor reserves the right to impose local sanctions on top of any disciplinary outcome that may include an unsatisfactory or failing grade for work submitted or for the course itself.


  • Communicating with classmates about problems in English (or some other spoken language).

  • Discussing the course’s material with others in order to understand it better.

  • Helping a classmate identify a bug in his or her code, such as by viewing, compiling, or running his or her code, even on your own computer.

  • Incorporating snippets of code that you find online or elsewhere into your own code, provided that those snippets are not themselves solutions to assigned problems and that you cite the snippets' origins.

  • Reviewing past years' quizzes, tests, and solutions thereto.

  • Sending or showing code that you’ve written to someone, possibly a classmate, so that he or she might help you identify and fix a bug.

  • Sharing snippets of your own solutions to problems online so that others might help you identify and fix a bug or other issue.

  • Turning to the web or elsewhere for instruction beyond the course’s own, for references, and for solutions to technical difficulties, but not for outright solutions to problems or your own final project.

  • Whiteboarding solutions to problems with others using diagrams or pseudocode but not actual code.

  • Working with (and even paying) a tutor to help you with the course, provided the tutor does not do your work for you.

Not Reasonable

  • Accessing a solution to some problem prior to (re-)submitting your own.

  • Asking a classmate to see his or her solution to a problem before (re-)submitting your own.

  • Decompiling, deobfuscating, or disassembling the staff’s solutions to problems.

  • Failing to cite (as with comments) the origins of code, writing, or techniques that you discover outside of the course’s own lessons and integrate into your own work, even while respecting this policy’s other constraints.

  • Giving or showing to a classmate a solution to a problem when it is he or she, and not you, who is struggling to solve it.

  • Looking at another individual’s work during a quiz or test.

  • Paying or offering to pay an individual for work that you may submit as (part of) your own.

  • Providing or making available solutions to problems to individuals who might take this course in the future.

  • Searching for, soliciting, or viewing a quiz’s questions or answers prior to taking the quiz.

  • Searching for or soliciting outright solutions to problems online or elsewhere.

  • Splitting a problem’s workload with another individual and combining your work (unless explicitly authorized by the problem itself).

  • Submitting (after possibly modifying) the work of another individual beyond allowed snippets.

  • Submitting the same or similar work to this course that you have submitted or will submit to another.

  • Using resources during a quiz beyond those explicitly allowed in the quiz’s instructions.

  • Viewing another’s solution to a problem and basing your own solution on it.


Your work on this writing problem will be evaluated along three axes primarily.


To what extent does your submission align with the requirements of the specification?


To what extent is your submission correct and free of factual errors?


To what extent is your submission readable (i.e., thoughtfully organized, coherent, words properly spelled)?

To obtain a passing grade in this course, all students must ordinarily submit all assigned problems unless granted an exception in writing by the instructor.

A Brief History of Time

Suffice it to say, interacting with computers is getting easier and easier, though hopefully not because us humans are getting lazier and lazier. Nowadays, you don’t even have to physically touch your computer in order to interact with it, as voice user interfaces (VUI) have entered the mainstream.

Of course, before we had devices like Echo, the biggest innovation in user interfaces was probably touch-screen devices—​also known as tactile user interfaces (TUI)–in particular touch-screen smart phones. And of course, as we all know, the first-ever touchscreen smartphone was introduced by Apple in 2007 with the long-anticipated…​ wait, huh?

Hmm…​ well, there’s a fun fact! To be sure, touch screen interfaces existed before even the 1990s, but in the timeline of computing, they’re still a fairly modern spin on human-machine interaction.

We stole Apple’s thunder a moment ago, but to give them some credit, they did have the first commercially-successful modern graphical user interface (GUI) for home computing, with the Macintosh 128K computer, which was released in 1984. (Windows 1.0, the analogous Microsoft-produced operating system[1] was released one year later).

The computer mouse, which was popularized by the Macintosh 128K but was not itself invented by Apple[2], was critical to the success of graphical user interfaces because it gave humans a convenient and visually-intuitive way to interact with their machines; the gestures made with the pointing devices on the surface of the desk or table was replicated by the pointing arrow on screen.

Humans had, of course, long been able to interact with machines. But from the mid-1960s through the mid-1980s most of that interaction was done through a command-line interface (CLI) which can indeed be a bit more complex. (The Apple advertisement video above, though it cuts off the beginning, is effectively criticizing the then-prevailing enterprise computer system, the IBM personal computer, which required command-line interaction and came with a number of large manuals describing the various text-based commands one could use.)

Command-line interfaces are still quite common today though, as you likely saw from completing the problems in Unit 1 and working with CS50 IDE at the terminal. Many programmers still prefer command-line environments because once the commands are memorized, CLIs can be a speedy means of navigating one’s system, and they eliminate the need to use any part of the machine’s RAM to deal with the overhead that comes with supporting a GUI. Indeed, one way to resuscitate or salvage an older computer with much more limited RAM and a slower CPU is to wipe the operating system it came with and instead install thereon a lightweight flavor of Linux which relies exclusively or at least primarily on using a CLI instead of a GUI.

Permit us to take one final step back in the history of human-computer interaction. Before CLIs, GUIs, TUIs, and VUIs (enough acronyms yet?) humans primarily interacted with computers using batch interfaces. Programs were written by punching holes in cards which computers knew how to read but were submitted (in batches, hence the name), and output from those computers came via simple printers.

Phew! Aren’t you glad you don’t have to program with punch cards?

The Good, The Bad…​

In that history lesson, we omitted a large variety of interface types that popped up in between (though many of them are admittedly variations on a theme), but give us credit: we did disclaim that it was a brief history. In this writing problem, we want you to do two separate things, possibly filling in some of the gaps over which we jumped.

Open a text editor and create a file called ‘ui’ (be sure that the file extension is either .doc, .docx, .pdf, or .txt). First, pick two different types of interface and juxtapose them. You aren’t limited to the types we’ve spoken about above, as indeed there are numerous others. How are your chosen interfaces alike, and how are they different?

Try to go beyond the surface. Yes, a CLI is similar to a VUI inasmuch as both allow humans to interact with a computer. How else are they similar? One example might be that they both can be frustrating to use. A CLI requires you (the user) to learn the commands required to interact with the system by learning them from reading a manual; this requires time and effort. But a VUI can be tricky to work with, too. How many times have you use Siri or Google Now only to find it has completely misinterpreted what you said, requiring you to repeat yourself (perhaps ridiculously and loudly enunciating in a public space) in order to have the desired result?

The contrast part, we assume, will be a bit easier than the compare part. Again though, dig a little deeper than the obvious differences.

You should aim to write about 300 to 400 words in this part of the problem.

…​and the Future

The second thing we’d like you to do is to find the nearest crystal ball and take a little time to predict the future of user interfaces. Things have certainly evolved since the 1940s, but it seems quite unlikely that we’ve reached the pinnacle of human-machine interaction already. Where do you think things are heading in the next 5 years? 10 years? 50 years?

Importantly, don’t forget this question: Why do you think your prediction is the wave of the future?

If completely unsure where to begin, head to Netflix’s repository of science fiction movies[3] for inspiration. Your creativity is the only limiting factor in this part!

You needn’t write more than 200 words for this part of the problem (both write ups should be in the same file); predicting the future is tough work! Just ask a meteorologist.

How to Submit

Step 1 of 3

Go to https://github.com/submit50/USERNAME, substituting USERNAME in the URL with your own GitHub username. On the left side of the screen, click on "Branch: master". In the field that says "Find or create a branch…​", type cs50/2017/ap/ui and click "Create branch".

Step 2 of 3

Click the button that says "Upload files". Drag your ui.(doc, docx, pdf, txt) file into the box that says "Drag files here".

Step 3 of 3

Click the green "Commit changes" button and you’re done!

If you run into any trouble, email sysadmins@cs50.harvard.edu!

You may resubmit any problem as many times as you’d like before the deadline.

Your submission should be graded for correctness within 2 minutes, at which point your score will appear at cs50.me!

This was Me, Myself, and UI.

1. There’s actually a fascinating history of collaboration between Apple and Microsoft here, which is well worth reading up on to get some context about the modern game of rivalry and one-upsmanship between the two companies.
2. It was actually a successor (after several generations of design iteration) to the trackball, which was first invented in 1947!
3. Or, if you still have one in your area, the local video rental place. Just be sure to return the movie on time; those overdue fees are just awful.