The History of the Scroll Wheel

Eric Michelman, program manager for Excel

Back in 1993, as I was watching many Excel users do their work, I noticed the difficulty they had moving around large spreadsheets.  Finding and jumping to different sections was often difficult.  I had the idea that perhaps a richer input device would help.

My original idea was the zoom lever.  This was simply a lever, presumably for your non-mouse hand (i.e. on the left side of your keyboard if you're right-handed).  When you push it away from you the spreadsheet zooms out.  When you pull it towards you, it zooms back in.

Imagine if you could control how big the earth is... If you want to go to the store, you would shrink the earth down (everything but you shrinks too), till you could see the store and then just take a big step over to it; then once you're there and want to go inside, you'd bring the earth back up to normal size and proceed like nothing unusual happened.  If you wanted to visit San Francisco, you would make the earth much smaller, till you could see the SF Bay, take a step over to it (we'll ignore tsunamis here), and then bring it back to normal size.  To walk to the next office, you wouldn't resize the earth.  Same thing for spreadsheet navigation.

I prototyped this by hooking a joystick up to my computer and using DDE to connect it to Excel for zooming.  Using a joystick button along with the stick, I also had it do "data zooming", which was drilling in and out through Excel outlines.

This all seemed useful, so I showed it to the Hardware division at Microsoft.  They were initially cool to the idea, which I presented as a zoom lever, and it didn't go anywhere at that point.

At this point most people thought it was kind of wacky.  Focusing on zooming was a very Excel-centric approach.  More specifically, it was a very 2-D centric approach.  That is, using an application that presents 2-dimensional data, like a spreadsheet or graphics, it's very useful to zoom in and out.  But the other main style of application is a linear flow application like Word, and there it's not as useful.  You could do zooming with Word, where zooming out shows you a multi-page view and then you click on a desired page and zoom into it, but that's not as natural as with a spreadsheet or graphics and images.

2004 Note: Microsoft has now introduced keyboards with a zoom lever built in. They call it a zoom slider.

A number of people suggested adding panning and scrolling functionality.  In particular I remember Chris Graham saying zooming was just too limiting and it should pan as well.  In response to this feedback, I added panning to the prototype, so moving the joystick side-to-side and back-and-forth scrolled Excel in the corresponding direction.

Around this time, the hardware guys came back and said that they had considered adding a wheel to the mouse, but they weren't sure what it would be used for.  Document navigation answered that question, so they said that if I could get Office to support it, they would build it.  This really meant Excel and Word since they were the "800 lb gorillas" -- if Excel and Word supported something, then the other Office apps would follow, and if Office as a whole supported something, then everyone else would follow too (this was early 1993 when Office was the heart of most people's computer usage).

Being the program management lead for the next version of Excel, I was able to get a commitment from the Excel team to support it.  The Word group was also willing to go along, due in no small part to the support of Ed Fries, their development manager, who I had worked with earlier in Excel.  The program manager assigned, Todd Roshak, and developer, Ryan Kim, did a great job by focusing on scrolling for Word.

Having Word scroll in response to the wheel roll while Excel zoomed was very controversial since people didn't want them to be incompatible (even though Ctrl-roll allowed each to do the other function too).  Ironically, most of the pressure at that time was on Word to go along with zooming since that was still considered the primary use of the wheel.

This zoom vs scroll question remained a huge on-going controversy within the project.  There was a great deal of pressure for compatibility (having all the apps do the same thing), and I resisted this for two reasons.  First, I didn't think we had enough experience with the wheel to stop experimenting at that point, I wanted to let people continue trying different things as they saw fit.  After all, if we insisted on strict compatibility from the start, we would have been left with only zooming.  Secondly, I was more concerned with users finding the wheel very useful in their main applications.  Being compatible but not useful didn't seem to me like a recipe for success.  We did a number of usability tests as well, but they produced the usual results which are that each program manager (including me) sees what they want.

The hardware group gamely went along with this controversy.  They accepted my initial enthusiastic pitch of zooming and it was a bit uncomfortable for them to proceed with what was a large investment in tooling up to make the new mouse while a big controversy raged over what it would be used for.  But they were always nothing but constructive and went along with it. Their team really deserves a lot of credit for moving forward and pulling it off. Carol Clemett was their project manager and she excels at the graceful running of large projects. Steve Kaneko did the industrial design (if that's the right term here). Kabir Siddiqui was their lead hardware designer and he did a great job adding the wheel and then mid-stream making the wheel a button as well (see below). Todd Holmdahl led the software development and Tim Brewer was the program manager, both of whom did a terrific job. Rick Thompson was head of the hardware group and enthusiastically supported the project and helped it get going. Undoubtedly I'm forgetting people who deserve mention and I'm sorry for that.

Around this time, we also made the wheel a button -- you could press it as well as roll it.  I remember David Jones, an Excel program manager, bringing in a TV remote which had a wheel button and we saw that it worked pretty well.  Adding this allowed panning -- while keeping the button pressed and moving the mouse, the document scrolls in the direction that you move the mouse.  The further you move the mouse, the faster it scrolls.  And then if you just click the wheel (as a button), you go into "reader mode" where you can have the document continuously scroll (where the speed is adjusted by how far you move the mouse from the point of button-down).  This is cool functionality, and remains useful today, although in retrospect I don't remember why we thought this was important enough to add in the middle of the project.  Again, the hardware group made a superb effort to add this, and it was a non-trivial engineering task to combine the wheel and button within the mouse.  I should add that the Excel and Word developers on the project, Juha Niemisto and Ryan Kim did really terrific work on this project and enthusiastically took the functionality far beyond what was originally planned -- not an easy thing to do in the middle of a Microsoft development project where you have a long list of schedule-based deliverables.

The zoom vs scroll controversy eventually came to a head when one of the marketing people in the hardware group gave a pre-release demo to Walt Mossberg of the Wall Street Journal.  He liked the idea but was scathing in his "Microsoft doesn't get it" criticism of Excel and Word being "incompatible".  When I heard how it was presented to him I was quite angry since it seemed to me that it was presented poorly, without adequate explanation of the benefits of our approach.  But then I had a small epiphany and realized that if our approach required it to be presented in "the right way", then it was the wrong approach.  So I sent out an "I Give Up" email and agreed to have Excel scroll by default.  I was told that at an Executive Staff mtg that morning (Billg & staff) they spent the first 10 to 15 minutes talking about whether that was the right decision.

Another aspect of the project worth mentioning was the support of the Windows team, in particular Mike Schmidt.  Having the mouse driver generate the roll message was an inefficient way to handle it, so the roll msg was built into the OS.  Originally we wanted a new message for the wheel button, but Mike said that there already was a third button defined and we should use that, which was the right approach.

Along the way I also worked with many other product groups within Microsoft to encourage their support of the wheel.  By the time the mouse shipped, over 20 product groups had support built in or under development.

From the Visceral Excel project

This project was part of a larger project I called Visceral Excel. The idea was that by 1993 Windows apps had strayed from the original GUI intention, which was that you'd see familiar things on the screen and interact with them in intuitive ways. The classic example was the desktop arrayed with your documents and a trashcan into which you could drag and drop a document. Or dynamically resizing columns, where you click and drag the border and see it resize as you move it. The point was that you'd intuitively know how to use the computer without a lot of thought and mental processing on your part. 

In other words, GUI's were to be a more visceral experience.  This was the point of the Visceral Excel project -- to get us back to that.  Even in the mid-90's, the big Office apps were past 200 menu commands, with lots of compound dialog panes, and untold numbers of dialog box options.  Of course today it's even worse.  Using these apps was (and still is) very much an intellectual exercise of immersing yourself in the product's UI, not your content and objectives. This work is over 10 yrs old now, but I think it's still just as relevant and important. Read more about the Visceral Excel project.