<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Design&gt;Documentation&gt;Web Design</title>	<link>http://tc.eserver.org/dir/Design/Documentation/Web-Design</link>
	<description>A listing of the most recently indexed works about Design and Documentation and Web Design in the field of technical communication.</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Design&gt;Documentation&gt;Web Design</title>
		<link>http://tc.eserver.org/dir/Design/Documentation/Web-Design</link>
	</image>
	<item>
		<title>Web 2.0, and Me</title>
		<link>http://tc.eserver.org/35210.html</link>
		<guid>http://tc.eserver.org/35210.html</guid>
		<description>As help systems continue to evolve, whatever name they are called, we will increasingly have to face responsibility for their content, and bring their expertise to what we write. The new systems provide us with all the required tools that tell us the problems with their content. It is up to us to leverage that information to provide better content, and act as ambassadors for products that we write. If writers can go a step ahead, and use their help information to sell products, and reduce the burden on customer support, we would have truly arrived.</description>
	</item>
	<item>
		<title>Calling Accessible Context-Sensitive Help with Unobtrusive DOM/JavaScript: A Help Authoring Guide</title>
		<link>http://tc.eserver.org/35190.html</link>
		<guid>http://tc.eserver.org/35190.html</guid>
		<description> This Fast Track tutorial demonstrates two methods to call Context-Sensitive Help in a Web Form. We&apos;ll discover how Unobtrusive DOM/JavaScript achieves the desired result in calling Context-Sensitive help, and demonstrate how to keep the Structure, Presentation, and Behavior layers of a web page completely separate from one another ensuring good practice with current web standards and accessibility rules.</description>
	</item>
	<item>
		<title>Tips To Create A Clean Structured About Page</title>
		<link>http://tc.eserver.org/35158.html</link>
		<guid>http://tc.eserver.org/35158.html</guid>
		<description>When it comes to an about page, think outside the box. Try to think of something new and creative that’s different form the rest of your site. Of course display images of you / your staff, and descriptions of each, but try to lay it out in a very fun way, whistle keeping it clean and readable.</description>
	</item>
	<item>
		<title>Reviewing Wiki Documentation via Crucible</title>
		<link>http://tc.eserver.org/33694.html</link>
		<guid>http://tc.eserver.org/33694.html</guid>
		<description>I have been playing around with Crucible, Atlassian’s peer code review tool. The latest version of Crucible allows you to review Confluence wiki pages. This is a new feature, so I decided to try it out. Also, I was wondering why you might want to use an independent tool to review a wiki page, when you could instead just add comments to the page or update the page directly.</description>
	</item>
	<item>
		<title>Systems That Get Better the More People Use Them</title>
		<link>http://tc.eserver.org/31740.html</link>
		<guid>http://tc.eserver.org/31740.html</guid>
		<description>In Publishing 2.0, Tim O&apos;Reilly says Web 2.0 is &apos;any network effect that makes a system better the more people use it.&apos; Web 2.0 isn’t just user-generated content; it’s harnessing the collective intelligence of your users to make your system better.</description>
	</item>
	<item>
		<title>Is Your Website Poised to Deal With Its Growth?</title>
		<link>http://tc.eserver.org/30766.html</link>
		<guid>http://tc.eserver.org/30766.html</guid>
		<description>Every webmaster nourishes the dream that his or her website will make it the big way. This is very much human because people carry out any task in ardent hope. What is more human out here is that earthy fellows like us base our aspirations more on speculation rather than specific set of steps undertaken to bring the dream a bit closer to reality. And this is not all, particularly in case of growth of a site which brings newer problems in the wake of its growth.&#xD;&#xD;It cannot be disputed that you can probably get some good web hosting on economy price. But if you expect top of the line service on this price, acknowedge gracefully that your are just asking for the moon. Probably you are not catching up with wisdom that business needs decisive investments.</description>
	</item>
	<item>
		<title>Communicating Design: Web Design Documentation</title>
		<link>http://tc.eserver.org/29535.html</link>
		<guid>http://tc.eserver.org/29535.html</guid>
		<description>An overview of web design methods, including a survey of questions one should ask during the process.</description>
	</item>
	<item>
		<title>The Convergence of Web 2.0 with Help Documentation</title>
		<link>http://tc.eserver.org/28795.html</link>
		<guid>http://tc.eserver.org/28795.html</guid>
		<description>This podcast talks about the convergence of web 2.0 with help documentation. It mentions examples of Web 2.0 sites, such as Flickr, Payscale, and Digg, and what help files need to incorporate these same Web 2.0 features.</description>
	</item>
	<item>
		<title>Applying Web 2.0 Technologies to Technical Documentation </title>
		<link>http://tc.eserver.org/28228.html</link>
		<guid>http://tc.eserver.org/28228.html</guid>
		<description>This article is based on my presentation at the Institute of Scientific and Technical Communicators&apos; annual conference in October, 2006.  Every now and then, there is a change in the value of what technical authors deliver. These are moments when organisations pay attention to technical documentation. This is because they recognise that these changes mean they can create something that will be of real value to the business and to their customers. &#xD;&#xD;In recent years, there have been three &quot;waves of interestingness&quot;. The first wave was the introduction of Windows Help (WinHelp). The second major wave was the introduction of the Internet and intranets. This was a time when organisations looked at how they could transfer large amounts of information from paper to online. They were faced with issues such as how users could access and understand all this information easily - issues that technical communicators deal with on a day-to-day basis. &#xD;&#xD;I believe we&apos;re just about to approach the new wave, which we have called &quot;Tech Writing 2.0&quot;.</description>
	</item>
	<item>
		<title>Constructing a One-Stop &quot;Answer Station&quot; Website for Software Users</title>
		<link>http://tc.eserver.org/27658.html</link>
		<guid>http://tc.eserver.org/27658.html</guid>
		<description>The web allows us to easily provide updated documentation to our users, but why stop there? There is more to making users successful quickly than just providing documentation. By creating a complete &apos;Answer Station&apos; that is accessible from the application or product, we can not only direct users to that updated documentation, but we can also provide information about technical support, consulting, training, sales, etc.&#xD;&#xD;This article discusses writing a proposal for an Answer Station, determining content, working with other departments to gather information, designing the site, making that design work with an existing corporate website, dealing with tool issues, and finally, going live.</description>
	</item>
	<item>
		<title>Six Tips for Improving Your Design Documentation</title>
		<link>http://tc.eserver.org/25619.html</link>
		<guid>http://tc.eserver.org/25619.html</guid>
		<description>Good organization, complete information, and clear writing are, of course, key to the success of any design document, but there are some other, less-obvious techniques you can use to make your documents more readable and understandable. Here are a few of them.</description>
	</item>
	<item>
		<title>Hypertext for Handling Conceptual Material</title>
		<link>http://tc.eserver.org/23264.html</link>
		<guid>http://tc.eserver.org/23264.html</guid>
		<description>Turning &apos;help&apos; systems and &apos;browsers&apos; into robust structured-document viewers: the DocBrowser.</description>
	</item>
	<item>
		<title>Visual Vocabulary Three Years Later: An Interview with Jesse James Garrett</title>
		<link>http://tc.eserver.org/23216.html</link>
		<guid>http://tc.eserver.org/23216.html</guid>
		<description>This interview focuses on Jesse James Garret&apos;s Visual Vocabulary, a site architecture documentation standard.</description>
	</item>
	<item>
		<title>Writing Web Documentation</title>
		<link>http://tc.eserver.org/22651.html</link>
		<guid>http://tc.eserver.org/22651.html</guid>
		<description>Your product is almost ready for release. You&apos;re about to pat yourself on the back when you realize that you have no user documentation! Panic sets in.</description>
	</item>
	<item>
		<title>Designing a Help System for a Web Site</title>
		<link>http://tc.eserver.org/21564.html</link>
		<guid>http://tc.eserver.org/21564.html</guid>
		<description>When I worked for a large insurance company, my team as tasked with re-designing the customer service area for a external Web site that supports annuities and mutual fund customers. I proposed redesigning the entire site including an actual help system (like with ones you can create with RoboHelp) to reduce customer service support calls. I was really surprised that everyone thought this was such a novel idea -- I thought it made perfect sense. Then, it hit me -- you don&apos;t see a lot of help systems for Web sites.</description>
	</item>
	<item>
		<title>Restructuring Online Documentation for the World Wide Web</title>
		<link>http://tc.eserver.org/20551.html</link>
		<guid>http://tc.eserver.org/20551.html</guid>
		<description>Technical communicators around the world are turning to the World Wide Web us their primary delivery agent for&#xD;on-line documentation. The transition from older forms of&#xD;on-line documentation to HTML-based documents pre -&#xD;sents new challenges in every phase of the documentation&#xD;process: document creation, layout, access, and especially&#xD;hypermedia capability The constant development of new&#xD;web tools presents an even greater challenge for an organization&#xD;seeking to stay abreast of technology with an ever&#xD;decreasing budget. This panel will outline the basic steps&#xD;in migrating to the web while focusing on one&#xD;organization’s solution to meeting the challenges of restructuring&#xD;its on-line documentation for web migration.</description>
	</item>
	<item>
		<title>Building the Treasure House: Creating Knowledge Bases on the World-Wide Web</title>
		<link>http://tc.eserver.org/20287.html</link>
		<guid>http://tc.eserver.org/20287.html</guid>
		<description>Web knowledge bases offer an excellent platform for delivering technical documentation and customer support information. They also represent an area of great&#xD;opportunity for technical communicators to expand their&#xD;skills, satisfy their customers, and create value for their&#xD;employers or clients. This session explores the&#xD;components of a web knowledge base and the tasks&#xD;involved in planning and building one.</description>
	</item>
	<item>
		<title>Large-Scale HTML Conversion Using a Word Processor</title>
		<link>http://tc.eserver.org/19958.html</link>
		<guid>http://tc.eserver.org/19958.html</guid>
		<description>In 2000, the Hitachi Technical Information Department carried out a large-scale documentation project requiring the revision of 47 English manuals (about 15,000 pages) and production of the manuals in both&#xD;paper and HTML formats. Many projects of this size would normally use more complex software and file formats, such as FrameMaker and SGML. However, most of the English manuals were already in Microsoft Word (hence forth &apos;Word&apos;) format, and we decided to use Word 2000 to convert the manual document files into HTML files directly. The presentation discusses solutions to problems encountered in this HTML conversion project.</description>
	</item>
	<item>
		<title>Applying Object-Oriented Design Concepts to Web Publishing</title>
		<link>http://tc.eserver.org/19917.html</link>
		<guid>http://tc.eserver.org/19917.html</guid>
		<description>This is a story of how one internal project at Sun Microsystems migrated printed user and reference documentation to an internal Web site. The&#xD;principle architect of this site discusses how she&#xD;applied object-oriented design concepts to the Web&#xD;architecture to accommodate many learning styles&#xD;simultaneously. As important as the successes of&#xD;this project are its failures, which offer some insight&#xD;into when and how to use the World Wide Web as a&#xD;communication vehicle in your overall&#xD;communication strategy.</description>
	</item>
	<item>
		<title>Achieving Success with Intranet-Based Online Documentation</title>
		<link>http://tc.eserver.org/19901.html</link>
		<guid>http://tc.eserver.org/19901.html</guid>
		<description>To key to achieving a successful online documentation implementation on the intranet is to understand that the resulting system is indeed a &apos;system.&apos; The need for well-written, formatted and structured documents is necessary but the interactive framework in which those documents exist is equally important. It is crucial to understand the role of each individual involved in the system from Reader to Author and I.T. provider.</description>
	</item>
	<item>
		<title>Designing for the Web: Special Considerations for Safety Information</title>
		<link>http://tc.eserver.org/13105.html</link>
		<guid>http://tc.eserver.org/13105.html</guid>
		<description>Manufacturers are currently grappling with determining whether they should put safety information on the Web and if they do how it should be presented. Technical&#xD;communicators, Web content developers, and Web&#xD;designers will ultimately be responsible for the&#xD;presentation of Web-based safety information. This&#xD;article discusses special considerations that should be&#xD;given the formatting (HTML, PDF, etc.), design, (font,&#xD;size, and color), and location of safety information on&#xD;the Web. Additionally, areas for future research on the&#xD;issue of Web-based safety information are identified.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Design/Documentation/Web-Design.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>