delaniej@microsoft.UUCP (Delanie Alcorn-Jones 3/1009) (08/03/89)
Hi! My name is Delanie Alcorn-Jones and I'm the writing manager for the Applications Office Business Unit of Microsoft. We are responsible for the documentation of the Microsoft Word and Microsoft Mail products. This is in response to some mail between Brian Diehm (Tektronix) and David Luebert (Development/Microsoft). First, let me start by saying that we in the User Education department do listen to our users and are interested in hearing even more from you. We all agree that it is all to easy to isolate ourselves from our users and their needs. I and a couple other writers monitor this news group as well as others on UseNet. In addition, we have a writer that monitors CompuServe activity. What Brian Diehm says about our MacWord documentation is true and we are very aware of it. Its organization suits the product but often not its users. It's very hard to find the little features. If you don't know the Word term, you can lose valuable time trying to find the information you need. Our products use a language of their own and we are striving to get better at breaking down the barrier between Word's lingo and everyday terms. We still have a long way to go but we are trying. Recently, we have been researching new or different ways to present and organize information. Our goal is to make the documentation more usable and the information more accessible. We plan to implement our new ideas on our next major releases of Word. Brian brought up a very good point about indexes. We're also looking into ways to improve our indexes such as allowing the indexers time to learn about competitive products so they index non-Word terms. I'm very interested in hearing from those of you that have suggestions for our documentation or if you've found mistakes that we need to correct on future reprints. Answers may be a bit slow in coming if I get a mass quantity of mail but please rest assured that we will definitely read all that we recieve. (Unconstructive flames will be forwarded to /dev/null.) Again, my product areas include Microsoft Word (PC & Mac) and Microsoft Mail. I can't answer questions about other products but I can *try* to forward them on. Thanks, Delanie Alcorn-Jones OBU Writing Manager uunet!microsoft!delaniej Microsoft Corporation 16011 NE. 36th Way Redmond WA 98073-9717 ----------------------------------------------------- >> Actually, it's very easy to get a list of all of Word 4.0's commands key and >> menu assignments by using the Edit/Commands dialog. Simply press the List >> button. This creates a new document consisting of a table listing every Word >> command and its current assignments. If you want to know what a command does >> press the Help... button in the dialog. For Paste Special Character the Help >> button produces the text: "Inserts a special font character indicated by >> decimal code you type". The fact that Word can tell you what a command does >> at user request puts the lie to the claim the Paste Special Character command >> is "COMPLETELY undocumented". >> >> Dave Luebbert >> Microsoft Corporation >From: briand@tekig4.LEN.TEK.COM (Brian Diehm) > >OK, you win, it's not COMPLETELY undocumented. It's just that in order to find >out about the feature, you have to already know about the feature. When we >started our quest to find the feature (we knew it was in 3.xx), we looked for >all the appropriate topics we could think of in indexes and tables of contents. > >WHO WOULD GUESS THIS FEATURE WOULD BE FOUND UNDER PASTE? OR SPECIAL CHARACTER? >We tried Code (suggested from the old feature), ASCII, literal, insert, and >several others, but a group of people spent a half hour on it without getting >it from the manual. Another member of the group found it first by experimen- >tation. > . > . > . >It is incumbent on the writers to index under EVERY LIKELY title that people >may think of when they search for the feature, not just the name that the >feature has been assigned for that package. That's a tall order, and Microsoft >isn't alone in doing a less-than-perfect job. However, the lack of user- >orientation as opposed to "official" orientation seems pretty strong in Word >documentation. > >If Microsoft differs with this opinion, they should listen to their customers >instead of trying to shout them down. I am certainly not alone in my critical >assessment, if my incoming mailbox is to be believed. > -- >-Brian Diehm >Tektronix, Inc. (503) 627-3437 briand@tekig4.LEN.TEK.COM >P.O. Box 500, M/S 39-383 >Beaverton, OR 97077 (SDA - Standard Disclaimers Apply)
chuq@Apple.COM (Chuq Von Rospach) (08/03/89)
>Recently, we have been researching new or different ways to present and >organize information. Our goal is to make the documentation more usable >and the information more accessible. We plan to implement our new ideas >on our next major releases of Word. >Brian brought up a very good point about indexes. We're also looking into >ways to improve our indexes such as allowing the indexers time to learn >about competitive products so they index non-Word terms. >I'm very interested in hearing from those of you that have suggestions >for our documentation or if you've found mistakes that we need to correct >on future reprints. I've found that the Cobb Group's book ("Word 4 Companion" 0-936767-14-2) serves my purposes nicely. I think the presentation is better thought out and easier to find stuff in. It has some weak spots (the infamous "what *is* this character" command is missing there, too) and the index still isn't what it could be, but it's steps in the right direction. Of the books on Word I've seen, including the manuals, it's the one I keep handy. Chuq Von Rospach =|= Editor,OtherRealms =|= Member SFWA/ASFA chuq@apple.com =|= CI$: 73317,635 =|= AppleLink: CHUQ [This is myself speaking. No company can control my thoughts.]
robinson@prism.gatech.EDU (Stephen M. Robinson) (08/03/89)
Why don't we see more KWIC indexing for large applications like MSWord? (KWIC
= Key Word In Context.) Admittedly, KWIC indexing can take a bit more paper
but I know that I've found KWICs very helpful in the past, particularly for
large systems. As an example, volume 10 of the Symbolics genera 7.x documen-
tation is a several hundred page KWIC index which is invaluable to using the
system and its documentation. Concepts, functions, etc are indexed under
every word in their description (the short form of their description, that is,
not the entire text which discusses them!) so you will find "defun special
form" indexed under "defun" "special" and "form" (and several other key
words too such as major argument types). Just wondering...
P.s. I use Word4.0 quite a bit and like it. Thank goodness I don't have to
do my Lisp development on a Mac........
--
Stephen M. Robinson, AI Group, School of Information and Computer Science
Georgia Institute of Technology, Atlanta Georgia, 30332-0280 404-894-8932
uucp: ...!{allegra,amd,hplabs,uiucdcs,ut-ngp}!gatech!prism!robinson
Internet: robinson@prism.gatech.edubriand@tekig4.LEN.TEK.COM (Brian Diehm) (08/04/89)
> Hi! My name is Delanie Alcorn-Jones and I'm the writing manager for > the Applications Office Business Unit of Microsoft. We are responsible > for the documentation of the Microsoft Word and Microsoft Mail products. > > This is in response to some mail between Brian Diehm (Tektronix) and > David Luebert (Development/Microsoft). > > I'm very interested in hearing from those of you that have suggestions > for our documentation or if you've found mistakes that we need to correct > on future reprints. > > Again, my product areas include Microsoft Word (PC & Mac) and Microsoft > Mail. > > Delanie Alcorn-Jones > OBU Writing Manager uunet!microsoft!delaniej > Microsoft Corporation > 16011 NE. 36th Way > Redmond WA 98073-9717 Delanie - I think this is absolutely wonderful, and I hope that you get deluged with proper, polite, helpful suggestions. I appreciate your response on this issue. Netters - We owe this lady all the input we can give, and some respect for making the offer. I also believe that David Luebert would be happy to receive HELPFUL comments about bugs and "missing" features. These people have made the effort to respond, and sometimes to less-than- kind comments on the net (some from me, even! ;-) ). Since they have responded, we owe them courtesy and help. It is a rare opportunity for us to directly contact the people responsible for tools we all use. Everyone - My first suggestion for Delanie is that if Word is to have a dictionary- style reference book, it must have entries for each and every command that is listed in the "Commands..." dialog. The second suggestion for documentation is that the tutorial materials, though fairly good, fail to develop a true "mental model" of what is going on. This takes a fair amount of research into devising the desired mental model of the product, and then a fair amount of research into devising a proper sequenced method of building that model, and then a fairly simple process of writing to that sequence. The third suggestion for documentation is one where I will not suggest a fix, but merely point out a problem. There are many many degrees of freedom in Word, some Mac-like and many that are carryovers from (retch, my opinion) PCs. In all this feature-richness, you the user may be completely unaware of just the feature you are looking for. For example, I just found out about the Fast Save Enable command, which lets me DEFEAT fast saves. I think it's more than wonderful that I can defeat them (I never trusted them) BUT I was unaware of the feature until it became general user "lore." I need to be able to know about the feature before I can use it. My suggestion to David Luebert is one I have made before, and one which MORE than annoys many users: make the program remember font assignment by name, not number. Apple guidelines are explicit on this point (to be fair, Apple has waffled until spring of 88). In the meantime, Word is the one and only program that is stopping our department from a changeover to the new Adobe/Apple font numbering scheme with NFNTs. Microsoft's policy on this issue is inexcusable. So, how about the rest of you guys? -- -Brian Diehm Tektronix, Inc. (503) 627-3437 briand@tekig4.LEN.TEK.COM P.O. Box 500, M/S 39-383 Beaverton, OR 97077 (SDA - Standard Disclaimers Apply)
delaniej@microsoft.UUCP (Delanie Alcorn-Jones 3/1009) (08/05/89)
Wow! You like to start out with the difficult stuff, don't you?!?! You brought up some really good points and ones that we continually face. Well here goes: Brian Diehm says: > My first suggestion for Delanie is that if Word is to have a dictionary- >style reference book, it must have entries for each and every command that is >listed in the "Commands..." dialog. This is a tough one. One one hand, you do want an entry for every command in the product; but, on the other hand, the Commands command added many esoteric commands to the product that would have greatly enlarged the documentation if each had a separate entry. Massive documentation raises two flags for us: user perceptions and international translations. First, users often relate big manuals with products that are hard to use. We are trying to strike the balance between documenting everything and too much documentation. Second, internationally translationed books grow an average of 30%! That's makes our large manuals absolutely huge in other languages! I do agree that the features should have been covered in some manner in the documentation; however, many of the undocumented commands in the Commands command came from suggestions from beta testers. At that time the documentation was too far along to add new information. (Printed documentation has a fairly large lead time due to production, typesetting, and printing times. This means that the documentation is frozen weeks before the software.) We felt that some of the suggestions from the beta testers were important enough to add to the product even if we couldn't reflect them in the documentation. We did document them in the readme file and have been trying to incorporate them into the printed documentation where possible in subsequent reprints. Brian Diehm says: > The second suggestion for documentation is that the tutorial materials, >though fairly good, fail to develop a true "mental model" of what is going on. >This takes a fair amount of research into devising the desired mental model of >the product, and then a fair amount of research into devising a proper sequenced >method of building that model, and then a fairly simple process of writing to >that sequence. This is a very good point! One of the things we've realized about alphabetic references is that there's really no entry point for users -- no beginning, no end, no overall view. We are addressing this in our research and are usability testing new ways to present information to solve this problem. Another related area is that of understanding the way Word thinks and acts. Word has many quirks that if you don't know, can slow you down. For example, the fact that Word works by the "select then do" process -- that is, you must select text or graphics before you can do something to it -- confuses many users until they realize it. We also have some ideas for ways to address this. Only our usability tests will tell for sure if we're on the right track! Brian Diehm says: > The third suggestion for documentation is one where I will not suggest a >fix, but merely point out a problem. There are many many degrees of freedom >in Word, some Mac-like and many that are carryovers from (retch, my opinion) >PCs. In all this feature-richness, you the user may be completely unaware of >just the feature you are looking for. For example, I just found out about the >Fast Save Enable command, which lets me DEFEAT fast saves. I think it's more >than wonderful that I can defeat them (I never trusted them) BUT I was unaware >of the feature until it became general user "lore." I need to be able to know >about the feature before I can use it. Another tough one! One of the sad things we've come to realize in the last year (sad to writers anyway) is that most users do not "read" documentation. In most (?) cases, users learn by experimentation, from their peers, or by looking up specific information to accomplish the task at hand. So even when we document a feature, many users won't know about it unless someone tells them about it or they have a defined need for it and look it up. When you're looking up something, you'll often have to try 2 or 3 terms/names before you hit on something that directs you to the right area. This is even more complicated by Word's rich array of features and some feature names. So I guess what I'm trying to say is that we are looking into this area but I don't know if we'll ever be able to satisfy 100% of the users in this area because of the diversity of our audience and their learning styles. Again, thanks for the feedback. I'm passing all of the Usenet feedback on to our User Education group so we can all learn from it. I'll be answering some more global issues on the net and some of the more specific questions or comments via email. I'm really pleased with the response so far!!! Delanie Alcorn-Jones uunet!microsoft!delaniej
mjkobb@mit-amt.MEDIA.MIT.EDU (Michael J Kobb) (08/05/89)
In article <7246@microsoft.UUCP> delaniej@microsoft.UUCP (Delanie Alcorn-Jones) writes: >Brian Diehm says: >> My first suggestion for Delanie is that if Word is to have a dictionary- >>style reference book, it must have entries for each and every command that is >>listed in the "Commands..." dialog. > > This is a tough one. One one hand, you do want an entry for every > command in the product; but, on the other hand, the Commands command > added many esoteric commands to the product that would have greatly > enlarged the documentation if each had a separate entry. Nonetheless, ALL the features really need to be _visibly_ documented to do any good. > First, users often relate big manuals with products that are hard > to use. Maybe you should do it the way Aldus did their PageMaker 4 docs. A user's manual, which is all you really need if you're a normal mortal doing daily stuff; and, a reference manual, which is for when normal mortals venture into the unknown. (Of course, immortals or abnormal mortals don't need _any_ manuals ;->) > We felt that some of the suggestions from the beta testers were > important enough to add to the product even if we couldn't reflect > them in the documentation. We did document them in the readme file Kudos! If people would read the readme files, they would find out things. I think it's admirable that Microsoft put the features there. Having them there and documented in the Readme file is far better than awaiting another release to add them for the sake of putting the docs in the manual. I'll usually get around to reading my manuals cover to cover (skipping only the Getting Started sections for stuff I've already figured out). I haven't done this yet with 4.0, since I just got it, so the following may have been done: How about formatting the Readme files so that if printed, it looks like a manual page, so that it could be easily stuck into the manual in the appropriate place? Silicon Beach went so far as to enclose a Xeroxed, laser- printed addendum with their 2.0 docs, and all you had to do was go through and insert/replace the appropriate pages in their manual. > This is a very good point! One of the things we've realized about > alphabetic references is that there's really no entry point for > users -- no beginning, no end, no overall view. Once again, maybe the user's manual - reference manual pair would solve this. Only the reference manual need be alphabetical. > Another tough one! One of the sad things we've come to realize > in the last year (sad to writers anyway) is that most users do > not "read" documentation. "When all else fails, read the directions." Too many people, myself included, use this too often. THANKS for being responsive and being here. It shows a really positive trend in Microsoft's thinking... --Mike Standard disclaimers.