User:Cjl/Sandbox1: Difference between revisions
No edit summary |
(demo) |
||
Line 1: | Line 1: | ||
==Focus on content== |
==Focus on content== |
||
A useful start to buildng a health library can be made by collecting/creating some fairly simple, but nonetheless potentially lifesaving, public health content. The "low hanging fruit" content (WHO, UNESCO, NIH, etc.) that can be used to rapidly bootstrap a health content library is mostly available in HTML or PDF formats. If converting from PDF, I plan to mostly use HTML. |
A useful start to buildng a health library can be made by collecting/creating some fairly simple, but nonetheless potentially lifesaving, public health content. The "low hanging fruit" content (WHO, UNESCO, NIH, etc.) that can be used to rapidly bootstrap a health content library is mostly available in HTML or PDF formats. If converting from PDF, I plan to mostly use HTML. |
||
Testing one two three |
|||
# one |
|||
#two |
|||
==Strive to be application agnostic (mostly)== |
==Strive to be application agnostic (mostly)== |
Revision as of 03:11, 2 August 2008
Focus on content
A useful start to buildng a health library can be made by collecting/creating some fairly simple, but nonetheless potentially lifesaving, public health content. The "low hanging fruit" content (WHO, UNESCO, NIH, etc.) that can be used to rapidly bootstrap a health content library is mostly available in HTML or PDF formats. If converting from PDF, I plan to mostly use HTML.
Testing one two three
- one
- two
Strive to be application agnostic (mostly)
HTML content will present via Browse, which makes a lot of sense. Other possible choices (e.g. .odt and other open-specification word processor formats would presumably default to Write, except for the fact that Write (or it's parent AbiWord) do not currently support .odt natively . It may be best to be application (specifically word-processor) agnostic.
Internationalization / Localization
Adopting a simple HTML layout will produce content that is readily internationalized and localized via Pootle. HTML appears to be easy to package as a content (.xol) bundle Creating_a_content_bundle.
Content Harvesting tools
There are a variety tools for harvesting HTML content in a semi-automated fashion (e.g. wget) and the files used to internationalize/localize the HTML for www.laptop.org can be used as examples.
- See also http://po4a.alioth.debian.org/
Empower local control of final content
Even after language localization and bundling, simple HTML is generally suitable for further modification before use according to local requirements. We don't have a fancy word for this, but I would coin the term "regionalization" for that aspect of the content life-cycle. This will be necessary to patch up the inevitable short-comings in the cultural-competency or coverage of centrally-produced (essentially generic primer) materials.
- Need to develop and i18n/l10n Simple_HTML_Style_Guide
Widely understood, easily learned, easily edited
The web provides a substantial set of "open-source" samples (e.g. view page source in any browser on any page) that generally allows even novice users to learn enough HTML to perform simple edits (including addition or subtraction of entire text/topic elements). Any text editor will do as a reasonable authoring tool as long as syntax is kept pretty plain-vanilla. Call it "tag soup" if you must, but it works, many web-sites have been built and maintained with nothing more complex than Notepad.
Advanced publication features not really essential
Nearly everyone likes the 'beauty-of-design" elements that more sophisticated layout/mark-up tools can provide, but by-and-large the target textual content are extremely simple documents, some text and a picture or two. There is no point in over-engineering them.
That's my argument in favor of HTML, you are certainly free to use whatever
(open) format you want for the content that you plan to contribute, although
some are clearly more suitable than others.