Google Notifier tips and tidbits

Monday, January 29, 2007 at 7:37 PM

Posted by David Phillip Oster, Mac Software Engineer

Google Notifier is a program I wrote that lets you know when there is new Gmail ready to be read in your inbox and when you have upcoming Google Calendar events. The basic features of Notifier are pretty obvious, but there are a few bits of trivia that Notifier users might be interested in. That's the purpose of this post.

Notifier is a descendant of Gmail Notifier, Greg Miller's Gmail-only program. (And I want to thank him for getting me started here at Google.)




Notifier basic interface philosophy

To understand the basic interface strategy of Notifier, let's compare it with the way Dashboard works. Dashboard is designed to show you an instrument panel of information, like a car's dashboard, when you want to see it. Dashboard flies in when you want it, and flies out when you're done. In a sense, you are interrupting your normal collection of applications to see its information. Google Notifier is intended to be the opposite: you've given it permission to interrupt you, to get your attention about something nearby in time. If you want to see the full details of your calendar, you can open Google Calendar in a browser. If you want a quick overview of what's important now, Notifier is the way to go.

Based on Calendar GData

The first version of Notifier only let you know about Gmail. After that version came out, the Google Calendar team launched a new, publicly available data feed called GData for Calendar. This seemed like a great opportunity to add Calendar features to Notifier, so I revised Notifier so that it also lets you know about your upcoming Calendar events.

Notifier gets attention your way

When it's time to get your attention, Notifier plays a sound and shows a dark, translucent window in the upper right corner of your screen. That window fades out after a few seconds, or you can click on it to get rid of it right away. I've picked a sound and a window style I like, but because this a Macintosh, you can make it work the way you want: you can pick your own alert sound in Notifier's Preferences dialog, and you can completely change the way Notifier gets your attention by using the free third-party product Growl, with the Growl+Notifier adapter. (Note: these are not Google products, and I've got no say in how they behave.)

Easter egg

As a reward for reading this far, here's a hidden feature you might like. Pull down the Notifier menu (either Calendar or Gmail), hold down Command and Option, and click Preferences on the menu. You'll see a hidden settings editor. Enter MaxMessagesOnMainMenu in the Key field (upper and lower case must be entered as shown) and 20 in the Value field, then click Set. Quit Notifier and start it up again. Now, when you pull down the Notifier menus, you'll see all your Gmails and all your Calendar events listed in single menus, without any "View More" sub-menus.

If you want to get the sub-menus back, get the hidden settings editor back again, enter MaxMessagesOnMainMenu for the Key, and 4 for the Value, then click Set. Quit Notifier and start it again, and your sub-menus will be back, good as new.

The Spotlight File System for MacFUSE

Tuesday, January 23, 2007 at 10:49 AM

Posted by Greg Miller, Software Engineer, Mac Team





A little over a week ago, we announced the open-source release of MacFUSE. Since FUSE makes it so easy to slap a file system view on data, I thought it might be neat to give Spotlight a file system interface. So in my spare time I wrote SpotlightFS, which is now available for download from the MacFUSE project page.

SpotlightFS is a MacFUSE file system that creates true smart folders, where the folders' contents are dynamically generated by querying Spotlight. This differs from Finder's version of smart folders, which are really plist files with a ".savedSearch" file extension. Since SpotlightFS smart folders are true folders, they can be used from anywhere—including the command line!

SpotlightFS is not very complicated, and it's a good example of what can quickly and easily be done using MacFUSE. Please check out SpotlightFS and the other cool stuff on the newly updated MacFUSE project site.

Macworld keynote campout

Friday, January 19, 2007 at 12:16 PM

Posted by Rose Yao, Mac Product Manager and Mike Pinkerton, Software Engineer

Remember when I said I was "new to the Mac"? Well, after camping out the night before Steve Jobs' keynote speech at Macworld Expo, I now consider myself a Mac veteran. I joined a group of product managers and Google Mac Team engineers, and we were the second group in line to get in. Although the Google Mac team now has almost 20 people, I only managed to convince three engineers that it was a good idea to camp overnight in San Francisco to see the keynote. (I wonder why?)

So here's the rough timeline for this whole thing based on what Mike and I remember:

December 2006 - Rose gets shamed into camping out at Macworld Expo by other Google product managers because she is the Mac PM. Rose immediately turns around and tries to shame other Mac team members into camping out with her.

January 8, 3 PM - The people going to the campout wonder if we have tents or need permits to camp in the middle of downtown San Francisco. Rose emails Avichal, our official planner for this, who responds, "Tents? Permits? What?" We know we'll be OK, however, as our Engineering Director would be more than happy to bail us all out of jail on trespassing charges simply to get the airline miles.

6:30 PM - Headed to Moscone North to pick up our badges. This will ensure we do not need to get out of line at 6 AM :).

8 PM - We get our badges and wonder what's next. Aha, Thai food and beer! Need you even ask?

10:45 PM - We get in line behind a few guys from Arizona (whose names we wrote down but can't read because we didn't write them down until 5 AM; we think they were Andrew, Steven, and Robinson). We're incredibly disappointed to find that we aren't the first in line, but we quickly learn that it's better for a restful (hah!) night's sleep that we aren't, as the front of the line collects much media attention. With long faces, we set up Camp Google behind the early birds and settle in.

11 PM - A photographer from Apple comes by to take our picture. Apparently he couldn't believe we were camping out either.

11:10 PM - We start playing some odd board game derived from some other odd board game, but when the rules became too complicated (what, there are more than two rules?!) we end up playing BS (Rose won). At this point it starts to sink in that we really are in for a long night of concrete and board games.

11:20 PM - Media descends: Unofficial Apple Weblog interview. Rose tries to get free PR for Google Earth, SketchUp, and Notifier, but just ends up getting hit on. The rest of us try to look busy, or enthralled in some other board game, so we won't get asked any questions. In the background, the larger of the two tents is raised, causing passersby to stop and ask what tickets we were in line for. We decide the best answer is either Aerosmith or Bon Jovi, because that sounds much less lame than lining up for a computer show.

11:45 PM - Marissa Mayer, our VP of Product Management, shows up to encourage the campers. We manage to fit 14 people into an 8-person tent. It was warm, it was cozy, and it felt something you would do in college -- like so many other things we do around here.

January 9, 12:30 AM - Some people decide to start working.... Also typical for Google.

2 AM - 4 AM - Catnap. Rose stays warm, but several of us do not, although being in the tent allows us to stay fully functional. It's quite cold (even by East Coast standards) and there is a significant difference in temperature inside and outside the tent.

4:30 AM - Documentary film crew shows up. Avi wakes up at 3:50, Pink at 4:30, Rose and Amanda around 5:00. By this point we are very glad we're not first in line, as every 5 minutes another group of people with cameras and microphones shoves an electronic recording device in the faces of the poor chaps ahead of us. They are a popular item; we're not sure they slept a wink the entire night.

5:15 AM - The coordinator comes out and lets us know they'll "soon" be letting us inside, so we need to start clearing the tents and compacting the line. At this point, the line extends down two full sides of Moscone West, and nobody looks particularly warm or happy. There's still at least another two hours until sunrise. We compact the tents, and the line compacts in turn. Weary faces greet Marissa as she arrives fresh with doughnuts and water. Coffee arrives, donated by a local coffee shop.

6:20 AM - Hooligans drive by, shouting "Windows Vista" out the car window.

6:35 AM - We start moving indoors. Incredulous looks from Apple employees inside (you would think they're used to this by now). One of us says, "It's gonna be another two hours. I'm gonna work!" They snake us around inside the building, reminding us that we are supposed to be the example for the remainder of the mob behind us: we must walk slowly and not run, else everyone else will run. Run?! Who has the energy to run?! They lead us to the very front of the line, and we can almost feel the cushions on the chairs in the 10th row. Then they start lining up the SuperPass VIP ticketholders beside us. They get to go first, so we don't like them. People start doing calculations on how much each lost hour of sleep was worth in terms of the VIP ticket price.

6:50 AM - Macworld employees are miming a tennis match with their large directional signs. I guess we're going to be here a while.

7:50 AM - People with Platinum and Superpass tickets start moving forward -- and stop. Everyone sits back down again. The concrete indoors is only marginally better than the concrete outdoors, but at least it's warm.

8:30 AM - We're moving. Then not. Stop teasing us!

8:55 AM - Almost moving. This time for sure! Again we're supposed to be the responsible ones and walk (not run) up the escalators, and we're assured we will be getting incredible seats for the keynote. I think they just said that so we wouldn't trade their lives for a muffin.

9:06 AM - We're in, about halfway back from the stage. The entire front section is taken by VIPs, Platinum, and SuperPass ticket holders. After dreams of 10th-row seats, we're disappointed, but we're in!

11:30 AM - The keynote is over. Steve Jobs is a god and we must all buy an iPhone now :) Sadly, there's nothing to buy immediately so we can't even run over to the Apple store and fight over boxes of pretty plastic. Now we must wait, and tape together our cutout iPhone mockups like everyone else.

As a team-building experience (rest of the team, where were you? You know who you are!) this was a lot of fun. Seeing so many Googlers excited about Apple and its announcements keeps us excited about delivering insanely great Mac products. Would we do it again? I can't say yes for sure, especially since we ended up so far back after all that waiting and sleep deprivation. But we had to do it once, and we certainly picked a great show to camp out for. Next year I think I'll just wait for the weblogs. Unless there's a SuperPass out there with my name on it.

Taming Mac OS X File Systems

Thursday, January 11, 2007 at 11:57 AM

Posted by Amit Singh, Mac Engineering Manager

Google is a fantastic company to work for. I could cite numerous reasons why. Take the concept of "20 percent time." Google engineers are encouraged to spend 20 percent of their time pursuing projects they're passionate about. I started one such exciting project some time back, and I'm pleased to announce that Google is releasing the fruits of this project as an open source contribution to the Macintosh community. That project is MacFUSE, a Mac OS X version of the popular FUSE (File System in User Space) mechanism, which was created for Linux and subsequently ported to FreeBSD.

FUSE makes it possible to implement a very functional file system in a normal program rather than requiring a complex addition to the operating system. More importantly, the FUSE API is very easy to program for. The large number of interesting and/or useful FUSE file systems out there is a testament to this. An often-cited example of such a useful file system is sshfs, which until now was not available on Mac OS X.

One of the missions of the Google Macintosh team is to contribute to the Mac community and make the Mac OS X experience better for users and developers. We hope that MacFUSE will not only make several existing FUSE file systems readily available to Macintosh users--typically, right out of the box--but will also help Macintosh developers give vent to their creative fervor and come up with innovative products and file systems that we have never seen before.

The MacFUSE implementation Google is releasing today includes the following components:
  • A virtual file system (VFS) kernel extension
  • A special-purpose mount_fusefs program
  • A patch to the FUSE user-space library
  • A patch to the SSHFS file system
More details on using and developing for MacFUSE are available on the project's Google Code page.

Small disclaimer: Please note that MacFUSE is a complex piece of software, and it is a work in progress. We believe in releasing early and often, so we're releasing it now so that the community can help us to make it more robust.

Finally, I would like to express my thanks to the FUSE developers for having created FUSE in the first place. Miklos Szeredi did a wonderful job with FUSE on Linux, and Csaba Henk did an equally great job porting FUSE to FreeBSD.

Enjoy your file systems!

Spolsky and me

Thursday, January 04, 2007 at 9:48 AM

Posted by Mike Morton, Member of Technical Staff, Mac Team

One of the nice things about working for Google is that even though we engineers have a lot to do in our day jobs, we’re encouraged to learn new things. We attend "tech talks" (which aren’t always technical, despite their name), tackle 20% projects, take training courses, and so on. Among the things I do is try to read one technology book each quarter. That can be a lot of effort, given the complexity (not to mention the sheer mass) of some of these books.

Last quarter, I read User Interface Design for Programmers by Joel Spolsky, host of the popular Joel On Software. It was more interesting — and more useful — than I expected.

It’s also short (about 140 pages paperback) and fairly light reading, a rare pleasure in a technology book these days. I recommend it. My only complaints are that it’s five years old and mostly covers Windows (so it’s really 15 years old in Mac years). Most of the book revisits things we (should) already know: user-centered design, the user’s model, the importance of usability testing. Spolsky is great at explaining these things succinctly and memorably.

Here are some of his thoughts, which I think are worth keeping in mind, even though I don’t agree with all of them:
  • Usability testing of five or six users tells you all you need. You’re looking for big problems, not statistical significance on the small ones.
  • Users want to accomplish their tasks, not use your features ("users care about a lot fewer things than you might think").
  • Usability isn’t the same as learnability, and “usability testing” usually tests the latter.
  • So what if 30% of users fail to accomplish the task in testing? Those people will ask for help or read the doc, or aren’t your target users, anyway.
  • Karen Fries at Microsoft invented the Wizard as a way to teach you how to use the usual UI, not to do the task for you.
  • Users don’t read (documentation or dialog instructions).
  • Users can’t use the mouse as easily as you think.
  • Invent imaginary users, name them, and talk about them to make them seem like real people, which they do represent.
  • Icons work well to represent nouns, but not verbs.
My favorite quote: "Pull up the Tools > Options dialog box and you will see a history of the heated arguments that the software designers had about the design of the product." That’s not exclusively a Windows problem — the same is true if you select Preferences from the application menu on a lot of Mac products. The next time I have the urge to say “Let’s just make that a preference setting," I should keep this book in mind.

If you have time to read only one chapter, read “The Process of Designing a Product," which describes Activity-Based Planning. It’s one of several chapters you can read for free on Spolsky’s site, but as he points out, the published book is more polished, and you might enjoy it enough to read the whole thing.