by Julie Fisher by Kim Campbell by Bernadette Longo |
![]()
Technical Communicators: How Do You Contribute to Interface Design?
A summary of participant’s idea market contributions
by Julie Fisher
Research I recently conducted highlighted the high level of involvement technical communicators have in the design of user interfaces. Most technical communicators make some contribution, ranging from comments to developers if, from their perspective, something on the interface does not work, to actually designing the interface elements. This led me to propose a question for an idea market for IPCC 98 in Quebec. The question I asked participants was:
How do you, as technical communicators, contribute to interface design?
The question generated a lot of interest, with technical communicators sharing their experiences and providing many examples of what they do and how they contribute. Here is a summary of the points they raised.
Consistency. This proved to be a major issue and one that particularly concerns technical communicators. In many development projects, different programmers work on different aspects of a system and each programmer is responsible for the screens for their part of the system. Often no one sees the whole system until it is nearly finished. Participants suggested that often the technical communicator, during the process of documenting a system, is the first person to see the system in its entirety. The technical communicator sees the inconsistencies and is in a position to draw them to the attention of the developers.
Consistency of spelling was highlighted as a problem, particularly with systems which might be used in both Canada and the United States. Which spelling convention is to be used? The participants said that often no decision is made on which spelling to use. The interface then ends up with text that uses both spelling conventions!
A third issue was the lack of consistency between the printed information and the wording on the screen. This, articipants suggested, happens when systems change after the documentation has been written. However, the technical communicators said they are raising these issues with developers and encouraging developers to involve them earlier in the process.
Contributing to Different Interface Elements. One participant described how she had been involved in the development of a menu structure. She suggested that the menus could be simplified and should contain fewer options for users, and she also helped in the design of the links. Another person mentioned that they helped with the design of the system workflow, the order in which users perform certain actions. This technical communicator helped to ensure that the system workflow more accurately mirrored the users’ workflow.
Other technical communicators said they suggested changes to icons. A good-news story for technical communicators was that in one case the developer, after usability testing the icons of a new system, concluded that they were not working and called in the technical communicator to help. The technical communicator of this system said that usability testing the documentation had led the developers to test the system more thoroughly. The developers were pleased with the results and now they involve the technical communicator more.
Error Messages. Not surprisingly, these were raised as a problem by many participants. Some said they are now consulted by the developers and have been involved with changing poor messages. Using technical communicators for consultation, one technical communicator said, was helped because users were complaining and pointing out problems to the developers. Another technical communicator said that where there are space restrictions on the error message text, then it is even more important to involve the technical communicator to ensure the best minimal messages are constructed.
How Do You Get Developers to Listen? This question was asked by many participants. One suggestion was to explain to the developers why a particular part of the interface does not work for users. For example, why flashy graphics and scrolling text do not work on a Web site. Explaining to developers, in a positive way, saying "this is better" rather than"this is bad", often is a more effective way to capture the developer’s attention and interest.
A number of participants raised the issue of web site design and how technical communicators have a role to play. The point was made that often businesses get caught up with wanting to go online but pay little attention to who their audience is and why they want a web site. In some cases it may not be appropriate. A technical communicator pays attention to these things and will stress to those developing web sites that it is the information that is important, not the flashy graphics.
Technical communicators are skilled in audience analysis. This is a useful skill in Web site design because many sites are developed without an understanding of who the audience is. For example, if the Web page is to describe a shopping site, then there is a need to understand shopping behaviour. If the site looks inviting, then the user is more likely to "stay".
-------
Idea markets are a great way for participants to share their experiences with each other and with the activator. I learnt, from those who stopped to talk with me, more about how technical communicators are contributing to interface design than I knew before the session. It is not necessarily a new area that technical communicators are moving into, but it is one that developers are starting to notice and appreciate the contribution you, as a technical communicator, can make.
Making Research Usable
Notes from the Idea Market at IPCC 98 in Quebec
by Kim Campbell
On Friday 25 September 1998, Laurel K. Grove and Kim Sydow Campbell conducted a session regarding ways that both practitioners and academics could gain better access to the results of technical communication research.
They led into the discussion with the following questions:
Responses came from both academics and practitioners, from both sides of the Atlantic. All find it difficult to make adequate use of research results, for various reasons. One particular disincentive to using research results is the current scattering of information. For instance, Sage publishes Communication Abstracts (on paper) but that publication neglects many technical communication journals. Some practitioners mentioned that they rely on publications by the Society for Technical Communication, although they realise that those publications represent only a fraction of all that might be relevant.
Most researchers rely on electronic services, such as Web search engines, Uncover (a research database), and First Search (another research database). Altogether, the participants reported, there are a dozen or so relevant databases. To be thorough, a researcher must use several, because although there is some overlap among them, there are also gaps between them. However, many people use only one database (often the one they learned first) and never go beyond it. Even then they find that many of the sources that their searches identify are irrelevant or inapplicable.
Grove and Campbell asked what would better meet technical communicators' needs. One model suggestion was a reference librarian service. With the trend in libraries toward electronic communication and away from staffing, an alternative suggestion was a database. If they are to use a database, technical communicators would like to be able to select on dates or years of interest, language, and keywords, then obtain every abstract meeting all the selected criteria. They could settle for that set of abstracts, or if necessary fine-tune the search further.
Several payment options were suggested. For instance, the service could be set up as a subscription, with password protection. For an annual fee, subscribers would be allowed as many searches as they want. Alternatively, payment could be by the number of abstracts or articles downloaded. A price of $5-10US per usable abstract was suggested as reasonable. Accepting advertising on the database could subsidise costs, as could support from professional societies. (In another session, Tom van Loon suggested that journal publishers would be responsible for collecting payment per downloaded article and then would pay a royalty to the database according to the number downloaded.)
The specific content to be included is a matter for debate. Some technical communicators would be satisfied with abstracts rather than full articles; some said an annual annotated bibliography or review articles would meet their needs. A number of other questions were also not resolved, such as those concerning form of delivery (electronic versus paper), coverage (annual versus archival), and language (original language only or translated to major languages).
In discussing ways to disseminate research results, the discussion inevitably shifted to the value of research. One problem is that practitioners need quick turnaround from project inception to usable results. They argue that research conducted in academia is generally outdated by the time it is published. Practitioners contend that research lags practice, and then publication lags research. For this reason, they often look to the work of their colleague practitioners rather than to academia for answers.
With that and the question of timeliness in mind, they suggested that any database should include the white papers being published on company white pages, because such work tends to be on the cutting edge of practice. Although such papers would not have been through the quality control implied by the peer review process, practitioners believe that the peer review process within technical communication has been so weak as to be meaningless; academics are generally not hard enough on each other to really eliminate poor quality. On the whole, practitioners said that they were simply concerned about finding out what works, without regard to the underlying reasons sought by academia. They thought that a specific trade journal could inform them without the common problem of being overly academic (Campbell referred them to the "Interface" section of the IEEE Transactions on Professional Communication, which supports this purpose).
Researchers expressed other dissatisfactions. They noted that technical communicators, both practitioners and academics, tend to look within their own field to the exclusion of others. Thus much relevant work that may be going on in associated fields beyond technical communication is likely to be missed entirely. They were hopeful that a more inclusive database could help solve that problem.
Grove and Campbell conclude from their presentation that there is sufficient reason to explore the feasibility of establishing some form of abstracting service for the technical communication field. At this stage, two questions must be answered:
Grove and Campbell plan to survey technical communicators to assess the demand for an abstracting service and to interview information systems providers to estimate the cost of satisfying that demand. In this way, more authoritative information can be used in developing a proposal that can then be presented to potential supporters within the IEEE and its Professional Communication Society, at the Society for Technical Communication, and elsewhere.
Blurring the Boundaries:
Bringing Students, Faculty and Business Partners into Mutual Learning Spaces
Notes from the Idea Market at IPCC 98, Quebec
by Bernadette Longo
This idea market session explored five questions:
1. How can teachers negotiate, mediate, and moderate sometimes conflicting expectations and needs in an industry/academic partnership for classroom projects?
2. How can teachers design projects that enhance course content when projects encompass so many diverse skills and levels of knowledge?
3. How can teachers and industry partners schedule classroom projects, when industry schedules tend to be so much quicker than academic schedules?
4. What skills do industry partners want students to learn from industry/academic partnerships?
5. How can these partnerships facilitate multi-directional communication among all participants?
In response to question 1, participants suggested that expectations be negotiated early and be thought of as a contract between the class and industry partner. Some discussion followed on the following management and pedagogical issues raised by this contractual model:
• Are students to be treated the same as employees? There was a consensus that students cannot be thought of as employees because they are not compensated for their project work, neither are they contractually bound to work a set number of hours on the project.
• Meeting production deadlines cannot be seen as equal to learning. Therefore, production of a deliverable cannot be the only course objective in this type of partnership. Student learning must remain the focus of the classroom.
In response to question 2, participants generally agreed that course projects should be as close to “real life” as possible. In other words, these projects should mirror industry situations, demands, and skill levels wherever possible. In this type of partnership, it is the teacher’s responsibility to ensure that projects help students to meet course learning objectives and enhance course content. In this case, teachers and industry partners need to negotiate expectations early, as recommended in the previous question. In these negotiations, teachers need to keep their course objectives in mind and shape projects that will work with those objectives. If teachers and industry partners cannot accommodate course objectives, the resulting project will probably not be beneficial to student learning.
In response to question 3, participants did not resolve this scheduling issue. There was discussion on the difficulty of accommodating industry and academic schedules, raising the possibility of multi-semester or multi-quarter projects. In those cases where teachers need to plan for projects months in advance of the course, industry partners may only be able to offer a limited range of projects, since industry turn-around can be on a tighter schedule than academic terms.
In response to question 4, participants agreed that students need to learn directly applicable job skills from these partnerships. Many participants saw these industry/academic partnerships as an effective way to teach students current industry practices. They are also an effective way to help teachers stay current with industry practices.
In response to question 5, participants saw these partnerships as extending beyond one semester and one classroom. Instead, they recommended that industry/academic partnerships become an ongoing relationship that can flourish in areas other than classroom partnerships. Some of their suggestions for more permanent partnering include the following:
• Talk often, not just before or during a course. Make the partnership a routine aspect of academic and industry life.
• Create corporate advisory boards for professional communication programs and keep in close contact with these boards. Give board members meaningful roles to play in the academic program.
• Explore the possibility of industry partners contributing financially to the academic program in ways such as equipping facilities to enable in-class partnerships.
• Collaborate on grant proposals to provide a framework for ongoing partnerships.
• Create opportunities for industry representatives to teach university courses.
• Create corporate internships for faculty to work in industry settings.
• Work with professional associations to provide organizational support for ongoing partnerships. Request that a Web site for industry/academic partnerships be developed and maintained by a professional association.
• Use industry partnerships as focus for cross-disciplinary projects.
In these responses, participants emphasised the need for industry and academic partners to maintain routine and ongoing lines of communication among industry representatives, teachers, and students. These open lines of communication will provide the most effective pathway for ensuring that the needs of all partners are addressed and accommodated to the best of their abilities. This communication pathway can lead to the spaces where mutual learning can occur for everyone involved.