User:Brettz9/dreamwiki

This is a subpage dedicated to housing my thoughts on an ideal wiki system (and local hard-drive), all based on the concept of unity-in-diversity (inspired by the [Bahá'í Faith].

1. Would have the option of being WYSIWYG (including for editing tables by their individual cells) with word-processing-type options covered by one's browser (which would also thereby become a "writer" too). This should be possible before one even clicks "edit" at a webpage (one should just need to "save" it)
2. Text-box would be searchable (useful when editing long pages and one wishes to find a string of text)
3. Would be fully integrated with one's local computer (and all of the applications on one's local computer would be fully integrated with each other).

• • One could easily (w/o cutting and pasting) save the contents of an individual wiki page (or subpages) to one's hard-drive (without saving all of the other "wikipedia" frame code.
  • One's local applications such as email, browser, web-authoring, stickies, word-processing, the Finder itself and even multimedia would not be distinct programs (e.g., with a click or key command a sticky-note could be turned into an email, a webpage into an editable sticky (possibly also collaborative if the viewer wishes to repost it to his/her own site or to submit it back to the website he "borrowed" (if the website is collaborative).
    • The option to click on an individual application (such as via a dock, etc.) would still be possible (e.g., one could specify that one is now writing/checking emails by clicking on an email button, but the option would still exist to transform the email being viewed/written into another type of application such as a sticky note (locally shared or not).
      • This also gives the idea that one could assign a URL to display a collection of webpages as sticky-notes (collaborative or not) or other window-types (why not allow circular windows even?).
    • Allow centralized control of all duplicatable features of applications (through "System Preferences') (e.g., any macros could be edited centrally and checked for conflicts with other macros, windows/database windows such as in a mail program, spreadsheet, browser, etc. could be accessible to any application function (when reading a list of emails, the email itself need not be confined to appear below the list but could be previewed (and edited) to the right or above, etc. and be detachable if desired (defaultable) just as one should be able to preview/edit any type of file (such as a webpage) in such a manner))
    • All of these applications (including the Finder) and their files would be accessible through one interface (with some possible uncategorizable exceptions--such as a video game perhaps, though even this should be able to optionally run in a preview window). One could thus specify from this universal interface whether one wanted to view all of the items in a directory or just the emails and collaborative websites, for example.

1. One could import an entire hierarchy of files (such as a yahoo category and its sublinks) and have the links resolve into a hierarchical set of folders/files on one's hard-drive. This could then be edited and shared back without any unnecessary intervening steps.
2. The XLink idea of allowing inline links could not only be specified as a preference by the website designer, but also by the user through his browser's preferences (e.g., automatically insert all webpages inline (or do not insert any or only insert them as aliased links--e.g., titling them all as "link"--this would save space on emails, web-browsing, etc. if the user so preferred (though the original URL could be detected before visiting)) to one degree or several degrees (and shrinking or expanding the inline items to a specified degree--magnifiable as a mouse rolls over it). This would also be possible for a network of collaborative sites where any cell could be edited WYSIWYG (w/o needing to first click on an edit button to get the new code).
3. Any webpages (locally-stored stickies/word-processing, emails, etc.) could be browsed via a column view, list/tree view (single window or double window--left/right, up-down, etc.), combined column-list/tree view, etc.
4. All Wikipedia features such as "recent changes", "page history", "what links here" could apply to individual rows or columns (or sets of rows or columns) in a wiki tabularly-viewable database. One could
5. One could specify in any URL (recognized by each browser) some anchor code not only to drop to a specific anchor specified by the programmer, but also to allow the linker to specify how much of the page should appear (from point A to B (of HTML code or text that appears on screen) including discontinuous excerpts --useful especially for inline links) and whether any text within the text to appear should be highlighted, underlined, bolded, etc. (e.g., one could type http://wikipedia.org/###Main%20Page--Cooking to bold everything between the first occurrence of "Main Page" and the first subsequent appearance of "Cooking" ) This would be useful in highlighting text within a long book (all at one URL) and only showing a range of pages or sentences (without the web designer having to set up his site such that options existed to browse the book by page, section, chapter, etc.). Ideally this could be done without needing to load the whole page in first, but this may be complicated, I imagine, if important formatting code appears before point A, as a decision would need to be made as to whether to try to figure out the prior formatting instructions, even if the prior text would be skipped).
6. One could specify within a page that certain text should be added to a particular category, and these categories could be themselves be collaboratively added to and programmed. For example, at Wikipedia one could designate all dates (preferably automatically with code-recognition) to show up as dates, such that one could view a list of all articles which included a specific date or dates within a specific range. One would not then need to add them to the calendar pages. The list of articles would ideally be viewable both as a sequential list of dates with links to the article name and even with the surrounding text of the mention of the date being excerpted. For example, if the page on DNA mentioned its discovery being in 1953, then when searching the calendar of 1953, this discovery would automatically appear in the appropriate place for 1953.