Why Use A Wiki: An Introduction to the Latest Online Publishing Format

WHY USE A WIKI?
An Introduction to the Latest Online
Publishing Format

A WebWorks.com White Paper

Author:
Alan J. Porter
VP-Operations
WebWorks.com
a brand of Quadralay Corporation
aporter@webworks.com

WW_WP0309_WIKIpub
© 2009 – Quadralay Corporation. All rights reserved.

NOTE: Please feel free to redistribute this white paper to anyone you feel may
benefit. If you would like an electronic copy for distribution, just send an e-mail to
info@webworks.com

CONTENTS
Overview ................................................................................................................................ 2
What is a Wiki? ...................................................................................................................... 2
Open Editing = Collaborative Authoring .................................................................................. 3
Wikis in More Detail................................................................................................................ 3
Wikis Are Everywhere ............................................................................................................ 4
Why Use a Wiki...................................................................................................................... 5
Getting People to Use Wikis ................................................................................................... 8
Populating the Wiki................................................................................................................. 9
WebWorks ePublisher and Wikis ............................................................................................ 9
Conclusions ..........................................................................................................................10
Additional Resources.............................................................................................................10
WebWorks Wikis ...................................................................................................................10
About ePublisher ...................................................................................................................11
About WebWorks.com...........................................................................................................11
Contact .................................................................................................................................11

Overview
The aim of this paper is to introduce the concept of the Web-based collaborative authoring environment
commonly referred to as wikis, and examine how they can be used in a corporate publishing environment.
The paper also includes suggested techniques for transferring existing content from native authoring tools
into a wiki format for online delivery.

What is a Wiki?
In simple terms a wiki is perhaps best described as a Web site that can be easily edited by anyone
straight in the Web browser without need for any additional software.

The official definition of a wiki, by the wiki creator Ward Cunnigham in his book “The Wiki Way: Quick
Collaboration on the Web,” gives a slightly more detailed definition.

Cunningham describes the concept of wikis this way:

 A wiki invites all users to edit any page or to create new pages within the wiki Web site, using
only a plain-vanilla Web browser without any extra add-ons.
 Wiki promotes meaningful topic associations between different pages by making page link
creation almost intuitively easy and showing whether an intended target page exists or not.
 A wiki is not a carefully crafted site for casual visitors. Instead, it seeks to involve the visitor in an
ongoing process of creation and collaboration that constantly changes the Web site landscape.

From a publishing perspective, a wiki gives a means for documents to be created collaboratively among a
group of authors without those contributors needing to learn a complex mark-up language. The basic
premise can be very powerful in opening up content creation to subject matter experts and knowledge
holders.

But wikis are far more than a simple collection of documents. Individual wiki pages can be easily linked to
other wiki pages through a series of hyperlinks, thereby creating what is essentially a database that can
be browsed, navigated, and searched.

Page 2 of 11 Wiki Publishing WW-WP0309_WIKIpub
© 2009 – Quadralay Corporation

Open Editing = Collaborative Authoring
Perhaps the most significant aspect of a wiki is how easy it is to create and update pages. In most wiki
installations there is no review process before modifications are accepted, with changes appearing almost
instantly.

This facility, while one of a wiki’s biggest advantages, is also perhaps the area of greatest controversy
and concern to those new to wiki publishing.

Does having open access lead to chaos and devaluation of the material?

Most wikis require that anyone who wishes to contribute first register a user account. Depending on the
wiki setup different type of accounts can be given different access and editing privileges. It is also
recommended that wikis be set up with a login needed at the start of an editing session to create a wiki
signature cookie to enable tracking of who makes edits.

The driving philosophy behind wikis is to encourage peer review and to make it easier to input material
and correct mistakes, rather than putting up barriers that make it difficult to contribute in the hope of
preventing mistakes.

Wikis in More Detail
As mentioned earlier, the content of a wiki can have structure and formatting applied through the use of a
simple mark-up language, usually referred to as wikitext. For instance, most wikis use a simple asterisk
(*) to indicate a bulleted list. This is a lot simpler than, for instance, the same code in HTML for display on
a traditional Web site.

Wikitext HTML Code Formatted Content
* This is a bulleted list item <ul><li>This is a bulleted list  This is a bulleted list item
item.</li></ul>

Note that the style of wikitext markup can vary between different types of wikis, and some wikis will allow
the use of HTML coding too.

The reason for using a simpler mark-up syntax is that HTML coding can get very complex, making it
difficult to easily differentiate and edit the content. This complexity can also act as a significant barrier to
contribution. Most wikis favor plain-text editing. An increasing number of wikis, especially those designed
for more general public usage, are incorporating WYSIWYG type editing interfaces.

Many types of wikis allow users to include an edit summary, usually just a few lines, describing why they
have made the changes they have. This information is not displayed, but kept as part of the page’s
history. Most wikis keep a record of changes; in fact, they usually keep a copy of each version of a page,
enabling simple “rollback” to a previous version if required. Some wikis also include a “diff” functionality so
that different versions of a given page can be easily compared. This amounts to a simple content
management / revision control system that is included as part of the wiki implementation, providing
functionality only previously available through separate and expensive third-party applications.

Navigation between the pages of a wiki is achieved through the use of hypertext links. This technique
generally leads to a flat navigation structure rather than a more formalized hierarchical structure. Links
are created in wikis using a simple syntax, and it is a common practice in wikis to create a link to a page
that does not yet exist in the hope that the existence of the link will encourage another participant to
supply the required content for the missing page. Many wikis also include a backlink feature so you can


see which pages link to the page you may be working on, or see what other topics reference the one you
are reading. Despite the inherently flat structure of wikis, it is still possible to create more traditional
hierarchical navigation tools such as a table of contents.

The flat, some would say anarchic, format of wikis can present a management and maintenance
challenge. To help with this most wikis provide ways of categorizing and tagging pages.

Studies have shown that among the current “Internet generation” the first reaction of over 50% of users
when they need to find information is to use a search tool, like Google, rather than navigate through a
series of steps. Wikis support this growing behavior pattern as most offer at least a title-based search,
and many also include full-text search capability. The performance and scalability of these searches can
vary depending on whether the wiki engine uses an underlying database. Several wikis will also support
the integration of third-party specialist search engines such as Google.

Wikis Are Everywhere
Wikis were initially used within enterprise-based technical communities as a collaborative software
platform. Once the flexibility of wikis started to be appreciated the uses expanded and today they are
used for things such as project communication, intranets, and documentation. Many companies have
totally replaced old static HTML-based intranets with collaborative wikis. While there are still probably
more wiki implementations behind corporate firewalls than on the public Internet, that landscape is also
changing, with more and more wikis being made available for public usage.

One example of this trend can be seen with the adoption and use of wiki by the WebWorks.com team.

 2003 – First wiki was installed for use by the software development team.
 2005 – A Project wiki (Trac) was selected for use by the services group to communicate with
customers. Access was controlled behind the firewall between the services group and selected
customers.
 2006 – Internal and external wiki software (MoinMoin) was selected as the standard WebWorks
wiki platform.
 2006 – The development wiki expanded to become a company-wide Inner wiki replacing a static
HTML Web-page-based intranet.
 2007 - An external Help Center wiki was launched (wiki.webworks.com) with access by request.
Customer contributions are welcomed and encouraged.
 2007 – Showed “proof of concept” wiki publishing demo at RoundUp Users Conference.
 2008 – The RoundUp wiki launched (webworksroundup.com) as a collaborative tool for
organizing and posting information about the WebWorks Users Conference, replacing a
traditional Web site.
 2008 – First practical use of “publish to wiki” with launch of WebWorks Documentation Wiki
(docs.webworks.com) with merged content from FrameMaker, MS-Word and DITA-XML sources
used to automatically deliver both PDF, help sets and wiki pages online simultaneously, and give
customers access to wiki feedback features.

At the time of writing the WebWorks team uses and maintains five wiki installations: two internal (the
MoinMoin corporate information wiki and the Trac projects wiki), and three external wikis that our
customers can access and use (the RoundUp conference wiki, the Help Center wiki, and the
Documentation wiki.)

In the space of just five years the wiki platform has gone from being just a technical tool used by a small
number of developers to something that is an essential part of our business operations. In fact we
consider ourselves to be a “wiki-driven company.”


Outside of corporate use wikis are also gaining wider acceptance and use in the consumer market.
Wikipedia, the online collaborative wiki-based encyclopedia, has become one of the most visited sites on
the Internet, and for many people has replaced textbooks as their default source of information about
almost everything.

Wikis are also replacing Web-rings and other similar groupings of Web sites among special-interests
groups. Instead of people with a shared interest creating their own Web sites (often duplicating
information) and sharing cross links, these groups are now creating a wiki where people can share
information in a central, searchable repository.

Wikis are also gaining popularity as individual productivity tools. A personal wiki can be used as a
notepad, a repository of Web links, or a scratch pad to capture ideas and information. Some vendors offer
centralized wiki farms, which hosts individual wiki instances. Other wiki vendors have versions of their
wikis that can be downloaded to a local machine or even run off a flash drive. Using a wiki as a personal
productivity tool gives the advantage that it is platform- and browser-independent, so you can access it
and use it from any machine, anywhere.

If wikis have one negative aspect at the moment, it is the simple fact that there are so many different
types of wikis available. The potential confusion isn’t helped by the fact that there is, as yet, no agreed
standard for the wikitext mark-up language.

The first attempt at standardizing wikis has been based on the already existing XML-based remote call
procedure (RPC). Although not originally designed for wikis, XML-RPC can be used between wikis that
use XML as their encoding mark-up language. This standard is currently only supported by a handful of
wikis, but its use is spreading.

Despite the apparent plethora of wiki choices, there are a few that are emerging as market leaders and it
only takes a short amount of research to establish which wikis are best suited for a particular application.
As mentioned earlier, the WebWorks team standardized on the MoinMoin wiki for most uses, but retained
the Trac wiki for project management. Wikipedia is based on the popular MediaWiki format, while
Confluence is another popular implementation in the corporate world. The best way to pick a wiki is to
decide what you want to use it for and what usability and functions you need, then do some research on
what other people have used.

Why Use a Wiki

The Good
There are many advantages to setting up a wiki for use in a corporate environment. The following is a list
based on our own experience at WebWorks.

Easy to set up – Ease of setup can vary from wiki to wiki. The MoinMoin wiki that we
standardized on is very easy and quick to set up. It also comes in desktop and personal versions
that can even be run from a flash drive if required. Setup can be achieved in less than an hour for
a personal implementation and in just a few hours for a corporate version. Note that some of the
other wikis can be more complex to set up and may also need the installation of other tools (such
as an underlying SQL database) and IT-level configuration of the Web server.

Easy to use – Navigating a wiki is intuitive and usually means using a familiar Google-like search
and then simply clicking on links in the search results to navigate to the page you want. Related
information within the page is shown by hyperlinks, while some wikis also keep a track of the
pages you have visited and show an interactive “bread crumb” trail so you can backtrack if
needed.


Easy to edit – Most wikis can be edited by a simple click of an “edit” button. With more wikis
adopting WYSIWYG interfaces the edit controls will be similar to those found in a popular word
processor. If you do need to use a specific wikitext markup language, they are invariably easy to
learn and the basics can be mastered in minutes.

Anyone can edit them – The fact that wikis are open and easy to use means that people from all
over the company can contribute content, comment, and discuss as needed, reducing reliance on
production bottlenecks and expensive training in unfamiliar tools that might only be needed on an
occasional basis.

Just load, populate, and go – As mentioned earlier, a wiki can be set up in a very short time. Of
course for a wiki to be useful it needs data. Once the initial population of data is complete it’s
ready for use by anyone in the company. They can then quickly become a valued contributor and
the wiki can become a growing information resource in a short time.

Enabling collaboration – By lowering the barriers to entry, wikis encourage collaboration.
Teams can work together to easily produce documents, project plans, etc. And each member of
the team can easily track progress and make comments on other contributions.

User-generated content – No one knows your product or service like your customers. They are
the ones who use it every day. By having an accessible wiki you can leverage that expertise by
encouraging your customers (internal and external) to document their experiences, make
suggestions, and even let you know about new ways they have found to use your product. By
using a wiki, publishing of product information is no longer a one-way broadcast of knowledge; it
becomes a feedback loop based on shared experiences.

Tagging – Most wikis allow the use of categories and tagging, familiar to many from various Web
2.0 tools such as blogs and various social networks. Using tags and categories can replace
traditional hierarchical navigation techniques, replacing an enforced taxonomy with a user-driven
folksonomy that will give a better indication of what information the wiki users are really interested
in.

Version control – Most wikis include a version control capability that lets the user see the history
of the page, and if required open an earlier version and compare it with the current version of the
page. This is functionality that until a few years ago required a special document or content
management system.

Change tracking – As well as version control, most wikis include a “Recent Changes” function
that allows a user to see what changes have been made in a set timeframe. The changes are
tagged with time and date stamps and the user name of the person who made the last change.
Most wikis also include an optional “reason for change” field that is kept as metadata separate
from, but linked to, the changed content. It is also possible with some wikis to set up an RSS feed
so that recent changes can be monitored from an external application.

Reduced training costs – As wiki usage is largely intuitive, and many of the skills and
techniques used with a regular word processor and surfing the Web apply, the learning curve is
very shallow and short in duration. At WebWorks our initial wiki training session for the staff was
just two hours, and has been followed up by the occasional 30-minute lunchtime “brown-bag”
session if any major changes or software upgrades have been made.

Cross-functional cooperation – As stated above, a wiki can be used by anyone. Wiki usage
removes departmental boundaries and the need for specialized tools, skills, and training.

Enables agile development process – A wiki is the ideal tool for companies, such as
WebWorks, that use an agile development process. The wiki enables a team-driven approach
where information needs to be shared, communicated, and discussed in a short timeframe.


Can be used to capture corporate knowledge – As much as 60% of corporate information is
trapped in e-mail threads and as attachments that are never downloaded and shared. By
encouraging people to post the information to a wiki instead, and just e-mail the hyperlink to the
wiki page, companies can drastically reduce the risk of “lost” information, and also reduce
unnecessary duplication of effort. By reinforcing the “put it on the wiki” message a wiki can quickly
become a usable corporate knowledge base.

Keeps everyone informed – A well-maintained centralized wiki that is frequently updated and
seen to be a living repository of useful information can quickly become an information resource
that is trusted as the “depository of record” and an approved source of information.

The Bad
While wikis are a great enabling tool with vast potential for improving many aspects of your business, they
aren’t perfect. Listed below are some areas of wiki usage that you need to give serious consideration to
before implementation.

Anyone can edit them – While an open wiki encourages collaboration, you may not want
everyone to see and be able to edit everything on a wiki. By enforcing the need for a user login,
you can then restrict access and editing rights as needed. You may want to restrict some
information to particular groups, or you may want particular groups to have full edit authority in
some areas, but only be able to comment on other areas. This can all be controlled through
applying different access controls to named groups and user accounts. However, beware that
being too restrictive will undermine the reasons for implementing a wiki in the first place. The
philosophy behind wikis is to make it easy to contribute and correct, rather than trying to prevent
“mistakes” by putting up barriers.

User-generated content – The main consideration with encouraging user-generated feedback is
that, if not correctly organized, labeled, and managed, it can easily blur the lines between what is
”official” information and what isn’t. If you are encouraging users to contribute content then it
needs to be done in a controlled way.

Information overload – Wikis can grow very quickly, and if not monitored topics and pages can
be duplicated. There can also be a tendency to overload the wiki with irrelevant information
(although some may argue that nothing is irrelevant on a wiki). Inevitably some pages will
become “orphaned” and may need to be deleted to avoid redundancy.

Not everyone will contribute – No matter how you try you will not be able to get everyone to
contribute. Some people have a natural built-in reluctance to sharing in an open forum. Wikis are
best if they grow naturally, and through peer usage. Don’t mandate wiki contribution; let it spread
naturally. The section below contains some ideas on how to get people to contribute based on
our experience at WebWorks.

Wikis need maintenance – For a wiki to be useful it needs to be maintained. Maintenance
includes user administration, cleanup, structural organization, relocating or deleting orphaned
pages, etc. However, any company or group that has experience in maintaining a static HTML-
page-based Web site will find that maintaining a wiki is a lot less work.

You need to pick a wiki – As noted earlier, there is currently no standard for wikis, and the
features and functions can vary from wiki to wiki. You need to do some research to define which
wiki best suits your requirements. You also need to establish a migration path for your data in
case you decide to change to another wiki format (or a standard emerges) at a later date.


Getting People to Use Wikis

In the previous section I mentioned that it is impossible to get a 100% contribution to a wiki. The best we
ever achieved for the internal wiki at WebWorks was 90%. At the time of this writing, about 70% of the
company contributes something on an occasional basis, with about 50% being active wiki contributors.
The following are a few tips and techniques that we find useful in achieving that level of participation.

Social feedback – One of the best ways to ensure continuation of wiki contribution is to
acknowledge the contributions as they are made. A simple verbal “Thanks for posting that great
information on the wiki” from a fellow team member or manager will help reinforce the value of the
contribution. A verbal acknowledgement will also encourage others who hear it to contribute.

Seed the wiki – While the main focus of the wiki may be technical, you can speed acceptance by
seeding the wiki with other topics that may have a broader appeal. For instance, one of the things
we use the wiki for at WebWorks is organizing the company holiday party – something that
everyone was interested in and wanted information on. By asking for menu suggestions and
comments we also introduced the idea of using the wiki for feedback and commenting.

Feedback for contribution – Nothing encourages contributions like receiving feedback. Make
sure that every contributor gets some meaningful feedback. Of course too much meaningless
feedback soon becomes valueless, so it is a fine balancing act. The main thing to ensure is that
the feedback, either verbally or on the wiki itself (not by e-mail), adds value.

Keep as open as possible – While you may want to impose some initial structure, it should be
very minimal – ideally only top-level categories like department or projects. This way the wiki user
community will build the structure that best fits their own information retrieval requirements.

Senior involvement and buy in – While senior managers may approve of and want to promote
a wiki, it will not gain any credence unless they also participate. Good wiki practice and
contribution levels will only happen if key stakeholders and sponsors also participate. At
WebWorks every member of the executive management team is a frequent contributor to the
wiki; in fact, the wiki is a central part of the way we conduct all of our business activities.

Design for the culture, not the process – Do not model the initial wiki structure on an existing
paper process. Wikis function best when they grow organically in response to the culture of the
group using them. Having said that, a more formal organization may find greater acceptance with
some appropriate level of recognizable structure applied. You need to determine what “level of
chaos” you are comfortable with. You will also need to do a periodic review to see if the content
needs to be reorganized. We have done at least three complete reorganizations of the content
structure of the WebWorks inner wiki since its inception to reflect changes in our business and
our team’s structure and personality mix.

You need a wiki maven – You will need either a person or group that is passionate about the
wiki, not only its underlying technology, but in promoting its business benefits and use. (As you
are reading this white paper – perhaps it’s you?)

It takes cheerleaders to bring others to the wiki – Wikis are a social network, and like all good
Web 2.0 type social networks it grows and functions best through recommendation. Collect
stories about how a wiki makes life easier for people and teams to deliver on their objectives.
Encourage people to share those stories. “I found that out on the wiki,” should become a
catchphrase.


Populating the Wiki
So you’ve decided that a wiki can bring benefits to your business, improve your team’s performance, and
become a great knowledge base. You’ve done the research, selected a wiki you want to use, and made
some decisions about structure, access rights, and management tasks. Now you want to seed the wiki
with information that you already have in the company, in either HTML pages, XML, FrameMaker, or
Word documents.

How do you go about importing all that information?

Until recently there were only a few choices:
- Some wikis had dedicated one-way filters from a selected editing environment. This would be fine if
all your information is just in Word and the destination wiki just happened to fit your needs.
- Cut and paste the content over from the source document into the wiki and pray that the formatting
transferred. Invariably this means doing some clean-up work.
- Retype the selected content and apply the wikitext markup through the wiki editing interface.

In the fall of 2008 that changed with the release of the 2008.3 version of the WebWorks ePublisher
platform.

WebWorks ePublisher and Wikis

The 2008.3 release of the WebWorks ePublisher platform in the fall of 2008 included the first
commercially available multi-input / multi-output “Publish to Wiki”™ functionality. First unveiled at the
WebWorks 2007 RoundUp Users Conference and subsequently shown at Doc Train West and the STC
National Summit during 2008, the “Publish to Wiki”™ concept was met with enthusiasm from industry
experts and customers considering moving to the wiki format for delivering online content.

This functionality supports ePublisher’s automation workflow, and gives publishing teams the ability to
convert existing information developed in Adobe FrameMaker or Microsoft Word or to the DITA-XML
standard, and deploy it to wikis that support the Wiki XML-RPC standard as well as the popular
MediaWiki format, without having to do any manual conversion or mark-up. The ePublisher “Publish to
Wiki”™ functionality saves hundreds of hours for companies wishing to embrace the latest in online
publishing technology. Once content has been converted, publishing teams can take advantage of wiki
technology to enable feedback via commenting, tagging, version rollback, and even user-enabled editing
if required.

WebWorks is further supporting the move to wiki distribution by publishing ePublisher 2008.3
documentation on a dedicated wiki site at http://docs.webworks.com. Tony McDow, CEO and founder of
Quadralay, said that “The ePublisher Fall 2008 release marks another significant milestone for the
WebWorks.com team, opening up the power of ePublisher to a new generation of content publishers who
are embracing Web 2.0 technology.”


Conclusions
Are wikis the next step in online publishing, as recent industry buzz would tend to suggest? Wikis have a
lot of things in their favor: You don’t need to be a programmer or learn a new mark-up language or
esoteric standard in order to set one up and use it, they are inexpensive (some are even free), and above
all you will find that passionate people will share.

Yes there are issues to think about, such as planning and management, but that is true of any information
system irrespective of the technology it is based on. Initial population of wikis used to be an issue, but
that obstacle has been removed with the release of ePublisher’s “Publish to Wiki”™ functionality.

Every branch of publishing is looking at wikis. We believe that wikis have the potential to be the most
widely accepted form of online publishing in the near future.

Additional Resources
 Wikipedia on Wikis – http://en.wikipedia.org/wiki/Wiki
 Wiki matrix – Web site for comparing Wikis - http://www.wikimatrix.org/
 Wiki Patterns – a guide to Wiki adoption -
http://www.wikipatterns.com/display/wikipatterns/Wikipatterns
 Wikis in Plain English – Short video explaining the concept of a wiki -
http://www.youtube.com/watch?v=-dnL00TdmLY
 Future Changes: Grow Your Wiki – excellent blog on adopting and using wikis - http://www.ikiw.org/

WebWorks Wikis
 WebWorks Help Center – http://wiki.webworks.com
 WebWorks Documentation Center – http://docs.webworks.com
 WebWorks RoundUp Users Conference – http://webworksroundup.com


About ePublisher
ePublisher is a multiple component product that enables cost-effective processes for efficiently writing,
presenting, and deploying online and print publications. Through the use of its three components,
organizations can leverage existing authoring tools and content management systems and meet
organization-wide publishing needs without incurring expensive training or software deployment
initiatives. Its open system architecture, based on industry-standard XSL, enables a large degree of
flexibility, customizability, and migration investment protection.

ePublisher is available in two packages: ePublisher Standard Version and Enterprise.

ePublisher Standard Version is for writing groups that manually convert and deliver their online content.
The Standard Version includes ePublisher Pro and ePublisher Express. Pro will be used to create,
maintain, and deploy your ePublisher Stationery; Express will be used by your writers to run reports, proof
online output, and deliver final online content.

ePublisher Enterprise Version is for writing groups that have frequent updates of their online content,
would like to integrate online help deliverables into a software build, or want to utilize the power of a
content management system. The Enterprise Version has the same components as the Standard
Version, plus the powerful and flexible ePublisher AutoMap.

Each version of ePublisher will save your group time and seamlessly fit into your writing workflow, giving
your writers more time to do what they do best - write.

About WebWorks.com
WebWorks.com, a brand of Quadralay Corporation, is the leading provider of comprehensive online
publishing and help system delivery solutions. Its products and services constitute the definitive single
source for all your ePublishing needs. We specialize in content conversion software that outputs Web,
online help, wiki, and electronic publication formats. Our ePublisher Platform can automate the
conversion of source documents in popular authoring formats such as DITA-XML, FrameMaker or Word
and convert them to multiple end-user formats such as WebWorks Help, HTML, CHM, and PDF. Our
conversion system is based on XSL so that output formats can be customized or even developed from
scratch.

Contact

Phone: 1-877-8-WEBWORKS
Email: info@webworks.com
Web: http://www.webworks.com


Why Use A Wiki: An Introduction to the Latest Online Publishing Format

More Related Content

What's hot (18)

Viewers also liked (20)

Similar to Why Use A Wiki: An Introduction to the Latest Online Publishing Format (20)

Recently uploaded (20)

Why Use A Wiki: An Introduction to the Latest Online Publishing Format