Pre-populated Favorites?

[BL_N]

I do not find anything on this by searching so I thought I'd ask -- can you pre-populate the 'favorites' list in webhelp/dotnet help/etc. outputs? I do realize it's a bit lacking etiquette-wise, but it would be hugely helpful to have a short list of the 'must read' topics already in the favorites list for our clients. I see a favorites.htm file in the output directory but before I start monkeying with it, thought I'd ask if it is possible within Flare (and I just haven't figured out how as yet)?

[RamonS]

It is not possible with Flare and I do question the motive as well (sorry). If the documentation is that unintuitive that having the Favorites list is the desired plan of action I'd recommend to take a step back and see if the help can be organized differently. Also, the Favorites tab and its function is not one of the commonly known things that users are aware of in help systems. I'd rather add a section at the top of the ToC that lists the "must read" topics. I am sure it will get noticed way more than something that is hidden on the Favorites tab.

[BL_N]

It is not possible with Flare and I do question the motive as well (sorry). If the documentation is that unintuitive that having the Favorites list is the desired plan of action I'd recommend to take a step back and see if the help can be organized differently. Also, the Favorites tab and its function is not one of the commonly known things that users are aware of in help systems. I'd rather add a section at the top of the ToC that lists the "must read" topics. I am sure it will get noticed way more than something that is hidden on the Favorites tab.

Ignoring the personal slant and assumption, the documentation/help in question is for people new to the product altogether and the notion of putting a 'quick start' list of topics in the favorites folder is simply another means of insuring anywhere they click, there's something there for them to see.

We already have a link in the TOC and in the header for 'must reads'. This is more a 'cover all bases' item.

My mentor (long long ago) told me that rule number one is "never assume". I found it wisdom.

[LTinker68]

The favorite topics and search term favorites use cookies on the user's machine. The only way to pre-populate those fields would be to write a little script that ran when the user first ran the help (or was installed by your app) that creates the cookies on the user's machine. And if you tried that then the user's anti-virus/firewall/etc. might raise a flag, although cookies aren't generally capable of doing much, but still -- from a security standpoint it's not something you should do. What I did on one project was have on the "welcome" page info on the different features in the help, including the favorite topics and search term favorites, as well as the glossary, index, and search.

If you don't want to do that, then I'd go with a book at the top of the TOC titled something like "Most Useful Topics" or something like that. MadCap does something similar titled "Most Recent Articles".

[BL_N]

One of the review committee is asking for a 'faq' at the top level (all caps, strobing red lettering... no, heh, just kidding, but I suspect they'd go for it). The favorites idea was suggested by another. So I dutifully plopped it out here just in case it was possible (reporting all possibilities, letting them decide which they want to use).

My personal preferences are not in the mix and my professional recommendations are already made. It's pretty much listening, telling them what is or is not possible, and moving forward as they wish.

Thanks for the insight. I'm happy to have a ready resource for details of Flare that I have not yet had time to learn. (Or things to check when I haven't had enough coffee!)

[RamonS]

My mentor (long long ago) told me that rule number one is "never assume". I found it wisdom.

True, so why assume that the users know what the Favorites do and that they are there. From my experience most users are challenged by the extra features of help systems and I rarely found users who use what one could call advanced features of a help system. And those who do are typically those who mastered the application a long time ago.

[BL_N]

My mentor (long long ago) told me that rule number one is "never assume". I found it wisdom.

True, so why assume that the users know what the Favorites do and that they are there. From my experience most users are challenged by the extra features of help systems and I rarely found users who use what one could call advanced features of a help system. And those who do are typically those who mastered the application a long time ago.

I was speaking to your assumption as presented in your previous post.

I'm fairly certain most are aware of the pre-population of the favorites list as a pretty standard means (i.e., Firefox, Microsoft, Google, and more use this method regularly) of communicating information, particularly quick links to items that one may reasonably consider helpful to the user (e.g., "Getting Started", "Frequently Asked Questions", "Most Popular Topics", etc.).

I am content to agree to disagree with you on the opinion/perspective as to the use of favorites and how they may or may not be utilized as an additional avenue for guidance. While advanced functionality should never be other than transparent to the novice user, the advanced user counts upon its presence and in most cases, assumes it (Houser, 1998; Zubak, 2003). The insinuation that the average computer user today doesn't know what favorites are or how to use them, frankly, is specious.

[RamonS]

The knowledge on how to use advanced features such as Favorites is very dependent on the audience. I created end-user documentation that was to be used by locksmiths who typically (with more and more exceptions) have only a very basic skill set and knowledge about how software applications or "computers" in general work. So referencing the Favourites of a web browser would not do any good as I met many who did not know the difference between Notepad, Windows Explorer, and Internet Explorer. I also got involved in end-user documentation project for school bus dispatchers, who do know software related things very well if they use a software based routing system (which is a given when they use the documentation). I agree that there isn't a safe way to argue about what the current abilities of the average computer user is, especially since there are exceptions in both directions in any targeted group. I agree to that extent with your points that in order to give a suitable recommendation one would need to know who the targeted audience is and what their general skills and expectations in regards to software. My experience with the various audiences is that for the most part users are challenged by way more fundamental things that in some cases even prevent them from making use of a help system. That is why I recommended to take that step back first and evaluate if the overall documentation is in a form or shape that suits the audience. I did not imply that it doesn't. That was more an inquiry than a statement and in general based on my experiences.

[BL_N]

I agree that there isn't a safe way to argue about what the current abilities of the average computer user is, especially since there are exceptions in both directions in any targeted group.

It may be that most users you work with are novices with computing and that would certainly affect your perspective on what is or is not 'the norm' overall. Were I writing to an audience who's best grasp on technology was dialing up to AOL, I'd not expect them to know about favorites. Of course, were I writing to that audience, I'd not be using 'help' as the medium (since the entire concept of that audience being comfortable with computerized or online help is decidedly shakey, at best).

On the other hand, there is pretty good research available on 'the average computer user', 'the average internet user', and 'the average business technology user' which renders the need to 'argue' over how to define them rather moot. IDC, Neilsen and the Pew Internet Project (http://www.idc.com, http://www.nielsenmedia.com, and http://www.pewinternet.org, respectively) have been producing respectable insights and demographics for some time to define these three and a good bit more besides.

As for 'advanced features', a recent article out of Microsoft neatly evidences something most have been saying for years -- online help is used by advanced users, not novices. (citation: http://blogs.msdn.com/jensenh/archive/2 ... 97861.aspx with the meat of the actual evidence in Cooper's book.) The system we're designing is not oriented to novices to technology or computing, but to novices as related to the industry practice, which is why the notion of pre-loaded favorites was close to the top of the list.

[BL_N]

Small addendum: That sounded snarkier than intended. You cannot hear the grin. Apologies.

[RamonS]

Yea, alright....and Microsoft invented the ribbon and Vista, which IMHO disqualifies that company to make any statements about what users can and what users want. I will take a look at the research studies and hope to find out who funded them, which will put the findings into the right perspective.

[BL_N]

Alan Cooper isn't Microsoft, though I suppose anyone outside the core of tech would easily assume otherwise since Microsoft now 'owns' VB (it was developed by Cooper and his company Tripod in 1991 and later snapped up by Microsoft). Alan's company, Cooper Consulting, has been involved in usability and user assistance for quite some time and he's readily accepted by most in usability and user assistance as both a pioneer and sage.

You may also wish to check out the Yahoo Developer Group, which has been saying pretty much the same thing. Or Neilsen's 'Use It' site (http://www.useit.com) or, actually, pretty much any outlet that has more than ten years invested in this professionally, as they're all saying pretty much the same thing: 'Help' per se is for the advanced user, not the beginner. For the beginner or novice user (particularly if they are new to both computer and the application in question) are far better served by in-screen or paned 'tips' and guides.

I'd enjoy discovering if your opinion and perspective manages to change once you shake off your assumptions and biases.

[RamonS]

That may happen, but I doubt it since it isn't some unfounded bias, but hard earned experience from now over ten years in various customer facing positions, most of them in software development. I found that a surprisingly large number of new users made frequent use of the help system, mainly because the F1 key is associated with help functions since the day of the main frames. I especially became aware of that after receiving many complaints about having the "wrong" help file included in our first browser based product. The F1 key press brings up the help for the browser, but not the browser based application.
During the same time I witnessed the shift from WinHelp to CHM and only once from a pool of thousands of users got a complaint that CHM no longer allows for personal annotations the way WinHelp did. In fact, only because of that complaint I became aware of this feature and its great potential, something that is now implemented in a more public format with MadCap's Feedback Service. It also was point of several discussions on this board.
During all this time I never received any complaints about Index, Search, Browse Sequences or Favorites although I knew that at times some of these features were flawed (because I missed some things). I am still baffled that I never got any comments or complaints about Search.
I did get many comments and complaints about content, which indicated that users do use help and do so often. Most of the complaints were easy to resolve, but pointed out that help system optimization was needed and that some approaches just didn't hit the mark (such as not providing or only providing process oriented topics).
While this is not at all a study that holds up to any focused research it gives an insight on how users make use of help systems and how important they are, especially when some processes are used only once or twice a year, but that every year. Proper documentation for things like that is essential since it saves calls to support, which saves both the customer as well as the company time.
I'd need to look for the proper reference in my MS thesis about how support experiences impact software quality, but I do recall that a study was performed where phone support of a software company was asked to ask each caller if they read the relevant help topics. The vast majority of callers did and was able to exactly name the topics reviewed and why the information provided in there does not address their problem. That, too, may not be considered a comprehensive study of the body of all software users, but it shows that help systems are used by customers and before they place a support call. Studies like this one as well as my own experience make me doubt the accuracy of the claim of " 'Help' per se is for the advanced user, not the beginner".
Honestly, I find experiences by those who did and do software support way more convincing than any scientific research study by people who may know the industry, but never sat down through the busiest weeks of the year and answered one question after another and then took that knowledge back to the TW to have help system, technical bulletins, and knowledge bases optimized. By the way, that is to some extent what Nielsen writes in the paper about iterative UI design, but in the example used I find no mentioning that only advanced users made use of the help system. Quite contrary, the system under study lacked a help system in its first version, a point that is stressed as lack of helpful feature. It was not specified who attempted or later on used the help system, but it was not pointed out that only advanced users made use of it.

One way to convince me otherwise is to provide proper references to the documentation rather than to just post a URL from which a bulk load of various documents are available. While they are good and interesting most of them are irrelevant to our discussion. Same applies for the tip to check out the Yahoo Developer Group. Who in that group made the statement? Software developers? If yes, how much customer interaction did these developers see? One thing about developers that applies to most but not all of them is that they do not use the software they create. So far I have to meet a developer who spent considerable time using the own software in a production setting with all the established workflows and deadlines. While there are honorable exceptions I find that most developers have no first hand experience how the customers end up using the software. The developers do become aware if there is a massive problem that trickled through the various levels of support and QA, but that is a point where the developers better get it right this time. While I may err in some cases, but I generally tend to question the ability of a developer to make any realistic statement in regards to end-user behaviour and use of the application. I don't mean that they don't care or intentionally ignore this, but due to the lack of direct exposure to customers they just don't know.

[RamonS]

The study I was referring to was done by Cem Kaner and the results are summarized on pages 25 - 27 in the book "Bad Software" by Kaner & Pels (1998, John Wiley & Sons Inc.). Cem Kaner is often considered THE guru when it comes to software quality and software user rights. In this study done by Kaner support asked the calling customers and 90% answered "yes" if they consulted the documentation before they called. Later on Kaner&Pels indicate that both manuals and help were considered, but given that the book was written ten years ago it may have been more printed documentation than a help system. Nevertheless, assuming that the distribution of skills among the customers follows that of other skill set distributions among a target group it is likely to be a Gauss distribution, which very rarely is slanted so much that the 90% of users who did consult the documentation are to be considered "advanced" users. I'm just speculating, but it is more likely that the 10% that did not consult the documentation are mainly the advanced users who know the application that well already that they know if something is off without reading the documentation again. It would be interesting to redo this study and find if the use of documentation by callers into support changed.

[BL_N]

Sorry, I didn't mean to give you the impression I was trying to convince you. I'm not. People tend to believe precisely as they want to, regardless any information presented to the contrary (a statement neatly demonstrated in your last reply, wherein you specifically state that you find technical support experiences as being more reliable than aggregate research, and rather casually set aside an entire cadre of specialists in this area in favor of anecdotal personal experience).

For the rest who may be reading, I recommend Alan Cooper's work as one of the early pioneers (post-IBM era) of "modern usability", specifically the impact of technological solutions in supporting the user experience. (http://www.cooper.com/ -- which is much more a product design site these days.)

Jakob Neilsen is the man to read for statistical information relating to web usability and underlying tech and science issues (e.g., eye tracking, reading versus scanning, information chunking, norms for internet interactions, etc, all of which are applicable to developing help systems or online support systems). (http://www.useit.com)

If you're really geeky (or just like seeing nifty product designs), Don Norman is the current champion of real world, hand's on product usability. (http://www.jnd.org)

I'm a bit of a usability geek myself. The real interesting days where the ones wherein product engineers had to figure out how to communicate use of massive and potentially lethal household appliances. What we consider usability pales by comparison. But the history of HCI is an interesting tale, too, particularly depending on whose perspective you grant credence. My favorite site for keeping up with the latest, greatest bits of usability and such is the Human-Computer Interaction Resources site at http://hcibib.org.

It's yet another site of links you'll have to explore to get anything out of, but I doubt you'll find it wasted time if you work in the tech industry or have any need to keep abreast of usability.

[BL_N]

The study I was referring to was done by Cem Kaner and the results are summarized on pages 25 - 27 in the book "Bad Software" by Kaner & Pels (1998, John Wiley & Sons Inc.). Cem Kaner is often considered THE guru when it comes to software quality and software user rights. In this study done by Kaner support asked the calling customers and 90% answered "yes" if they consulted the documentation before they called. Later on Kaner&Pels indicate that both manuals and help were considered, but given that the book was written ten years ago it may have been more printed documentation than a help system. Nevertheless, assuming that the distribution of skills among the customers follows that of other skill set distributions among a target group it is likely to be a Gauss distribution, which very rarely is slanted so much that the 90% of users who did consult the documentation are to be considered "advanced" users. I'm just speculating, but it is more likely that the 10% that did not consult the documentation are mainly the advanced users who know the application that well already that they know if something is off without reading the documentation again. It would be interesting to redo this study and find if the use of documentation by callers into support changed.

Kaner's specialty is testing and metrics as relates to testing and design (code, not usability). He would be the last person to say he's a usability proponent, heck he's only now getting into researching usability as its own topic (see his site for details). The reference you cite dealt with consulting the user manual prior to calling support, not a help file (the manual and/or a CHM file were the norm for the time). It is also worth mention that Kaner frequently cites Cooper and that's hardly indicative of disagreement.

There is no "THE" in this. Rather, there is a tight grouping of about 15-20 individuals who have, collectively, hefted the framework for usability as we know it today out of the mud.

The information I cited is not assumption but constitutes a considerable amount of effort and research. I suggest you read Cooper's book and see for yourself.

Your own speculations, being admitted as such, I'm content to bypass.

[RamonS]

Fine, I guess we won't get anywhere in this discussion, but I find it somewhat disrespectful to brush aside over a decade of experience as nonsense or unfounded bias.

[BL_N]

Fine, I guess we won't get anywhere in this discussion, but I find it somewhat disrespectful to brush aside over a decade of experience as nonsense or unfounded bias.

I find this fascinating. You entered this topic essentially doing just this and you exit it accusing me of doing it. I have provided you with a sizeable and rather impressive series of reference citations, most of which you dismissed by saying you prefer your direct, personal experience to any research on the matter.

Who was disrespectful? From where I'm sitting, it was you. Sorry, should I bow to the wisdom of ten years of personal experience or to the collective wisdom of over forty years across a number of disciplines? You'll excuse me if I prefer the insights and documented research of the creators and pioneers in the industry to the speculations of someone with less than a quarter the experience.

I have been trying very hard to remain polite, but I must say, you make it difficult with your snideness. Perhaps you consider it some manner of accolade to be the "Simon Cowell" of the forum, but, frankly, it seems more than a little like an attention getting device.

I'm not sure what 'getting anywhere' is supposed to mean. If you mean 'everyone learns something new', we've managed that nicely as there are a host of links in the topic that I hadn't seen here previously.

However, if you just mean 'you get to convince or convert someone', then I suppose you may well be correct.

I'll leave the last word to you. Between the bad taste left by your assumptions and the notion that somehow, your opinions and speculation are (or should be) considered on par with the professionals who conceived and raised the concepts of total quality, usability, and linked the intangibles that make them matter to real world examples that business and those who run them could understand, suffice to say I am roundly, soundly, and profoundly unimpressed.