Another year, another HackMIT FAQ readers experiment. From May 31 to August 7, we had the following item in HackMIT’s FAQ:

Like last year, the experiment wasn’t particularly scientific. We just wanted to give people the opportunity to email us random stuff.

Last year, we did a qualitative analysis of the emails we received, so for a change, this year, we took a very quantitative approach.

Basics

We had 227 unique individuals email us (compared to 493 last year). We responded to 220 of these people, giving us a response rate of 97% (up from 80% last year).

The distribution of response times was pretty good:

A handful of team members were responsible for the majority of responses:

Some team members got pretty competitive trying to be the fastest to respond to emails:

Time

Even though the experiment began on May 31, we received a lot more email once registration opened on July 1st, receiving the greatest number of emails on July 2nd:

People did sent us email at all hours, but the morning seemed to be the least popular time to send messages:

Domains

Unsurprisingly, gmail.com and mit.edu were the most popular email domains among FAQ readers:

Text

Emoji

Emoji were quite popular in our emails. Among all the emails that were sent and received, here are the most used emoji:

Apparently, the HackMIT team really loves emoji, being responsible for 67% of the total emoji use:

Sentiment

Luckily, the majority of emails we received were positive (according to a sentiment analysis engine):

Here’s the most negative email we received:

And here’s the most positive:

Conclusion

Okay, so most of this data analysis is pretty silly. It’s not meant to be taken too seriously! We had a great time going overboard and making pretty graphs.

In case anyone is curious about how we did the analysis, here’s a short summary. We archived all the emails that were sent to faq-readers@mit.edu, and after the conclusion of the experiment, we loaded all the data into a Jupyter notebook using Python’s mailbox library. We analyzed the data using NumPy, pandas, NLTK, TextBlob, talon, and emoji, and we made the graphs using matplotlib and Seaborn.

Thanks to Claire, Kimberli, Stef, and the rest of the HackMIT team for feedback on this post!

Lumen: Magic Auto Brightness Based on Screen Contents

I do most of my software development in my terminal, with my trusty tmux / zsh / vim setup. When coding, I frequently switch back and forth between my terminal, which has a dark background, and my web browser, where sites usually have light backgrounds.

One big problem with this setup is that my laptop’s backlight is either so dim that I can’t read the text in my terminal or so bright that I’m blinded by looking at websites. The problem is especially bad at night.

Many laptops support automatic brightness control, but it’s usually not very useful. Both macOS and Windows support setting screen brightness automatically based on ambient brightness, but the feature rarely comes in handy. It seems to cause more harm than good. I keep it disabled on my laptops.

A Better Way

What if laptops set screen brightness automatically, but based on screen contents rather than ambient brightness? I did some research, but I couldn’t find any software that does this, so I wrote my own tool.

This is how Lumen was born. Lumen is a tiny menu bar app for macOS that magically sets screen brightness based on screen contents.

Here’s what it looks like in action:

Configuration

In an early prototype, I had hard-coded relationships between the lightness of screen contents and the backlight settings that I desired. This turned out to be somewhat annoying, because my preferences changed slightly depending on the environment that I was in and exactly what I was doing. I needed to make the settings customizable.

It’s annoying to have lots of explicit on-screen controls for something that should be simple, so I implemented something that I think is a pretty neat feature. As it’s running, Lumen monitors how you change your backlight settings using the keyboard. If you override anything that Lumen does, it takes note, automatically learning your preferences. The implementation is not too complicated, but I think it’s a neat UI paradigm.

Lumen is open source, released under GPLv3. There are binaries available for download too.

Who's in the Office? (Space-oriented Personal Location Sharing)

Most personal location sharing services are people oriented — the applications are designed for following specific people. For example, with Find my Friends, you can share your GPS location with selected contacts. Instead, what if a location sharing service were designed for following people’s presence in a single physical space?

Recently, I built and deployed a location sharing system designed for a particular physical space to solve a specific problem. I’m part of a student group called HackMIT, and we have an office in the student center where we like to hang out. However, it’s no fun to hang out in our office when nobody else is there, and it’s kind of awkward to always be asking “is anyone in the office?” on Slack. So we wanted a better way of knowing when people are there. Maybe this sounds slightly ridiculous, but it’s a real problem we had. Our solution was OffiX, a WiFi-based presence tracking system for our office.

Such a system that inverts traditional location tracking has some interesting properties. Based on feedback I’ve gotten, space-oriented systems feel less awkward to use than person-oriented systems. Furthermore, even though it’s an always-on system, the space-oriented system better respects people’s privacy, because their location is only shared when they’re in that specific place. Plus, in our case, people’s privacy is enforced by the physical limitations of the implementation: the system cannot possibly be used to track people outside the space.

Interface

OffiX was designed to require minimal effort to set up and use. We have a web interface for initial setup, where each individual creates an account and adds the wireless MAC addresses of their devices:

And that’s it! After that, people can see who is in the office by looking at the web interface:

We also have a Slack interface, so people usually end up using that over the web interface:

The Slack interface even has push notifications to #social for new arrivals to the office:

Implementation

The technology powering the system is quite simple. It uses WiFi for tracking presence, so it doesn’t require any sophisticated hardware. Here is how it works: every couple minutes, wireless-enabled devices broadcast a special type of 802.11 frame called a probe request. The frame includes the device’s MAC address, which is a globally unique identifier. Once people register the MAC addresses of their computer and phone to create an association between their identity and their devices’ addresses, it’s possible to monitor presence by passively monitoring WiFi signals. All it takes is a wireless card supporting monitor mode and a little bit of C code to extract the data. The physical setup is pretty simple, too:

Impact

Before deploying OffiX, my hypothesis was that people would visit the office a lot more often as a result of deploying the system. And luckily, it did turn out that way — OffiX actually had a pretty huge impact on the frequency of people hanging out in the office. Even when people knew the office was empty, they’d go there, knowing that others would hear about it and probably come hang out.

OffiX significantly increased office traffic, probably helped most by the Slack integration, especially the “\$name is in the office!” announcements. Now I hear stories like this every so often: “I was walking by the student center, and I was going to go home, but then I saw that someone was in the office, so I went there to hang out”.

When I asked my friends about their thoughts on OffiX, they had some interesting things to say:

Source Code

As is the case with a lot of projects I work on, the source code for OffiX is available under a free software license. If you do anything cool with it, be sure to let me know!