- Văn bản
- Lịch sử
Having covered the basics of creati
Having covered the basics of creating simple documents and document repositories, we now turn to creating larger repositories, being more formal, and
managing content.
9.2.1 A Dynamic Documentation Repository
The idea of a “living documentation” site, or dynamic documentation repository, is simply that of a site or repository where documents are expected
to be updated periodically to meet the needs of the environment. The Internet phenomenon known as Wikipedia (www.Wikipedia.org) is a wonderful
example of this kind of system. Beginning with the original Wiki Encyclopedia, dozens of groups have created special-interest content repositories on
this model. In contrast to a traditional document repository, a living documentation repository shifts the focus to the customer’s interaction with the
documents. Rather than being able to merely locate and read a document,
the customer can annotate, edit, collect documents into views, send document
references to colleagues, and so on.
Although we use a wiki as the primary example of a living documentation
site, it is important to note that this does not mean that everything must be
integrated into the wiki. It is sufficient to have a central point to organize
information, including links to other information systems.
9.2 The Icing 253
Using Different Wikis for Different Situations
Different software packages have different strong points. One site found that it was
better to maintain DokuWiki for its customer-facing support documentation, Trac for
documents and ticket tracking related to internally developed source code, and RT for
the customer-facing request tracker. The site found that it was rare that documents
cross-linked, and when they did, it was easy to copy and paste or hyperlink to bridge
them.
9.2.2 A Content-Management System
A content-management system (CMS) is a publication system for web sites.
For example, a newspaper CMS system might facilitate the process of reporters creating stories, which are then queued to editors, edited, and approved for publication. The CMS system releases the article at a specific
time, placing it on the web site, updating tables of contents, and taking care
of other details. For an IT site, CMS might permit plug-ins that give portal
features, such as summaries of recent outages.
A number of features are required to implement a functional CMS. A
content-management system specifically consists of three layers: repository,
history, and presentation. The repository layer is generally a database but
may also be a structured file system with metadata. The content is stored in
this layer. The history layer implements version control, permissions, audit
trails, and such functionality as assigning a global document identifier to new
documents. The history layer may be a separate journal or database or may
be stored in the repository. The presentation layer is the user interface. In
addition to allowing document interaction, such as browsing or editing, the
presentation layer may also implement document controls, such as read-only
access or permissions.
Advanced wiki systems have many of the features of a full CMS. Many
CMS systems now include wikilike features. Two popular open source CMS
systems are Drupal and MediaWiki.
9.2.3 A Culture of Respect
A living documentation site needs a culture of respect; otherwise, people
become hesitant to post or feel that they may post only “approved” stuff.
Such trade-offs are inherent in implementing a moderated posting process.
Not just anybody should be editing the standby-generator test instructions,
254 Chapter 9 Documentation
for instance, yet the approved author may have missed or changed something in the original posting. This problem can be addressed in most cases by
enabling comments to a page and promoting comments into content when
they seem valid to the original author or to enough other commenters. When
a genuine mistake is made, revision control can enable access to an unaltered version. When it is unclear which version is authoritative, at least revision control can show a list of changes and provide some context with
which to make a judgment call or to request clarification via phone or
email.
Expect to put in a bit of management time on the wiki until people get the
hang of it and match it to your particular culture. There’s a level of detail that
will be “right” for your group, and, like any kind of writing, there’ll be some
bracketing on either side before things start looking as you feel they should
look. Some groups have a documentation system that is merely pasted emails
in no particular order under topics; other groups have elaborate runbookstyle pages for each important piece of infrastructure. The lovely thing about
using a wiki or similar living documentation system as an interim CMS is
that you can transition from an ad hoc system to a more formalized system
as documents mature. Pages and entries can be reorganized and cleaned up
during slow days and perhaps promoted to new areas or exported to the more
formal CMS.
9.2.4 Taxonomy and Structure
Wiki systems tend to impose very little structure. Some simply provide navigation.
At the outset, don’t spend time worrying about structure. A major killer
of wiki projects is the imposition of too much structure during the early
stages. A notion of low barrier to entry spawned the wiki. Updating a page
should be as easy as sending an email; otherwise, people won’t use it. It’s far
better to have to clean up some pages for readability than to have the info
sequestered in someone’s mail folders where no one can find it when he is
on vacation. If a particular type of document will be written many times by
many people—for example, design proposals or feature requests—provide a
template to keep those more formal documents in the same format.
Differentiate between writing documentation and organizing documentation. As your content grows, folks will increasingly use search rather than
categories to look for things. You can always create structured categories and
refactor the pages or their links as the wiki grows.
9.2 The Icing 255
9.2.5 Additional Documentation Uses
Here are some more ways to use a living document system. Many wiki systems
have templates or plug-ins specific to these applications.
9.2.5.1 Self-Help Desk
Customers can use the self-help desk area of the documentation site to interact
directly with the site. Perhaps your current site has a Create a new ticket
link that allows customers to make a request via the ticket system.
This area is a good place for such items as news on planned outages,
updates on situations in progress, and prominent links to policies and howto documents. Examples of the latter might be how to log in remotely via
VPN, how to set up synchronization to your mobile device, and so on.
Another item that belongs in the self-help desk area is customer access
to monitoring results, such as multirouter traffic graphics (MRTGs) or even
scripted lists of free space on shared volumes. Sites that rely heavily on shared
software licenses, such as those used by CAD tools, may find it very helpful to
place a link to the license-monitoring utility on this page, to head off questions
about who has what licenses checked out.
9.2.5.2 Internal Group–Specific Documents
SAs are early adopters, and many SA groups build out a living documentation
site for their own benefit. Having information on how to perform complex
tasks that only one or two people in the group routinely undertake can save
the day when someone is out sick or called away. The creation of groupspecific documents is the beginning of forming an institutional memory, a
very important piece of continuity for any group.
Although the SA group might lead the way, any group or department can
benefit from having its own area in the site. Some groups have a de facto living
documents site in the form of a source code repository, which may be used
for specifications, customer lists, and marketing materials, as well as code.
Owing to the sensitive nature of some group-specific documentation, this area
is likely to have restricted access, with only that group and administrative staff
able to access the area.
9.2.5.3 How-To Docs
At many sites, a short, self-explanatory document called a How-To, or
HOWTO, helps customers to help themselves when SAs are unavailable.
HOWTO documents cover a single topic, generally the accomplishment of
a specific task; are usually customized to the environment of the site; and
256 Chapter 9 Documentation
generally include both customer input and program response, often with
screen shots. A HOWTO document is designed to solve a particular problem rather than to serve as a conceptual tutorial. The streamlined format,
tailored to the environment, serves to encourage buy-in from customers who
would otherwise consider reading documentation to be too time consuming
or difficult and would open a support call instead.
Typical examples of HOWTOs include setting up an email client, obtaining remote access to networks or file servers, accessing printers, and configuring software for use in the local environment. University sites, which
often have a very large ratio of customers to SAs, benefit particularly from
the self-help desk and How-To documents. Sites documenting helpdesk usage
and support levels in their organizations might consider web server logs of
HOWTO access as a metric to track and report.
9.2.5.4 Frequently Asked Questions
To most Internet users, the Frequently Asked Questions (FAQ) list is a familiar
tool. The FAQ is simply a list of the most common queries about a particular
topic, often organized into sections and subsections and usually evolving
over time. Some wiki plug-ins automatically generate a table of contents or
present the questions as hypertext links to the answers. (This approach has
the downside of making it difficult to read all the questions and answers in
order or to print or search the list.)
The FAQ l
managing content.
9.2.1 A Dynamic Documentation Repository
The idea of a “living documentation” site, or dynamic documentation repository, is simply that of a site or repository where documents are expected
to be updated periodically to meet the needs of the environment. The Internet phenomenon known as Wikipedia (www.Wikipedia.org) is a wonderful
example of this kind of system. Beginning with the original Wiki Encyclopedia, dozens of groups have created special-interest content repositories on
this model. In contrast to a traditional document repository, a living documentation repository shifts the focus to the customer’s interaction with the
documents. Rather than being able to merely locate and read a document,
the customer can annotate, edit, collect documents into views, send document
references to colleagues, and so on.
Although we use a wiki as the primary example of a living documentation
site, it is important to note that this does not mean that everything must be
integrated into the wiki. It is sufficient to have a central point to organize
information, including links to other information systems.
9.2 The Icing 253
Using Different Wikis for Different Situations
Different software packages have different strong points. One site found that it was
better to maintain DokuWiki for its customer-facing support documentation, Trac for
documents and ticket tracking related to internally developed source code, and RT for
the customer-facing request tracker. The site found that it was rare that documents
cross-linked, and when they did, it was easy to copy and paste or hyperlink to bridge
them.
9.2.2 A Content-Management System
A content-management system (CMS) is a publication system for web sites.
For example, a newspaper CMS system might facilitate the process of reporters creating stories, which are then queued to editors, edited, and approved for publication. The CMS system releases the article at a specific
time, placing it on the web site, updating tables of contents, and taking care
of other details. For an IT site, CMS might permit plug-ins that give portal
features, such as summaries of recent outages.
A number of features are required to implement a functional CMS. A
content-management system specifically consists of three layers: repository,
history, and presentation. The repository layer is generally a database but
may also be a structured file system with metadata. The content is stored in
this layer. The history layer implements version control, permissions, audit
trails, and such functionality as assigning a global document identifier to new
documents. The history layer may be a separate journal or database or may
be stored in the repository. The presentation layer is the user interface. In
addition to allowing document interaction, such as browsing or editing, the
presentation layer may also implement document controls, such as read-only
access or permissions.
Advanced wiki systems have many of the features of a full CMS. Many
CMS systems now include wikilike features. Two popular open source CMS
systems are Drupal and MediaWiki.
9.2.3 A Culture of Respect
A living documentation site needs a culture of respect; otherwise, people
become hesitant to post or feel that they may post only “approved” stuff.
Such trade-offs are inherent in implementing a moderated posting process.
Not just anybody should be editing the standby-generator test instructions,
254 Chapter 9 Documentation
for instance, yet the approved author may have missed or changed something in the original posting. This problem can be addressed in most cases by
enabling comments to a page and promoting comments into content when
they seem valid to the original author or to enough other commenters. When
a genuine mistake is made, revision control can enable access to an unaltered version. When it is unclear which version is authoritative, at least revision control can show a list of changes and provide some context with
which to make a judgment call or to request clarification via phone or
email.
Expect to put in a bit of management time on the wiki until people get the
hang of it and match it to your particular culture. There’s a level of detail that
will be “right” for your group, and, like any kind of writing, there’ll be some
bracketing on either side before things start looking as you feel they should
look. Some groups have a documentation system that is merely pasted emails
in no particular order under topics; other groups have elaborate runbookstyle pages for each important piece of infrastructure. The lovely thing about
using a wiki or similar living documentation system as an interim CMS is
that you can transition from an ad hoc system to a more formalized system
as documents mature. Pages and entries can be reorganized and cleaned up
during slow days and perhaps promoted to new areas or exported to the more
formal CMS.
9.2.4 Taxonomy and Structure
Wiki systems tend to impose very little structure. Some simply provide navigation.
At the outset, don’t spend time worrying about structure. A major killer
of wiki projects is the imposition of too much structure during the early
stages. A notion of low barrier to entry spawned the wiki. Updating a page
should be as easy as sending an email; otherwise, people won’t use it. It’s far
better to have to clean up some pages for readability than to have the info
sequestered in someone’s mail folders where no one can find it when he is
on vacation. If a particular type of document will be written many times by
many people—for example, design proposals or feature requests—provide a
template to keep those more formal documents in the same format.
Differentiate between writing documentation and organizing documentation. As your content grows, folks will increasingly use search rather than
categories to look for things. You can always create structured categories and
refactor the pages or their links as the wiki grows.
9.2 The Icing 255
9.2.5 Additional Documentation Uses
Here are some more ways to use a living document system. Many wiki systems
have templates or plug-ins specific to these applications.
9.2.5.1 Self-Help Desk
Customers can use the self-help desk area of the documentation site to interact
directly with the site. Perhaps your current site has a Create a new ticket
link that allows customers to make a request via the ticket system.
This area is a good place for such items as news on planned outages,
updates on situations in progress, and prominent links to policies and howto documents. Examples of the latter might be how to log in remotely via
VPN, how to set up synchronization to your mobile device, and so on.
Another item that belongs in the self-help desk area is customer access
to monitoring results, such as multirouter traffic graphics (MRTGs) or even
scripted lists of free space on shared volumes. Sites that rely heavily on shared
software licenses, such as those used by CAD tools, may find it very helpful to
place a link to the license-monitoring utility on this page, to head off questions
about who has what licenses checked out.
9.2.5.2 Internal Group–Specific Documents
SAs are early adopters, and many SA groups build out a living documentation
site for their own benefit. Having information on how to perform complex
tasks that only one or two people in the group routinely undertake can save
the day when someone is out sick or called away. The creation of groupspecific documents is the beginning of forming an institutional memory, a
very important piece of continuity for any group.
Although the SA group might lead the way, any group or department can
benefit from having its own area in the site. Some groups have a de facto living
documents site in the form of a source code repository, which may be used
for specifications, customer lists, and marketing materials, as well as code.
Owing to the sensitive nature of some group-specific documentation, this area
is likely to have restricted access, with only that group and administrative staff
able to access the area.
9.2.5.3 How-To Docs
At many sites, a short, self-explanatory document called a How-To, or
HOWTO, helps customers to help themselves when SAs are unavailable.
HOWTO documents cover a single topic, generally the accomplishment of
a specific task; are usually customized to the environment of the site; and
256 Chapter 9 Documentation
generally include both customer input and program response, often with
screen shots. A HOWTO document is designed to solve a particular problem rather than to serve as a conceptual tutorial. The streamlined format,
tailored to the environment, serves to encourage buy-in from customers who
would otherwise consider reading documentation to be too time consuming
or difficult and would open a support call instead.
Typical examples of HOWTOs include setting up an email client, obtaining remote access to networks or file servers, accessing printers, and configuring software for use in the local environment. University sites, which
often have a very large ratio of customers to SAs, benefit particularly from
the self-help desk and How-To documents. Sites documenting helpdesk usage
and support levels in their organizations might consider web server logs of
HOWTO access as a metric to track and report.
9.2.5.4 Frequently Asked Questions
To most Internet users, the Frequently Asked Questions (FAQ) list is a familiar
tool. The FAQ is simply a list of the most common queries about a particular
topic, often organized into sections and subsections and usually evolving
over time. Some wiki plug-ins automatically generate a table of contents or
present the questions as hypertext links to the answers. (This approach has
the downside of making it difficult to read all the questions and answers in
order or to print or search the list.)
The FAQ l
0/5000
Having covered the basics of creating simple documents and document repositories, we now turn to creating larger repositories, being more formal, andmanaging content.9.2.1 A Dynamic Documentation RepositoryThe idea of a “living documentation” site, or dynamic documentation repository, is simply that of a site or repository where documents are expectedto be updated periodically to meet the needs of the environment. The Internet phenomenon known as Wikipedia (www.Wikipedia.org) is a wonderfulexample of this kind of system. Beginning with the original Wiki Encyclopedia, dozens of groups have created special-interest content repositories onthis model. In contrast to a traditional document repository, a living documentation repository shifts the focus to the customer’s interaction with thedocuments. Rather than being able to merely locate and read a document,the customer can annotate, edit, collect documents into views, send documentreferences to colleagues, and so on.Although we use a wiki as the primary example of a living documentationsite, it is important to note that this does not mean that everything must beintegrated into the wiki. It is sufficient to have a central point to organizeinformation, including links to other information systems.9.2 The Icing 253Using Different Wikis for Different SituationsDifferent software packages have different strong points. One site found that it wasbetter to maintain DokuWiki for its customer-facing support documentation, Trac fordocuments and ticket tracking related to internally developed source code, and RT forthe customer-facing request tracker. The site found that it was rare that documentscross-linked, and when they did, it was easy to copy and paste or hyperlink to bridgethem.9.2.2 A Content-Management SystemA content-management system (CMS) is a publication system for web sites.For example, a newspaper CMS system might facilitate the process of reporters creating stories, which are then queued to editors, edited, and approved for publication. The CMS system releases the article at a specifictime, placing it on the web site, updating tables of contents, and taking careof other details. For an IT site, CMS might permit plug-ins that give portalfeatures, such as summaries of recent outages.A number of features are required to implement a functional CMS. Acontent-management system specifically consists of three layers: repository,history, and presentation. The repository layer is generally a database butmay also be a structured file system with metadata. The content is stored inthis layer. The history layer implements version control, permissions, audittrails, and such functionality as assigning a global document identifier to newdocuments. The history layer may be a separate journal or database or maybe stored in the repository. The presentation layer is the user interface. Inaddition to allowing document interaction, such as browsing or editing, thepresentation layer may also implement document controls, such as read-onlyaccess or permissions.Advanced wiki systems have many of the features of a full CMS. ManyCMS systems now include wikilike features. Two popular open source CMSsystems are Drupal and MediaWiki.9.2.3 A Culture of RespectA living documentation site needs a culture of respect; otherwise, peoplebecome hesitant to post or feel that they may post only “approved” stuff.Such trade-offs are inherent in implementing a moderated posting process.Not just anybody should be editing the standby-generator test instructions,254 Chapter 9 Documentationfor instance, yet the approved author may have missed or changed something in the original posting. This problem can be addressed in most cases byenabling comments to a page and promoting comments into content whenthey seem valid to the original author or to enough other commenters. Whena genuine mistake is made, revision control can enable access to an unaltered version. When it is unclear which version is authoritative, at least revision control can show a list of changes and provide some context withwhich to make a judgment call or to request clarification via phone oremail.Expect to put in a bit of management time on the wiki until people get thehang of it and match it to your particular culture. There’s a level of detail thatwill be “right” for your group, and, like any kind of writing, there’ll be somebracketing on either side before things start looking as you feel they shouldlook. Some groups have a documentation system that is merely pasted emailsin no particular order under topics; other groups have elaborate runbookstyle pages for each important piece of infrastructure. The lovely thing aboutusing a wiki or similar living documentation system as an interim CMS isthat you can transition from an ad hoc system to a more formalized systemas documents mature. Pages and entries can be reorganized and cleaned upduring slow days and perhaps promoted to new areas or exported to the moreformal CMS.9.2.4 Taxonomy and StructureWiki systems tend to impose very little structure. Some simply provide navigation.At the outset, don’t spend time worrying about structure. A major killerof wiki projects is the imposition of too much structure during the earlystages. A notion of low barrier to entry spawned the wiki. Updating a pageshould be as easy as sending an email; otherwise, people won’t use it. It’s farbetter to have to clean up some pages for readability than to have the infosequestered in someone’s mail folders where no one can find it when he ison vacation. If a particular type of document will be written many times bymany people—for example, design proposals or feature requests—provide atemplate to keep those more formal documents in the same format.
Differentiate between writing documentation and organizing documentation. As your content grows, folks will increasingly use search rather than
categories to look for things. You can always create structured categories and
refactor the pages or their links as the wiki grows.
9.2 The Icing 255
9.2.5 Additional Documentation Uses
Here are some more ways to use a living document system. Many wiki systems
have templates or plug-ins specific to these applications.
9.2.5.1 Self-Help Desk
Customers can use the self-help desk area of the documentation site to interact
directly with the site. Perhaps your current site has a Create a new ticket
link that allows customers to make a request via the ticket system.
This area is a good place for such items as news on planned outages,
updates on situations in progress, and prominent links to policies and howto documents. Examples of the latter might be how to log in remotely via
VPN, how to set up synchronization to your mobile device, and so on.
Another item that belongs in the self-help desk area is customer access
to monitoring results, such as multirouter traffic graphics (MRTGs) or even
scripted lists of free space on shared volumes. Sites that rely heavily on shared
software licenses, such as those used by CAD tools, may find it very helpful to
place a link to the license-monitoring utility on this page, to head off questions
about who has what licenses checked out.
9.2.5.2 Internal Group–Specific Documents
SAs are early adopters, and many SA groups build out a living documentation
site for their own benefit. Having information on how to perform complex
tasks that only one or two people in the group routinely undertake can save
the day when someone is out sick or called away. The creation of groupspecific documents is the beginning of forming an institutional memory, a
very important piece of continuity for any group.
Although the SA group might lead the way, any group or department can
benefit from having its own area in the site. Some groups have a de facto living
documents site in the form of a source code repository, which may be used
for specifications, customer lists, and marketing materials, as well as code.
Owing to the sensitive nature of some group-specific documentation, this area
is likely to have restricted access, with only that group and administrative staff
able to access the area.
9.2.5.3 How-To Docs
At many sites, a short, self-explanatory document called a How-To, or
HOWTO, helps customers to help themselves when SAs are unavailable.
HOWTO documents cover a single topic, generally the accomplishment of
a specific task; are usually customized to the environment of the site; and
256 Chapter 9 Documentation
generally include both customer input and program response, often with
screen shots. A HOWTO document is designed to solve a particular problem rather than to serve as a conceptual tutorial. The streamlined format,
tailored to the environment, serves to encourage buy-in from customers who
would otherwise consider reading documentation to be too time consuming
or difficult and would open a support call instead.
Typical examples of HOWTOs include setting up an email client, obtaining remote access to networks or file servers, accessing printers, and configuring software for use in the local environment. University sites, which
often have a very large ratio of customers to SAs, benefit particularly from
the self-help desk and How-To documents. Sites documenting helpdesk usage
and support levels in their organizations might consider web server logs of
HOWTO access as a metric to track and report.
9.2.5.4 Frequently Asked Questions
To most Internet users, the Frequently Asked Questions (FAQ) list is a familiar
tool. The FAQ is simply a list of the most common queries about a particular
topic, often organized into sections and subsections and usually evolving
over time. Some wiki plug-ins automatically generate a table of contents or
present the questions as hypertext links to the answers. (This approach has
the downside of making it difficult to read all the questions and answers in
order or to print or search the list.)
The FAQ l
Differentiate between writing documentation and organizing documentation. As your content grows, folks will increasingly use search rather than
categories to look for things. You can always create structured categories and
refactor the pages or their links as the wiki grows.
9.2 The Icing 255
9.2.5 Additional Documentation Uses
Here are some more ways to use a living document system. Many wiki systems
have templates or plug-ins specific to these applications.
9.2.5.1 Self-Help Desk
Customers can use the self-help desk area of the documentation site to interact
directly with the site. Perhaps your current site has a Create a new ticket
link that allows customers to make a request via the ticket system.
This area is a good place for such items as news on planned outages,
updates on situations in progress, and prominent links to policies and howto documents. Examples of the latter might be how to log in remotely via
VPN, how to set up synchronization to your mobile device, and so on.
Another item that belongs in the self-help desk area is customer access
to monitoring results, such as multirouter traffic graphics (MRTGs) or even
scripted lists of free space on shared volumes. Sites that rely heavily on shared
software licenses, such as those used by CAD tools, may find it very helpful to
place a link to the license-monitoring utility on this page, to head off questions
about who has what licenses checked out.
9.2.5.2 Internal Group–Specific Documents
SAs are early adopters, and many SA groups build out a living documentation
site for their own benefit. Having information on how to perform complex
tasks that only one or two people in the group routinely undertake can save
the day when someone is out sick or called away. The creation of groupspecific documents is the beginning of forming an institutional memory, a
very important piece of continuity for any group.
Although the SA group might lead the way, any group or department can
benefit from having its own area in the site. Some groups have a de facto living
documents site in the form of a source code repository, which may be used
for specifications, customer lists, and marketing materials, as well as code.
Owing to the sensitive nature of some group-specific documentation, this area
is likely to have restricted access, with only that group and administrative staff
able to access the area.
9.2.5.3 How-To Docs
At many sites, a short, self-explanatory document called a How-To, or
HOWTO, helps customers to help themselves when SAs are unavailable.
HOWTO documents cover a single topic, generally the accomplishment of
a specific task; are usually customized to the environment of the site; and
256 Chapter 9 Documentation
generally include both customer input and program response, often with
screen shots. A HOWTO document is designed to solve a particular problem rather than to serve as a conceptual tutorial. The streamlined format,
tailored to the environment, serves to encourage buy-in from customers who
would otherwise consider reading documentation to be too time consuming
or difficult and would open a support call instead.
Typical examples of HOWTOs include setting up an email client, obtaining remote access to networks or file servers, accessing printers, and configuring software for use in the local environment. University sites, which
often have a very large ratio of customers to SAs, benefit particularly from
the self-help desk and How-To documents. Sites documenting helpdesk usage
and support levels in their organizations might consider web server logs of
HOWTO access as a metric to track and report.
9.2.5.4 Frequently Asked Questions
To most Internet users, the Frequently Asked Questions (FAQ) list is a familiar
tool. The FAQ is simply a list of the most common queries about a particular
topic, often organized into sections and subsections and usually evolving
over time. Some wiki plug-ins automatically generate a table of contents or
present the questions as hypertext links to the answers. (This approach has
the downside of making it difficult to read all the questions and answers in
order or to print or search the list.)
The FAQ l
đang được dịch, vui lòng đợi..
Có bao phủ những điều cơ bản của việc tạo ra các tài liệu và kho tài liệu đơn giản, bây giờ chúng ta chuyển sang việc tạo ra các kho lớn hơn, là chính thức hơn, và
quản lý nội dung.
9.2.1 Một tài liệu Repository động
Ý tưởng về một "tài liệu sống" trang web, hoặc kho lưu trữ tài liệu năng động, chỉ đơn giản là một trang web hoặc kho lưu trữ mà các văn bản được dự kiến là
sẽ được cập nhật định kỳ để đáp ứng nhu cầu của môi trường. Các hiện tượng Internet được gọi là Wikipedia (www.Wikipedia.org) là một tuyệt vời
ví dụ của loại hệ thống này. Bắt đầu với bản gốc Wiki Encyclopedia, hàng chục nhóm đã tạo ra kho nội dung đặc biệt quan tâm về
mô hình này. Ngược lại với một kho lưu trữ tài liệu truyền thống, một kho lưu trữ tài liệu sống thay đổi sự tập trung vào sự tương tác của khách hàng với các
tài liệu. Thay vì việc có thể chỉ đơn thuần là xác định vị trí và đọc một tài liệu,
khách hàng có thể chú thích, chỉnh sửa, thu thập tài liệu vào quan điểm, gửi tài liệu
tham khảo cho các đồng nghiệp, và như vậy.
Mặc dù chúng tôi sử dụng một wiki như các ví dụ cơ bản của một tài liệu sống
site, nó quan trọng là phải lưu ý rằng điều này không có nghĩa là tất cả mọi thứ phải được
tích hợp vào wiki. Nó là đủ để có một điểm trung tâm để tổ chức
thông tin, bao gồm cả các liên kết đến các hệ thống thông tin khác.
9.2 Icing 253
Sử dụng Wiki khác nhau cho các tình trạng khác nhau
các gói phần mềm khác nhau có điểm mạnh khác nhau. Một trang web được tìm thấy rằng nó là
tốt hơn để duy trì DokuWiki cho các tài liệu hỗ trợ khách hàng phải đối mặt với nó, Trác cho
tài liệu và theo dõi vé liên quan đến mã nguồn phát triển nội bộ, và RT cho
các yêu cầu theo dõi tiếp với khách hàng. Các trang web tìm thấy rằng nó là hiếm hoi mà các văn bản
liên kết ngang, và khi họ đã làm, đó là dễ dàng để sao chép và dán hoặc siêu liên kết để cầu
cho họ.
9.2.2 Một hệ thống Content-Quản lý
Một hệ thống quản lý nội dung (CMS) là một ấn phẩm hệ thống cho các trang web.
Ví dụ, một hệ thống CMS báo có thể tạo thuận lợi cho quá trình phóng tạo ra những câu chuyện, sau đó được xếp hàng đợi để biên tập, chỉnh sửa, và đã được phê duyệt để xuất bản. Các hệ thống CMS phát hành thông tin tại một cụ thể
thời gian, đặt nó trên trang web, cập nhật các bảng nội dung, và chăm sóc
của các chi tiết khác. Đối với một trang web IT, CMS có thể cho phép các plug-in cung cấp cho cổng thông tin
tính năng, chẳng hạn như bản tóm tắt của cúp gần đây.
Một số tính năng được yêu cầu để thực hiện một chức năng CMS. Một
hệ thống quản lý nội dung cụ thể bao gồm ba lớp: kho lưu trữ,
lịch sử, và trình bày. Lớp kho thường là một cơ sở dữ liệu nhưng
cũng có thể là một hệ thống tập tin cấu trúc với các siêu dữ liệu. Các nội dung được lưu trữ trong
lớp này. Các lớp lịch sử đã kiểm soát phiên bản, cấp phép, kiểm toán
những con đường mòn, và chức năng như gán một định danh tài liệu toàn cầu mới
tài liệu. Các lớp lịch sử có thể là một tạp chí riêng hoặc cơ sở dữ liệu hoặc có thể
được lưu trữ trong kho. Lớp trình bày là giao diện người dùng. Trong
Ngoài việc cho phép tương tác tài liệu, chẳng hạn như duyệt hoặc chỉnh sửa, các
lớp trình bày cũng có thể thực hiện kiểm soát tài liệu, chẳng hạn như chỉ đọc
truy cập hoặc cho phép.
Hệ thống wiki tiên tiến có rất nhiều các tính năng của một CMS đầy đủ. Nhiều
hệ thống CMS hiện nay bao gồm các tính năng wikilike. Hai CMS mã nguồn mở phổ biến
hệ thống là Drupal và MediaWiki.
9.2.3 Một Văn hóa của sự tôn trọng
Một trang web tài liệu sống cần có một nền văn hóa của sự tôn trọng; nếu không, mọi người
trở nên do dự để gửi hoặc cảm thấy rằng họ chỉ có thể gửi "phê duyệt" công cụ.
Chẳng hạn thương mại-off là cố hữu trong việc thực hiện một quá trình đăng kiểm duyệt.
Không chỉ ai nên chỉnh sửa các hướng dẫn kiểm tra chế độ chờ, máy phát điện,
254 Chương 9 Tài liệu
cho Chẳng hạn, nhưng các tác giả đã được phê duyệt có thể đã bị mất hoặc thay đổi gì đó trong việc đăng bản gốc. Vấn đề này có thể được giải quyết trong nhiều trường hợp bởi
cho phép ý kiến vào một trang web và quảng bá ý kiến vào nội dung khi
họ có vẻ hợp lệ cho tác giả ban đầu hoặc để đủ bình luận khác. Khi
một sai lầm chính hãng được thực hiện, kiểm soát sửa đổi có thể cho phép truy cập vào một phiên bản không thay đổi gì. Khi nó là không rõ ràng phiên bản nào là thẩm quyền, tại kiểm soát sửa đổi ít nhất có thể hiển thị một danh sách các thay đổi và cung cấp một số bối cảnh với
đó để thực hiện một cuộc gọi bản án hoặc để yêu cầu làm rõ thông qua điện thoại hoặc
email.
Mong đợi để đưa vào một chút thời gian quản lý trên wiki cho đến khi mọi người có được
hang của nó và kết hợp nó với văn hóa cụ thể của bạn. Có một mức độ chi tiết mà
sẽ là "đúng" cho nhóm của bạn, và, giống như bất kỳ loại văn bản, sẽ có một số
dấu ngoặc ở hai bên trước khi mọi thứ bắt đầu tìm kiếm như bạn cảm thấy họ cần
tìm. Một số nhóm có một hệ thống tài liệu đó là chỉ dán email
không theo thứ tự đặc biệt theo chủ đề; các nhóm khác có trang runbookstyle công phu cho mỗi phần quan trọng của cơ sở hạ tầng. Điều đáng yêu về
cách sử dụng một wiki hoặc tương tự như hệ thống tài liệu sống như một CMS tạm thời là
bạn có thể chuyển đổi từ một hệ thống đặc biệt để một hệ thống chính thức hơn
như các văn bản trưởng thành. Các trang và mục có thể được tổ chức lại và làm sạch
trong những ngày chậm và có lẽ thúc đẩy các khu vực mới hoặc xuất khẩu sang hơn
CMS chính thức.
9.2.4 Phân loại và cấu trúc
hệ thống Wiki có xu hướng áp đặt cấu trúc rất ít. Một số chỉ đơn giản là cung cấp điều hướng.
Ngay từ đầu, không dành thời gian lo lắng về cấu trúc. Một kẻ giết người chính
của dự án wiki là sự áp đặt của cấu trúc quá nhiều trong thời gian đầu
giai đoạn. Một khái niệm về hàng rào thấp để nhập cảnh sinh ra các wiki. Cập nhật một trang
nên càng dễ dàng như gửi email; nếu không, mọi người sẽ không sử dụng nó. Nó xa
tốt hơn để có để làm sạch một số trang cho dễ đọc hơn để có những thông tin
cô lập trong thư mục email của một ai đó mà không ai có thể tìm thấy nó khi ông là
vào kỳ nghỉ. Nếu một loại hình cụ thể của tài liệu sẽ được viết nhiều lần bởi
nhiều người, ví dụ, đề xuất thiết kế hoặc tính năng yêu cầu-cung cấp một
khuôn mẫu để giữ những tài liệu chính thức trong các dạng tương tự.
Phân biệt giữa văn bản tài liệu hướng dẫn và tài liệu hướng dẫn tổ chức. Theo nội dung của bạn phát triển, mọi người sẽ ngày càng sử dụng tìm kiếm chứ không phải là
loại để tìm kiếm những điều. Bạn luôn có thể tạo ra các loại cấu trúc và
cấu trúc lại các trang hoặc liên kết của họ như các wiki phát triển.
9.2 Icing 255
9.2.5 Tài liệu bổ sung Sử dụng
Dưới đây là một số cách khác để sử dụng một hệ thống tài liệu sống. Nhiều hệ thống wiki
có mẫu hay plug-ins cụ thể cho các ứng dụng này.
9.2.5.1 Tự Help Desk
Khách hàng có thể sử dụng tự giúp đỡ khu vực bàn về những trang tài liệu để tương tác
trực tiếp với trang web. Có lẽ trang web hiện tại của bạn có một Tạo một thẻ mới
liên kết cho phép khách hàng thực hiện một yêu cầu thông qua hệ thống bán vé.
Khu vực này là một nơi tốt cho các hạng mục như tin tức về cúp kế hoạch,
thông tin cập nhật về tình huống trong tiến trình, và các liên kết nổi bật với các chính sách và tài liệu howto. Ví dụ về sau này có thể là làm thế nào để đăng nhập từ xa qua
VPN, làm thế nào để thiết lập đồng bộ hóa với thiết bị di động của bạn, và như vậy.
Một mặt hàng thuộc trong khu vực bàn tự lực là tiếp cận khách hàng
để kết quả giám sát, chẳng hạn như giao thông multirouter đồ họa (MRTGs) hoặc thậm chí
danh sách kịch bản của không gian trống trên ổ đĩa được chia sẻ. Các trang web phụ thuộc nặng vào chia sẻ
giấy phép phần mềm, chẳng hạn như những người sử dụng bởi các công cụ CAD, có thể tìm thấy nó rất hữu ích để
đặt một liên kết để các tiện ích giấy phép theo dõi trên trang này, để đi off câu hỏi
về việc ai đã gì giấy phép kiểm tra ra.
9.2. 5.2 Internal Group-cụ thể Documents
SAs là sớm chấp nhận, và nhiều nhóm SA xây dựng ra một tài liệu hướng dẫn sinh hoạt
tại chỗ cho lợi ích riêng của họ. Có được thông tin về làm thế nào để thực hiện phức tạp
nhiệm vụ mà chỉ có một hoặc hai người trong nhóm thường xuyên thực hiện có thể tiết kiệm
trong ngày khi có người ra ốm hoặc gọi đi. Việc tạo ra các tài liệu groupspecific là sự khởi đầu của việc hình thành một bộ nhớ thể chế, một
phần rất quan trọng của tính liên tục cho bất kỳ nhóm.
Mặc dù nhóm SA có thể dẫn đường, bất kỳ nhóm hoặc bộ phận có thể
được hưởng lợi từ việc có khu vực riêng của mình trong trang web. Một số nhóm có một de facto sống
văn trang web trong các hình thức của một kho lưu trữ mã nguồn, trong đó có thể được sử dụng
cho thông số kỹ thuật, danh sách khách hàng, và các tài liệu tiếp thị, cũng như mã.
Do tính chất nhạy cảm của một số tài liệu hướng dẫn nhóm cụ thể, điều này khu vực
có thể có quyền truy cập hạn chế, chỉ với duy nhất nhóm và nhân viên hành chính
có thể truy cập khu vực này.
9.2.5.3 Làm thế nào-To Documents
Ở nhiều trang web, một tài liệu ngắn, tự giải thích được gọi là thế nào-To, hoặc
HOWTO, giúp khách hàng để giúp đỡ mình khi SAs là không có.
tài liệu HOWTO bao gồm một chủ đề duy nhất, nói chung là hoàn thành
một nhiệm vụ cụ thể; thường được tùy biến cho môi trường của trang web; và
256 Chương 9 Tài liệu
thường bao gồm cả đầu vào của khách hàng và đáp ứng chương trình, thường là với
ảnh chụp màn hình. Một tài liệu HOWTO được thiết kế để giải quyết một vấn đề cụ thể chứ không phải là để phục vụ như một hướng dẫn khái niệm. Các định dạng sắp xếp hợp lý,
phù hợp với môi trường, phục vụ để khuyến khích mua vào từ khách hàng
nếu không sẽ xem xét việc đọc tài liệu là quá tốn thời gian
hoặc khó khăn và sẽ mở một cuộc gọi hỗ trợ thay thế.
Ví dụ điển hình của HOWTOs bao gồm việc thiết lập một ứng dụng email, xin truy cập từ xa đến các mạng hoặc các máy chủ tập tin, truy cập vào máy in, và cấu hình phần mềm để sử dụng trong các môi trường địa phương. Các trang web đại học, trong đó
thường có một tỷ lệ rất lớn của khách hàng để SAs, lợi ích đặc biệt từ
các bàn tự giúp đỡ và như thế nào-Để tài liệu. Những trang tài liệu sử dụng quầy trợ giúp
và mức hỗ trợ trong các tổ chức của họ có thể xem xét các bản ghi máy chủ web của các
truy cập HOWTO như một thước đo để theo dõi và báo cáo.
9.2.5.4 câu hỏi thường gặp
Đối với hầu hết người sử dụng Internet, các câu hỏi thường gặp (FAQ) danh sách là một quen thuộc
công cụ. Các câu hỏi thường gặp chỉ đơn giản là một danh sách các truy vấn phổ biến nhất về một đặc biệt
chủ đề, thường được tổ chức thành các phần và các phần phụ và thường tiến triển
theo thời gian. Một số plug-ins wiki tự động tạo ra một bảng nội dung hoặc
trình bày các câu hỏi như các liên kết siêu văn bản đến các câu trả lời. (Phương pháp này có
nhược điểm làm cho nó khó khăn để đọc tất cả các câu hỏi và câu trả lời trong
trật tự hay để in hoặc tìm kiếm danh sách.)
Các câu hỏi thường gặp l
quản lý nội dung.
9.2.1 Một tài liệu Repository động
Ý tưởng về một "tài liệu sống" trang web, hoặc kho lưu trữ tài liệu năng động, chỉ đơn giản là một trang web hoặc kho lưu trữ mà các văn bản được dự kiến là
sẽ được cập nhật định kỳ để đáp ứng nhu cầu của môi trường. Các hiện tượng Internet được gọi là Wikipedia (www.Wikipedia.org) là một tuyệt vời
ví dụ của loại hệ thống này. Bắt đầu với bản gốc Wiki Encyclopedia, hàng chục nhóm đã tạo ra kho nội dung đặc biệt quan tâm về
mô hình này. Ngược lại với một kho lưu trữ tài liệu truyền thống, một kho lưu trữ tài liệu sống thay đổi sự tập trung vào sự tương tác của khách hàng với các
tài liệu. Thay vì việc có thể chỉ đơn thuần là xác định vị trí và đọc một tài liệu,
khách hàng có thể chú thích, chỉnh sửa, thu thập tài liệu vào quan điểm, gửi tài liệu
tham khảo cho các đồng nghiệp, và như vậy.
Mặc dù chúng tôi sử dụng một wiki như các ví dụ cơ bản của một tài liệu sống
site, nó quan trọng là phải lưu ý rằng điều này không có nghĩa là tất cả mọi thứ phải được
tích hợp vào wiki. Nó là đủ để có một điểm trung tâm để tổ chức
thông tin, bao gồm cả các liên kết đến các hệ thống thông tin khác.
9.2 Icing 253
Sử dụng Wiki khác nhau cho các tình trạng khác nhau
các gói phần mềm khác nhau có điểm mạnh khác nhau. Một trang web được tìm thấy rằng nó là
tốt hơn để duy trì DokuWiki cho các tài liệu hỗ trợ khách hàng phải đối mặt với nó, Trác cho
tài liệu và theo dõi vé liên quan đến mã nguồn phát triển nội bộ, và RT cho
các yêu cầu theo dõi tiếp với khách hàng. Các trang web tìm thấy rằng nó là hiếm hoi mà các văn bản
liên kết ngang, và khi họ đã làm, đó là dễ dàng để sao chép và dán hoặc siêu liên kết để cầu
cho họ.
9.2.2 Một hệ thống Content-Quản lý
Một hệ thống quản lý nội dung (CMS) là một ấn phẩm hệ thống cho các trang web.
Ví dụ, một hệ thống CMS báo có thể tạo thuận lợi cho quá trình phóng tạo ra những câu chuyện, sau đó được xếp hàng đợi để biên tập, chỉnh sửa, và đã được phê duyệt để xuất bản. Các hệ thống CMS phát hành thông tin tại một cụ thể
thời gian, đặt nó trên trang web, cập nhật các bảng nội dung, và chăm sóc
của các chi tiết khác. Đối với một trang web IT, CMS có thể cho phép các plug-in cung cấp cho cổng thông tin
tính năng, chẳng hạn như bản tóm tắt của cúp gần đây.
Một số tính năng được yêu cầu để thực hiện một chức năng CMS. Một
hệ thống quản lý nội dung cụ thể bao gồm ba lớp: kho lưu trữ,
lịch sử, và trình bày. Lớp kho thường là một cơ sở dữ liệu nhưng
cũng có thể là một hệ thống tập tin cấu trúc với các siêu dữ liệu. Các nội dung được lưu trữ trong
lớp này. Các lớp lịch sử đã kiểm soát phiên bản, cấp phép, kiểm toán
những con đường mòn, và chức năng như gán một định danh tài liệu toàn cầu mới
tài liệu. Các lớp lịch sử có thể là một tạp chí riêng hoặc cơ sở dữ liệu hoặc có thể
được lưu trữ trong kho. Lớp trình bày là giao diện người dùng. Trong
Ngoài việc cho phép tương tác tài liệu, chẳng hạn như duyệt hoặc chỉnh sửa, các
lớp trình bày cũng có thể thực hiện kiểm soát tài liệu, chẳng hạn như chỉ đọc
truy cập hoặc cho phép.
Hệ thống wiki tiên tiến có rất nhiều các tính năng của một CMS đầy đủ. Nhiều
hệ thống CMS hiện nay bao gồm các tính năng wikilike. Hai CMS mã nguồn mở phổ biến
hệ thống là Drupal và MediaWiki.
9.2.3 Một Văn hóa của sự tôn trọng
Một trang web tài liệu sống cần có một nền văn hóa của sự tôn trọng; nếu không, mọi người
trở nên do dự để gửi hoặc cảm thấy rằng họ chỉ có thể gửi "phê duyệt" công cụ.
Chẳng hạn thương mại-off là cố hữu trong việc thực hiện một quá trình đăng kiểm duyệt.
Không chỉ ai nên chỉnh sửa các hướng dẫn kiểm tra chế độ chờ, máy phát điện,
254 Chương 9 Tài liệu
cho Chẳng hạn, nhưng các tác giả đã được phê duyệt có thể đã bị mất hoặc thay đổi gì đó trong việc đăng bản gốc. Vấn đề này có thể được giải quyết trong nhiều trường hợp bởi
cho phép ý kiến vào một trang web và quảng bá ý kiến vào nội dung khi
họ có vẻ hợp lệ cho tác giả ban đầu hoặc để đủ bình luận khác. Khi
một sai lầm chính hãng được thực hiện, kiểm soát sửa đổi có thể cho phép truy cập vào một phiên bản không thay đổi gì. Khi nó là không rõ ràng phiên bản nào là thẩm quyền, tại kiểm soát sửa đổi ít nhất có thể hiển thị một danh sách các thay đổi và cung cấp một số bối cảnh với
đó để thực hiện một cuộc gọi bản án hoặc để yêu cầu làm rõ thông qua điện thoại hoặc
email.
Mong đợi để đưa vào một chút thời gian quản lý trên wiki cho đến khi mọi người có được
hang của nó và kết hợp nó với văn hóa cụ thể của bạn. Có một mức độ chi tiết mà
sẽ là "đúng" cho nhóm của bạn, và, giống như bất kỳ loại văn bản, sẽ có một số
dấu ngoặc ở hai bên trước khi mọi thứ bắt đầu tìm kiếm như bạn cảm thấy họ cần
tìm. Một số nhóm có một hệ thống tài liệu đó là chỉ dán email
không theo thứ tự đặc biệt theo chủ đề; các nhóm khác có trang runbookstyle công phu cho mỗi phần quan trọng của cơ sở hạ tầng. Điều đáng yêu về
cách sử dụng một wiki hoặc tương tự như hệ thống tài liệu sống như một CMS tạm thời là
bạn có thể chuyển đổi từ một hệ thống đặc biệt để một hệ thống chính thức hơn
như các văn bản trưởng thành. Các trang và mục có thể được tổ chức lại và làm sạch
trong những ngày chậm và có lẽ thúc đẩy các khu vực mới hoặc xuất khẩu sang hơn
CMS chính thức.
9.2.4 Phân loại và cấu trúc
hệ thống Wiki có xu hướng áp đặt cấu trúc rất ít. Một số chỉ đơn giản là cung cấp điều hướng.
Ngay từ đầu, không dành thời gian lo lắng về cấu trúc. Một kẻ giết người chính
của dự án wiki là sự áp đặt của cấu trúc quá nhiều trong thời gian đầu
giai đoạn. Một khái niệm về hàng rào thấp để nhập cảnh sinh ra các wiki. Cập nhật một trang
nên càng dễ dàng như gửi email; nếu không, mọi người sẽ không sử dụng nó. Nó xa
tốt hơn để có để làm sạch một số trang cho dễ đọc hơn để có những thông tin
cô lập trong thư mục email của một ai đó mà không ai có thể tìm thấy nó khi ông là
vào kỳ nghỉ. Nếu một loại hình cụ thể của tài liệu sẽ được viết nhiều lần bởi
nhiều người, ví dụ, đề xuất thiết kế hoặc tính năng yêu cầu-cung cấp một
khuôn mẫu để giữ những tài liệu chính thức trong các dạng tương tự.
Phân biệt giữa văn bản tài liệu hướng dẫn và tài liệu hướng dẫn tổ chức. Theo nội dung của bạn phát triển, mọi người sẽ ngày càng sử dụng tìm kiếm chứ không phải là
loại để tìm kiếm những điều. Bạn luôn có thể tạo ra các loại cấu trúc và
cấu trúc lại các trang hoặc liên kết của họ như các wiki phát triển.
9.2 Icing 255
9.2.5 Tài liệu bổ sung Sử dụng
Dưới đây là một số cách khác để sử dụng một hệ thống tài liệu sống. Nhiều hệ thống wiki
có mẫu hay plug-ins cụ thể cho các ứng dụng này.
9.2.5.1 Tự Help Desk
Khách hàng có thể sử dụng tự giúp đỡ khu vực bàn về những trang tài liệu để tương tác
trực tiếp với trang web. Có lẽ trang web hiện tại của bạn có một Tạo một thẻ mới
liên kết cho phép khách hàng thực hiện một yêu cầu thông qua hệ thống bán vé.
Khu vực này là một nơi tốt cho các hạng mục như tin tức về cúp kế hoạch,
thông tin cập nhật về tình huống trong tiến trình, và các liên kết nổi bật với các chính sách và tài liệu howto. Ví dụ về sau này có thể là làm thế nào để đăng nhập từ xa qua
VPN, làm thế nào để thiết lập đồng bộ hóa với thiết bị di động của bạn, và như vậy.
Một mặt hàng thuộc trong khu vực bàn tự lực là tiếp cận khách hàng
để kết quả giám sát, chẳng hạn như giao thông multirouter đồ họa (MRTGs) hoặc thậm chí
danh sách kịch bản của không gian trống trên ổ đĩa được chia sẻ. Các trang web phụ thuộc nặng vào chia sẻ
giấy phép phần mềm, chẳng hạn như những người sử dụng bởi các công cụ CAD, có thể tìm thấy nó rất hữu ích để
đặt một liên kết để các tiện ích giấy phép theo dõi trên trang này, để đi off câu hỏi
về việc ai đã gì giấy phép kiểm tra ra.
9.2. 5.2 Internal Group-cụ thể Documents
SAs là sớm chấp nhận, và nhiều nhóm SA xây dựng ra một tài liệu hướng dẫn sinh hoạt
tại chỗ cho lợi ích riêng của họ. Có được thông tin về làm thế nào để thực hiện phức tạp
nhiệm vụ mà chỉ có một hoặc hai người trong nhóm thường xuyên thực hiện có thể tiết kiệm
trong ngày khi có người ra ốm hoặc gọi đi. Việc tạo ra các tài liệu groupspecific là sự khởi đầu của việc hình thành một bộ nhớ thể chế, một
phần rất quan trọng của tính liên tục cho bất kỳ nhóm.
Mặc dù nhóm SA có thể dẫn đường, bất kỳ nhóm hoặc bộ phận có thể
được hưởng lợi từ việc có khu vực riêng của mình trong trang web. Một số nhóm có một de facto sống
văn trang web trong các hình thức của một kho lưu trữ mã nguồn, trong đó có thể được sử dụng
cho thông số kỹ thuật, danh sách khách hàng, và các tài liệu tiếp thị, cũng như mã.
Do tính chất nhạy cảm của một số tài liệu hướng dẫn nhóm cụ thể, điều này khu vực
có thể có quyền truy cập hạn chế, chỉ với duy nhất nhóm và nhân viên hành chính
có thể truy cập khu vực này.
9.2.5.3 Làm thế nào-To Documents
Ở nhiều trang web, một tài liệu ngắn, tự giải thích được gọi là thế nào-To, hoặc
HOWTO, giúp khách hàng để giúp đỡ mình khi SAs là không có.
tài liệu HOWTO bao gồm một chủ đề duy nhất, nói chung là hoàn thành
một nhiệm vụ cụ thể; thường được tùy biến cho môi trường của trang web; và
256 Chương 9 Tài liệu
thường bao gồm cả đầu vào của khách hàng và đáp ứng chương trình, thường là với
ảnh chụp màn hình. Một tài liệu HOWTO được thiết kế để giải quyết một vấn đề cụ thể chứ không phải là để phục vụ như một hướng dẫn khái niệm. Các định dạng sắp xếp hợp lý,
phù hợp với môi trường, phục vụ để khuyến khích mua vào từ khách hàng
nếu không sẽ xem xét việc đọc tài liệu là quá tốn thời gian
hoặc khó khăn và sẽ mở một cuộc gọi hỗ trợ thay thế.
Ví dụ điển hình của HOWTOs bao gồm việc thiết lập một ứng dụng email, xin truy cập từ xa đến các mạng hoặc các máy chủ tập tin, truy cập vào máy in, và cấu hình phần mềm để sử dụng trong các môi trường địa phương. Các trang web đại học, trong đó
thường có một tỷ lệ rất lớn của khách hàng để SAs, lợi ích đặc biệt từ
các bàn tự giúp đỡ và như thế nào-Để tài liệu. Những trang tài liệu sử dụng quầy trợ giúp
và mức hỗ trợ trong các tổ chức của họ có thể xem xét các bản ghi máy chủ web của các
truy cập HOWTO như một thước đo để theo dõi và báo cáo.
9.2.5.4 câu hỏi thường gặp
Đối với hầu hết người sử dụng Internet, các câu hỏi thường gặp (FAQ) danh sách là một quen thuộc
công cụ. Các câu hỏi thường gặp chỉ đơn giản là một danh sách các truy vấn phổ biến nhất về một đặc biệt
chủ đề, thường được tổ chức thành các phần và các phần phụ và thường tiến triển
theo thời gian. Một số plug-ins wiki tự động tạo ra một bảng nội dung hoặc
trình bày các câu hỏi như các liên kết siêu văn bản đến các câu trả lời. (Phương pháp này có
nhược điểm làm cho nó khó khăn để đọc tất cả các câu hỏi và câu trả lời trong
trật tự hay để in hoặc tìm kiếm danh sách.)
Các câu hỏi thường gặp l
đang được dịch, vui lòng đợi..
Các ngôn ngữ khác
Hỗ trợ công cụ dịch thuật: Albania, Amharic, Anh, Armenia, Azerbaijan, Ba Lan, Ba Tư, Bantu, Basque, Belarus, Bengal, Bosnia, Bulgaria, Bồ Đào Nha, Catalan, Cebuano, Chichewa, Corsi, Creole (Haiti), Croatia, Do Thái, Estonia, Filipino, Frisia, Gael Scotland, Galicia, George, Gujarat, Hausa, Hawaii, Hindi, Hmong, Hungary, Hy Lạp, Hà Lan, Hà Lan (Nam Phi), Hàn, Iceland, Igbo, Ireland, Java, Kannada, Kazakh, Khmer, Kinyarwanda, Klingon, Kurd, Kyrgyz, Latinh, Latvia, Litva, Luxembourg, Lào, Macedonia, Malagasy, Malayalam, Malta, Maori, Marathi, Myanmar, Mã Lai, Mông Cổ, Na Uy, Nepal, Nga, Nhật, Odia (Oriya), Pashto, Pháp, Phát hiện ngôn ngữ, Phần Lan, Punjab, Quốc tế ngữ, Rumani, Samoa, Serbia, Sesotho, Shona, Sindhi, Sinhala, Slovak, Slovenia, Somali, Sunda, Swahili, Séc, Tajik, Tamil, Tatar, Telugu, Thái, Thổ Nhĩ Kỳ, Thụy Điển, Tiếng Indonesia, Tiếng Ý, Trung, Trung (Phồn thể), Turkmen, Tây Ban Nha, Ukraina, Urdu, Uyghur, Uzbek, Việt, Xứ Wales, Yiddish, Yoruba, Zulu, Đan Mạch, Đức, Ả Rập, dịch ngôn ngữ.
- thứ hai,máy tính ảnh hưởng đến kết quả h
- Come round to
- dimond là cái gì hả bạn
- hôm nay là một ngày chủ nhật đẹp trời. t
- hien thi
- 2.4 Phụ tải tính toán căn hộ D:Bảng 2.9
- What else is there?
- Reinforcements were sent.We should get o
- nouvo after
- I have an account with apple. From Frida
- ,,hello my love just now I am.at Paris b
- Đèn huỳnh quang 1,2m- 2 bóngĐèn huỳnh qu
- • 3/2015: Tham gia sinh hoạt tại phường,
- Hôm nay là ngày bao nhiêu. Ngày 18 tháng
- drinking coke
- 4.1.3. Fishing vessel economicsIn this s
- GIFT CODE
- Hôm nay là ngày bao nhiêu. Ngày 18 tháng
- . 直到一切尘埃落定, 该死的人都已经死了
- Hoạt động thanh toán theo phương thức nh
- Du khách nghỉ dưỡng ở Nam Hai resort đa
- Hoạt động thanh toán theo phương thức nh
- Hôm nay ông ấy cảm thấy sức khỏe tốt
- KHI BẠN ĐÃ VỮNG VÀNG TRONG CÔNG VIỆC VÀ
