Running naked shows the reliance wiki members place on the wiki wrapper functions for home page, recent changes, and search functions. For instance, a NakedWiki page will most likely have no explicit links back to the home page, making navigation a unidirectional effort. Subpages also lose their links to their parent pages, if the links are not explicitly embedded in the page content.
The NakedWiki mode is useful for putting wiki content on a CDROM, converting a wiki to a Help system, developing indexing files, or publishing content developed on a wiki but intended for read-only distribution -- project specs, staff address files, inventory catalogs, documentation and how-to files, etc.
Specific wiki pages fetched in NakedWiki mode can serve as dynamic content for other web pages, popping up cheerfully and well-formatted in FRAME and IFRAME contexts, making the NakedWiki mode a useful component in an intranet. Department contributors can have their updated info appear on the corporate-sanctioned intranet and internet sites with no (intervening) publishing effort on the part of the IT webmasters.
A wiki may also appear in dual-mode, as a NakedWiki to visitors, but as a fully-editable wiki to contributors. You could then password-protect the editing process, but keep the results open. With no access to recent changes or other type-into-the-URL functions, access routes through the content would be controlled strictly by explicit linking. In a dual-mode NakedWiki, it would seem desirable to run with full HTML enabled for the extra pizzazz offered by even basic HTML. A dual-mode wiki could be a commercially viable venture, with visitors on subscription, and contributors paid by page-access, using the access-logging functions already built-in to the wiki (or provided by the server) to track access and credit payments.
The 0.92 version of UseModWiki has a partial implementation of an "embedded" feature. You can see a an embedded version of this page at . The current implementation does not alter any of the links, however, which lead to full non-embedded versions of pages. It wouldn't be hard to alter the code to make all pages embedded, with a separate non-embedded version of the script used for editing. --CliffordAdams
That's interesting! As you know, I used the separate-version solution for my experiments. I'd have to some heavy thinking about user scenarios to decide which way to go. -- JerryMuelver
Somewhere between this embedded feature for each page and the current implementation is a theoretical code in which the implementer can customize each of the elements in the bars at the top and the bottom, perhaps even incrementally adding each element, depending on the config settings. --MatthewSimpson
Preferably dragging and dropping them.
I prefer the "chess" terminology:
Don't confuse presentation (header / no-header) with access restrictions (open / closed).
What do you mean by the META tags? And no, currently it's not XHTML, but it will be when I'll finally refactor to produce Wiki XML. -- JürgenHermann