A directory of resources inthe field of technical communication.

Hughes, Michael A.

59 found. Page 1 of 3.

About this Site | Advanced Search | Localization | Site Maps
 

1 2 3  NEXT PAGE »

 

1.
#37946

Accessibility: Some Honest Talk

I'm not saying we shouldn't do it; I just wish the conversation about accessibility would be more frank when it comes to the opportunity costs and real costs to implement it. And I'm embarrassed by my own petty frustration in having to accommodate someone who has a real beef with the world and a legitimate cause for frustration.

Hughes, Michael A. Humane Experience, The (2011). Articles>Accessibility

2.
#10354

Active Learning for Software Products   (peer-reviewed)   (members only)

This article shows how principles from the fields of adult learning and situated learning can be applied to the method of Instructional System Design to create classroom-based training for software products. These principles and methods do not need to be antithetical; rather, they can complement each other to create instructional strategies that incorporate context-rich activities for work-oriented instruction.

Hughes, Michael A. Technical Communication Online (1998). Academic>Computing>Instructional Design>Software

3.
#37035

Analysis of a Diagram

Just because you like something you created, it doesn't mean it's any good or you have a big ego. But it can be useful to stop and ponder something you did that you particularly like--so that you can understand your own design priorities a bit better.

Hughes, Michael A. Humane Experience, The (2010). Articles>User Experience>Technical Illustration>Visual Rhetoric

4.
#28905

The Anatomy of a Help File: An Iterative Approach

This article presents an approach to Help file design that focuses on creating a task-centered user experience and accommodates an iterative development strategy. This methodology allows the introduction of user assistance into early test phases--not only getting earlier validation for its accuracy, but also supporting quality assurance testing by serving as the test scripts for interactions with the user interface. This approach can also be a self-contained strategy--that is, one that allows an iterative approach to user assistance development even if the rest of product development operates on a waterfall model.

Hughes, Michael A. UXmatters (2007). Articles>Documentation>Methods>Help

5.
#34468

Architecting User Assistance Topics for Reuse: Case Examples in DITA

In this column, I’ll review what user assistance architects mean by reuse and what its benefits can be. I’ll then describe some different scenarios for reuse and offer guidelines that user assistance architects and information developers can follow. My examples show how DITA (Darwin Information Typing Architecture) can be an effective reuse framework. But the principles I discuss go beyond DITA, and you can apply them to any structured information framework or toolset.

Hughes, Michael A. UXmatters (2009). Articles>Content Management>Documentation>DITA

6.
#37943

Assume an Amorphous User

There are a couple of models that can guide us in dealing with negative scenarios—meaning scenarios that deviate from the happy path and result in user failure. One model, negative scenario testing, comes from quality assurance; the other, negative case analysis, from qualitative research.

Hughes, Michael A. UXmatters (2011). Articles>Usability>User Centered Design>Personas

7.
#32088

Cognitive Tools

I've long been an advocate that teaching technical communication without teaching tools is like teaching art students about painting without talking about brushes.

Hughes, Michael A. User Assistance (2008). Articles>TC>Software

8.
#35572

Comic Relief

As part of a project I'm working on, we are going to develop a comic-style collection of user scenarios to help communicate best practices around a security service we are offering.

Hughes, Michael A. User Assistance (2009). Articles>User Centered Design>Technical Illustration>Personas

9.
#34867

Cop vs. Consultant

Pay attention to the legal requirements and translatability issues, not only in your own documents, but in the documents of other groups like marketing and engineering. It's an area where we add value.

Hughes, Michael A. User Assistance (2009). Articles>Intellectual Property>Trademark>Technical Writing

10.
#37686

Dashboard Design 101

The explosion of information that analysts and executives must consume, as well as the increasing variety of sources from which that information comes, has boosted the popularity of information dashboards. Modeled after the dashboard of a car or airplane—which informs its operator about the status and operation of the vehicle they’re controlling at a glance—dashboard user interfaces provide a great deal of useful information to users at a glance. Typically, the role of an information dashboard is to quickly inform users and, thus, enable them to take immediate action.

Hughes, Michael A. UXmatters (2010). Articles>User Interface>Information Design>Visual Rhetoric

11.
#37947

The Degentrification of User Assistance

My job right now as the UX architect on the project is to translate these high level requirements into scenarios and the starts of stories so that my Engineering cohorts can estimate the various features. So with apologies to my technical writer friends, I have embarked on creating a design that will make it easy for SMEs, who have insight about how to get value out of our portal and services, to pass that insight along. I want it to be easy for the SME to post, and easy for the user to get to it.

Hughes, Michael A. Humane Experience, The (2011). Articles>User Experience>Technical Writing>Help

12.
#35758

Dip Management

We go from one moment being very proficient with our current tool or technology to being pretty stupid with a new one. So the basic question every user ends up answering is Was the improvement labeled "B" worth the pain and humiliation labeled "A?"

Hughes, Michael A. User Assistance (2009). Articles>Technology>User Experience

13.
#31870

Excel Hacks for Help Writers

One of my earlier careers was in manufacturing management, and it grounded me in the principles of project planning and management. When I moved into technical communication, I brought my project management disciplines with me, and I embraced the prevailing tools of my new profession. I dutifully produced documentation plans in Microsoft Word and supported them with detailed project plans in Microsoft Project. However, the problem is that—like bad relationships—these artifacts never gave back results that were sufficient to reward the effort I put into creating them.

Hughes, Michael A. UXmatters (2008). Articles>Documentation>Technical Writing>Microsoft Excel

14.
#29926

The Help Landscape: A Mile Wide and 30 Seconds Deep

Two questions any writer must deal with are: 'What do I write about?' and 'How much do I say about it?' Essentially, these questions deal with the scope and the depth of a document. Technical communicators have a tendency to want to document a topic as completely as possible, and we carry this instinct with us when we architect and write Help files. In this column, I challenge that prevalent instinct and offer an alternative way of thinking about the scope and depth requirements of Help systems. The benefits of this approach are, I hope, better Help for users and, for our clients and employers, a more efficient use of technical communicators' time. First, I'll discuss three principles that underpin my perspective, then I'll give some practical advice about writing Help that people will actually use.

Hughes, Michael A. UXmatters (2007). Articles>Documentation>Help>Online

15.
#30818

Hockey Sticks and User Assistance: Writing in Times of Resource Constraints

If you have all the resources you need, do the very best job you can in all respects. But if your resources are tight, ask yourself whether you are writing the essential stuff at a level of quality users will notice. Also, ask whether the value of the documentation you are producing aligns with the economic pressures on your company.

Hughes, Michael A. UXmatters (2008). Articles>Writing>Technical Editing

16.
#34446

How to Improve the UI--Really!

A colleague has made me realize that user assistance writers are codependents of bad UI design. Because we explain how the UI really works, we somehow leave our developers and companies feeling like they're "covered" when the users have a bad experience.

Hughes, Michael A. User Assistance (2009). Articles>User Interface>Documentation>Technical Writing

17.
#28658

Instructional Text in the User Interface: Some Counterintuitive Implications of User Behaviors

User assistance occurs within an action context--the user doing something with an application--and should appear in close proximity to the focus of that action--that is, the application it supports. The optimal placement of user assistance, space permitting, is in the user interface itself. We typically call that kind of user assistance instructional text. But when placing user assistance within an application as instructional text, we must modify conventional principles of good information design to accommodate certain forces within an interactive user interface. This column, User Assistance, talks about how the rules for effective instruction change when creating instructional text for display within the context of a user interface.

Hughes, Michael A. UXmatters (2007). Articles>User Interface>Help>Online

18.
#36129

Management as a Discourse Community

Every discourse community has its jargon and its cliches that are important vessels for cultural values and which are rich in meaning within those communities. Discourse community itself is a jargon-like word that I'm sure seems odd to someone not familiar with communication research.

Hughes, Michael A. Humane Experience, The (2010). Articles>Business Communication>Management

19.
#18534

Managers: Move from Silos to Channels   (PDF)

Advocates restructuring technical communication departments to eliminate 'silos'—isolated groups within the department—and develop 'channels'—a cooperative grouping of workers and teams through which information about a product can flow.

Hughes, Michael A. Intercom (2003). Careers>Management>Collaboration

20.
#13602

Moving from Information Transfer to Knowledge Creation: A New Value Proposition for Technical Communicators   (peer-reviewed)   (members only)

This article first reviews the current literature that addresses the value of the technical communicator. Whereas those discussions focus on what is delivered to the user (reader), this article examines the value the technical communicator adds by creating organization (internal) knowledge. The article then examines the philosophical underpinnings that support any discussion of knowledge and defines the role of technical communicators as creators of knowledge. Finally, it offers an expanded value proposition for technical communicators and examines its practical implications.

Hughes, Michael A. Technical Communication Online (2002). Design>Information Design>Content Management>SMEs

21.
#14255

Moving from Information Transfer to Knowledge Creation: A New Value Proposition for Technical Communicators   (peer-reviewed)   (members only)

This article first reviews the current literature that addresses the value of the technical communicator. Whereas those discussions focus on what is delivered to the user (reader), this article examines the value the technical communicator adds by creating organization (internal) knowledge. The article then examines the philosophical underpinnings that support any discussion of knowledge and defines the role of technical communicators as creators of knowledge. Finally, it offers an expanded value proposition for technical communicators and examines its practical implications.

Hughes, Michael A. Technical Communication Online (2002). Articles>TC>Assessment

22.
#10319

Online Documentation in Reference-Based Instruction: A Practical Model for Integrating Help Systems Into Product Training   (peer-reviewed)   (members only)

Companies can improve customer satisfaction while reducing training time and product support costs by integrating online documentation with product training. Online documentation can be designed to be not only the reference at the point of use but also the primary instructional medium used during training. This use of the online documentation during training increases user acceptance of it and helps develop the required skills for its use. This expanded role for online documentation provides new opportunities for technical communicators to add value to their roles within their companies. This article defines reference-based instruction and outlines its benefits. It describes how reference-based instruction can be incorporated into an instructional system design (ISD) and provides specific examples of learning objectives and student exercises. It lists guidelines for how to structure usability tests for Help systems, and finally, it advises how technical communicators can use reference-based instruction to ex

Hughes, Michael A. Technical Communication Online (1997). Articles>Documentation>Instructional Design>Education

23.
#34709

Online vs. On-Line

This isn't a discussion of hyphenated vs. not hyphenated. It examines the difference between putting a PDF file on the Internet (what I call an on-line document) and having a truly electronic Web presence for that content (what I call an online document). Unfortunately, the two often get bundled together.

Hughes, Michael A. User Assistance (2009). Articles>Web Design>Publishing>Adobe Acrobat

24.
#28019

A Pattern Language Approach to Usability Knowledge Management   (PDF)   (peer-reviewed)

Knowledge gained from usability testing is often applied merely to the immediate product under test and then forgotten--at least at an organizational level. This article describes a usability knowledge management system (KMS) based on principles of pattern language and use-case writing that offers a way to turn lessons learned from usability testing into organizational knowledge that can be leveraged across different projects and different design teams.

Hughes, Michael A. Journal of Usability Studies (2006). Articles>Usability>Knowledge Management>Language

25.
#33154

PDF Manuals: The Wrong Paradigm for an Online Experience

Let me describe a familiar user assistance experience. A user installs a new application, and when the user wants Help, the application directs her to the user documentation on a Web site or CD-ROM. What the user finds there is a PDF file containing the manual—or a collection of PDF files, representing a library of manuals, including a user guide, configuration guide, troubleshooting guide, and various references. And the layout of each of these PDF manuals is exactly the same as if it were a printed book. This raises an interesting question: If we’re giving manuals to users to read online, why do we design and write them for paper?

Hughes, Michael A. UXmatters (2008). Articles>Documentation>User Experience>Adobe Acrobat

 
 NEXT PAGE »

 

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon