Ryan Greenberg

Clockwise from top-left: A foggy afternoon on Feb. 18; from the main staircase of South Hall on Feb. 24; nighttime on Mar. 1; and the west facade before sunset on Feb. 25.

Sather Tower, also called the Campanile, is at the center of UC Berkeley’s campus. It’s right across from South Hall, where the School of Information is housed, and where I spent most of my time. These are four pictures I took of Sather Tower in a two-week period.

This semester I’m taking a class on user interface design and development. One common technique we’ve covered is think-aloud studies, where you get a user to explain what they’re doing aloud as they do it. This gives you some insight into what the user is thinking about your interface, and why they choose the options they do.

For this class, we post our assignments to a class wiki run on Twiki. Twiki is an adequate piece of software, but it has some rough edges. I got frustrated trying to attach images to my assignment, so I wrote a think-aloud dialogue of my interaction with the software.

This is the popup dialog to insert an image into the current page. You have to enter the image’s URL or select an image that you uploaded before getting to this page.

Ryan: Great, I’m just going to upload some pictures to my page. I’ll just click the insert picture button.
Twiki: Sure thing. What’s the URL for the picture that you want to insert?
Ryan: Uhh…I don’t have one. I mean it doesn’t have a URL. Err…not yet?
Twiki: No problem. You can select a picture that you’ve already uploaded.
Ryan: I haven’t uploaded any pictures.
Twiki: (silence)
Ryan: So where do I go to upload a picture?
Twiki: (silence)
Ryan: Can I do it anywhere on this page?
Twiki: You can attach pictures to a page…
Ryan: Great—that’s what I want to do.
Twiki: …but not when you are editing the page.
Ryan: OK, so I’ll save this page and come back later to finish editing after I upload my pictures.
Twiki: Just click the attach button.
Ryan: OK, so now I can upload my pictures on this page.
Twiki: Picture.
Ryan: Picture?
Twiki: Why would you want to upload more than one at a time?
Ryan: Oh, I don’t know, I just have a few I want to put on this page.
Twiki: One. Picture.
Ryan: Fine, I’ll upload a picture and click Attach and then repeat the process for each picture that I have.
Twiki: Good.
Ryan: This one picture that I uploaded, though. It’s 2000 pixels, which is kind of large to display in a browser window. Could you do something about that?
Twiki: That seems like something you should have though about before you uploaded it.
Ryan: I mean, can’t you resize it or something to make it the right size for my wiki page?
Twiki: No.
Ryan: OK, hold on, I’ll be right back. I have to go resize these images by hand.
Ryan: Back! Now I’ll upload these three…oh…right…Attach, upload, save, attach upload, save, attach, upload, save.
Twiki: Good work.
Ryan: Now let’s put these images into my wiki page.
Twiki: Image.
Ryan: Image?
Twiki: Well, you have to do it one at a time.
Ryan: (sigh) You’re the wiki for a class on usability?
Twiki: Apparently so.
Ryan: Is this some kind of joke?
Twiki: No.
Ryan: This is ridiculous. I couldn’t design a less usable wiki if I sat down and tried to.
Twiki: Now you’re just exaggerating.
Ryan: And don’t even get me started on your “WYSIWYG” editor. It’s like you vomit on my text whenever I’m not looking.
Twiki: Please be reasonable.
Ryan: I AM BEING REASONABLE. And what kind of name is “Twiki”? Even the pronunciation is unusable! I’ve been speaking English for decades and I can’t decide how to use your name. Tee-wiki. Twick-ee.
Twiki: It’s my name.
Ryan: It’s absurd.
Twiki: You just wish I was Wikipedia.
Ryan: No, I don’t want—
Twiki: You wish I had millions of contributors and video and embedded SVGs and links everywhere.
Ryan: Really I just want you to be easier to—
Twiki: (sobbing) WHY CAN’T YOU JUST LOVE ME FOR WHAT I AM?
Ryan: I’m sorry. I didn’t mean to—
Twiki: You can be so cruel.
Ryan: I’m sorry. I’m sorry. I’m sorry. (softly, not realizing this is a bad time) It’s just that, on a lot of other wikis—not that I want you to be exactly like them—but it’s just that I could probably have uploaded my pictures in the time it took me to write this. But with you…
Twiki: (muffled sobs)
Ryan: …
Twiki: …
Ryan: You know what, forget I said anything. I’ll just upload the photos.

President Clinton is speaking at UC Berkeley next week. Tickets were available to students who filled out an online form starting at 7:00am this morning. Predictably, at 6:59am the website offering tickets looked like this:

Judging by messages on Twitter, hundreds of other students had the same experience. At 7:39am, tickets were sold out.

Despite being awake and online at the right time, I never even saw the form. I’m not upset or tremendously disappointed, but this experience started me thinking about the process of distribution. This is the fourth or fifth time I’ve participated in an online offer in the last year, and they always leave me with the sense that they’re not fair. In this situation I think fair means that every person who is eligible to receive a ticket and wants one has an equal chance to receive one. ¹

The issue is that this system relies on first-come, first-served rationing (FCFS) for a scarse resource. FCFS is pretty well understood in the physical world. We know that people can only be in one place at a time: each person gets a single spot in line. Whoever shows up first, or camps out overnight, will get to see the movie first. Incidentally, these practices are exactly why organizers want to move to an online system. Real-world FCFS means large, unwieldy crowds and groups of students who set up tents on campus.

An online version of first-come, first-served solves these problems: when people vie for a resource online (on the Internet, or calling by phone), they don’t form massive crowds outside your door or camp on your porch. Without the restrictions of the physical world, however, FCFS is different online. I can get 10 places in line just by loading a page in my browser 10 times. If I am handy with programming, I might be able to get hundreds of places in line by writing a script to connect on my behalf. If I have a slow Internet connection, or I’m positioned at a certain point on the network, I might never be able to get in line because the server is too busy. In short, online FCFS has a chance at being fair only if your servers can handle the load and you can prevent people from taking multiple places in line.

A natural next question might be how you can prepare your servers for the demand created by an event like this. People who know a lot more than I do about IT might suggest things like caching, replicated servers, faster machines, and more memory. But this misses the real problem: online FCFS is not a good approximation of fair.

A better alternative is an online lottery. Instead of awarding tickets based on whoever arrives first, you provide a window during which anybody can obtain a lottery number. Then you randomly select people using a computer and give them tickets. This system solves the same problems that online FCFS does: there are no large crowds and no camping out. It also solves some of the problems with FCFS. Since you can get a lottery number at any time during the window, network traffic will be spread out across this time. And since awards are based on random chance,² a lottery is more fair because every ticket holder has an equal chance.

Of course, there are some similar problems. If the window to get a lottery ticket isn’t large enough everyone who wants a ticket won’t have a chance to get one—not fair. Also, the problem of multiple people in line is now replaced with the problem of multiple lottery tickets. People will find ways to get multiple lottery tickets, increasing their odds of being selected. But I don’t think that ballot stuffing is a much greater problem than having multiple spots in line. With a lottery system you can deal with ballot stuffing on your own time instead of in real time.

In the controlled circumstances of the Clinton ticket giveaway, stuffing is nearly impossible. Each student has a unique student ID number which can be checked to ensure that each person gets only one lottery number. And since each student can only obtain a single ticket for this event for personal use (confirmed with photo ID when claiming the ticket), people cannot use their friends to get extra lottery numbers.

The only downside to a lottery is that it requires more work. With online FCFS you can just tell people to come, watch your server buckle under the load, and eventually give away all the tickets. Online FCFS is also fine if you’re not interested in fair. I don’t mean this in a pejorative sense. If you’re selling concert tickets, you get paid no matter who buys them; there’s no obvious incentive for fair distribution.³

Given the detailed instructions for distributing tickets, it seems like Berkeley does want to be fair about the process. Next time, I suggest they consider a lottery.

¹ Of course there are other definitions for fair. If you understand fair in a different sense (like “following an defined process for distribution”) then this system may well be fair. I am using fair as equitable because I think that is a popular understanding of fair. ↩

² Computers only generate pseudorandom numbers, but these are random enough for our needs. ↩

³ There might be external repercussions for distribution using a process that isn’t perceived as fair. The New Yorker ran an article last summer, “The Price of the Ticket” addressing this issue as it applies to Ticketmaster and fishy practices selling tickets. ↩

This past Christmas my future in-laws gave me a lovely gift, the nook, Barnes & Noble’s new electronic reader. I’ve decided to use the nook to conduct a semester long experiment, where I use it for as much of my reading as possible.

Even with the imminent arrival of the Apple Canvas, I’m excited about testing the nook for a few reasons. First, I’m hoping that reading on a reflective screen like the nook’s will be easier on my eyes. Every semester I have at least a few hundred pages of reading, nearly all of which is only available online. With the nook I have another alternative besides printing everything out or reading on my computer screen, which is hard on my eyes.

Second, I think that having a device just for reading will make it easier to stay focused on the task at hand (command-tab is my worst enemy). Some people think that single-purpose devices are too limited to become popular. For my money, I think they’re right—multipurpose devices will probably be more popular, but a smaller market doesn’t mean the nook (or Kindle) can’t be a commercial success.

While I’m testing the nook over the next few months I’ll write up my thoughts. Here’s my first batch.

Out of the Box

The nook ships with a message on its screen which lasts indefinitely because of the E Ink technology.

The nook arrives in an attractive clear plastic box that feels quite hefty. When I pulled off the cardboard cover from the box there was a message welcoming me to the nook. This was a nifty touch that actually tricked me: I thought the message was printed on a clear film that I would have to pull off the screen, but it was displayed on the screen itself. One of the advantages of the E Ink technology is that it remains on the screen indefinitely without consuming any power, so they display this message at the factory and it stays there until you see it. I had to fumble with the box for awhile to get it open and remove the nook. The packing is somewhat excessive, as indicated by the two pages of instructions on how to unpack your nook. If I need seven steps to get your product out of the box, you packed it wrong.

I’m taking an exciting class this semester called Theory and Practice of Tangible User Interfaces. Today was our first lab class where we got our box of inputs and outputs, a breadboard, and an Arduino microcontroller. With these tools I have a way to sense and control things in the physical world with a normal programming environment, which is a step towards the “tangible” interfaces from the class’s name.

TUI, as students call the class, culminates in a final projects that in past years have been a real showcase of creativity: the bubblegum sequencer, Jug Hero, blowing virtual bubbles, and others. I haven’t had my innovative and great idea yet, but since we just got our kits today, I have a bit of time.

Now the main task is to get working with the new hardware and development environment. The language you use to program the Arduino board—also called Arduino—is based on C, which is a more low-level language than I have been using recently. (I spent the summer writing Javascript and Ruby, both of which are very high-level languages). Anyway, typically the first task in any programming language is getting the computer to display the message “Hello world”.

My Physical Computing textbook explains:

Anybody who has learned how to use a couple of different computer systems or programming languages will tell you that the hardest part is getting a computer to do anything at all. … In software, it’s traditional to prove your mastery of any environment by getting your program to say “Hello World!” The “Hello World!” message of the microcontroller is a blinking LED. Once you get the microcontroller to blink an LED, it’s all downhill from there.

But a simple blinking LED didn’t seem like an appropriate start, especially since the newer Arduino boards are programmed at the factory to blink any connected LED. Once I finished fumbling with my breadboard and resistors and finally plugged in all the parts, my light started blinking automatically without me doing any programming at all. I decided that a better start would be to have my light blink “Hello world” in Morse code.

Like almost everyone, I know only enough Morse code to do SOS, and it turns out I was doing even that wrong. Whenever I tap out SOS, I put longer delays between dashes than dots. That’s wrong—the delay between symbols that form a letter is supposed to be constant. The rules for timing are systematic:

International Morse code is composed of five elements:

• short mark, dot or ‘dit’ (·) — one unit long
• longer mark, dash or ‘dah’ (-) — three units long
• intra-character gap (between the dots and dashes within a character) — one unit long
• short gap (between letters) — three units long
• medium gap (between words) — seven units long

I copied this timing information and the codes for all the letters from Wikipedia and implemented them as my first Arduino program. It took a bit longer than I expected because I’m not that familiar with C. Debugging was also tricky because I realized I had no idea what the Morse code for “Hello world” was supposed to look like! While I was debugging, I had to use SOS to see if everything was working properly.

Here’s what the end result looks like:

If you want to see the code behind my Morse, here’s the source. It’s messier than I would like because I couldn’t get sizeof() to operate as I expected.

Bad design is ugly, it is frustrating, it doesn’t create joy, it is not well considered, but above all bad design wastes time. This isn’t to say that design is just about saving time: Good design can make you slow down, it can make you think, it can be about things besides efficiency. Good design makes you think as much as you should, but no more.

This form is about the size of an index card.

I’m writing after a particular encounter with time-wasting bad design via the U.S. Postal Service’s form 3849. When a package cannot be delivered, the mail carrier leaves a orange slip that lets you request redelivery or go to pick up the package at the post office.

My girlfriend wasn’t home when the postman came earlier this week, so I went to pick up a package for her. She signed item 2 on the form, which is labeled “Sign here to authorize redelivery or to authorize an agent to sign for you.” I went to the post office, waited an hour, presented the signed slip, and was turned away: my name didn’t appear in the space for the agent’s name. “What?” I asked, “what space for the agent’s name?” “Right here,” the clerk told me, “it clearly says to write the agent’s name right here.”

She was right. The words on the form clearly indicate that the agent’s name should be entered in the upper-right corner. The form’s visual language, however, contradicts these instructions. Once you follow the numbered list and sign in section 2, it doesn’t look like there is anything else you have to do. The space for the agent’s name is so tiny that a glance at the form would never suggest that you have to write anything there. This is bad design. Not only does it waste time because a person has to think too much about filling it out—Look at the instructions in section 1, for example, which tell you to fill out section 3, then come back to section 2—but it also wastes time when people wait in line with an improper form.

In my case, it wasted an hour. That’s bad design.

3:58. As a culmination of two years of study at the School of Information, masters students present final projects that represent a significant work based on learning in the classroom. Next year I’ll be giving one of these presentations, but this year I’m just along for the ride.

The first step is a lightning round where each group of students get two minutes to present an overview of their projects. The projects are separated into three tracks.

Love to chat, but it’s time to get started…

While looking at Twitter last week I noticed that updates were missing from my user timeline. According to Twitter, I didn’t post anything between March 20 and April 9. Through a little investigative coding (and some help from Twistory, I found that my updates were still part of the Twitter system, but not associated with my user timeline. For instance, I posted this message on April 1, but if you look at that part of my user timeline, it doesn’t appear.

Twitter has closed the support ticket on this issue, but my problem isn’t solved. I opened my own support ticket, but the only advice I’ve received so far has been about changing my bio.

Since Twitter is such a large service, fixing this problem probably isn’t a high priority if it only affects a couple people. But it’s hard to know if it affects you unless you feel like going through all your messages and counting. Since computers are pretty decent when it comes to counting, I built Missing Tweets to help people check if they are missing any updates. The script works on the assumption that Twitter still maintains the correct total count for a user’s updates. This is true in my case: Twitter says I have made 993 updates, but only 955 show up in my user timeline. That means that 38 are missing.

Most people I have tested this script on aren’t missing any tweets, but a few are. Test it on yourself, and let Twitter know if you are missing tweets.

Note: This doesn’t work if you have more than 3200 tweets. Also, you can still use this even if your account is protected. Your browser will prompt you for your username and password. This communication is happening directly between your computer and Twitter; my site isn’t involved in any way.

There is a dedicated lane for cyclists on the west side of the bridge.

I bought a Kona bike last fall, and notwithstanding the incident where someone stole it and I found the thief and stole it back (another story—ask me later), it has lead a provincial life. During the week I ride it a couple of miles to campus and back each day. I put on some extra mileage when I run errands. Every now and then Caitlin and I will ride around town, either along sleepy Bicycle Boulevards, over the I-80 bridge and along the bay, across the Ohlone Greenway, or in the rolling Berkeley Hills. But this weekend, Caitlin and I decided to try out our wheels in the big city.

Our plan was to ride across the Golden Gate Bridge. Since we haven’t perfected the ride-across-the-water technique, we boarded BART with our bikes Saturday morning. It’s nice to have the option of taking your bike into San Francisco using public transportation. Once we arrived at the Embarcadero station, we rode along Market to the Ferry Building where we checked out the Saturday farmers’ market. After sampling a tasty blood orange, we barreled down Embarcadero.

This semester I’m taking a course called Information Law and Policy where we review court cases and laws related to, well, information. Our professor assured us that we would be completely unqualified to sit for the bar in May, but that we would understand some of the relevant issues about copyright, liability, fair use, and so forth. In other words, we should have some idea of when to consult a lawyer.

A few weeks ago we discussed fair use, a provision of copyright law that allows people to reproduce copyrighted works under certain conditions. There isn’t an clearly itemized checklist of when fair use applies; it depends on things like “the nature of the copyrighted work” and the use’s effect on the market for the original work. Our discussion made me think about a blog post I made almost two years ago.