Help and Program Flow
From CS 160 Fall 2008
Lecture on Oct 22, 2008
Readings
- Designing Apple Help Knabe Design.
Discussions
Please post your critiques/commments on the required readings below. To do that, first login by using your user name and password, then click the "edit" tab on the top part of this page (between the "discussion" page and the "history" page), New to wikis? Read the Wiki editing guide. . Hint - Please put a whole line == ~~~~ == (literally) at the beginning of your submitted critique, so the wiki system will index, sign and date your submission automatically.
Xuexin Zhang 01:43, 22 October 2008 (UTC)
In the artical Designing Apple Help, Kevin Knabe talks about Apple's research of online help and its goals. Once users' exploratory learning failed, users would look for helps. Knabe discusses how the online help could improves the usabilty of the system when the designers make the help discoverable and make it easier for the auther to write. I really like the idea of centralized point of access for all available help document and makes it searchable. From my experience, the centralized help document is where I turn for help to and it could also covers related topics to let me have a better understanding of the system which leads to better usablity.
Buda Chiou 04:26, 22 October 2008 (UTC)
The Help option is definitely a very important function for user interface. However, I believe most people would have rather done their task without using Online Help. This doesn't mean an interface shouldn't have an help option, but it's better that users can figure out how to perform their desired task immediately, and a way to accomplish that is to make pop-up Help for every object on interface so that users can figure out what to do without looking for the online help. Besides, the help menu designed by apple are mostly composed by text, which makes the menu looks nasty so that users may have to spend long time finding what they are looking for. I think each option in the menu should also be label by some icon like the Start menu of Windows so that users can more easily to find their target, and it also makes the program more accessible for users who don't know English.
Kumar Garapaty 04:30, 22 October 2008 (UTC)
Its interesting the problems they note, because they are problems that people currently face even after all these years. For example, going out of the active part of the application to go to help is still a problem in many software programs. Some of the problems they face such as the spoon feeding can be seen as problems before they even do the testing of the application, so I wonder why they bothered to go through with actual prototyping even when that's quite obviously a major flaw.
Mike Kendall 04:50, 22 October 2008 (UTC)
IT IS REASSURING TO FIND OUT THAT APPLE IS DELIBERATELY KEEPING ITS USERS IN THE DARK
Jordan Berk 05:43, 22 October 2008 (UTC)
I found the discussion of the MacOS help system to be in line with many of the subjects we've discussed in the class. The designers clearly took a very iterative process for the design, since the article makes it clear that the system went through multiple revisions, even as MacOS itself was being upgraded. As for the help system in the article, the design seems to be of some quality; they certainly improved it with time and added some useful features. That said, though, I personally hate application-based help systems. As a rule, I generally have problems finding the answer I'm looking for. I much prefer a general internet search for this purpose, even if it links me right back to the application developer's website. The MacOS Help system, which I assume is very old considering the year and OS, is probably very different now, but at the very least Knabe's article shows the improvements that a good goal-based design cycle can lead to.
Saliem Than 05:55, 22 October 2008 (UTC)
Its funny, I was trying to make mantras out of a number of things in this article including the points about the type of help scenarios:
• goal-oriented questions ("What can I do with this?") • descriptive questions ("What is this?") • procedural questions ("How do I do this?") • interpretive questions ("Why did that happen?") • navigational questions ("Where am I?")
and the design goals:
- Making help discoverable
- Making help easy to author
- Providing a central access to help
- Taking advantage of the internet
- Broadly defining the tasks
- Writing minimally and
- Automating tasks
I was hoping to remember these things when designing help features on my group projects application. These heuristics for help are useful, but then I just remembered that I usually just Google for an answer when it comes to situations such as these. For example when I can;t figure something out when I'm in basecamp or zoho, I turn to Google hoping to catch an archived conversation about someone encountering a similar if not the same problem. Usually I find what I need there. I think these heuristics should be taken one level up in an abstraction somehow because of this.
Hao Luo 06:03, 22 October 2008 (UTC)
The reading took something we are all familiar with now and explores how it was designed. The help function. We're all used to seeing that "Help" option on the taskbar of almost any application that to see it as a question mark icon really takes you back. Not that I would know. In looking at how such standard features were formed we can gather much better information on user testing, since these features have been so successful and prevalent. On the other hand, because we're so familiar with how these features work, some of the design ideas that were new and innovative are very commonplace to us now, so we don't get as much out of studying them. Overall it was an okay read.
Perry Lee 06:26, 22 October 2008 (UTC)
Like Jordan, I found the discussion very in line with what we have been discussing in class. The article shows how effective an iterative approach is and the importance of getting early feedback. Without the continual feedback, you may (and very likely will) make incorrect assumptions as the Apple developers found. The end design goals they established can also be readily applied to any number of situations (e.g., write minimally).
Cynthia T. Hsu 07:17, 22 October 2008 (UTC)
I agree with Buda Chiou, that the best user interface would allow the majority of functions be utilized without the need for resorting to Apple help. I also agree that the vast majority of help menus that I've seen to date are very trying on the user because of the long list of instructions that he or she must read and comprehend, when a visual matching of the icons in the user interface or a moving cursor to point out specific things would be useful.
Saliem Than brought up a really interesting point - bring the wealth of information available on Google to the next level. Sometimes I find the interface on webpages much more engaging, whether it be because of the friendliness of forums, the diversity of exchange available, or the more aesthetic layout.
I don't have that much experience with Apple Help but I did find it interesting that,
"Apple Guide was designed to address the problem of layer switching. When users access help in Apple Guide, they stay in the active application. Instructions are presented in small system windows that float on top of everything else on the screen so that help is never covered. The instruction panels present one step at a time, so that instructions are small and unlikely to cover the functional interface. The user pages from one step to the next. The help is able to skip steps that the user has already completed and present remediation when the user gets off track."
It is definitely a very good idea, but at the same time, my problem with Apple is that their interface is designed such that there are a lot of small windows open at any given time wth no sense of order. I don't think having the help as an additional floating window would make it any easier to refererence.
Billy Grissom 08:04, 22 October 2008 (UTC)
I thought this article was pretty interesting. The first idea sounded phenomenally good and like something new and fresh. Seemed cool to have a help interface that is complex to develop but in the end makes something cool and different for the user.
But alas, as this article seems to point out what may seem cool from a developer point of view isn't exactly the coolest thing for the user. I'm sure the first system was far more harder to develop than the second interface...and in the end it seems the user prefers the simple interface over the complex one.
People seem to prefer two things: practicality and simplicity. Although it seemed like a good idea, the first interface lacked these two ideas. Although a step by step guide seemed cool, it definitely is not a simple interface for the user to work with. In addition to this, it wasn't a very practical approach for users to work with. As the article pointed out a lot of users complained that this interface lacked detailed and required them to go through many steps they may not have needed to look at it in order to get what they really wanted. Furthermore it was also hard for the developer to develop for.
The second interface seemed to work because it was both simple and practical. People are use to looking at web pages, so it makes sense to use HTML to display help information. in addition to this, it makes it easier for the developer to work with. Finally, the web page look is just far more practical and easier to expand on. It's easy for a user to find info and skips steps.
Mohammed Ali 08:10, 22 October 2008 (UTC)
Some of the design goals set by apple were obvious, however, extremely beneficial. For example, removing the small question mark from the right corner to include it as part of the main menu was a crucial. When looking for something, users often look at the menu items to find it, so the best thing would have been to include it as part of the main menu. Minimalist design was also good in the overall help experience. Useless lines telling me the obvious will only frustrate the user instead of helping them.
Kai Lin Huang 08:18, 22 October 2008 (UTC)
Apple help development process from Knabe’s article briefly shows how Apple help feature becomes a successful User Interface example in the area. The one thing stands out to me is that Apple takes out the help page for how to click on the “play” button in order to play music. I would imagine that the UI designers and the product requirement writers would have different opinions on this because for the sake of completeness, they should put this on (especially it is a very important feature). The usability study convinced the team to eliminate this page because the triangle inside a button tells all to anyone who knows how to turn on a computer. Since I have the experience of writing product specifications, from that perspective, I would inject that page anyways. However, from the user perspective, I believe it is a genius idea to not put something like that to waste my time in troubleshooting my unplayable CD.
Vedran Pogacnik 08:28, 22 October 2008 (UTC)
It seemed obvious to me that the functions should be grouped on a panel in a consistent manner- placing a separate question mark away from all the menus seems completely backwards to me. As the text says, that concept was abolished. However, a question mark in the right hand corner would make sense if that meant something defined on mouse hover over the question mark (like associating it only with the “how do I use this” function).
Making a transition to html was definitely a good idea for the company, but not for the developers. Had it kept the standard proprietary, Apple would have to hire a bunch of developers; that means jobs for us… :)
Alan McCreary 08:57, 22 October 2008 (UTC)
Help applications like the "Help Viewer" that Knabe shows us in this article are somewhat inconvenient to me, since I rarely use such applications to help solve any problems I have. A simple (and well-phrased) Google search generally takes me to a solution very quickly, while the whole process of "click on category" -> "click on subcategory" ... can be tedious in comparison.
As a whole, I think this article demonstrates the benefits of making improvements based on actual user feedback, rather than what the designer thinks will be useful.
Karen Tran 09:11, 22 October 2008 (UTC)
“Designing Apple Help” was interesting because it went over the many details that went into designing the help. Writing minimally seems to be a recurring theme throughout good design; this is an important part of good communication that designers strive to attain. The article points out the observation that HTML was used to make it easier to author documentation. This was a wise move, as you want to have make this process quick and easy to write very presentable help with an easy-to-learn standard across many platforms. If you look at applications like Photoshop, operating system help like that in Windows, or HTML readme files with many small freeware out there, many developers have chosen to write their own help in this manner. However, I tend to get help with an application by searching on the web. In many cases, searching through an application's help browser did not return what I was looking for.
Jimmy Nguyen 09:27, 22 October 2008 (UTC)
This was an interesting article about design and help layout as I think about our group project. In our project, we even include a “tutorial” mode, but this could be potentially important for a project that can be quite complicated. In terms of the article, I definitely agree and on the side of the fact that there sometimes unnecessarily too many windows and help functionality. Over helping and asking for needed assistance can be quite bothersome (i.e. Microsoft Office paperclip) and can often crowd the layout (i.e. old Bart payment sign).
Frank Yang 09:42, 22 October 2008 (UTC)
This article was actually rather interesting to me. In fact, our group had been considering offering help items to address the "what is this?" questions that we received during the interviews. It seems that it is most common now to have help in one of the toolbar menus. Like the text mentions, help menus can have the problem of trying to help too much, when only a simple answer is needed. I usually find help menus a lot more cumbersome, and I tend to avoid them for that very reason. And that Microsoft Office Paperclip? Horrible.
Geoffrey Lee 09:47, 22 October 2008 (UTC)
I noticed that Microsoft has definitely copied Apple with the standard Windows help application. Although, I hadn't used the help features in Vista yet, and in particular, in Office 2007. So I took a look at Word 2007 and was surprised to see that they removed the Help menu and replaced it with the tiny question-mark icon in the upper-right-hand corner - the same approach that failed for Apple according to the article. However, I was pleased to see that the help window is now always-on-top, and the traditional Content and Search tabs have been consolidated into one interface. It looks like the Index was removed, but personally, I never used it anyway. All in all, the help icon was a usability regression, but the help window has improved a bit.
Witton Chou 10:06, 22 October 2008 (UTC)
It is always interesting to see the iterative design process in action on a commercial product. However, I have personally found help menus to often contain too much text. I think part of the reason why users would prefer having a "Do this for me" kind of solution to a problem is a result of not wanting to read the help contents. There are many times where simple pictures or animations will help the visualization process and facilitate the user's understanding of where certain items are. If the "Do this for me" link would animate the process of mouse movements/clicks over directly completing the task for the user, the user wouldn't have to resort to using the help menu as often as they will learn from the demonstration. I think that this would have a much better impact on the user's efficiency and increase their satisfaction over having to read the help contents and keep track of where they are in the help article. It's much easier to learn and follow an example than to read and interpret a block of text.
Jacekmw 13:16, 22 October 2008 (UTC)
I agree with the most of the changes apple has made in terms of the help menu. I still think the question mark could have been used well if it had been on the left as a menu, though it would have to be graphically changed a bit to fit in more with the system. This is something of a moot point now, however, when average screen sizes are far higher than during the times when this help was developed. What I absolutely agree with are Apple's choices to a) go with html as far as help documents go, and b) to go for the minimalist approach described at the end. It is very unlikely that the user is having problems knowing where the play button is given the CD player's interface, for example, so it makes much more sense to give advice for likely problems if the user searched for 'play cd', such as issues with the player not working correctly. That html was a good idea, on the other hand, goes without saying as it is a very standard format known by pretty much anyone who's anyone these days. Lastly, I also like the coaching circle idea and wish windows had something of the sort - I always hate having to dig through the interface to find something described in help when they plainly could just do it for me. This rides the fine line between doing it for the user and still forcing them to learn to use the interface, so we have the best of both worlds.
Antony Setiawan 14:40, 22 October 2008 (UTC)
Based on my experience and with other people's opinion, I can say that windows help has the worst design ever. First, it is not easily discoverable. User would even ended up confusing themself looking for the help window to pop up. It does has central points but the central points sometimes sway from what it says. Next is the search result. For certain keywords, users would ended up landing on something totally of the keyword. Connecting to the online knowledge base would be a plus but still potentially confuses users with unrelated search result. Another plus would be the automation as also shown by Knabe.
Bing Wang 15:23, 22 October 2008 (UTC)
In the article, Kevin mainly talked about how Apple added the help menu to its OS since Mac OS 8. I knew that Apple was the first computer company that came up with the windowing manager but I did not know that they were also the ones who introduced the help menu. I always thought that there always had been a help menu since the beginning of the computer age. I believe that the new style of the help menus are quite innovative. It does seem much easier to type in the question instead of going around and find answers. Nowadays, most people do not even use help anymore because they just google the answer to the questions that they need help on. Since Apple's help menus have been so successful, it is not surprising that this style of help menu has been adopted by other programs.
Juanpadilla 15:56, 22 October 2008 (UTC)
As mentioned above, help is a very important aspect of the user interface but the traditional help under one roof is usually a last resort. Even in our task analysis for our project, I noticed users would look for other ways to figure out what they needed to do and only go to the help button if they were just completely stuck. Even still, it was a great idea for Apple to add the help menu just incase the user actually needed it. Sometimes, Apple’s minimalist approach is good, such as in this case and sometimes it can be bad …. No button mouse?
Greg Nagel 16:07, 22 October 2008 (UTC)
I find task completion to be a bad measure in this scenario. The help is built in terms of the pre-selected tasks, and if a user is given one of those pre-selected tasks with the same wording, the help is bound to be useful. The problem for me with these help systems is always that I can't find what I'm looking for. Users don't have the same vocabulary unless you give it to them.
Trinhvo 16:16, 22 October 2008 (UTC)
The reading was interesting. I never thought designing help would take such so many steps. To me, a question mark icon on the menu bar is discoverable enough, but it's strange that many users usually don't see the question mark on the right side of menu bar and they would just scan over whatever on the left side and then stopped exploring. It's also interesting to know that users don't follow guiding steps linearly when they get stuck, and this makes designing help interface much harder.
JoshuaKwan 16:39, 22 October 2008 (UTC)
The idea of help screens have always been slightly offputting for me. My earlies t memory of help was poking around in ClarisWorks 2.1 on a System 7.5 machine and trying to figure out what the heck "mail merge" did. Help taught you how to do weird, scary things. And honestly - that's what it should be for. I feel like everything else in an interface needs to be intuitive enough that help isn't necessary; if you do use help to explain the interface, that's a final measure to make sure the user isn't left at sea, but it should not be necessary.
One of the things I really like about the Mac OS model of help, though, is the idea of interactive demonstration ("show me.") Not only does it perform the task for you, it takes control of the mouse and actually shows how you would do it if you were doing it on your own. I personally think that isn't prevalent enough in modern help systems.
Stuart Bottom 16:42, 22 October 2008 (UTC)
In particular, the fact that users had trouble finding the question mark icon speaks volumes about how important consistency is in user design. It seems like putting the question mark in the corner didn't make it easier to find, it made it harder, i.e. making an exceptional item into a "special case" may only make it more invisible to the user, or at least make the UI more confusing. In this case, it seems the obvious simple solution was the best one: put access to help with the rest of the menu bar items; be consistent about where links to different functions are.
In general, I suspect most users access help for their computer system / application only as a last resort because the return on their time investment is generally low. I'm not a Mac guy, but at least in Windows the help systems are generally abysmal. To me, Windows Help and Support (the help system installed with the OS) is a joke; I can never find anything I need in there and it's pretty much a waste of time for me to even look. Going online and searching with Google or on the MS website is a lot faster and returns way more relevant results for me. Granted, I'm not searching for help on tasks like "how to use the CD player," but still, why not make all help accessible from one place? If you can successfully integrate Internet sources with your offline help system, all the better.
As several readers have mentioned, the difference between the linear task model and the iterative one is eye-opening. As one of my fellow group members already pointed out (thanks Jimmy), this raises questions about the applicability of the "tutorial" mode we incorporated into our game, which is a very linear step-by-step walkthrough of how to use the game. Is there a difference between this sort of help (introductory, for which a tutorial might be more appropriate) vs. help that is being sought by users already familiar with the application (for which a flexible searchable help system is better)? I would argue there is, but the line between the two could be difficult to define.
Gary Wu 16:49, 22 October 2008 (UTC)
Along the same lines as the article, I found that our low fidelity prototype testing also yielded mostly descriptive and procedural questions. I also appreciate and recognize the importance of the coachmark. Having written step-by-step tutorials for students in classes I've taught, the simplest and clearest way for guiding a user's attention is the coachmark. Otherwise, it would be extremely difficult and confusing the explain in words the exact point on the screen (not to mention long-winded). I agree with the third design goal that the Apple team had. Having a central point of information greatly reduces window clutter and search time. I feel that the sixth goal that the Apple team had is a very tough one to solve. As Mark Twain once said, "I wanted to write a short letter. But I didn't have the time so I wrote a long one, instead."
Volodymyr Kalish 16:51, 22 October 2008 (UTC)
Whenever a group of developers release a product, the biggest issue is documentation and help with usability, since those are the most boring things to do. Some developers are so found of their product, that they believe it doesn't need help or don't provide enough help, beleiving that it isn't necessary. But as this reading proved, the availability of help and its discoverability play one of the most important roles in a product and the success its usability.
I think it is a great idea to have an online help system, but there should also be some help availbale locally, in case there is no internet connection and especially if one needs help in establishing one.
KevinFriedheim 17:01, 22 October 2008 (UTC)
As I'm pretty sure most have mentioned, help screens (and apparently this applies to early Apple help screens as well) have always been counter intuitive. Its almost as if user interface design went right out the window when it came to putting together the help. Perhaps this is due to the fact that designers felt them unnecessary but a standard that no program can go without. Although the reading states that the "Apple approach" had led to high user task success, I don't agree that their design cannot be improved -- as it resembles too many help screen interfaces that are generally unhelpful.
Anthony Kilman 17:10, 22 October 2008 (UTC)
• One big issue was that when users would switch to help items, they would have to switch contexts and have to remember where they were to continue working.
• Another common issue was that the help menus were initially designed to provide information that would be ``spoon fed, `` though more experience users did not want to be spoon fed.
• Key point in this discussion. Icons that don't stand out or provide an immediate human recognition on all levels must be learned. Though once learned, they are useful a point I feel that should be emphasized is that these must be learned and it is not intuitive to learn to use them immediately.
• The example shown in the AppleCD image is what happens when your documentation people are underpaid. It's good to highlight exactly what is wrong, but at the same time I believe the author spent about 1/8th of the time writing that as supposed to a solid example of documentation.
Yuta Morimoto 17:14, 22 October 2008 (UTC)
From my experience, there is an obvious difference from useful help and other one which makes users confused and forces them to obtain meta-help. I think good help should include many different examples. They can show actual usage and allow users to compare their task. Some bad help do not contain detail explanation but lack many actual examples. Those defects have me take other help to understand original one. For example, Many API documents have great detail explanations. However, those documents do not contain concrete examples and just contain detail description that may be good for expert. Moreover, they have unfamiliar terminology so that I need to learn other thing before read the help. It is very ridiculous that the help demand other help to understand original help.
Paul Im 17:17, 22 October 2008 (UTC)
This article talked about the approach that Apple took to make its products more usable and helpful. There were many areas that related to our class, especially in how they hired users to do some hands-on testing for their software. Setting design goals seems like a great way to make advantages to a product. Most of the goals that Apple Help designers set for themselves seem plausible and helpful. We can certainly see that these goals in designing Apple Help have propelled the usability of the Mac OS.
Personally, I believe that taking things from the web is somewhat tedious when trying to search for help. The lag time to open the web browser and make the connection to the server is too long to appreciate online help. I would rather spend a couple more seconds and figure things out myself. I agreed on the goal to write minimally, however, because people obviously do not want to spend hours trying to sift through the text.
MuQing Jing 17:18, 22 October 2008 (UTC)
It seems like Apple Help has, at least in the past, been used as a standard or benchmark, as many applications modeled their own help after Apples. One of the most significant contributions of Apple help is the fact that they used an iterative approach, which allowed for the help system to be updated to suit user needs more often. Nowadays, though, more and more applications are turning to an Online Help approach, which seems to combine the benefits of a larger resource (since there are no longer local constraints) as well as being able to update the help topics and content much more often, since it is no longer bound to a user's machine.
James Yeh 17:22, 22 October 2008 (UTC)
The development of Apple help demonstrates the usability testing and iterative design. In particular, the reading mentioned how a lot of the feedback that the company received after testing their help interface on users contributed to improvements to the design. The “having [testers] think aloud while performing tasks” method that Apple employed closely relates to the type of testing that we did for our low-fi prototype. From our experience with testing our own prototype, I agree that this kind of testing is very productive, and can help weed out many key usability inconveniences. In addition, I liked how Apple clearly outlined their design goals for their help interface. After reading through these goals, I, as a user, can much more easily evaluate the interface in relation to each goal and determine if Apple is adequately achieving their goals or not. Also, while some of the goals were obvious and necessary (i.e. accessibility and searchability), goals such as authoring and minimalism were eye-opening ideas that I probably would have overlooked. However, these goals made sense to me after I read them, and now I can better understand how a minimalist help interface proved more in-depth content and faster information access at the same time.
Kevin Lam 17:28, 22 October 2008 (UTC)
Apple has always been on the leading edge of user interface design. This article gives us some insight on how Apple is able to create simple, yet powerful user interfaces. It was reassuring to read about how Apple conducted user tests (i.e. for the location of the "Help" menu), because it justifies that what we're learning in class is implemented in industry. Also, we see in the article how centralizing all the information benefits the users. The notion of having help features stem from one place parallels the idea of having web portals for corporations. Another key point is that some help features aren't necessary and I absolutely agree with it. For instance, it can be safe to assume that someone who is comfortable using a computer won't have trouble distinguishing a play button from a stop button on a video player.
Jonathan Fong 17:48, 22 October 2008 (UTC)
Even though this article is/seems "old," (8 years in 'technology-time' is a long time) I was surprised to see how little has changed since then in the area of help. First, Apple was smart enough to figure out to use the Internet. Back then, the internet was just budding, but now, one can't consider doing anything without the internet being involved. Second, the graphics/effects to draw the red circle around the actual button/feature-of-interest is pretty fancy. Overall, maybe we shouldn't be so suprprised Apple's help is so well-polished: 1) we only see the final product and have some discussion of the process Apple went though; 2) Apple is pretty user-centric.
Haosi Chen 17:52, 22 October 2008 (UTC)
The Help option is a very important function for user interface. However, I believe that most people would have rather done their task without using Online Help. This doesn't mean an interface shouldn't have an help option, but it's better that users can figure out how to perform their desired task immediately, and a way to accomplish that is to make pop-up Help for every object on interface so that users can figure out what to do without looking for the online help.
Mikeboulos 17:59, 22 October 2008 (UTC)
It was very interesting to see how people wanted to get help. The designer thought it was a good idea to put a question mark (?) on the top right but that was not obvious, because when I want HELP, I will look for HELP and not a ? so it made more sense to actually put the word help up there. Also changing the help to an online/HTML documentation helps a lot because now they can also add the animation which reminded me with the master apprentice model. I applaud apple for working around what the user wants and not what the program thinks is fit, Even though this design was done a long time ago.
