Help and Visual Flow

From CS1635 Spring 2016
Jump to: navigation, search


Required Readings

Reading Critiques

Charlotte Chen 15:42:01 3/18/2016

The article gave a really informative walk through of the design goals in designing Apple’s new help system. While the goals clearly address the question of what makes Apple help good specifically, they also suggest universally of what constitutes a good system design. Design goal 1 “Make help discoverable” fits really well with the design principles we talked before — “visibility”. I find design goal 5 “Define tasks broadly” to be new and interesting; it shows that the developers are trying to address the users’ learning habits in a way they don’t even realize themselves, by helping the users to form goals and interpret feedbacks. Design goal 7 is the best out of all in my opinion, because it’s my favorite feature of the help section in modern software designs. It addresses the user’s problem fast and accurate.

Jason Naughton 9:59:46 3/21/2016

I have noticed a number of new-user help flows on web and mobile applications lately; periodically (whether as a new user to the site, or after a new feature has been relased), the site will "spotlight" a button or part of the page, and provide a large tooltip description. Typically, the user proceeds through these help flows linearly with "previous" and "next" to show the help. As with the design of the Apple Guide, this keeps users in the task and "coachmarks" potentially confusing interface elements. I thought this and a few other innovations, such as the one-point of reference for help that was non-proprietary and easily accessible--were particularly interesting.

Bogdan Kotzev 10:37:56 3/21/2016

The article helped me understand the improvements of the help box in Mac OS and the reasons for those improvements. The development started by identifying the types of questions that users would ask when using the software. Mac OS 7.0 designed the help around the questions, "What is ...?" and "How do I ...?" Unfortunately, the design of the help did not score very well with the users. In Mac OS 8.5, the help was redesigned with 7 design goals in mind. I will only mention the 3 most important of those 7. The most important design flaw that was fixed was that the help icon was hard to discover for users. The second most important design concern was that the help pages should be written in HTML. This would make authoring the help pages much easier. And I believe the third most important design improvement is in the adding of the central point of access. The one place where you can get any help that you want. I have had my experience with bad help boxes, and I know how important they are to the user.

Joshua Fisher 15:45:57 3/21/2016

I enjoyed reading about how much work and thought went into the help menu for Mac OS. What is interesting is now they have gone away from a help menu, and rather use a search bar to help users when they need help with some functionality. It would be interesting to see when this transition happened. The article discusses Mac OS 8.5, and their most recent OS is 10.13.

Jonathan Blinn 22:08:38 3/21/2016

The one thing that struck me the most was how the users were interacting with the system during their usability tests. For example, they mention how some people did not bother looking in the upper right corner (where the help icon was located) and that others, when searching, did not even try to look under menus in the top left corner. I would imagine (as well as hope) that this was extremely rare and that most people were able to find the icon in the right hand corner. Besides this, I found it interesting seeing the small evolution and the thought process that went into designing the help menu. However, I would have liked to have seen a more modern example - what are some of the best ways to put a help menu into an Android app? What are some of the best practices with this? While seeing this outdated Apple version helped in some ways, some times it is harder to relate to things (such as a person not looking in the corner for a help icon).

Tiffany Martrano 22:59:35 3/21/2016

I thought it was interesting how a lot of the things talked about in this article related to things we talked about previously in class. Such as making things simple for the user, and guidance easy. I thought it was interesting that people had trouble with images, and that the image icons caused confusion. It was cool to see how the development of this could be applied to a mobile application.

Chris Finestone 23:55:36 3/21/2016

It seems to me that HTML help screens became obligatory simply because michaelsoft was doing it too. Help menus have historically been of little use, as many target very specific problems. That said, it's difficult to develop help tools for more advanced users.

Alexandra Krongel 23:58:41 3/21/2016

I immediately recognized some of the initial development steps as part of strategies we've discussed for this class, like videotaping users and having them think aloud. It is cool to see a real-world example of the kind of design process we've discussed all term. The 'write minimally' guideline is an example of making choices between experienced and novice computer users. It may isolate totally new users to assume they will do tasks through exploratory learning. At the same time, one has to assume some level of competency to navigate to the help window.

Matthew Reinhold 0:03:09 3/22/2016

The reading shows a good read world example of how user testing can impact the final product. Without user testing, the functionality described relating to the Macintosh help system probably would have taken longer to reach a useful state for most users that need help.

Max Benson 1:05:57 3/22/2016

Designing effective documentation is something that seems to be overlooked pretty often, so it's cool to see a full-fledged iterative design process for a help system. This article highlighted some of the issues that I think can be difficult to detect by non-users, such as the organization of documentation, the level of detail with which that documentation is written, how that documentation is accessed by users, etc. By testing how effective users were when completing tasks based on the help system, the designers of Apple Help were apparently able to address these issues. I think that such testing of documentation would benefit many system developers who add help systems almost as an afterthought, without ever considering (beyond their own biased perspective) how helpful they'll actually be.

Daniel Hui 1:20:10 3/22/2016

The section on 'Usability testing and market research' makes me wonder whether or not different softwares analyze the data in regards to customers who use the help/index/tableofcontents functionalities of the software. This section recognizes that this data can be analyzed to help identify what problems people are having with the software. If software companies do in fact keep track of this what users need the most help with they will essentially have 'free' usability testing since they are given which parts of the software the users struggle the most with.

Adhyaksa Pribadi 1:41:46 3/22/2016

This seems to be very outdated. The Help menu in today's day and age usually goes unread. User Interfaces simply rely on their intuitiveness. As said in the article, if all else fails, the user is more likely to search for an answer by googling. A lot of the times, users need answers to achieve a specific task. Rather than going through the manual Users will go to forums because they will provide more of a concise answer.

Sarah Dubnik 2:16:35 3/22/2016

Like many of our readings, this one revealed some of the important steps in product design that I never considered too much before. It never occurred to me that so much testing goes into using help systems, though of course this make sense. I appreciated that one of the issues addressed by Apple help systems was the problem of switching layers; I always thought it was immensely inconvenient to have to switch back and forth between instructions and context, and I'm sure it causes many missed or incorrect steps, as mentioned in the reading. I also found it interesting that most users preferred to use the "do it for me" links to open programs and other similar tasks. Again, it makes sense to choose these links to speed up the process, but I thought it was important - and may say something about human psychology - that users would rather just get the task done than try to understand it in more detail. I also did not expect the section about removing unnecessary help: that users who never had to use instructions to complete a certain task would show the designers/writers that the instructions needed to be condensed more, removing superfluous steps and instead focusing on troubleshooting. I just never thought about the fact that instructions may be edited that way.

Luke Kljucaric 5:09:09 3/22/2016

Documentation for any software is an important part of any design apporach. If your user cannot use your software, where would they go to look for help without proper documentation? It is essential for any peice of software to have a good help manual that can help a user do the specific tasks they are trying to accomplish. A user manual should also be easy to use and not require a separate user manual resulting in some sort of endless loop of user manuals. I aggree with the fundamentals of this reading completely.

Dustin Chlystek 5:16:50 3/22/2016

I like the way that they designed their help section of the earlier Mac OS. I especially like goal 6. A minimalist approach to most problems is better. I hate when I am looking for help and I have to read a 10 page document to figure out something that could have been explained in a few sentences.

Yijia Cui 8:04:06 3/22/2016

This article presents the process of how Mac designs a good, easy-accessible online help for customers. The evolution of online help involves three aspects: the early research (five categories of questions), the design of apple guide, and the usability testing and market research. There are seven design goals for Mac online help: 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. During the process of user testing and design, the team aims to solve the problem common and provide better user experience to users. No wonder why Mac is easier to use than windows.

Nicholas Carone 8:05:53 3/22/2016

This is an interesting article about the iterative design process of the Apple Help system. The amount and depth of the usability testing and the market research performed in order to eventually get the best product to market is impressive, and one wouldn't expect it of such a seemingly small part of an operating system at that time. Also the way the team was able to take advantage of the internet for the Help system way back then is note-worthy to say the least. This is a fine example of how clearly defined design goals and extensive market research and testing can produce a forward thinking product launch and successful piece of technology.

Clark Nicolas 8:23:55 3/22/2016

I think this article was helpful in describing how design choices can make for a better user experience.

Andrew Lucas 8:28:57 3/22/2016

My first response is that despite the fact that all this effort went into help functions, I rarely use their Microsoft counterparts. Since Google's search function is so much more powerful than any help function, and any problem that is common to very many users has undoubtedly been answered in an internet forum, help functions are largely obsolete. With Windows 10, while Cortana is far better than past Microsoft search features, I still use her as a calculator more often than anything else, mainly because she is not connected to google. Again, even once you restrict help functions to things that can be found on Google, I am much more likely to read a Stack Overflow question than some expert-designed help document. I want a specific answer to my specific question as quickly as possible.

David Fioravanti 8:35:54 3/22/2016

I always found that "help" documentation on applications were never really helpful. The reason is that they would direct you to some general documentation that was really wordy or hard to find specifically what you are looking for. I liked how they mentioned about leaving out documentation on things that no one had trouble with figuring out how to do something, such as playing the CD Audio Player. I think this helps solve the problem of documentation being too wordry and can focus on having users find the help documentation that they are struggling with.

Nate Patton 9:05:55 3/22/2016

It was an interesting on how something so widely renowned and used has evolved. Sounds odd, but I thought how the help menu has evolved interesting. It started out as a question mark, and because that was a bad design and people didn't "notice" it, caused it to change.

Ishvaraus Davis 9:11:48 3/22/2016

The reading today involved an application that we've all used, the help functionality in a program. The reading detailed the ways in which to make this software successful and most effectively help the user. For example task automation can be done to create an easier and more fluid experience for the user, while simultaneously giving them more confidence and affinity for the software that they're using.