The achieved goals of Raconteur are:

• Build and maintain static websites that are independent of
  Raconteur.

• Support very large websites while also supporting small websites. Our first client started with a site of about 4000 pages. Our smallest client has 11 pages, but with about 300MB of media files.

• Support an evolutionary approach to building and maintaining a website (you can start a website small and grow it)
• late decision making (allows flexibility)
• routine and easy re-organisation of content
• enter content once

• Team-focused.

• Work on many websites.

• No installation required (offered only as SaaS or as an appliance) and minimal configuration required—none before getting started.

• Browser based.

• Multilingual content, and the user interface can be localised.

• Easy deployment and site management (zip and tar ball archives;
  rsync+ssh will automatically remove unused files from the remote host).

• Separate design and content by taking advantage of web standard
  technologies of course, but also Raconteur’s workflow keeps design and
  content development independent:
• Design and content are developed independently and in any order.
• Different content can be applied to the same design.
• Different designs can be applied to the same content. For
  example, one design for desktop browsers, another for smart phones,
  another for a flash player, or even for deployment through a web
  application (e.g. there is a small course management system that
  uses Raconteur to write its courses).
• The live site is re-design safe.
• It is possible that a website may be generated for each combination
  of design and content and delivered to the same or different hosts.

• Designers build themes which normally specify CSS, templates (html,
  xml, PHP, or whatever you can think of), javascript, and any media assets used by the design:
• Powerful and safe template system that can generate any
  textual content (not just html or xhtml).
• Can develop families of themes that share assets.
• Themes are independent of the content, and may ignore or react to hints (called intents) provided by the authors… just like in real life, the default behaviour is to ignore the intent of the authors.
• Templates use convention, not configuration, to determine where
  they should be used.
• It is possible to generate more than one output for a single content
  structure (e.g. both html and xml output).

• Authors write content in a structured framework that is known to scale to tens of thousands of pages:
• Modifying a website is easy, with little or no training
  required.
• Content is organised into hierarchical structures of sections, each
  section should be thought of as a possible page on a site (ultimately,
  it is the theme that decides what is a page — a page can be
  stitched together from sections and their subsections).
• The author can indicate to the theme the intent of each section
  (e.g. news item, event, article, or anything else you can think of).
• There are no predefined content types (e.g. article, event, page); any content type should be representable.
• There are several editing tools supported, including raw text/html,
  textile, markdown, and a WYSIWYG browser based editor.
• Internal links are easy to specify and are automatically
  maintained by Raconteur.
• External links are checked for validity and allows the author to
  navigate between pages that use the same link.

• Formatting is done in the template not the content. For example,
  where there is content that represents an article that has a few associated images, Raconteur strongly encourages the theme to place the images correctly on the page. This can be a tricky and error prone thing to do for the author, can be impossible in multiple use scenarios, and invariably leads to inconsistent page appearance. In many ways, the placement of an image is a design matter and so should be something that can be changed with the design rather than going through and editing all the content.

• The user interface is a single dashboard-like screen with all
  functionality available from that screen.

• A user can work on more than one collection, in which case all
  collections are available from the dashboard-like user interface. There is no need to remember URLs or login and out for each collection.

• The user permission system is simple, as as simple as we could make it: there is only one role, controlled on a per collection basis. This is in concordance with with Raconteur’s team-oriented approach. If you think you
  really want finer grained control, there can be multiple collections
  contributing to a single website, and each collection has its own team, so…
  anyway, when you change your mind, you can merge the collections and get
  rid of all that complexity and confusion.

• The workflow is simple, as simple as we could make it, five steps: build, preview, approve, verify, export.

• Snapshot/backups: Backups are a simple xml format with all uploaded
  asset files, and may be downloaded and processed as you wish.