Gmail UI woes

A couple of months ago, our IT-department configured the university's firewall to block all outgoing SMTP-traffic (except for its own Exchange server of course). As a consequence, I've been using the Gmail web interface a lot lately, and Oh! My! God! has it been driving me crazy. I'm no designer by any stretch of the imagination, but I'm guessing that whoever is responsible for this jumbled mess wasn't getting straight A's in designer school either. Every day there are numerous aspects of that confuse, irritate, and bewilder me, but for the sake of keeping the amount of complaining on this blog to a minimum, let me pick out my two main grievances. First off, take a look at the following pair:

Pop quiz, hotshot: which of these is the back button and which is the reply button? If I had a eurocent for every time I've mixed these two up, well, I'd have a lot of eurocents. And to add insult to injury: in the view where these two buttons pop up together—the detailed view of a single (thread of) message(s)—the back button is superfluous, because the left-hand column also contains a button to take you to the inbox, which is exactly what the back button does. But hey, it's a good thing replying to messages is not something one does frequently in an email client, right?

A second thing one rarely does, is write new messages. In order to help you execute this obscure task, Google has devised this beauty:

Oh, where to start? There's so many things wrong here. First off, it doesn't look like a button at all. Here's what it looks like in context:

It doesn't look anything like the other buttons in this column. If anything, it looks like the title of the column, something that's not even clickable. I'm guessing the reasoning here was: "Composing a new message is a very common task, so let's make a Big Fat Red Button for it", but the effect has been the exact opposite; by making it stand out so prominently, it completely disappears and becomes invisible.

Looks aside, though, let's focus on what the button says. The Dutch verb opstellen is the literal (Google Translate-style) translation of English 'to compose'. Aha, exactly what someone who wants to compose a new message needs, right? Nope. You see, the verb opstellen is only rarely used in combination with mail or e-mail. You don't have to take my word for it; we can look at some numbers. I did a couple of searches in the Corpus of Contemporary Dutch, a corpus of over 70 million words from (among others) newspapers, journals, legal documents, television news broadcasts, novels, and internet texts. The verb opstellen (in any of its inflectional forms) occurs 24,650 times, the noun e-mail 12,264 times, and mail 8,320 times. The question now is to what extent these sets overlap. It turns out that (e-)mail co-occurs with opstellen only a meagre 16 (sixteen!) times. Compare this to the numbers for sturen 'to send' and schrijven 'to write':

mail e-mail total
opstellen 11 5 16
sturen 1706 1409 3115
schrijven 621 771 1392

What does this mean? Well, it means that Google should have chosen a different name for their button. The verb they've put on there is only very rarely associated with the action connected to the button, which makes it unintuitive and hard to use. That said, though, I think the problem is more fundamental than the choice of verb. Even if the numbers in the table had been reversed, I still think the button would have been poorly designed. The most informative part of the verb phrase een nieuw bericht opstellen 'to compose a new message' is the direct object een nieuw bericht 'a new message', not the verb. So if anything, that's what should have been on the button: nieuw 'new' or nieuw bericht 'new message'. It would sidestep the whole issue of which verb to use, and instead would focus much more directly on the result the user is trying to achieve.

Anyway, the good news is that I will be changing workplaces soon—more on that in a future post—at which point my days of Gmail-web-interface-suffering will be over. I can't wait.

  1. Both nouns are used interchangeably in Dutch.

  2. A quick word on my methodology: for both mail and e-mail I did two searches: one with the noun preceding the verb and one with the noun following the verb. In both cases I allowed for anywhere between 0 and 20 optional intervening words. For opstellen the number of hits was so small that I was able to manually verify all of them and throw out any false positives. For sturen and schrijven I didn't do that because there were too many hits. Note that sturen occurs 72,022 times in the whole corpus, and schrijven 209,487 times.

A reviewer's review

I won't name names. Technically, it is not even possible for me to name names, because the review process is doubly blind. However, as many of you know, between theory and practice there is only a quick Google search or a sly glance at the document properties, and very often you have a pretty good idea of who's behind the review. In this particular case, however, even a six-year old could have figured it out.

I've spent a considerable portion of the day wading through a badly written, poorly structured 60+ page maze of a linguistics paper. Why? Because a reviewer thought that the one footnote I had previously devoted to this publication didn't do it justice. As I was reading, however, it became clear that most of the other comments also implicitly referred to this paper. I needed to add some stuff on adverbs? Turns out the paper had a whole section devoted to adverbs. Discussion of languages X and Y was missing? Turns out languages X and Y were the centerpiece of this paper. More on cross-linguistic variation? Bingo! A subsection on cross-linguistic variation. It pretty soon became clear that 90% of the 'major issues' pointed out in the review could be paraphrased as Refer More Extensively To My Paper!.

Now, don't get me wrong, I'm a big fan of peer review in academia. I don't think there's a single publication of mine that didn't get better in some way thanks to reviewers' comments. (Even the review which prompted me to write this post contained some valid points and pointed out a number of weaknesses in the paper.) At the same time, however, oftentimes a paper also gets worse in some respects because a reviewer is trying to push his own agenda. So let me try and lay down Three Simple Ground Rules for Reviewing:

  1. Be specific: this is my number one pet peeve when it comes to reviews. You think a paper sucks? Fine, give specific, concrete, clearly formulated arguments to back that up. A whole lot of literature is missing? Give the full bibliographic info of at least one of those missing references. There's a problem in section 2? Give the page and line number of where the problem occurs. Vagueness in a review is not only utterly useless to the author, it's also annoying for the editor, who will have no way of knowing whether you're being vague because you didn't feel like doing the review and didn't invest the time into it, or whether the paper is really deficient in some fundamental way.
  2. Structure your review: editors don't have the time to read all the papers that are submitted to their journal. This means your review should help guide their decision and in this respect, structure is golden: a clear, concise overall judgment of the paper at the start of your review, a numbered, structured list of the major issues, and a possibly longer list with smaller issues. No lengthy summary of the paper—the editor can read the abstract—and no long swaths of rambling prose; this text isn't about (showing how brilliant) you (are), it's about evaluating the paper as objectively as possible.
  3. Be prepared to think along: this is probably the most controversial of the three, but I feel that if a paper starts out from a number of assumptions or axioms, the reviewer should think along inside that framework, unless he has (concrete, specific, clearly formulated, see point 1) arguments for rejecting those assumptions. Very often a reviewer simply disagrees with some assumption (because he adheres to some other flavour of linguistics) and starts bitching about it, trying to push his own agenda.

Call me naive, idealistic, or just plain stupid, but I think that a couple of simple rules like this—if properly adhered to of course—could really improve the reviewing process. It might even make it possible to get rid of the anonymity of peer review, but that's a whole nother can of worms.

  1. Actually, I feel reviews should always contain a full list of references (excluding the ones that were mentioned in the original paper). It's a matter of common courtesy and professionalism.

Service announcement

I've been busy behind the scenes getting the site more up to date, and am happy to share some of the fruits of my labor today. First off, my list of publications now reflects its most current state, and I've added downloadable versions of everything going back to 2008. If you want something from 2007 or earlier, either let me know or be patient: I plan to add them in due time.

Secondly, I've added a new subsection called Talks, which contains—you'll never guess—a complete list of all my talks. Here too, I've added downloadable versions of handouts and slides going back to 2008. This new subsection should give you a good idea of what I'm currently doing research-wise, especially since my talk-to-paper conversion rate isn't always as high or as fast as I'd like it to be. You'll notice quite a bit of verb clusters and (reverse) dialectometry in my most recent presentations; more on that in a later post. In the meantime, comments or questions about any of this (or even some good ole fashioned hecklin') are most welcome.

  1. Well, almost everything: for books I simply link to their webpage.

Adverbs and scope

Today's random linguistic observation: an adverb that is extraposed in an adverbial subclause can take scope over the complementizer of that subclause. Take a look at this pair:

  1. omdat 	hij	waarschijnlijk	slaapt
    because	he 	probably 	sleeps
    'because he's probably sleeping'
  2. omdat 	hij	slaapt waarschijnlijk
    because	he 	sleeps	probably
    'probably because he's sleeping'

As is clear from the English translations, in (1) the adverb waarschijnlijk 'probably' scopes below omdat 'because', while in (2) it scopes higher. Now, that an extraposed adverb in Dutch can scope relatively high should come as no surprise, but as high as the complementizer? There's two obvious ways of interpreting this contrast: (i) waarschijnlijk can indeed adjoin as high as CP and from that position it takes scope over omdat, or (ii) omdat is not as high up in the structure as one might think—e.g. it occupies a low projection in a split CP-system—allowing an extraposed adverb to take scope over it.

Unless of course the real answer is secret option number three: you'll notice that the examples in (1) and (2) don't contain a matrix clause. What if waarschijnlijk is not so much extraposed from the adverbial clause as it is a matrix adverb? Let's take a look at a more complete example:

  1. Ze	hebben 	hem	ontslagen 	
    they 	have 	him	fired 	
    omdat   hij	stal 	waarschijnlijk.
    because he 	stole	probably
    'They probably fired him because he stole.'

Forget all my earlier talk about waarschijnlijk adjoining all the way up to CP or omdat being base-generated lower that the highest C-position: maybe waarschijnlijk is just a matrix adverb in examples like (2) and (3) and never has any relationship with the adverbial clause. That would immediately explain its high scope, but it wouldn't mean we're out of the woods yet. For one, the combination of because-clause and adverb seems to form a constituent, as they can be fronted together to the pre-V2-position:

  1. Omdat   hij	stal 	waarschijnlijk
    because he 	stole	probably
    hebben 	ze	hem	ontslagen. 	
    have	they	him	fired
    'They probably fired him because he stole.'

This would seem to bring these examples in line with a construction discussed by Sjef Barbiers in the mid nineties and which I also briefly dabbled in (not in ‘Nam of course) ten years ago in unfinished and unpublished work, whereby both an argument and an adverb precede the finite verb in a declarative main clause:

  1. De  krant 	gisteren  meldde   het voorval  niet.
    the newspaper 	yesterday reported the incident not
    'The newspaper didn't report the incident yesterday.'

What makes this example similar to the data discussed above is that the adverb gisteren 'yesterday' takes clausal rather than nominal scope. In Sjef's analysis the object-DP de krant 'the newspaper' is in the specifier of the adverb gisteren 'yesterday', while I tried to argue that (5) is a genuine case of V3, but what both of us agreed upon, is that the adverb originates in the clausal spine, so it looks like option C might be the right one to go for after all.

  1. If you're an old-fashioned guy like me, you might even think that this is because every projection up to CP is right-headed and so in (2) you're adjoining at least as high as IP.

  2. In fact, if this is the right solution, it must adjoin as high as CP, because to my ear, the readings indicated are the only ones that are available.

  3. The relevant ground for comparison is the DP de krant van gisteren 'yesterday's newspaper' (lit. the newspaper of yesterday), where the adverb does not take clausal scope.

Applications in the Air

I've always been in love with the MacBook Air: from the day Steve Jobs pulled one out of an envelope (i.e. the day when it was still ridiculously overpriced, underpowered, and equipped with a measly 80GB of non-SSD storage) I knew that one day this beauty—or rather, one of its descendants—would be mine. I like my gadgets small, especially when they are equally capable as their bigger siblings.

Fast-forward to 2014:

It's a white box!

It's a white box!

Needless to say, this wasn't a snap decision. Like any good nerd, I first went through an extensive mental process of justifying the purchase: I didn't simply want a MacBook Air, I needed one to be able to do my job properly. (In fact, it was a miracle that I had gotten this far without one.) This meant finding that highly specific use case that wasn't already covered by (a) my MacBook Pro, (b) my iPad, or (c) my Asus Eee PC 1005HA-H. Fortunately, as I was in the midst of this arduous task, John Siracusa said: Justification, schmustification: just go ahead and buy the damn thing.

With the hard part out of the way, it was time to enter stage two of the pre-purchase fun: the configuration. First of all, was this the right time to buy a MBA? The MacRumors Buyer's Guide suggested that I should Buy only if you need it but that was a bridge I'd already crossed. There had been whispers of a twelvish-inch version with a Retina display but I actually prefer the 11-inch form factor—recall that I like my gadgets small—and Retina is a bonus, not a must. Moreover, Broadwell didn't seem like it was coming any time soon, so there was little point in waiting for the increase in battery power that this tick is supposed to bring. In short, all signs started pointing to 'yes'.

Step two: the configuration. That I wanted an 11-inch Air rather than a 13-inch one should come as no surprise by now. Similarly, deciding on the right amount of RAM was a breeze (always max out the memory), but the CPU took some more pondering: was the upgrade from a 1.4 GHz Core i5 to 1.7 GHz Core i7 really worth 150 euros? Would I be doing anything so CPU-intensive on this machine that the difference between the two configurations would even be noticeable? In the end I opted for “better safe than sorry” and chose the i7, especially when AnandTech’s testing revealed that the i7 (surprisingly) was more battery-efficient under light usage. As for the hard disk, the MacBook Air standardly comes with a (non-upgradeable) 128GB SSD and that’s also what I went for. An upgrade to 256GB wouldn’t have meant I could fit all my stuff and any upgrade higher than that is so prohibitively priced that it wasn’t even on the radar.

All of which extensive preambling brings me to the actual topic of this blog post (no, we weren't there yet and yes, there is one): moving from from a 480GB MacBook Pro to a 128GB MacBook Air meant I couldn’t follow my usual upgrade path of restoring from a Time Machine backup. Instead, I had to go all Dan Benjamin and configure the Air from scratch. That in turn was a good incentive to take stock of what applications I really need/use in daily life, and which ones I can happily do without. I’ve listed them below, split up into "no-brainers", "trusted companions" and "flotsam & jetsam".


Dropbox: Dropbox has been indispensable in my work life since the day I first installed it. Everything I am currently working on or involved in—be it related to teaching, research or fun—is in my Dropbox-folder. Thanks to their "invite a friend, get 250MB extra storage space"-policy I’m currently up to 10GB of free storage, but this is a service I’d actually consider paying for if I really needed more space. Almost all of my collaborations involve Dropbox in some form and the fact that all these files are also accessible on mobile or in a web browser has saved my ass on many an occasion.

TextExpander: such a simple idea, so incredibly useful. I have a bunch of general-purpose snippets (names, greetings, etc.), often create temporary ones for repetitive tasks, and have loads of application-specific ones (e.g. for writing LaTeX or HTML). Over the past couple of years, TextExpander has saved me many an hour of typing time.

Things: true to my INTJ-personality, I’m into making lists, to do and otherwise, and in this respect I’ve been a heavy Things-user for several years. It is simple yet powerful and it syncs extremely fast and reliably across all my devices. There are times when I want to make even more detailed overviews and lists—the J-portion of his personality is strong with this one—and I consider switching to Omnifocus, but I always end up sticking with Things.

TotalTerminal: no, I'm not a Unix-ninja who lives and breathes the command line and thinks GUIs are for pussies, but there's something super-convenient about having a Terminal only a single shortcut key away at all times, regardless of where you are or what you are doing, and I find myself using it basically every day.

Trusted companions

Texpad & BibDesk: my go-to LaTeX-editor and bibliography manager. Texpad is being actively developed (there's an iOS-version as well) and keeps adding stuff, but for me the killer feature is how it lets you see the LaTeX-version and the pdf-output side by side. BibDesk is basic, no frills, but rock solid (although it drives me nuts that Cmd-F doesn't mean "search" like in any other well-behaved Mac-app).

MailMate: I've been having a love-hate relationship with Apple Mail lately, and as I was setting up my mail accounts on the Air and Mail started hogging the CPU and sent the fans spinning, I decided it was time for an alternative. After a brief search (and influenced by an overview article from Macworld) I settled on MailMate, and haven't been disappointed so far: it is rock solid, eminently customizable (with keyboard shortcuts for just about anything), very energy efficient, and has great support. My only gripe is that it doesn't support POP (minor annoyance) or Exchange (medium annoyance), but neither of these was a dealbreaker.

BBEdit: I'm not a programmer by any means (I only know a little bit of Python), and so BBEdit, the programmer's text editor par excellence, is probably a bit overkill for me, but when I use it, I always love it. It is perfect for preparing large files with raw data—amazingly powerful find and replace!—and can open many different types of files without clutter or hassle.

Remote Desktop: when you're one of a handful of Mac users in a mostly Windows environment, Remote Desktop is a very useful app to have. I use it mainly to connect to the university's file servers.

Tweetbot: my favorite Twitter client for Mac (and iPhone for that matter) these days. Elegantly designed, fully featured yet intuitive to use, and it syncs well: what more do you want?

DaisyDisk: this is one of those apps that I rarely use, but whenever I do, I'm very happy to have it, and on a space-constrained MacBook Air it is a valuable addition. DaisyDisk allows you to keep track of and manage disk space in an elegant and intuitive way. Bought it based on a Daring Fireball sponsorship and have not been disappointed.

Chrome: this was a close call, in that Chrome was originally going to be in the "Flotsam & jetsam"-list: I wanted to make the Air a Flash-free, Google-light safe haven. After a few weeks, though, I caved and installed Chrome: sometimes it's just darn handy to have Flash available. Moreover, all things considered, Chrome is a very good (and superfast) browser, and more generally, it's always useful to have more than one browser around.

Skype: more or less the same story as with Chrome: to repurpose a famous Jobs quote: I think Skype is a bag of hurt. Half the time, it works poorly, if at all, and it is a tremendous battery and CPU hog. However, I was in a pinch, needed to have a conference call with a co-worker, and neither FaceTime nor Google Hangouts worked, so a quick Skype install was required.

Flotsam & jetsam

Microsoft Office: in case you wonder, I don't like Office.Really don't like it. Seriously. Me no likey. So with the Air forcing me to start from scratch, I decided it was time to say bye-bye to Redmond. Most of my own writing has been switched over to LaTeX (and TextEdit for notes and brainstorm-style texts), so that part was easy. Slightly trickier were (a) non-LaTeX co-authors, and (b) functioning in an Office-centric environment, but as it turns out, a combination of Google docs and Pages/Numbers goes a long way.

TotalFinder: this is a case of 'obsolescence through OS X-update': I was using Totalfinder mainly because it gave me tabbed browsing in the Finder, but since that has now become a system feature, I no longer had a need for this app.

Echofon: superseded by Tweetbot, for the reasons outlined above (the main one being OS X/iOS-sync).

iStat menus: this one was briefly in the "trusted companions"-category, but I got tired with it quickly. I've long used and liked this app as a dashboard widget (called iStat Pro), and so when I saw there was a similar app, I decided to try it out on the Air, but was disappointed: it often took too long for the app to display up-to-date info, and—quite ironically—it proved to be fairly resource intensive.

This concludes my overview. Given that my app usage tends to fluctuate over time, I might revisit this list occasionally, but for now, it provides a nice picture of what applications I have (up) in the Air.

  1. Just a quick example, whenever the fans on my Mac start spinning, I open up a Terminal window, type top -o cpu, and immediately see what's causing the trouble (usually iTunes or a pending software update).

  2. Well, half geek half nerd.

  3. Ok, technically that is not literally what he said, but it sure sounded like that to me at the time.

  4. In the meantime, Apple has actually upgraded the Airs, but they’re relatively minor spec bumps and I’ve already had several weeks worth of fun from mine, so no regrets here.

  5. That’s one thing that hasn’t changed since the first version of the Air: Apple’s SSD-prices are still unreasonably high.

  6. Yes, I know that Dropbox is not a substitute for backups, and so have several other backup mechanisms in place.

  7. In fact, when I encounter a file type that I haven't seen before and that my Mac doesn't know how to open, my first option is always to try BBEdit.

  8. For a long time, Chrome was my primary browser as it was clearly faster than Safari. Since the scrolling issues in Mavericks, though, I switched to Safari and have not looked back.

  9. Yes, I know that streaming video is bound to tax the CPU and the battery, but when I use FaceTime or Google Hangouts, the effect seems less pronounced.

  10. For instance, I'm currently pretty heavily invested in R and RStudio, and am beginning to enjoy the taste of Caffeine, but that's food for another post.