The designer working on the red squiggles was Randy Winjum. He provided dozens of alternative graphic designators, but the squiggle stuck.
And I remember you asking us for the fancy animation in the Answer Wizard! You wanted the dialog to somehow reflect the intelligence behind it to differentiate it from 'just another help index' and thought an animation would do the trick!
It's probably hard for most people to appreciate the pioneering use of Bayesian Networks in a user interface given the ubiquity of AI in products today. And because the model sat local on the machine, it lacked the ability to improve over time. Eric Horvitz has a nice history written up that also includes the importance of conducting usability lab research to tune the experience and the shipping model. http://erichorvitz.com/lum.htm
It's also worth pointing out that because early instrumented version (IV) data typically came from 'early adopters' and 'advanced users', the data could give the wrong impression of real world use. But it was still better than the alternative - which was a lot of opinions! Still the same, much of the dominant patterns found in the telemetry were very similar across activities and demographics - like the inordinate use of the backspace key! As Office scaled to the enterprise, IT managers put gates on access to 'normal people' using Office inside their companies making data collection from the field increasingly difficult. It still is.
I have a little flavor to add to the red squiggly story (or should I say flavour, as a fair %age of the Word 95 team was Canadian).
I was the dev lead (headed the core engineering team) for Word 95. What a great project. Very small team - 6 developers including myself, one program manager, and a very small test team. Everyone on the team was super strong - literally every person moved one level up the management chain within one release after Word 95. The majority of the Word engineering effort was on what became Word 97, so Word 95 was limited in scope.
Job 1 was to sim-ship (literally on the same day) an incredibly high quality product with Windows 95 as the first 32-bit version of Word, and take advantage of what Windows 95 had to offer. The second was to do what we could for high-impact features, and fixing the most annoying problems, but always remembering that Job 1 was primary. On the day I took over Word 95, I was told (only partially in jest) that my primary job was to say No. There were a ton of great ideas for improvements, and people very passionate about their ideas, so I had to create some creative mechanisms to politely defer, but ensure that the best ideas were eventually implemented.
I vividly remember the thinking behind background spelling.
I had been on Word for a number of years, and one of the teams I'd previously led was the proofing tools team, which did spell check, grammar, hyphenation, thesaurus, etc. Since I'd also designed and implemented the API that allowed various Microsoft apps to easily use spell and other text checking (one of my first patents) so I was pretty familiar with the speller and how to effectively use it within an app.
I had also previously run the File Conversions team, which did document conversions to and from WordPerfect, Wordstar, Lotus 1-2-3 (for Excel), etc. We had agreements with a number of corporate customers (like the ones running the IV) in which they also shared many documents with us (both Word and competitor docs) which allowed us to ensure we did a great job of supporting them.
Partway through the Word 95 project, three things came together for me.
1) A lot of the documents I saw from customers in the file conversions team had tons of spelling errors. A pile of them. Enough that it made me wonder if they ever ran the spell checker. So I talked to a number of the customers. It turns out that they DID run the spell checker, or thought they did. But perhaps they didn't run it on the last few versions, or had turned off the option to run the spell checker when they saved the document. The standard option (whether Spell was invoked manually, or automatically when the document was saved) was to go through the entire document from the beginning, highlighting every single misspelled word. The user had to fix, ignore, or add each word to their dictionary. This often took a very long time, esp with a long document, and often they wanted to save and go home, or switch to a different task. So in short the UI worked, but it wasn't a great experience, and thus many users skipped spellchecking their documents. Even worse, they didn't realize they're skipped it until I talked to them about it, as they were surprised that I found all those typos in their docs.
So it was clear to me that the existing UI and method of invoking and operating spell checking, which was 'modal' (it took over and interrupted anything else you were doing until it was finished) wasn't optimal, and it resulting in a lot of docs that had misspelling 'left the building' unintentionally.
2) The Intel person supporting Office engineering, Susan Mattison, had long been trying to convince me to have Word and other Office apps do 'more work'. They wanted people to upgrade their PCs with faster Intel processors. Since a lot of the work I did on Word was performance (speeding up app launch, reducing memory and CPU consumption, etc.) I was predisposed to be in the opposite camp, to work on the slowest machine possible, to give a great experience. (Fun tip: check out defrag.exe, which shipped with Office 95. It rearranged clusters on disk in a particular order so that Office apps would launch 70% faster, as the disk would see and read them in the exact order they were needed, rather than seeking from winword.exe to office.dll to some windows dll and back to winword.exe, etc.)
Susan had made a recent visit and revisited the theme of having Word do 'something hard and interesting'. I had a dream that night about Word rendering a video game in the background (secret tip: Word for DOS 5.5 has a working Space Invaders game as the credits, where shooting a ship causes it to explode into the name of a member of the team. I may or may not have been one of the two engineers that wrote it)
3) I had been doing some other performance-related and bugfix work in the idle loop, and it was a common pattern for it to 'walk through' the document, performing some task. The main one in fact being displaying the document on the screen (rendering was the term we used internally) - basically only capturing keyboard input was a foreground task, everything else was done in the idle loop. So the pattern of walking through Word's text and associated data structures that apply to text was already there. I realized that 'has been spell checked' was already part of the status of text, so that spell check wouldn't accidentally correct the same section twice in a single run. And when I checked, there was room in the data structures for an additional 'is currently misspelled' bit! And these data structures would be saved on disk with the document, so the spelled status was always 'up to date' once it had been done once, subject to any document changes or edits.
So all of these came together in basically one 'aha' moment, into the idea for making spellcheck modeless, and doing it in the idle loop as background spelling. Coding it was pretty straightforward, it didn't take too long. All I needed to do was walk the doc, spell check any word that hadn't been spell checked, and set the 'misspelled' bit if necessary. Then I needed to update the 'FormatLine' code which displayed the document on the screen, to add visual formatting to a word if the word has been spell checked and the misspelled bit was set. I did the spellcheck as the lowest priority task in the idle loop, and it was coded, as were almost all the other idle loop tasks, as interruptible, meaning that it would save its progress as it went along, and if something else happened (like a user hit a key) it would immediately abort. But Word was pretty fast, and could get through everything in the idle loop pretty quickly. Others as you read came up with the red wavy underline as the formatting. We originally tried underlining or double underlining, but quickly realized it would be problematic if it was something that could be done 'on purpose' in the document formatting.
At the time it seemed like a cool, high-impact, low-risk feature add (the code was straightforward, and it was easy to test and validate both from the user and internal code perspective). Little did I know what the reaction would be!
"In Excel 3.0 there was even a presentation template that made Excel look like PowerPoint complete with animated transitions between slides (which were really ranges of cells)."
Ahh, the "Slide Show" Add-in. A classic shot across the bow in the checkbox feature wars with Quattro Pro. Written by then-intern RussellW, tested by an unnamed then-neophyte tester over a weekend, it had little of the utility of the red squiggles. But, as can be more than occasionally the case with the "Excel users are different" crowd - it had its adherents.
I think it didn't last more than a release or two (to the relief of all involved)...
Do you have any stories about when people at Microsoft started to notice that other companies (like Netscape) were shifting to a much shorter cycle of shipping new versions every few months using the internet? "Awesome! Walt liked our squiggles - hmmm wonder if this new Javascript thing is going to be important..."
The designer working on the red squiggles was Randy Winjum. He provided dozens of alternative graphic designators, but the squiggle stuck.
And I remember you asking us for the fancy animation in the Answer Wizard! You wanted the dialog to somehow reflect the intelligence behind it to differentiate it from 'just another help index' and thought an animation would do the trick!
It's probably hard for most people to appreciate the pioneering use of Bayesian Networks in a user interface given the ubiquity of AI in products today. And because the model sat local on the machine, it lacked the ability to improve over time. Eric Horvitz has a nice history written up that also includes the importance of conducting usability lab research to tune the experience and the shipping model. http://erichorvitz.com/lum.htm
It's also worth pointing out that because early instrumented version (IV) data typically came from 'early adopters' and 'advanced users', the data could give the wrong impression of real world use. But it was still better than the alternative - which was a lot of opinions! Still the same, much of the dominant patterns found in the telemetry were very similar across activities and demographics - like the inordinate use of the backspace key! As Office scaled to the enterprise, IT managers put gates on access to 'normal people' using Office inside their companies making data collection from the field increasingly difficult. It still is.
I have a little flavor to add to the red squiggly story (or should I say flavour, as a fair %age of the Word 95 team was Canadian).
I was the dev lead (headed the core engineering team) for Word 95. What a great project. Very small team - 6 developers including myself, one program manager, and a very small test team. Everyone on the team was super strong - literally every person moved one level up the management chain within one release after Word 95. The majority of the Word engineering effort was on what became Word 97, so Word 95 was limited in scope.
Job 1 was to sim-ship (literally on the same day) an incredibly high quality product with Windows 95 as the first 32-bit version of Word, and take advantage of what Windows 95 had to offer. The second was to do what we could for high-impact features, and fixing the most annoying problems, but always remembering that Job 1 was primary. On the day I took over Word 95, I was told (only partially in jest) that my primary job was to say No. There were a ton of great ideas for improvements, and people very passionate about their ideas, so I had to create some creative mechanisms to politely defer, but ensure that the best ideas were eventually implemented.
I vividly remember the thinking behind background spelling.
I had been on Word for a number of years, and one of the teams I'd previously led was the proofing tools team, which did spell check, grammar, hyphenation, thesaurus, etc. Since I'd also designed and implemented the API that allowed various Microsoft apps to easily use spell and other text checking (one of my first patents) so I was pretty familiar with the speller and how to effectively use it within an app.
I had also previously run the File Conversions team, which did document conversions to and from WordPerfect, Wordstar, Lotus 1-2-3 (for Excel), etc. We had agreements with a number of corporate customers (like the ones running the IV) in which they also shared many documents with us (both Word and competitor docs) which allowed us to ensure we did a great job of supporting them.
Partway through the Word 95 project, three things came together for me.
1) A lot of the documents I saw from customers in the file conversions team had tons of spelling errors. A pile of them. Enough that it made me wonder if they ever ran the spell checker. So I talked to a number of the customers. It turns out that they DID run the spell checker, or thought they did. But perhaps they didn't run it on the last few versions, or had turned off the option to run the spell checker when they saved the document. The standard option (whether Spell was invoked manually, or automatically when the document was saved) was to go through the entire document from the beginning, highlighting every single misspelled word. The user had to fix, ignore, or add each word to their dictionary. This often took a very long time, esp with a long document, and often they wanted to save and go home, or switch to a different task. So in short the UI worked, but it wasn't a great experience, and thus many users skipped spellchecking their documents. Even worse, they didn't realize they're skipped it until I talked to them about it, as they were surprised that I found all those typos in their docs.
So it was clear to me that the existing UI and method of invoking and operating spell checking, which was 'modal' (it took over and interrupted anything else you were doing until it was finished) wasn't optimal, and it resulting in a lot of docs that had misspelling 'left the building' unintentionally.
2) The Intel person supporting Office engineering, Susan Mattison, had long been trying to convince me to have Word and other Office apps do 'more work'. They wanted people to upgrade their PCs with faster Intel processors. Since a lot of the work I did on Word was performance (speeding up app launch, reducing memory and CPU consumption, etc.) I was predisposed to be in the opposite camp, to work on the slowest machine possible, to give a great experience. (Fun tip: check out defrag.exe, which shipped with Office 95. It rearranged clusters on disk in a particular order so that Office apps would launch 70% faster, as the disk would see and read them in the exact order they were needed, rather than seeking from winword.exe to office.dll to some windows dll and back to winword.exe, etc.)
Susan had made a recent visit and revisited the theme of having Word do 'something hard and interesting'. I had a dream that night about Word rendering a video game in the background (secret tip: Word for DOS 5.5 has a working Space Invaders game as the credits, where shooting a ship causes it to explode into the name of a member of the team. I may or may not have been one of the two engineers that wrote it)
3) I had been doing some other performance-related and bugfix work in the idle loop, and it was a common pattern for it to 'walk through' the document, performing some task. The main one in fact being displaying the document on the screen (rendering was the term we used internally) - basically only capturing keyboard input was a foreground task, everything else was done in the idle loop. So the pattern of walking through Word's text and associated data structures that apply to text was already there. I realized that 'has been spell checked' was already part of the status of text, so that spell check wouldn't accidentally correct the same section twice in a single run. And when I checked, there was room in the data structures for an additional 'is currently misspelled' bit! And these data structures would be saved on disk with the document, so the spelled status was always 'up to date' once it had been done once, subject to any document changes or edits.
So all of these came together in basically one 'aha' moment, into the idea for making spellcheck modeless, and doing it in the idle loop as background spelling. Coding it was pretty straightforward, it didn't take too long. All I needed to do was walk the doc, spell check any word that hadn't been spell checked, and set the 'misspelled' bit if necessary. Then I needed to update the 'FormatLine' code which displayed the document on the screen, to add visual formatting to a word if the word has been spell checked and the misspelled bit was set. I did the spellcheck as the lowest priority task in the idle loop, and it was coded, as were almost all the other idle loop tasks, as interruptible, meaning that it would save its progress as it went along, and if something else happened (like a user hit a key) it would immediately abort. But Word was pretty fast, and could get through everything in the idle loop pretty quickly. Others as you read came up with the red wavy underline as the formatting. We originally tried underlining or double underlining, but quickly realized it would be problematic if it was something that could be done 'on purpose' in the document formatting.
At the time it seemed like a cool, high-impact, low-risk feature add (the code was straightforward, and it was easy to test and validate both from the user and internal code perspective). Little did I know what the reaction would be!
"In Excel 3.0 there was even a presentation template that made Excel look like PowerPoint complete with animated transitions between slides (which were really ranges of cells)."
Ahh, the "Slide Show" Add-in. A classic shot across the bow in the checkbox feature wars with Quattro Pro. Written by then-intern RussellW, tested by an unnamed then-neophyte tester over a weekend, it had little of the utility of the red squiggles. But, as can be more than occasionally the case with the "Excel users are different" crowd - it had its adherents.
I think it didn't last more than a release or two (to the relief of all involved)...
Do you have any stories about when people at Microsoft started to notice that other companies (like Netscape) were shifting to a much shorter cycle of shipping new versions every few months using the internet? "Awesome! Walt liked our squiggles - hmmm wonder if this new Javascript thing is going to be important..."