Help and Visual Flow

From CS1635 Spring 2014
Jump to: navigation, search



Required Readings

Reading Critiques

Xiaoxuan Chen 2:54:46 3/21/2014

This article talked about the workflow of designing Apple Help. The development of this was a long process that included several studies where users were observed thinking aloud while doing tasks. Researchers came up with questions in the following five categories: • 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?") The majority of the essay discussed the seven design goals throughout Apple Help development and how each goal was reached. The seven design goals include: 1) Make help discoverable - use "Help" instead of question mark, 2) Make help easy to author - HTML based, 3) Provide a central point of access to all available help - browse among all the content in the Help folder instead of single application, 4) Take advantage of the Internet, 5) Define tasks broadly, 6) Write minimally, 7) Automate tasks when possible. This is a pretty cool article, showing how and what kind of goals developers form while developing an application, as well as how each goal is met. I think it's a good read.

Nicholas Amoscato 13:38:38 3/24/2014

Kevin Knabe’s article entitled “Designing Apple Help” provides a summary of the process behind designing the online help system included in Mac OS 8.5 and aggregates a set of guidelines. Initial research defined five general categories of questions: goal-oriented questions, descriptive questions, procedural questions, interpretive questions and navigational questions. Ultimately, it was the description questions (“What is…?”) and the procedural questions (“How do I…?”) that were implemented as Balloon Help and Apple Guide respectively. Apple Guide was designed to address several problems of traditional online documentation. First, they addressed the problem of layer switching by presenting the online documentation in a non-obtrusive window that floated on top of the screen. Second, they incorporated a coachmark (bright red circle) that clarified the difference between illustrations and functional interface components. Finally, they ensured that the documentation was uniformly accessible via a help menu, table of contents, alphabetical index and keyword search. While designers were able to mitigate several problems that came up in usability testing, the Apple Guide was ultimately insufficient for users who wanted easily accessible, in-depth content. There were several goals for designing help in Mac OS 8.5: (1) make help discoverable – the small help icon at the top right of the menu bar was replaced by a “Help” menu item at the end of the existing menu; (2) make help easy to author – Macintosh application developers would now be able to author content in familiar HTML; (3) provide a central point of access to all available help – the Help Viewer enables users to browse and search HTML help content from any application and launch Apple Guide sequences for step-by-step guidance; (4) take advantage of the internet – content was augmented with external links on the web; (5) define tasks broadly – sequences focused on assisting users in forming goals, performing actions and evaluating feedback; (6) write minimally – writers were encouraged to only write about tasks that users would be unable to figure out via exploratory learning; (7) automate tasks when possible. This article was particularly interesting when put in context of the current version of Apple Help. Today, the menu item is entirely focused on a simple search query that highlights the relevant aspect of the existing application menu hierarchy. As mentioned at the end of the article, this automation prevents me from actually learning the location of menu items. However, it drastically reduced my cognitive load.

Pedro Alvillar 22:48:12 3/24/2014

Knabe's article takes us through the evolution of online help for Mac. He starts off by describing how researches at apple found that users tend to represent problems in the form of questions, these questions usually falling into one of five categories: goal-oriented , descriptive, procedural, interpretive, or navigational. Knabe talks about how Mac's help designers tried to tailor the help interface to such needs by eventually implementing a way to answer "what is..?" as well as "how do I?". Another problem however arose, as users were being forced to switch out of context in order to seek help. This was solved with the design of the apple guide which allowed users to be able to see their active window while also searching for help; Apple went a step further by using this fact to the users advantage and actually pointing out what the help was referring to on the actual program GUI. Through much testing of their newly designed Apple Guide, designers at Mac used their knowledge about existing weaknesses of their system in order to improve it. One of such improvements was actually making help easily discoverable, which is why it was introduced as a menu bar icon in Mac OS 7.0. Another improvement that Apple made was to provide a central point of access to all available help for the system using multiple tables of contents and allowing querying of such contents. They were further able to improve their system by also providing links in their help center to constantly updated online help pages. One of the most important components that Apple added to their help center was the ability to automate tasks for the users which reduced user error and improved the success rate of the actual completion of a task.

Derrick Ward 11:29:12 3/25/2014

Today’s reading is about the iterative process that has taken place to design Apple’s help system. The design of Apple’s help system began in 1988. To help shape the system, apple’s employees conducted observational studies to see what problems user were being faced with. These problems were categorized into the following five categories: goal-oriented questions, descriptive questions, procedural questions, interpretive questions, and navigational questions. It was then found that most questions were descriptive and procedural. From all their studies and research Apple released the “Balloon Help” with Mac OS 7.0. As research and development continued, Apple conducted many usability tests to find ways of improving the system. During a usability test, six to eight participants were gathered and asked to perform certain task with the software while thinking aloud. This event is the same as what we did, as groups, to improve our android applications. From these usability tests and market research, apple created 7 design goals. Those goals were as follows: Make help discoverable, Make help easy to author, Provide a central point of access to all available help, Take advantage of the Internet, Define tasks broadly, Write minimally, and Automate tasks when possible. For design goal 1, the help icon on Mac OS 7.0 was changed and moved. Rather than the icon being a question mark, it was changed to the word “help”. The help system location was also moved to join the menu to the left. I too found this location and appearance to be better. For Design goal 2, Apple allowed and made it simple for Macintosh software developers to contribute to the Help system’s documentation by making the documentation HTML. This was a great idea, considering the fact that developers expressed a dislike to the idea of having to encode help-documents differently for two systems (Windows, and Macintosh). For design Goal 3, an application called “Help Viewer” was created that centralized all help documents on the system. These documents could be HTML, plain text, or URL link to the web. Design 4 also kind of went in hand with design goal 3, by taking further advantage of the Internet. For design 5 help documents changed the way they conveyed and received feedback from users. The model was changed from a traditional linear task model to an iterative task model. Design goal 6 simply asked writers to be as simple as possible. Design goal 7 I found to be a great milestone. In Design 7 they were going to trying to automate as many task as possible. All in all I found this reading to be great, both from a historical and learning reinforcement stand point.

Steven Bauer 23:09:50 3/25/2014

Thursday's reading is about the designing of minimalist documentation. They start out by discussing the start of the online help for Mac OS back in 1988 where they used many of the tools we learned already in the course, videotaping user behavior and listening to what they were saying when thinking aloud. They found that there were five main categories for questions. These were goal-oriented, descriptive, procedural, interpretive, and navigational. One of the breakthroughs they had was making the help small and have it stay above the running application such that the user could keep working as they followed the steps presented by the help program. In the next major revision (Mac OS 8.5) their goal was to make help more discoverable, make the help easy to author, make a central access point for all help, take advantage of the newly popular internet, define tasks in a broad manner, write minimally, and automate tasks when possible. By implementing and improving these features they saw a huge increase in the number of successfully completed tasks when the user consulted the help system. This text was interesting because as a fairly tech savvy user, I rarely look at the help documents for applications. I was skeptical to their utility, especially after earlier in the class it was said that only 7% of users look at the help, but after reading that they had such high success rates I have changed my mind toward help and will implement it in future projects of my own.

Charlie Koch 9:33:43 3/26/2014

Today's reading focused on how you can make a help menu and help functions that can effectively teach the user what they need to know when they are interacting with your software. Using the design process of Apple's Mac OS help system as an example, Kevin Knabe explores seven goals that Apple used to refine their design. What I found most interesting was the results of research and testing Apple did before they redesigned the system. People typically as questions such as "What is ...?" or How do I ...?" and the current system did not provide any method like this to search for answers. Apple based their entire new design around this framework. The other interesting thing (that still plagues many help menus and documentation today) is that people need to be able to see the help document and the actual program at the same time. If not, they commonly mistake steps and end up becoming more confused than they did before they searched for a solution. The design goals themselves seem to echo a lot of the interface design principles we have covered before. The first goal is to make the help visible, and not only visible but in a natural place that users will look so it is easy to find. The second goal is to make the help easy to write. If your help system requires special language, API, or other special requirements, less developers are likely to use it, which means there will be no help at all for the user! The developer may provide their own help system, but this directly violates goal number three, which is to make a central point that the help can be accessed from. The fourth goal is to use the Internet to supplement the help. No matter what you do, the user will always have unanswered questions. To keep the help concise, direct them to help on the Web that can provide extra information and detail. Goal number five goes along with this in that the help system should try to be very broad. This makes sure the user can get the information they need immediately as fast as possible and provide them further avenues to explore. Along with goal five, goal six continues the idea of keeping the help text simple and short. Finally, goal seven is to provide automation when possible. Using pictures or video can confuse the user, but taking the actual product and manipulating it in front of the user can greatly improve their understanding.

Hao Zhang 15:07:05 3/26/2014

It is pretty good idea to make an instruction or a help center for the new software or new system. User may not know how to use a new staff, and they will not use this new staff if they still don’t know how to use it. An instruction or a help center may solve this problem. They can make user be more familiar with new things. The design goals of these help tools are 1. Make help discoverable, 2. Make help easy to author and 3. Provide a central point of access to all available help, 4. Take advantage of the Internet, 5. Define tasks broadly, 6. Write minimally and 7. Automate tasks when possible. An online help center could make works more convenient. Users can access the online help center at anytime and anywhere as long as they have the internet. The online help center can collect the result globally and it doesn't require the customer service to maintain it for 24 hours. It will automatically show users the results if it has them. Generally, the online help center should contain some common issue that users probably have. What is more, the online help center should also record the question that users ask, so it will become a new result for other users who have the same problem. Hence, the online center will have more and more answers for users.

Cory Savit 17:58:48 3/26/2014

Today's reading, Designing Apple Help, went through the iterative design process that was used to create and fine tune apples help options, up to the time of publication. The process began with research, which included previous literature on the subject and user observation. This research helped the team to narrow down what help issues should be covered as well as how to organize and present the information. This was followed by rapid prototyping, user testing and usability testing. Although some issues were brought to light, and fixed, as a result of testing, others were not discovered or addressed until a new version of the OS software was released. The strength in this type of process is the ability to create something that works, but still have to ability and desire to improve upon the existing product as new insight is gained. I got the impression that the author was of the opinion that Apple Help had reached some level of perfection in its design. Since the article was published in 2000 we can see that today many changes have been made to Apple Help. I think this helps to show just how important the iterative design process is, since it is cycle that should continue for the life of any peace of software.

Zhanjie Zhang 19:29:01 3/26/2014

The design of the apple online help started by the group realizing that users asks common questions. They were goal-oriented, descriptive, procedural, interpretive, and navigational questions. So the designers decided to have the users begin by choosing a question type that they can ask from the help menu. During user testing, they found many problems associated with online documentation of help pages. The apple guide was designed to have the user stay in their current application. They also tries to prevent confusion by using coach marks around objects that is important. As the help guide was being developed, product test teams conducted usability tests to make sure that the help content was being developed properly. However, there were problems and apple designers set a few goals for mac 8.5. They wanted to make the help more discoverable, make help easier to author, provide a central point of access to all available help, take advantage of the internet, define tasks broadly, write minimally, and automate tasks when possible. This approach led to a higher rate of task completion in usability studies. Also, with the addition of the core elements of the system, troubleshooting-focused writing, task automation, and the use of step-by-step guidance when appropriate - appear to support users well "when all else fails."

Chris Solis 20:15:00 3/26/2014

The reading was an in depth analysis of the design behind Apple's help interface. Initial research revealed that user's described problems in the forms of questions. Based off this research they proposed an interface asking and answering questions. This design never came to fruition but set the ground work for the future help interface.The Apple Guide was built to alleviate layer switching. The Apple Guide sought to differentiate itself from other help interfaces by pointing out the actual object by drawing a "coachmark" around the object designed to help the user. Additional testing and research was done and found problems in user usability, search keywords, and using the panels. Mac OS 8.5 saw a description of design goals such as: make help discoverable, make help easy to the author, provide a central point of access to all available help, take advantage of the internet, define tasks broadly, write minimally, and automate tasks when possible. Each goal had a description of the way the Max OS 8.5 attempted to achieve the goal and the function that the interface implemented to achieve each goal's purpose. In the end the OS 8.5 help interface was a success for usability and post-design testing saw 21 of 23 cases completed by users which used the help. Overall the reading was a good in depth analysis of developing a successful user interface.

Matthew O' Hanlon 20:52:41 3/26/2014

The design of Apple Online Help involved quite a bit of research and user testing. Some initial research into the original help system found that most users didn’t find Apple’s help system to be of any use in completing a specific task. The study found that users look for help or attempt to learn by asking 5 general questions which are goal-oriented, descriptive, procedural, interpretive, and navigational questions. In order to help users answer these questions, Apple did some usability testing to help guide the design of the next online help system. The researchers found that there were several problems with the previous help system like the grouping of tasks in the table of contents, inadequate search keywords, trouble naming tasks, use of language that is unfamiliar to most users, and the help panels were too big. So, with these things in mind, Apple came up with design goals for the hext help system. The first design goal was that the help system should be discoverable. The original system had a question mark icon placed far to the right of the top menu bar. The design of the next help system was placed with the rest of the menu items and said “Help” instead of a question mark. Users found this much more helpful than the previous icon and used it much more. The second design goal held that authoring help should be easy. Apple wanted other developers to write programs for their platform, but including the content meant learning Apple’s complex scripting system for online publishing. Apple instead turned to HTML which was a standard for online publishing. That move meant that developers could use their existing knowledge to author their own help material. Another design goal was making use of the Internet. The basic idea of any help system is connecting users with the information that will help them with a problem. Apple decided to make links to online documentation that already existed rather than try to include everything in one system. The next design goal was to define tasks broadly. The study took note of how people normally troubleshoot problems which is a non-linear process. People normally form goals, refine those goal, try out one or more ideas, observe what happens, then make a decision as to what they’ll do next. The next online help system should help their users form goals, perform some actions, and help users interpret feedback from the system. The next design goal was to write documentation in a minimalist fashion. Some tasks are simple enough that they can be inferred or users have enough experience with existing designs that they don’t need the instructions to complete the task. The last task was to automate as much as possible. The study found that users much preferred to complete the task faster and error free than learn every detail about the problem. The study also found that many users used the automation scripts to learn about the task, and they even performed the task later without the assistance of automation. The next system was released for Mac OS 8.5, and subsequent studies found that there was a dramatic increase in the use of the online help system.

David Grayson 21:25:05 3/26/2014

"Designing Apple Help” documents the development of the online help system for Apple’s operating system. Beginning with the Human Interface Group, the Apple help system split into “balloon help” which answers users’ descriptive “What is this?” questions, and Apple Guide which answers users’ procedural “How do I?” questions. Apple Guide allows users to search for help with specific questions in a way that is user friendly. This help feature tries to minimize user error by displaying in a way that supports integrated use of the help feature and the actual interface. Apple also included a feature to circle objects on the interface instead of showing the icon, in order to reduce confusion due to showing objects that cannot be clicked on. The goals of the online help system for Apple were to “make help discoverable”, “make help easy to author”, “provide a central point of access to all available help”, “take advantage of the internet”, “define tasks broadly”, and “write minimally.” Overall, this article brings up many valuable points to remember when creating a help system for an interface, and even when creating the actual interface. Understanding how users interact naturally with interfaces will allow the design to reduce errors and increase usability.

Zach Sadler 21:36:28 3/26/2014

The process that the observers used to determine how to design Apple Help is very similar to the procedure we used in class. Its nice to know that we're using the state-of-the-art industry techniques. I found it pretty funny that they didn't realize that the users would have issues switching back and forth between on-screen documentation and the screen, but the Apple Guide is an outstanding solution. I was very impressed by what they were able to do and how they could lead the users to learn to use the system. I was a little surprised that the Apple Guide was viewed as too slow and that it spoon-fed users when they preferred more in-depth information since it was so early in the design of computers. I was not so happy to see the Help Center, since I've accidentally activated that menu a few times and never enjoyed it. The final design was actually not my favorite, but I could see why they reached that conclusion.

Guoyang Huang (Guh6) 22:13:21 3/26/2014

The reading taught me about two different kinds of user helps in the reading. One was descriptive and the other was procedural. Another thing I learned was layer switching and use coachmark rather than pictures because user might confuse it with functionality. The third thing I learned was that it is possible to do usability testing for help. Finally, I learned about Design goals of make help discoverable which is to make it visible, make help easy to author which is to make it easy for developers to use for portability between operating systems, provide a central point of access to all available help which is to create a guide that contains all of the help information, take advantage of the internet which is to use it as a community for answers, define tasks broadly which is to make it as non-specific as possible to allow for deviations of a given task, write minimally which is sometimes pictures can be in place of words and automate tasks when possible which is some tasks does not need to have help guide because most are able to do it.

MJ McLaughlin 22:31:55 3/26/2014

Kevin Knabe’s “Designing Apple Help” provides an interesting look at how the Mac OS help system both came to be and has evolved. The system was initially developed based on existing literature concerning help and help systems, as well as videotaped observations of user behavior. Researchers noticed that as users thought aloud while completing software-based tasks, these users tended to ask give general types of questions, with descriptive (“What is…?”) and procedural (“How do I…?”) questions being the most common. These question types helped inspire the design on the help system, with Balloon Help being based on descriptive questions, and Apple Guide being based on procedural questions. Apple Guide was designed to enable users to use a help system without having to navigate away from the program they’re currently using, which was a common problem in most help systems and one that increased the amount of mistakes made by users. Instruction panels were presented one-by-one in a layer floating above the current application in a step-by-step fashion. The Guide also pointed out interface elements of interest with red circles to help users focus on the appropriate interface elements. Focus testing of the Guide indicated that it presented information too slowly and without enough depth, however, so the next generation of help was iteratively designed in order to improve upon current weaknesses as described by user feedback. Based on this feedback, designers aimed to preserve the strengths of the system as well as fix weaknesses. First, the “Help” button menu was moved to a more obvious location, which fit the path of exploratory learning, or the process of users learning by simply exploring and using a program, and noticeably increased discovery and actual usage of help. The system also moved over to an easy-to-author system based on HTML, which made it easier for developers to actually provide help for their programs. All available help was also made accessible and searchable through the Help Viewer, which made accessing help much easier and more efficient. As there was already a vast amount of help available online for many programs, it was very useful to make this online help accessible from the help system as well. In the previous iteration of Apple Guide, help writers wrote tasks as a series of steps, which was in conflict with the actual iterative, goal-based task model people tend to take when problem-solving, so help should follow this task model as well. Help systems should also keep instructions to a minimum and focus on important tasks as opposed to trivial ones, so as to most help users and not overwhelm them. And finally, parts of tasks that can be automated should be, as it helps users complete tasks with less error and more quickly, and they also learn how to complete even these automated tasks. The iterative design of this evolving help system led to very high rates of task completion in user testing, with tasks being successfully completed in 21 of 23 cases in which users needed to use the help system after exploratory learning alone wasn’t enough to complete the task. Troubleshooting-focused writing, task automation, and step-by-step guidance, when appropriate, are all great “last resort” focuses of the help system that do help users successfully complete tasks they need help with. Following these ideas, as well as the iterative design process that helped solidify them, can help designers devise interfaces that should help users complete tasks without needing extra help, but also provide help when needed. And as users are the most important part of any piece of software, these very important principles should definitely be kept in the very front of our mind.

Longhao Li 23:17:44 3/26/2014

This article talked about the how to design the help pages. The entire article based on Apple’s design of their help on Mac OS. It starts from 1988. They make some observations on users’ reactions when they encounter questions, and find that user’s always represent problems as questions, which have five general categories. So they make a system to ask and answer questions, in which they implement two popular question types: "what it…?" and "how do…?”. These two types of question final became parts of Mac OS. "How do I…?” became the Apple Guide. The apple Guide redesigned the help page from the text-based articles to step by step help guidance. Also it will help user to find the right graphical button by cycling them with red cycles. It seems very helpful as a help page. But after doing usability testing and market research, they find that it is too slow to present information and sometimes spoon feed is not a good option. Some users need in-depth content. So the next generation of help came up. Firstly, they make the help discoverable: making question marks on the menu bar first and then it upgrade to a help menu in menu bar. Also they make it be easier for author: make an HTML based help pages turn out to be a good solution. Then the make a central point of access to all available helps. Users can direct search helps in it. Meanwhile, Internet support the help pages, and they made the tasks board by making the step-by-step procedures fit in different situations. Also the help should be in minimal when the task is obvious easy to be done without help, and make the help automatically finish the job is needed sometimes. By making this possible, I think the Mac OS’s help is very functional and easy to use. This is a great guideline to design the helping page.

Zach Liss 23:48:41 3/26/2014

This article summarizes the design efforts and presents a general set of guidelines for help writers and designers. In order to begin early research users are observed thinking aloud while doing tasks in application programs. A common problem with traditional online help is that users confused by pictures of interface elements. A key was making help discoverable and easy to use. The new approach led to remarkably high rates of task completion in usability studies.

Ariana Farshchi 23:48:57 3/26/2014

This weeks reading, “Designing Apple Help” outlined the evolution of help for the Mac OS. Online help began when Apple’s Human Interface Group started conducting studies on help and human behavior. The reading outlines seven design goals: make help discoverable, make help easy to author, provide a central point of access to all available help, take advantage of the internet, define tasks broadly, write minimally, and automate tasks when possible. At first, Apple found that users tended to represent problems in the form of questions in 5 general categories: goal oriented questions, descriptive questions, procedural questions, interpretive questions, and navigational questions. The reading showed how designing and testing “Apple Guide” has changed over the OS revisions. In Mac OS 7.0, help appeared as a small question mark icon in the menu bar. Many users did not notice the question mark, though, so in Mac OS 8.0, the menu was moved to the left and labeled “Help”. In Mac OS 8.5, all help was available though a central point of access, called “Help Viewer”, which integrated a variety of help technologies. Apple has found that incorporating these seven design goals into their help design has led to remarkably high rates of task completion in usability studies.

Sara Provost (stp28) 0:18:13 3/27/2014

This week’s reading is about the design of the Apple Help system. Online help for Mac OS began to form in 1988 when Apple’s Human Interface Group reviewed the available literature on help, evaluated current systems, and conducted videotaped observations of user behavior. After doing this, the researchers found that user questions tended to fall into five general categories, which are, “What can I do with this?”, “What is this?”, “How do I do this?”, “Why did that happen?”, and “Where am I?”. Based upon this knowledge the designers proposed a system for asking and answering questions. One of the main problems that Apple’s solution addresses is the problem of window switching while trying to both read the help guide and navigate other software. To solve this problem Apple came up with the idea of layers, which kept a small window that had the help information always in the front and therefore always visible. In Mac OS 8.5 there were new design goals. The first was to make help discoverable. To do this a help menu was added to the menu bar that had the easily recognizable icon of a question mark. However, some users had difficulty seeing it, and it did not do well in usability studies. The second goal was to make help easy to author, to do this Apple designers began to support html. The third goal was to provide a central point of access to all available help. To accomplish this, Apple designers added a Help View, which allowed them to organize all available help information into one easy to access place. The Help View also contained a search function, to make finding applicable help easier. The fourth goal was to take advantage of the Internet, which they accomplished by linking to existing content on their website. The fifth goal was to define tasks broadly, this was done by approaching every task as a series of actions. The sixth task was to write minimally, which was accomplished by only writing about tasks which users were unlikely to figure out by themselves. The seventh and final goal was to automate tasks when possible. This was done through “do it for me” buttons that user could click on to complete basic tasks, so that they could read through the help faster. I think that this reading will help us keep in mind what makes good help for our applications. From this reading we can remember to keep our help short and to the point, visible, easily accessible, easy to create, and to provide the user with tips and hints. All of these things are easily applicable to mobile applications. I feel that the goals discussed in this reading are very applicable to my group assignment, which is a children’s learning app. Our main users are children, so in order for our help to be useful it must be simple, clear, and easily found.

Matt Landram 0:39:13 3/27/2014

Today's reading was about how Apple's Mac OS Help functionality was designed and updated to be more user-friendly and efficient. Apple Guide developers recognized that people often clicked on pictures thinking they were interactive interface elements, so they started drawing circles on the screen around the elements themselves, enabling user interaction with the help interface. The developers also learned a lot from their usability testing, which pointed out they were lacking enough search keywords, using unfamiliar vocabulary, as well as numerous other issues. Had they not tested with users, they'd have never known of these issues and would have released a sub-par product. The method of accessing the Apple Guide changed over various iterations of the Mac OS as well. In OS 7.0, help was accessed via a small question mark icon, but they found that many users didn't notice the icon, instead opting to use the drop down menus like File, Edit, Special, etc. In OS 8.0, Help had its own drop down menu, greatly increasing its accessibility. Another accessibility goal the developers wanted to achieve was ease of adding to the help database. Many non-Apple developers didn't make use of the Apple Guide because scripting help databases was convoluted. Apple decided to make their Guide an HTML based service, enabling ease of access for all developers. The final goal Apple wanted to achieve was to make their help as minimized as possible. This meant condensing their help entries into small lists and even adding automation to the process. The example given shows how adding a button to open the Audio Player enables the user to skip reading the instructions and instead jump right into their desired task. Overall, the reading was very useful in seeing how the iterative design process takes hold in a mainstream application such as the Apple Guide.

Melissa Thompson 0:44:31 3/27/2014

This reading is about the evolution of the design of the online help system known as "Apple Help" or "Apple Guide". The goal of the article is to present "Apple Help" as an example of the design process in order to help other designers see how testing and setting new goals can improve a product. Initially when Apple Help was being created, the designers focused on creating a system that answered descriptive and procedural questions that users had. Developers also noticed that users often had to pause their task in order to access the help window, so they aimed to eliminate unnecessary screen switching by providing one step at a time and circling the current object of focus on the screen. Usability tests were done as these features were developed in order to identify problems such as unfamiliar vocabulary, limited search keywords, and window sizing issues. This market research showed that the overall reception of Apple Guide was not great. Providing one step at a time meant that going through instructions was slow, and to more advanced users this made the process of getting help even more tedious. But by creating this product the designers were able to keep the things that worked and eliminate or improve things that didn't in the next prototype. They focused on 7 design goals in order to make the next generation of Apple Help successful. The first design goal was to make help discoverable by having an easily identifiable way for users to access the guide. The second goal was to make help easy to author. In order to accomplish this the designers chose to switch to "the standard of authoring online information", HTML, so that developers could easily provide help documents for users. The third goal was to make all help accessible through one location. The "Help Viewer" was the result of this goal, a system which hosts a help browser/search for multiple help technologies. Taking advantage of the internet was goal number four, and was added when the designers realized that users were requesting information that was already available on the web. The fifth goal stated to define tasks broadly by focusing less on procedural steps and more on presenting reasoning and feedback for troubleshooting. The sixth goal was to write minimally, and the seventh and final goal was to automate tasks whenever it was possible to do so. Both of these goals aim to make tasks easier and quicker for users to understand and complete. After completing more user testing on the improved Apple Help, the designers saw a huge improvement in user reception and task completion. This is just one example of how doing user testing and market research can help to improve the product. Making changes based on feedback is essential when designing a product that will be useful and easy to use.

Michael Mai 1:34:36 3/27/2014

This article talks about the designing of Apple's help guide. Apple did a lot of user testing with different people and addressed to solve the problems that frequently came up. One of the first problems was that users would be confused and get off track when they had to switch to another application in order to get help. The testers found that users were not able to keep up with the help guide when switching back and forth. They set out to solve this layering problem by having a small box with one instruction at a time that would float right next to the application. The Apple team also did usability testing where they got 6-8 participants which they encouraged to use the online help when they couldn't figure out a specific task. This testing helped them identify a bunch of problems. Some of these included problems with the tables of contents, search keywords, and a couple other things. Next, the article talked about the design of the Appl help. They experimented with the placement of the Help icon and realized that many people miss it if it wasn't clearly visible. They fixed that by making sure it was clearly shown to the users. This accomplished one of their goals which was to make the help discoverable. The article goes on to discuss a few more goals that the team had. Another one of these was to take advantage of the internet. To do this, they realized a lot of information was already on the Apple website. They just linked the user to the website instead of making a whole new help document. Another design goal they had was to write minimally. This meant that the writers were encouraged to leave out aspects that users were already assumed to have known. This would make the help documents more helpful rather than have the user just read stuff that they know already. Overall, this article helped me see the design process that the Apple team had when designing their help service. The goals that they had set were very good and I will remember them for future designs.

Brian Kacin 2:29:13 3/27/2014

This article is about designing Apple Help that explains the research and development that went into creating an interface that the user base will be able to efficiently use. It starts off about the very beginning of the research which gears towards the audience feedback and conducts experiments of what the users are thinking when they have questions. This reminds me that during this class we are taught that user feedback is extremely vital to success of an application. They noticed that when they went to get help in an application, they lost their place and had to remember the sequence step by step and they lost their place. The Apple Guide addressed the problem of layer switching which was a great solution because nobody wants to go back and forth just to figure out a problem. After more research with Apple Guide, there were more problems addressed, which is great because this helped inform the next design for MAC OS 8.5. Once again, reinforcing the importance of experiments and user feedback for designing the product. After constantly designing based off user feedback and experiment results, it led to high rates of task completion. The great thing is that Apple plans to do continued research on how well the help system is accepted by developers and users in the field. There can never be enough feedback and with updating systems and knowledge the users possess, it is crucial to constantly know what the audience thinks of your product. Once you lose them, you lose everything.

Bret Gourdie 3:09:02 3/27/2014

Help is always a concern when developing an application. If the user cannot access a collection of knowledge provided by the program to solve the easier problems, hiring people to standby on phone lines is a much more costly solution. Apple, obviously, thought about the concept of help for a decade. At first, they found that user problem-solving skills fell into five distinct categories, so they decided on a design to answer such questions. However, this never took off. In my opinion, their approach seems a little too broad, and could not help someone who was phrasing their question incorrectly. As such, Apple developed the Apple Guide, a floating program that told the user what to do over top of the running application. It also came with standard help features, like keywords and indexes. However, people found the keywords were inconsistent as well as the speed of delivery and depth of guidance to be inadequate. The more seasoned users were "spoon-fed" instead of nudged in the right direction. The new help was positioned at the top-right of the screen to denote how there would always be space allocated to it. Unfortunately, users did not seem to see it, as they were accustomed to finish reading after reaching the end of the left half of commands. A solution was to append it to this list. But this help was difficult for developers to integrate into their own applications, not to mention that they'd have to make two completely separate help files for the two major OS's that were out. To solve this, HTML was adopted as the standard. This was well-received! Automation is a great idea for many help topics. Although the user will not have learned how to do the task, they will have learned where they can get to in order to accomplish the task. Then ends justify the means, right? Even now, Apple still cares about making it as easier for the user as possible. By utilizing the knowledge they've acquired over the past twenty years, they will be able to solve the problems of tomorrow, opening the demographic for ease of use.

Aamir Nayeem (aan14) 3:32:36 3/27/2014

Today's readings, on Apple's help menu design, was interesting in that it talks about strong design principles that presumably took a long time to devise and implement, but they're pretty standard to us at this point. From the brief view that it shows, help screens were very difficult and unintuitive to access before they were standardized and in the format that they're in now. This seems like an important concept, though, because, in a way, help menus are the most important final component of the system. If there is anything that a user of a system or program cannot do, they will go to the help screen to attempt to solve the problem. However, this usually happens after they have tried to solve the problem on their own in some capacity. Thus, when the user reaches the help screen, this is the final resort and final line of support to help them understand the system. If the help screen is unclear or difficult to use/access, the entire task becomes impossible for the user. Thus, while it doesn't need to be anything very fancy, a good, clear, easy-to-use help menu seems vital. I didn't really think about this much until now, but now it definitely seems to make sense that the help menu needs to be done properly and must be created with focus on the users, since a user needing to use it will not be familiar with the system and will not understand the system, and this is their last chance to understand it or even want to use it. The users who access the help menu are the users on the threshold of using the system and not, so a good, intuitive, and helpful help menu must be made and implemented. The Apple style seems to be a good approach.

Kyle Tanczos 8:40:00 3/27/2014

The reading today was interesting because the design goals were very well structured and implemented by the apple help team. I have never used the Mac help system, so I can't speak to its usability on a personal level. However, they follow alot of design steps similar to the iterative design cycle we follow for interface design. It caught me off guard that users didnt want to be spoon fed steps during the help. It is a very safe assumption that people who dont know how to do a task would like to know the steps directly so they can complete the task. This shows the importance of research, testing, and the target's conceptual model.

Ryan Ulanowicz 8:58:43 3/27/2014

Designing Apple Help splits the help system into Apple Guide and Balooon Help. Apple Guide is then made by watching how people use help interfaces. THey tried to reduce errors while overlaying help over the regular interface so you can see both. They also drew over the actual interface to make it obvious which buttons were relevant. Goals included making help easily discoverable and easy to author. It also gave a central point of access to all of help. It also took advantage of the internet and it's resources. This allowed tasks to be defined broadly.

Max Campolo 12:35:08 3/27/2014

This reading covered the benefits to having a help module in an application or operating system. Help systems are very important not only for procedural inquiries but also for goal oriented tasks that the user may need help understanding. The evolution of the Apple help module is a good guide on how help services should assist users as well as be easy for developers to implement. This encourages use of the systems and increases customer satisfaction. The first shift in help from literature to on the computer was designed to answer goal oriented, procedural, descriptive, interpretive, and navigational questions. These were identified as the types of main questions that would be asked by users. Guides were designed so that users did not have to exit the application to use them.Some design goals were to make help discoverable for the user and easy to author for developers. The help approach led to significantly increased rates of task completion in usability studies which proves the value of this kind of system.

Buck Young 12:39:38 3/27/2014

Todays reading was about the evolution of the Help component of the Mac OS. Apple found that users typically asked one of five categories of questions: What is this? What can I do with this? How do I do this? What happened? Where am I? Furthermore, the engineers found that questions were either procedural or descriptive. The system was comprised of several core elements: troubleshooting-focused writing, task automation, "minimal" writing, step-by-step guidance for procedural tasks, and making the help easy to author. Ultimately, from this research, they were able to create a user-friendly interface for their online help system.