Migrating to Bright Content

Analyze the site content for organization and content reuse opportunities

Bright Content supports many approaches to content organization, and many tools and techniques for content representation and templates, but the developers happen to like, XML, Wiki/structured text, XSLT and Atom, in reasonable doses (some things are just better as RDBMS, JSON and such, and Bright Content supports "low impedance": things should be in the most natural formats possible).

Regardless of details, look for the general information patterns for which Bright Content is designed:

Content element. A content element is a chunk of content that might be assembled into a document.

Document. A collection of content that the reader will usually consider a logical whole.

• XML works well for content elements and documents.

Data element. A very structured piece of data, generally more for processing by programs than for direct reading by people.

Records set. A collection of data elements. Think structured records spreadsheet or relational database tables, CSV and such.

• Good fit for RDBMS, less structured DBMS, JSON or the like, depending on volume, access patterns and such.

Anchored content. Content elements and documents that stand on their own and are not connected to a logical progression of information What are the content elements (general prose bits for humans)? Consider converting to XML or a structured text variant (such as Wiki) that can be mechanically translated to XML.

Content feed. Content elements and documents that are connected to a logical progression of information. The entries of a Weblog, features in a journal, comments in a bulletin board, songs on a radio station, and so much more

• Atom syntax works well for this.

Presentation Templates. Instructions and utility files for sewing the above into the overall user experience.

• Python+Javascript+XSLT works well, in a mix depending on developer preference