|
SIGDOC Newsletter
September 2007 :: Volume 8, Number 3
Features
- Member Responses on what is Design of Communication
- Part 1 Defining and improving graphic design services for information development deliverables
- From Simon Harper: A Joint conference proposal
- Responses to Simon’s Proposal
- Topics for a Panel Discussion
Member Responses on what is Design of Communication
By Rob Pierce
robertp@us.ibm.com
In previous Newsletter feature articles, I’ve shared some thoughts about what exactly falls within the bounds of what is termed “Design of Communication,” and began receiving responses from SIGDOC members who shared their input on the subject. Members continue to provide additional input which is included here.
Both of the responses included here are from members with a unique perspective on the visual, user interface (UI), and user experience perspectives in the design of communication.
Aidan Kehoe (in Ireland), works in software development for game development.
Steve Murphy (in Toronto) designs graphics for user assistance (UA) and the presentation of UIs that are intended to enhance the UA (and thus enhance the user experience) for software development tools. Steve, a graphics expert from IBM, provided the first installment of what he said will be a three part response to the question of what is DOC, from a graphics and visual perspective.
In addition, Simon Harper proposed the feasibility of having a conference in the future that included multiple SIGs, followed by several SIGDOC Board member responses. Because of the multidisciplinary nature of communication and design, Simon’s proposal is something that members should feel free to share their input on, before a plan is put into place for such a conference. Perhaps this can be a topic of discussion at this year’s Conference, even in the Panel discussion of which I will be one of the speakers. Members should feel free to suggest other topics for the Panel discussion, and I’ve shared a thread with David Novick on the topic following the section on Simon’s proposal from which I hope other members will share their input and join the discussion.
From Aidan Kehoe
Hi Rob,
I guess you'll get plenty of feedback from the traditional SIGDOC community with respect to your request.
One aspect of DoC is the application for user assistance. While this is covered by traditional SIGDOC and technical writing fields, I often see papers in the artificial intelligence (AI) and User Modeling areas that address user assistance.
This is a good review/introduction to that work: http://portal.acm.org/citation.cfm?id=606415
Some more input with respect to your thoughts about a book in DoC - I think that is a very good idea. I work in software development at Logitech, in the gaming area (middleware for various gaming platforms/consoles). Game development, as with areas such as DoC and HCI, is very much multidisciplinary. There was one book published recently in the game development area that did a good job in that it addressed a broad range of topics, perspectives, issues, and provided a good introduction/insight to newcomers in that field.
Here is the book reference:
http://www.amazon.com/Introduction-Game-Development/dp/1584503777/ref=pd_bbs_sr_2/002-2151732-9300047?ie=UTF8&s=books&qid=1184771112&sr=8-2
Different chapters are authored by people with expertise in specific fields, and the chief author (Steve Rabin) does an OK to job to tie together the different threads. HCI has a number of books in this style too, for example, http://www.amazon.com/HCI-Models-Theories-Frameworks-Multidisciplinary/dp/1558608087/ref=sr_1_1/002-2151732-9300047?ie=UTF8&s=books&qid=1184772175&sr=1-1
In my opinion this DoC community could do with such a text at this point in time. The books in that exist in the field could be considered somewhat dated (i.e. they typically originate in the technical writing/online help sphere) and would not encompass the more forward-looking SIGDOC vision you guys outlined at SIGDOC 2006.
Best regards,
Aidan
Aidan_Kehoe@logitech.com
From Steve Murphy
When I started to write you a letter for the SIGDOC newsletter, I didn't realize how much I had to say. When I actually put pen to paper, sort of speaking, words quickly piled up. To answer your call for participation, I am using myself as an example of a graphic designer's role and responsibilities through my tenure here at IBM. I am going to provide you my response in 3 parts. The first one I am providing to you, here, is “Part 1: Defining and improving graphic design services for Information Development deliverables.”
Thanks Rob for providing me this opportunity to participate in exploring the term "design of communication". The exercise should prove indispensable for our community as we move forward to an expanded understanding--one that reflects more closely what is currently being experienced in the industry.
I joined the SIGDOC community in 2002 to get better insight of industry practices that I could apply to my position as a graphic designer at the IBM Toronto Software Laboratory. At that time, I believe I was the only member that represented the graphic design discipline just when the definition of SIGDOC changed to "design of communication." During my time as an active member, I participated in Program Committees, attended Conferences, and wrote several papers on the subject of graphical information in documentation.
I started at IBM as a production graphic designer creating various images that were needed for software products, including: icons, diagrams, packaging components, and illustrations. By 1999, I was appointed Team Lead of the Information Development (ID) deliverables. Since 2002, my role and responsibilities changed to be more aptly described as an ID graphics specialist. My past experience and new role is the focus of my letter to you. By using myself as an example, my objective is to achieve a broader definition of a graphic designer's role in the design of communication paradigm.
Without getting into too much detail which would prove to be either mundane or irrelevant, I wish to share my long road to improving communication of graphical information.
back to top
Part 1 Defining and improving graphic design services for information development deliverables
By Steve Murphy
Having been appointed as the Toronto Lab Media Design Studio (MDS) team lead for ID and packaging deliverables serving over 100 writers and thousands of pages of documentation, I needed to first bring order to our "house." The graphics (which included screen captures, concept diagrams, flow charts, and syntax diagrams) from MDS were created
- In isolation from other product documentation (what I would call the "silo" effect) by numerous graphic designers who did not consult one another
- Inconsistently from product release to product release
- Without a standard design style
- Without a comprehensive usability practice
- With no means to properly store and record ID requests
My initial responsibility was the business aspect of graphic design services. My manager cited two clear goals to be met by a certain period of time: reduce our error rate and improve turnaround time. As a business analyst of sorts, I donned my efficiency hat to deliver much needed changes. With the assistance of my core team members, we set on improving our business process and productivity. As part of my early years, the following list can considered as some of graphic designer skills:
- Create a standard method for storing graphic files in server directories.
- Define core mission for the delivery of quality deliverables for ID.
- Create a request database for:
- Receiving ID graphics requests.
- Tracking requests through the production cycle.
- Receiving pertinent details in requests to map out the file storage directory structure.
- Forecasting upcoming projects.
- Mining data to detect trends in graphic usage and frequency, and in problem determination.
- Implementing a built-in quality checklist.
- Receiving final approval from the requestor to complete the creation cycle.
- Define business process for quality assurance which includes globalization and ISO standards.
- Eliminate low-valued services to focus on the mid to high value ones.
- Identify areas to expand our graphic design knowledge and to assist other communities such as ID.
In this first stage of creating ID deliverables, the business aspect of creating graphics was defined and refined to improve efficiency, quality, and production cost. In the aftermath of the overhaul, MDS was then able to manage a high volume of requests. An example of the success of the first stage achievement is the fact that by the end of 2002, the MDS ID request database recorded 383 requests totaling 1149 created or modified diagrams and 1213 screen captures file conversion or annotations.
The wealth of information from the database was wonderful from an empirical data and business point-of-view. However, it does not immediately relate to the idea of design of communication, or does it? I have yet to write anything about design style, usability, accessibility, or other relevant topics. As I look back on those formative years, the time and effort spent in the first stage was essential to move the ID graphic design team forward. Without the attention to the internal working of the team, much time would have been spent tending to the production machine depriving the team the opportunity to collaborate in the formation of best practices and to solidify better interaction with ID teams. Armed with data pulled from the database and with good business practices, MDS planned for the second stage of improving the communicative potential of ID graphics.
It is worth mentioning that at this point the ID graphic design team was mostly isolated from collaborating with other communities such as ID and User Centered Design (UCD). MDS provided a service of simply recreating images according to ID direction with little room for exchanges of ideas. We were not considered a partner in the development of technical documentation.
Part 1 proved that MDS could create ID deliverables quickly, efficiently, and nearly error-free. But how well were we measuring up to the quality of information? Were the graphics truly useable?
Part 2 will explore the creation of a common visual style and best practices of ID deliverables, the burgeoning partnership with ID and UCD, and the collaboration with the cross-site graphic design community.
Regards,
Steve
Steve Murphy
Illustrator/Media designer
8200 Warden Avenue, C1-255
Markham, Ontario L6G 1C7
srmurphy@ca.ibm.com
back to top
From Simon Harper: A Joint conference proposal
Hi there, I'm General Chair for SIGWEBs Hypertext Conference and SIGACCESSs ASSETS Conference as well as being on the HT Steering Committee and Secretary/Treasurer for SIGWEB (and an Executive Board Member).
I'm Contacting:
SIGWEB regarding the Hypertext Conference;
DOCENG regarding the Document Engineering Conference;
SIGDOC regarding the Design of Communication Conference;
I'm also cc'ing:
SIGACCESS regarding the Assets Conference; and
SIGCAS regarding a possible Society Conference/Workshop
It seems to me that we all have a common theme of communications in some way running through our conferences. Theses are all small sized and community driven, they all take place in the Autumn/Fall, and the Early-Bird pricing for ACM members seems to be constant across these conferences at around the 400-450 USD mark.
I propose that for 2009 we look at federating HT, DOCENG, and SIGDOC - and that if successful we add ASSETS and SIGCAS in 2010. By federating, all I mean is grouping together in the same place, running on consecutive days, and providing a discount the more conferences are attended. For the conference I see benefits of increased revenue, decreased costs of room rentals A/V etc, larger booking discounts, and increased submissions. For attendees I see benefits of cross-pollination, increased attendance (as there is only one airfare and hotel night 'slack' at each end), increased submission possibilities to multiple conferences that all cross-cut.
By grouping 3-5 conferences we may suffer from conference burnout and also some slack between conferences if the attendee only wishes to attend conference, say, 1 and 3. The first argument can be countered by looking to, the WWW conference, SIGGraph, and CHI all with week long conferences stretching into weekends who seem to maintain numbers. The second argument still means there are significant airfare savings - also the benefits of co-location means that 1 paper in one conference would pay for attendance at all of the federated conferences from a University accounting perspective, and a nice day or two day rest in the middle.
I do not propose that any conferences are amalgamated or joined in any way, and each would keep its general and program chairs etc, it's autonomy of pricing, etc. The only thing that would change is that a new federated chair spanning all conferences would sort out options for the conference location and submit the initial ACM PAFS and TMRF Part 1 for all conferences. The general chair would budget as normal the TMRF part 2. All requirements would then go through to the Federation Chair to co-ordinate on the ground - but everything else would be conference specific. Only the registration system would span all conferences to take into account bulk conference pricing.
I think that in a world where people are pushed for budgets, where disciplines cross-cut, where flights can be cut from 6-10 to 2, and hotel room slack reduced by 6-10 room nights, placing small conferences so they can compete with larger ones seems to me at least the right way to go.
I'd be interested to know you thoughts on this.
Best Regards,
Simon
Dr. Simon Harper
University of Manchester
Information Management Group, School of Computer Science
2.44 Kilburn Building, Oxford Road
Manchester, M13 9PL, United Kingdom
simon.harper@manchester.ac.uk
http://www.cs.man.ac.uk/~sharper
Human Centered Web Lab: http://hcw.cs.manchester.ac.uk
Diary (iCal): http://hcw.cs.manchester.ac.uk/diaries/SimonHarper.ics
back to top
Responses to Simon’s Proposal
Here are responses to this proposal so far from some of the SIGDOC board:
- I think this is an interesting proposal and am cc'ing people in our SIG who I think should also be able to provide input. If the consensus is to go for it, then coordinating the plan will be the next step and you might have ideas on how to arrange some of that, including a location if you have one in mind.
- Yes, this is absolutely a fine idea, albeit one that takes quite a bit of work and coordination. If the conferences are all ACM conferences, that makes it much easier. SIGDOC ran a joint conference in 2000, I believe, with IPCC, which is part of IEEE here in the US. The two greatest hurdles were the negotiations between ACM and IEEE on conference fees and schedules for announcement, and finding a venue whose financial requirements were acceptable to both sides. This was a combined conference with sessions on one schedule, multiple tracks. The conference ran for 3 days, with tutorials on the Sunday preceding the conference.
I think, however, that rather than having multiple conferences running on consecutive days (let's say 3 conferences each of 3 days = 9 days), it would be much better for the conferences to run in parallel. Many people cannot take the time to be out of the office for more than roughly 3 days; it would be most unusual for someone to be able to take 2 weeks for back-to-back conferences, and I doubt if that would be a Good Thing. Even a 5 day conference can produce conference burnout. Running three conferences in parallel would present a significant scheduling challenge, but is certainly possible. What would be really helpful would be an online conference schedule that attendees could check at the conference with searchable keywords to find sessions at all conferences that address their interests. For example, say an attendee wanted to see sessions that deal with virtual reality, entering that phrase should find all sessions at all the conferences that have that phrase/keywords in their session abstract or keywords. The attendees can also glean this information by reading the session proceedings, but if they sign up for only one conference, they will not see the other conference programs.
Definitely worth pursuing.
- I agree about running the conference in parallel over 3 days. Simon, if you are in El Paso, perhaps we can discuss some of this proposal in more detail. We have a board meeting on Sunday afternoon, else we can discuss later in the week, at the conference. As Kathy stated, we'll need quite a bit of coordination, communication, and leadership in making this thing happen! Simon, are you a SIGDOC member, and if so, are you interested in being conference chair or co-chair for 2009? Or, should we try to identify a SIGDOC 09 conf. chair who will work with you?
We'll discuss some of this in October, if not sooner.
- Marvelous idea ... and ambitious! Excellent points made about the benefits of having all the conferences be "coordinated" under the umbrella of the ACM. Ben Shneiderman's Conference on Universal Usability in 2000 was coordinated by several ACM Sigs and I'm sure he'd be willing to share some of the opportunities and challenges presented by that large effort.
Of course choosing a representative city would also be an exciting discussion -- for example, having several hosts working together would allow us to consider a "resort-type" location, especially if folks were encouraged to submit multidisciplinary work across "strands" for cross-fertilization over the three days (assuming we safe-guarded against similar submissions). Numerous issues to talk about!
back to top
Topics for a Panel Discussion
I was asked to be part of a Panel discussion that will address some aspects of what is “DOC” and want to first share a thread of emails between myself and David Novick on how SIGDOC can continue to be the best meeting of the minds for academia and industry for the design of communication.
I asked David Novick if I could share an email thread we had recently, and he said, "Absolutely! And if there’s anything that I can do move the locus of contributions more toward the meeting point of industry and academe, by all means please let me know."
Here's the gist of what we discussed and what will form a portion of the panel discussion at SIGDOC 07.
Rob:
One thought on what to discuss might include how SIGDOC leverages the "meeting between academia and industry." I think people in academia are interested in the real-world use cases and details of information design, development, and delivery, but you probably see a lack of academic rigor in how some of us (such as I) in industry try to present our findings.
I've listened to references to how concepts that are being utilized in the real world stem from research "in the 80s," as if the information is old hat - user experience concepts for example, or usability studies. It may be true, or not, and would be good material for a panel discussion.
Another example is from last year's panel - I made a point about metadata and feel that it was somewhat dismissed by a comment that there were many topics that were not researched by people in industry so that while the information was well known in academia, and not at all new and innovative, such as metadata, those in industry treated some of these things as new and innovative. Possibly true, but in industry metadata is currently a huge area in the real world in terms of all kinds of new innovations being designed and implemented in storage and database technology (not to mention in the area of DOC).
I think one of the of the key differences between academic findings and industry applications is the difference between there being research performed and published, and the actual design and implementation of solutions that make use of those concepts and findings. I think I might also be stating something obvious to you!
But, perhaps a discussion on this dynamic, which could be viewed as a healthy tension, might be quite beneficial to our members and to the strength of what is in my mind one of the best aspects of SIGDOC, namely, the meeting between academic research and real-world industry findings.
David:
My own research has over the last few years gone in the direction of looking directly at the user experience, including simply observing users at their work. Part of my motivation in doing this is a perception that much of “academic” work on DOC (a) isn’t helping people that much and (b) lacks fundamental understanding of what people do and how. Oddly, Industry and academia may not have the same vernacular, but both have something valuable to hear. Indeed, that’s one of the points of a panel, where everyone—panelists included—can learn from each other.
The idea to include experience reports was mine. I was motivated by my perception that SIGDOC was increasingly academic, and I wanted to begin to reverse this course. The call for experience reports was based on the SIGCHI model, which had achieved reasonable success in improving integration of industry folk and practitioners into their conference. I think I understand your point about more substantive contributions from industry. It would help future conferences if you could suggest better means of encouraging this sort of participation. Your thoughts?
Rob:
Thanks for your note - and I appreciate your sharing these thoughts. I think this would make good material, as stated before, for a panel discussion, and it might be interesting to see what our members thought about ideas on how to encourage more industry participation, and on how they view the writing and publication of experience reports, which I think is a very good idea.
back to top |
