Wednesday May 09, 2007

What I really learned from JavaOne ...

... is that it is hard to find information. Person comes up to the Sun Studio booth at JavaOne asking if the Sun Studio C compiler has a compiler option similar to an option in gcc. Well, let's look at the compiler documentation for Sun Studio 11. I know we had worked on a list of compiler options by language and platform. Go to Sun Studio 11 documentation page on developers.sun.com. Can't find the link. Use Google searching for Sun Studio compiler options on developers.sun.com, which points back to the original docs page where I couldn't find the link. It's here somewhere, let me keep looking. Meanwhile, the person who asked the question is looking on.

Another person offers to join the hunt. I know we have compiler options in the Sun Studio books on docs.sun.com. So this person starts to navigate through the convoluted path looking for the Sun Studio docs collection. Oh dear, there is no link to Sun Studio from the docs.sun.com main page. Used be a bit easier to find the Sun Studio docs. Watching the workarounds this person is following to navigate through the docs.sun.com site leaves me thinking how many workarounds have people implemented to try to get to our docs? How many people give up? How many people don't even know that we have information on these topics?

By this time, a third person steps in to say this is taking way too long. I just want to show a demo of the Performance Analyzer.

Later, I found the link to the page I was looking for (http://developers.sun.com/sunstudio/documentation/ss11/opts/index.html) through another Google search.

One theme of the JavaOne keynote was connecting everybody through devices, information, services, software. For us to do that, we need to look at the information needs of a broad range of people. How can we develop and deliver information that meets the needs of a person using a cell phone to a person using a large-scale system behind a firewall at a secure site with no internet access? If we are to be successful here, I'd like to think we at least have a handle of making it easy for people using the current devices we support to access the current information we provide. Will be some interesting discussions here.

Part of my message as we plan for these changing business needs is that it is of no value to create information people cannot find. It is of no value to have sites where you can't find the information you need. It is of no value if the information is not in a form that you can use. It is of no value if the information does not help you answer the questions you ask or help you to solve the problems you need to solve.

This is a partnership between the people within Sun and the communities we support with our information. The real value in the information we provide is realized when you can find and use that information, and that information has met your needs. Until that time, it is just a link in a list.

Saturday Feb 03, 2007

Changes in Information - Change is Change

What are we doing now for developing technical information? What should we be doing on developing and delivering technical information? What are the changes in information needs that are affecting us that we should be responding to?

I have been looking at how to categorize some of those changes, and in the process, my thoughts on how you communicate the changes have changed. When you talk of change, it is very easy to introduce or imply value judgments. Old and new, then and now, books and technical articles, printed content and web content. It's very easy for the 'and' to be interpreted as 'versus', and that changes the meaning of the conversation. It is not that what we've done in the past is bad or no longer relevant; it is more that information needs continue to change, and we evolve with the changes.

We have the option to deliver technical content to many places now. Printed docs and docs.sun.com were two of the main options, and we now also have the option of delivering content to developers.sun.com, java.sun.com, BigAdmin, netbeans.org, java.net, opensolaris.org, blogs.sun.com, a lot of sites.

We can deliver books, retail books, online help, man pages, technical articles, tutorials, guides, blogs, podcasts, webcasts, screencasts, how to's, FAQs, forum postings. The choices keep growing, and that is part of the the excitement about the changes in how we communicate.

We can work for months on a technical document, and we can work for minutes on a blog entry, with a lot of options in between. We don't have to wait until a doc is final to get your feedback. We can post a draft and you can comment right away. We have options to work with you that we didn't have a few years ago.

Communication about change goes both ways. People talk to me about changes they want in technical information, and sometimes their message can come across as being judgmental, or the past is bad, or that some of the deliverables are no longer useful. In the end, it isn't one way or the other; past, present, or future; good or bad. It really is about what do you need for your technical information and realizing it is a mix from book to blog, article to podcast. In my opinion, it is finding the right mix of content and information types that best meets your needs for information.

Saturday Jan 27, 2007

The Role of Information/Documentation in Product Adoption

How does information or documentation influence your decisions to download, install, and use a product? What role can tech writers/information designers play in the success of a product or a company? Is it that you download a product and then look at the documentation, or is it that we can provide you with information that influences your decision to download and use a product? Can we help to grow our user base, in addition to providing information that helps people to be productive with our products and technologies?

Growing the number of people using our products and technologies contributes to the success of a product and a company. I've been looking for ways to show a correlation between the technical information we provide and the success of a product/technology and to goals supporting the success of Sun. We've been looking at how to combine docs usage metrics with voice of the customer to get a better idea of showing how documentation contributes to product adoption.

Metrics alone doesn't tell you enough of what is going on. You can monitor docs usage trends and identify changes in trends that warrant further evaluation. Still, you need the feedback and voice of the customer to add meaning to the metrics. Conversely, voice of the customer alone isn't enough. We can have people that are very satisfied with our docs, but maybe we have only a small number of people using those docs.

How do we grow the number of people using our docs while maintaining the quality of the docs? How do we ensure we are delivering the right content in the right formats to the right locations where you can find and use that information?

When I was thinking about metrics this morning and asking myself how do we show the relationship between docs usage trends and product downloads, I realized I could ask people questions on how they use information and if information plays a part in their downloading Sun products. So here goes with a couple of questions. You can either send an email to david.lindt at sun.com or post a comment to this blog.

  • Does technical information play a part in your decision to download a product?
  • What technical information can we provide that motivates you to download our products and to use those products?
  • What information types do you find useful? Podcasts, screencasts, webcasts, technical articles, tutorials, books, etc.
  • As you start to use a product, what information types do you use?
  • As a tech pubs org, where should we focus our efforts? More multimedia, more books, more shorter web docs, other?

Thanks in advance for your participation.

Saturday Jul 30, 2005

Staying relevant

When asked about my career goals, my first response is to stay relevant. My second response is to be in a job position where I can participate in the discussions that affect us as an org or as a profession (in this case, technical communications). This last week has been spent looking at the FY06 goals and thinking of how we adapt to meet those goals. Part of that effort involves mapping the descriptions of what we do as technical communicators to the terminology of the goals and looking for ways to show how we can be relevant to achieving those goals.

We've had discussions about internal customers and external customers. As technical communicators, it is easy to see that we have external customers, who are the developers or sys admins that use our documentation deliverables. We also have internal customers, such as the VP who wants more training or the engineering director who wants smaller, web-based docs. Our ability to get funding and support depends on our ability to meet the needs of the internal customers. Our value as a profession depends on our ability to support our external customers with accurate information in a format they can use. How to maximize the satisfaction of both the internal and external customers is the challenge.

Tuesday Jul 19, 2005

What information do you need?

What does it take to make an interesting blog? Do you view blogs more as a source of technical information, a diary, a collection of personal thoughts, or all of the above?

I guess this blog is more a reflection of my interests at the time that I care to express them in a public forum. Right now, I am more interested in how we present information and what we can do to make it easier to give you the information you need.

How do we give you the information you need? First we have to figure out what you need. We've had surveys, talked to developers, talked with people in other groups within Sun, had weekly meetings about different things people are doing with web-based informations or various web sites supported by Sun. Lots of ideas, but no single answer.

Without a clear answer to what information do you need, then how do we proceed? Do we keep doing what we've done for docs five years ago or do we do something new? To do something new, we need to cut back on doing some things we've done in the past. Do we do more with technical articles or blog entries and less with manuals or online help? Do you want smaller docs or pieces of information or do you want larger books? Do we focus more on training or providing reference material?

We talked at lunch today about being flexible, but the word of choice now is to be adaptable. You've changed the way you work with information over the years with Google, smaller docs, and blogs, and as technical communicators, we need to adapt to those changes. Five years ago, we focused on books, man pages, and online help provided with the product bits. You still need a lot of that information, but now we have many different ways to deliver that information.

I'm willing to try some different things with docs, and to take some risks with how we give you information. If we cut back on something, and that is an issue, let us know through the Documentation Feedback page. Positive feedback on the information you like is also welcomed. We will focus more on what you need.

We do monitor the doc feedback aliases, and we do respond to your comments. I would really like to hear your opinions.

About

dlindt

Search

Top Tags
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today