Fliki Base

Based on ExtendingTheWikiParadigm, brainstorming features of a combo: A grand "dumping ground" for semi-structured info, and perhaps......everything?

I propose the following features:

Draft Dynamic Schemas based on MultiParadigmDatabase "rules":

 Entity: wikiNode (not to be confused with a WikiNode)
 ----------------
 ID (An Auto-ID is built into MultiParadigmDatabase, all records have them)
 wiki_title // wiki document or entry name; uniqueness not enforced, but warned. Required.
 text    // wiki-text
 parent_node  // ID of parent, if applicable
 file_ref     // path or ID to file (depending on implementation)
 paragraphed  // 1=paragraph-wiki-mode, 0=regular
 created_on   // create time-stamp
 changed_on   // modified time-stamp, same as create if new
 display_order  // numeric
 keywords
 (any customer-defined attributes...)

Entity: wikiCategory -------------------- wiki_ref // node reference category_ref

[under constru

Sample User Interface Screens using GUI AsciiArt

 QUERY SCREEN:
 -------------------------------------------------
 .
 Search Words: [________________________][*Go*]
 . 
 Search: [X]Wiki-Title [X]Keywords [X]Category [X]Wiki-Text
 .       [X]File-name  [_]File-content (if indexed)
 .
 Query: (optional)
 [..............................] [*templates*]
 [.....query text box...........]
 [..............................] 
 [..............................] 
 .
 --------------------------------------------------end screen

QUERY RESULTS SCREEN: ----------------------------------------------------------- 47 Matches Found . Wiki Title.......|Created.|Modified|File-Info|Key-words -----------------|--------|--------|---------|---------- Why we love wikis|12/12/07|12/13/07|55Meg XLS|Wiki, Love, Reasons I spilled my Milk|01/18/08|01/03/09|.(none)..|Milk, Accidents Tables Rule......|11/01/10|11/01/10|8 Gig TXT|TOP, Tables, Good Etc... // Click title for detail, per below. // Columns displayed are configurable. // Rollovers may show more details. ----------------------------------------------------end screen

WIKI ITEM EXPLORER SCREEN: ----------------------------------------------------------- Title: Why we love wikis ----------------------------------------------------------- [-] Content: . . . . . . [*full-screen*] Wiki content text goes here with a scroll-box and a full-screen button. Before that, it would take up about 2/5 of the screen by default. ----------------------------------------------------------- [-] File Info: .......File-Name: My_Dog_Wikituski_Pic.JPEG .......File-Size: 55.382 Meg .......Etc.... .......[*Open File*] // button ----------------------------------------------------------- [-] Key-Words: Wiki, Love, Reasons ----------------------------------------------------------- [-] Categories: Wiki, Proponents // combine with above? ----------------------------------------------------------- [-] Sub-Items: ....// (If items exist, same format as Query Results Screen above) ----------------------------------------------------------- [-] Attributes: . Name..........|..Value --------------|------------------------------ Created_On....| 12/12/2007 // standard attribute for wiki Modified......| 12/13/2007 My_Custom_Val.| Eat my socks! // custom-defined attribute Etc... ----------------------------------------------------end screen

(Dots are to prevent TabMunging)

The "[-]" mean that the item section is collaspable. It's similar to "tree viewers" that have a [+] and [-] icon to open or collapse branches. The order and default collapsed/not-collapsed status would be user and/or site configurable. "[*...*]" implies a button.

If the wiki item is in "paragraph mode", then the "reader" panel would display link markers to edit an individual paragraph. Rolling over the marker would also show the boundary of the target paragraph using a tint-block. The user could still do paragraph selection and editing using the "Sub-Items" panel, but that's not very convenient. Wiki titles will double as and display as paragraph (or section) titles if an item is part of a paragraphed topic. Note that using "paragraph mode" does not preclude multiple paragraphs per sub-section. "ParagraphWiki" may be a misnomer because of that. It's more like a sub-document, or divisible document.

Perhaps a ParagraphWiki should wait until version 2.0. It will add a lot of design complexity. Let people get used to a basic FlikiBase first before tossing in concepts such as ParagraphWiki. I'm mostly just "reserving conventions" for it so it can be added later with minimal changes. Maybe the whole concept of a ParagraphWiki can be made moot if it's easier to create virtual groupings. Needs more thinkification, as Bush might say.

The "standard" attributes would be tinted and placed at top to distinguish them from user/site-defined attributes (if allowed) in the "attributes" section of the above Wiki Item Explorer Screen.

Attributes combined with a DataDictionary of sorts and a data-entry screen/browser could provide basic internal form creation, kind of like LotusNotes. One could use the "attributes" section of the above Wiki Item Explorer Screen for a bare-bones form, but using a DataDictionary on top of it would give it polish. That for version 2.0 also?

Whether files would be embedded in the database used or stored elsewhere (such as a file system) and referenced in the wiki-base depends, and needs some pondering. It may depend on the performance capabilities of the wiki-base engine used. Maybe the choice could be a setup option.

--top
To consider:


SharePoint kind of tries to be a FlikiBase, but it's cumbersome and confusing, at least to the uninitiated. Its learning curve is not very gradual: you have to master and configure a lot before it's usable to "the masses". Granted, it has lots of features to lock down and control content, but in many ways that makes it anti-wiki. It's a BondageAndDiscipline version of a FlikiBase.

An individual Wiki database could be useful.If I were defining a database for this wiki, I wonder what I would do.

 Entity: Wikipages
  Attributes which comprise a page -
    Id
    PageName
    Text
  Attributes which can be derived for each page -
    Categories
    Contributors
    Title - with great difficulty
    Length of page
    Child Pages

Yeah - it could be very useful


See also: WebGodObjectDiscussion
CategoryWiki, CategoryMultiPurpose, CategoryCollaboration, CategorySpeculative

EditText of this page (last edited July 22, 2013) or FindPage with title or text search