FBI seizes MegaUpload, loses opportunity
23 January 2012
11:24 PM
1 Comment
Last week the FBI seized the file exchange site MegaUpload through a court order. Previously, users could exchange files too large to email through the service. Now visitors to the site see this message:
The significance of a website seized by law enforcement is heightened in light of the controversial SOPA and PIPA legislation currently being considered in Congress. Given the high stakes—the open exchange of information in a free society, government interference with the Internet—I feel compelled to let the people at the FBI know what I think.
Guys, this is embarrassing. Really amateur hour. Seriously, look at this again:
Where have I seen a better looking image? I mean, other than every movie ever made that shows a computer screen?
I don’t even know where to start. Fine, the seals. Any one of these seals by itself is like starting the drive from your own five-yard line. The three together is handing the ball to the other team and carrying them into the end zone. You’re not into football metaphors? OK, a seal crammed full of text like “National Intellectual Rights Coordination Center” is the design equivalent of dividing by zero. All three is taking the limit of bad design as it approaches zero and it evaluates to negative infinity. Math isn’t your thing? No sweat—what I said doesn’t make sense anyway. The point is, the seals are ugly.
But they’re your logos, you say? I feel badly saying this, but they look like someone just slapped them together at 4PM on Friday after a lunchtime happy hour. Take the right one. It says, “Protection is our trademark.” I’m not a IP genius, but it seems to me like if protection really is your trademark, and you want people to take it seriously, you need to use that symbol. Like “Protection is our trademark™” or maybe “PROTECTION™”. But since you’re not actually selling anything or engaging in trade, maybe it would be more accurate to say that protection is your service mark. You don’t see that little SM enough.
As if the seals weren’t texty enough already, someone put “FBI ANTI-PIRACY WARNING” on top of the middle one. Is that part of the seal? Operating under the dubious assumption that there’s any design merit to this logo in the first place, the last thing you want to do is cover up your logo. Can you imagine Nike labeling clothes with its swoosh but then covering half of it up with “GARMENT CARE INSTRUCTIONS”?
Who picked the color scheme for the background? Had this person eaten a hot dog recently? That’s the only way I can figure it out. You can’t even read the complete word “seized” once in this tiled background.
The cited list of alleged crimes at the bottom is a nice touch, but, guys, what are we doing with the typography here? A big block of bold, italic, centered text. I read the first line and I think, “This is heavy stuff—they’re being changed with Conspiracy to Commit” and then I get confused until I realize that it’s Conspiracy to Commit … Copyright Infringement (18 U.S.C. § 371). I know how to continue reading on the next line, but you’re taking some serious liberties with awkward line breaks.
Let’s check out the source of the page:
<html>
<title>NOTICE</title>
<body>
<img src="banner.jpg"/>
</body>
</html>
No JavaScript. No AJAX. No CSS. Not even any tables. The image doesn’t have ALT tags. Maybe you’re not worried about Google indexing this page, or visually impaired people being able to read it, but I hope you realize you are just flushing the last 8 years of the Internet down the toilet. Interestingly, you went with the trailing slash that closes empty elements in XHTML but the DOCTYPE is…nothing. Whatever—this stuff is for nerds.
What we need to focus on is what a colossal missed opportunity this is for you. MegaUpload is down and the notice on the site is getting tons of exposure and when you go there it’s like you’re stuck watching the beginning of a movie forever, or at least that’s what it seems like for those people who paid for the movie and have to watch the FBI reminder to pay for the movie.
You must plan these operations, right? I mean, it’s not like you just randomly seize private property on a whim. This is a failure of project management. You can’t just bring in a designer at the last minute and expect them to polish your design turd. This is your chance to shine. Go wild. Animation, maybe a Matrix-style flow of numbers in the background. Ominous type. Here are some ideas:
- The user goes to MegaUpload. The site looks normal. Suddenly, the eagles from your logos swoop in and the cool one with the arrows in its feet starts attacking the site while the other one hangs a banner over it that says “Seized by the FBI” and then jail bars drop down over the entire site.
- The user goes to MegaUpload. The screen is filled with static like an old television. Then it looks like the screen is flipping through different TV channels. They’re all static. Finally, you get to a channel with a retro-looking message: “Seized by the FBI”. The retro part here probably plays to your design strengths.
- The user goes to MegaUpload. The site is covered with sheets of brushed aluminum that look very heavy duty. Etched into the aluminum is the message: “Seized by the FBI”.
- The user goes to MegaUpload. It says “HTTP Error 460” (this doesn’t exist—you would be making it up): “Seized by the FBI”.
- The user goes to MegaUpload. A video of Rick Astley singing “Never Going To Give You Up” starts playing. When the video finishes, it fades out and is replaced by the text “Seized by the FBI”.
- The user goes to MegaUpload. Suddenly, a S.W.A.T truck drives onto the screen. Fighter jets fly overhead. Missiles, bombs—BOOM—the screen explodes. DOM elements lie in a heap at the bottom of the screen. Smokes rises from the ashes and all of a sudden you realize it’s forming words: “Seized by the F.B.I.”
There are probably jQuery plugins that do all these effects already and you could use those as framework to build on. So dust off your copy of Photoshop. Use the mosaic filter. Add some lens flares. Watch Sneakers and Hackers and The Net and The Matrix and Tron and WarGames. Stay away from Papyrus. Then go and take down MegaUpload and put up something amazing. This is your moment: seize it.
Seen through the lens
13 September 2011
9:11 PM
I took this photo of a red panda at the San Diego zoo last month. Notice anything funny about it?
Every person looking at the panda, this photographer included, is seeing it through the lens of a camera. Or on a smartphone LCD screen. It makes you wonder why we are so intent on capturing a moment for posterity that we may never have really seen in person.
Best of Chile
4 July 2011
12:07 PM
So you know how some musicians won’t have any new good songs in awhile and then they’ll release a greatest hits album just to cash in? Anyway, no reason.
Last week yet another friend told me he’s traveling to Chile, news that makes me simultaneously jealous but excited that he’ll get to experience one of my favorite places. Whenever I hear about someone visiting Chile I want to dispense all of the peculiar observations and advice—much of which is probably now outdated—that I accumulated in the years that I was there. I’ve written a bunch of one-off emails with shameless linking to my blog, so I thought I might as well collect those links here.
Destinations
Owing to the country’s slim figure, traveling in Chile is mostly movement along a single axis: north or south. Busses run up and down the country in three classes, normal, semi-cama, and cama, with increasing prices and degrees of seat recline-ability. I wasn’t living in Chile to travel, but I was fortunate to end up seeing many destinations anyway. Here are a few I wrote about:
- Chiloé. A magical island at the end of the Pan American highway, well known for its seafood.
- Elqui Valley. A agricultural valley that is the source of most of Chile’s pisco and the resting place of Chile’s first Nobel Laureate, Gabriela Mistral.
- La Serena. A charming city in the Norte Chico with more than two dozen churches and a moai from Easter Island.
- Torres del Paine. A national park deep in Patagonia, at the far southern tip of the country.
- Valparaiso. The San Francisco of Chile.
Many people also rave about San Pedro de Atacama, a small town by the Valle de la Luna in the Norte Grande.
Culture
- The Dieciocho. Chile’s national holiday is September 18, just as the cold winter is departing. See also a description from 2006.
- Music. A collection of songs from Chile’s folklore tradition including groups like Inti-Illimani, Los Jaivas, and Illapu. My favorite is Lejos Del Amor.
- Pisco sours. Pisco is the national liquor, pisco sours are the national cocktail. Also common is a piscola: pisco + Coca-cola.
- English in Chile. The proliferation of English in Chile manifests itself in funny ways.
- Currency. $100 for an ice cream cone, $200 for the city bus, $1,500 for lunch, and $20,000 for a pair of pants?
- September 11. Many years before September 11 became the day of the 9-11 attacks in the U.S., it marked the military coup in Chile that lead to Pinochet’s dictatorship.
- Pinochet’s death. Chile’s former military dictator died while I was living there.
Observations and Oddities
- Waiting in line. Not all countries treat lines with the respect they deserve.
- The triple caja. The Chilean system for making purchases in three easy steps. It’s in use at the Casa Royale.
- Ice cream. The Chilean summer practically force you to subsist on ice cream.
- Shopping on busses. No need to go shopping in Chile—just get on a bus.
- Chile is for lovers. The bar for acceptable public display of affection is rather lofty.
- Calefóns. Instant water heaters are more common in Chile than the U.S.
- Street graffiti. Where else can you see stenciled art featuring Mr. Spock, Twiggy, and Waldo?
Spanish Lessons
If you are planning on visiting Chile for more than a few weeks and you speak Spanish, you absolutely must get a copy of How to Survive in the Chilean Jungle. It’s the definitive guide to the cornucopia of Chilean slang and expressions.
- Spanish Lesson #1409
- Spanish Lesson #1835
- Spanish Lesson #2972
- Spanish Lesson #3103
- Spanish Lesson #3989
- Spanish Lesson #4361
These aren’t real language lessons. They’re just my screw-ups. Maybe they’ll make you feel better about your own. Whatever you do, no matter how old you are, remember that you only have one ano.
If you’re going to Chile, I hope you find something interesting here to get your excited for your trip.
"Unboxing the iPad Data," Deconstructed
10 April 2010
2:11 AM
2 Comments
Yesterday John Gruber linked to an infographic, “Unboxing the iPad Data” by John Kumahara and Johnathan Bonnell. In terms of graphic design it’s visually pleasing, but it falls short in a few areas and highlights common challenges in designing infographics. These are problems that occur all the time in visualizations, so let’s see what we can learn from this example.
I know it’s easy to misinterpret criticism, so I want to emphasize that these are comments about this particular graphic, not about the authors’ skills or ability.
Numbers
People understand numbers. So when you are evaluating a visualization one of the most important questions is whether the graphic is better than just the numbers. The most successful visualizations show trends, outliers, and insights that a table of numbers wouldn’t.
In some places “Unboxing the iPad Data” clearly shows the numbers of interest. In others, it obscures them for the sake of design.
The fact that Apple sold 300,000 devices and 1,000,000 applications in the first weekend is a big deal—so these should be big numbers. Instead you have to read the fine print to see that 1 actually means 1 million.
Equally large are numbers that few people care about, like the number of respondents or the specifics of the Likert scale used.
When the numbers speak for themselves, rely on them without decoration. Clearly show what is important.
Colors
Certain aspects of color are a subjective matter. One designer thinks this shade of red is the right choice; another thinks it’s ugly. But there is a science to the perception of color. We know that some colors catch people’s eyes more than others. I would argue that these pie charts would be more readily perceptible if the colors were swapped.
The intense saturation of the light blue makes it look like it is highlighting something. Here the portion of interest is the small white wedge representing 15%, but the white is overpowered by the blue.
(There is the separate question of whether these pie charts help us understand the difference between the 8% and 15% range represented in the left-most column. The small pie charts are attractive, but does this small multiples grid of pie charts help the viewer understand this dataset better than a table of these numbers alone?)
A similar issue affects the bar chart. Here the viewer must compare between likely (represented by white) and unlikely (represented by blue). Again, the blue stands out and draws the user’s attention.
A minor detail in the bar chart is the orientation of the text. In the U.S., we are more comfortable turning our heads right to read things instead of left. Think of a bookshelf—how do you turn your head to read the books’ titles? My preference (preference!) would be to rotate the labels on this bar chart 180°.
Meaning
Designers must be careful that their infographics accurately depict meaningful information. Here, for example, we see that the peak rate of tweets about the iPad was 26,668 in an hour.
The depiction juxtaposes this number against a timeline that suggests the peak occurred between 11:00am and 12:00pm. If this is the case, then the segment should be labeled so that the viewer can learn this readily. On other hand, if we don’t know the time of the peak, then this illustration is misleading because it implies a fact where there is ambiguity.
The segment of this infographic that depicts the cost of apps for the iPhone and iPad is less clear still.
The accompanying text reads:
The other notable difference between the iPad and the iPhone, are the app prices. The average price of the initial iPad apps ran around $4.99 (according to Mobclix) while the iPhone apps averaged a steady $1.99.
I’ve looked at this pie chart for some time and I can’t figure out what it is showing. The ratio of average app price to the total average app price? Even if that were the case, 5/7 is 71% and this chart is split into 60% and 40% segments.
Area
There are a variety of visual variables a designer can use to encode a given set of data. Among these are length, position, angle, area, color, lightness, and others. Some of these are better suited to certain kinds of data than others, and some are more readily perceptible than others (see Cleveland and McGill’s “Graphical Perception” for extensive details and experiments).
Look at this area comparison of percentage of iPads sold. Before we even consider the accuracy, look at these two circles and ask yourself how much bigger is circle B than circle A? Go ahead, just type your guess in the box.
The circle on the right is times bigger than the one on the left.
The area of the circle on the left is 1075 pixels (d = 37, r = 18.5, A = 1075 px) and the circle on the right is 7390 pixels (d = 97, r = 48.5, A = 7390). That’s 6.8 times bigger.
People are much better at comparing length and position than comparing area. This is a very common mistake (one I’ve made myself). Before you represent a variable with area, you should consider that you may be handicapping people’s ability to compare the data.
Area is hard to understand, but it’s hard for designers to get it right as well. Consider the legend for this map:
Are these circles the right size? Let’s construct a table and find out:
| Nominal Size | Diameter | Radius | Area | × 1% |
|---|---|---|---|---|
| 1% | 22 | 11 | 380 | 1 |
| 5% | 70 | 35 | 3848 | 10 |
| 10% | 102 | 51 | 8171 | 21.5 |
| 20% | 160 | 80 | 20106 | 53 |
The rightmost column shows the area of the circle compared with the area of the 1% circle. It turns out that the area of the 20% circle is 53 times bigger than the area of the 1% circle—more than 2.5 times bigger than it should be. Comparing areas is hard; it’s harder with an inaccurate legend. The difficulty of accurately representing area is another reason to avoid using it.
Maps
Maps are such a common form of visualization that we use them even when they are not helpful. On top of that, they’re hard. Maps’ static nature make it hard to show important dimensions of data.
The size of maps is fixed, which can be at odds with what your are trying to communicate. In the map shown above much of the interesting data is crammed into the northeast because that’s where those states are located. Meanwhile, a bunch of sparsely populated states in the northwest of the map use up space without communicating anything.
Data on maps is constrained by realities the map itself cannot express. There’s no convenient way to show population data. Does California have a giant circle because Californians buy more iPads than their counterparts across the country? Or is it because California has more people than any other state?
Here the map isn’t clearly better than just the numbers. A table listing the sales numbers for each state, possibly along with the per capita sales per state, would express the point with greater clarity and more succinctly. In the end, that’s the goal, right?
Greasemonkey & jQuery
23 March 2010
4:13 PM
6 Comments
I taught a class this past fall where we used Greasemonkey as a tool for building prototypes of new browser functionality. We also used jQuery extensively to make JavaScript in the browser simpler. There are some tricks to getting the two to work together that I’ve been meaning to share.
Loading jQuery in a Greasemonkey script
Simply loading jQuery within Greasemonkey hasn’t always been straightforward. I think they should just bundle jQuery with the Greasemonkey package since just about everyone is using it already, but that’s a separate issue.
The old way to include jQuery in your Greasemonkey scripts was to add a <script> tag to every page you visit linking to the jQuery library. Although this works, it’s a clunky solution. It introduces timing issues: since you can’t be sure when the script would load, you have to poll continually, checking to see if jQuery has downloaded yet. Once you detect that jQuery is available, you can run your script. This approach also might clobber other JavaScript running on the main page (like the Prototype library) before you have a chance to call jQuery.noConflict.
Fortunately, later versions of Greasemonkey made this hack unnecessary by adding the @require attribute to scripts. When you install a Greasemonkey script that has an @require statement, the listed resource is downloaded once and included in the script as if it were pasted directly into the document. Unfortunately, there’s a small stumbling block for people testing their scripts: the @require statement is only executed when you install a script. This means that if you create a new Greasemonkey script in Firefox, add the @require line, and save your file nothing will happen. You have to uninstall your script and reinstall it because @require is only processed at installation. Once you do this, you can use jQuery all you want in your script. Except for…
Sather Tower × 4
10 March 2010
3:34 PM
4 Comments
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.
Conversation with an Anthropomorphized Twiki
25 February 2010
7:08 PM
2 Comments
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.
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.
Is Online First-come, First-served Fair?
18 February 2010
10:28 AM
4 Comments
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. 1
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,2 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.3
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.
1 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. ↩
2 Computers only generate pseudorandom numbers, but these are random enough for our needs. ↩
3 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. ↩
A Nook of My Own
25 January 2010
12:47 AM
2 Comments
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 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.
Hello World! from Arduino
3 September 2009
11:54 PM
1 Comment
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.
