This page is not an official page for TWiki, it is a CodevCommunity page - opinions of the core team may well differ, as indeed will the community . Please see ReadmeFirst for a better description of the official TWiki Vision.
) Separating visions by horizontal lines makes sense I suppose. (Disagree with this? Change it!)
Also, one of the basic rules of brainstorming (this is brainstorming, right? ) is to postpone any critique at the first step. Will be plenty of time to sort crazy ideas from stupid ones later.
If you want a vision, here's one :
Every website a wiki - either published or active, with automatic interlinking between webs and sites based on phrases, not bumby words, with automatic searching available via logically nested webs, forming an ad-hoc semantic web - since a each page in TWikiWeb forms a tuple with a web being a relation - which allows people to query the WorldWideWikiWeb as a logical inconsistent whole.
Basically to summarise: I want multivac
- and I think TWiki can be it.
As above, but add:
I think automatic interlinking based on phrases is a great part of a vision. It reminds me of spelling and grammar checks. They used to be rubbish, now I find the background checking in Word with high accuracy and visual indicators you can ignore really useful. Wikis have made great use of the very simply text editing capability of HTML forms. I'd like to see a simple and easier to use system, probably with a fallback to simple text editing. I find that all the solutions on Codev to date leave a lot to be desired.
Not sure if this is a vision of TWiki, or of Wiki. It's very compatible with Michael's....
I don't know how serious it is, what to do about it, nor have any real plans to attempt to do anything about it, but there seems to be a fundamental dichotomy between visions that continue to have webs (and, in my preferred vision, hierarchical webs) and those with "No hierarchy, no webs, just a flat world which ..." Any ideas how to reconcile those two visions? Are they two options that can both be accomodated in one TWiki engine? Does the dichotomy signal a "natural" fork on the horizon? A big reason for my desire for hierarchical webs is to have multiple namespaces. (I won't promise that's my only reason — I probably need to sleep on that some.)
There is no dichotomy - databases are flat/global, and yet hierarchical/nested, much like the WWW is flat/global and hierarchical/nested. Categorisations form webs. Webs are physical categorisations - that is - a collections searches through categorisations stored physically separate. Webs also form namespaces - places to look for more named things. Separate namespaces however also allow multiple definitions for the same thing - this however is much like having sections through a single definition - much like dictionaries have multiple definitions - but they do it on a single page. Furthermore a web also indicates a realm of interest - of all the topics on TWiki.org, by specifying "Codev", we state a wish to limit internal links to just those categorised Codev (currently physically) - it clearly does not have to specified that way - as the find elsewhere plugin typifies. Ok, then — another reason I prefer to use webs to create different namespaces is because I can easily change namespaces (webs) in the browser address bar — if I can remember a page name I can just change the webname, I don't have to go through a search (or callup any other intermediate page).
My vision is to have the most usable wiki. Not a wiki by geeks, for geeks only. The ultimate test of usability: You can demo wiki to your company's vicepresident without blush and explaining "you know, it's open source, free, these hackers are sometines freaks and hard to manage". Not a single time. It means among other:
Changing topic to page hardly strikes me a part of a vision - it's more a matter of personal choice. Form to category is slightly bizare. People know what forms are and to be honest I think this is a more natural term than category. Meaning of category is something like "A specifically defined division in a system of classification; a class". Meaning of form "A document with blanks for the insertion of details or information". Whilst TWikiForms can be use for categorisation, it has other uses.
For me, TWiki is a way to have perennial data: I will put data as text in it, and it will be usable for years, decades, centuries... The engine and skins will change to adapt
to the changing world, specs, but the text format is in use for thousands of years.
Word processing formats, SGML & XML formats come and go, but text is immortal.
I use the twiki to support my Bussiness and SDLC ideas and methedologies. Its become an important management and information tool at my current Employer, and I hope to work towards integrating it into the documentation, revision document control and project management tool
Basically, i want to be able to use to as the one stop shop for everything from TimeSheets, Contract tracking, Task Planning, Software design......
-- SvenDowideit - 23 Aug 2003
Some more thoughts: What is the unique value of a wiki to a collaborating community?
why is there a hand written list of contributors at the end of this page (that was supposed to be in DocumentMode?) we should generate it from meta data... as a %CONTRIBUTORS% tag... should we have a DocumentModeEnhncements topic? And if the signature list is auto-generated, could the date on the signature be a link to the diff associated with that person's edit? Although I don't know how it would work if they edit multiple times on a single day, maybe a date entry for each edit?
And maybe instead of a %CONTRIBUTORS% tag at the bottom, there should be a %DOCUMENT_MODE% tag at the top of the page. Topics with the %DOCUMENT_MODE% tag could apply a document mode style sheet/twiki rendering template, automatic appending of the contributors list, etc.
mmmm, yummy pie-eyed dreaming.... I want painless spousal installs and upgrades for twiki. [spousal: "yes dear. yes dear, yes..." to all prompts] this includes installing plugins and patches. Uninstalling plugins and patches should be just as easy. Flat and/or Heirarchal namespaces, webs, categories, pigeon holes or whatever you want to call 'em -- on demand, according to the needs of the present situation. Sometimes I want nice trees, and others I just want to be able to find the damn thing without having to know what street it lives on. Much more focus on ease of use, at every step of the way using the least expensive mental transaction cost. Everything should be as simple as Mailinator. Nobody but the administrator should know or care what technology is letting them do their thing.
What's Related - I should be able to click on a link and get a list of all the pages which have a overlap of content with this one. Even better, if this was a:
Visual concept map ala TouchGraph, or granular enough to be based on the selected text or paragraph(s).
TWiki should output nothing but clean structured (x)html out of the box. Skins, plugins, stylesheets or whatever should be able to take it's output and mangle into whatever device is necessary for that service with a minimum of pain.
http://csszengarden.com/ for twiki.
Somebody said "text is immortal". I agree (with the understanding that immortal lies somewhere between a few years from now and the end of the century). The only tool I used everyday 12 years ago which I still use daily is the humble text editor (thank god I don't have to use the same text editor I was using a decade ago though!). I want to see more care and attention given to intelligently extracting markup from plain text conventions before we embark on yet more markup creation. Indeed some of the existing ones need to be backed out.
In spite of this belief, I still yearn for WYSIWYG editing. I'm just not sure if it can be done without sacrificing essential aspects of wikidom like guaranteed longevity and readability without an interpreter (aka txt > html > web browser). If a wysiwyg editor can be built which uses wiki-markup as it's storage format we might have the best of both worlds.
Inline word-level diff - so we can see the added/deleted text in context:
-- JohnTalintyre - 19 Aug 2003
-- CrawfordCurrie - 20 Aug 2003
-- PeterMasiar - 20 Aug 2003
-- MartinCleaver - 21 Aug 2003
-- MattWilkie - 11,15 Sep 2003
An Invitation
On TWikiIRC, Colas mentioned that OpenSource often requires (or is the concrete instantiation) of the vision of an individual or collection of individuals. I would suggest that TWiki's Vision is guided by more than one individual, and at the same time by one individual. (That person is YOU reading this.) I've personally got a vision of TWiki, but so have many others. I'm sharing mine. Please share yours. It will benefit everyone, no idea is too outlandish - when you start on a new journey knowing roughly what your endpoint is helps dramatically in planning where to place your feet and which roads to go down. Just to be different from the norm, it would help if you place your signature at the bottom of the page, rather than after your contribution - no single vision is more correct than any other, and names have power and meaning. (An rdiff will make it obvious anyway ) Separating visions by horizontal lines makes sense I suppose. (Disagree with this? Change it!)
Also, one of the basic rules of brainstorming (this is brainstorming, right? ) is to postpone any critique at the first step. Will be plenty of time to sort crazy ideas from stupid ones later.
If you want a vision, here's one
:
Every website a wiki - either published or active, with automatic interlinking between webs and sites based on phrases, not bumby words, with automatic searching available via logically nested webs, forming an ad-hoc semantic web - since a each page in TWikiWeb forms a tuple with a web being a relation - which allows people to query the WorldWideWikiWeb as a logical inconsistent whole.
Basically to summarise: I want multivac - and I think TWiki can be it.
As above, but add:
- "word" diffs
- better (and faster) searching:
- probably based on index(es)
- with features like near (w/10 = within 10 words)
- easy means of specifying different templates for different pages (maybe a popup menu)
- after some discussion (below) the ability to use multiple namespaces and switch between them easily — ideally, from the browser's address bar — with no intermediate callup of another page (like a search page)
- better and easier TWiki draw functionality, including:
- more Visio like grids and so forth
- easier offline editing, with ability to copy and paste portions of images from one drawing to another (by something more intuitive than copying and pasting text drawing commands)
- more choice of colors (to avoid contrast problems I've experienced (certain colored text on other colored backgrounds is very difficult to read (and, I've never tested positive for colorblindness))
- TWiki functions (like edit, save, preview, diff, more, etc.) invoked by keyboard shortcuts versus (or in addition to) mouse point and click
- better / easier editing (more browsers with ability to use an external editor (like Nedit, which can fold based on TWiki headings by the use of macros (I developed a set)))
- keyboard macros supported in X for easy additions of "boilerplate" text on TWiki pages
- the infrastructure surrounding my use of twiki.org (i.e., the TWiki engine, Sourceforge, my ISP, my dial-up connection) will be such that I can confidently click on a TWiki command (preview, save, edit, view, etc.) and "walk away" knowing that when I come back the command will have completed (no server timeouts or similar). Although mostly this lies outside of TWiki, I can't help but think there are things that might be done on the TWiki (or twiki.org) side to help. Make viewing always cached to reduce load in general? Somehow do a better job of receiving edited page content and processing it even if contact is lost with the initiating browser??? I don't know what I'm talking about here, just trying to provoke some other thoughts.
- another thing I'd like is WYSIWYG editing, and even a step beyond that, what I might call modeless editing — let me edit on the view page — too often I find one or more typos or other things I want to fix, change, or comment on, (while viewing), but forget or have difficulty finding them when I switch to edit mode. (Clearly, like the previous 4, this requires browser changes.)
I think automatic interlinking based on phrases is a great part of a vision. It reminds me of spelling and grammar checks. They used to be rubbish, now I find the background checking in Word with high accuracy and visual indicators you can ignore really useful. Wikis have made great use of the very simply text editing capability of HTML forms. I'd like to see a simple and easier to use system, probably with a fallback to simple text editing. I find that all the solutions on Codev to date leave a lot to be desired.
Not sure if this is a vision of TWiki, or of Wiki. It's very compatible with Michael's....
- No hierarchy, no webs, just a flat world which is organised in many dimensions through phrase, concept, keyword linking, categories. Different views of the information; slices through the information continuum; slices defined by searches.
- Different entry methods aiming at a canonical information representation.
- An end to markup; WYSIWYG editing of pages, supported in the browsers.
- "related" searches during editing
- Really easy sketches, line drawings. An open drawing architecture that gives people the foundation to build visually oriented applications.
- I like the idea of WorldWideWiki very much. Why should searches be restricted to your local web?
I don't know how serious it is, what to do about it, nor have any real plans to attempt to do anything about it, but there seems to be a fundamental dichotomy between visions that continue to have webs (and, in my preferred vision, hierarchical webs) and those with "No hierarchy, no webs, just a flat world which ..." Any ideas how to reconcile those two visions? Are they two options that can both be accomodated in one TWiki engine? Does the dichotomy signal a "natural" fork on the horizon? A big reason for my desire for hierarchical webs is to have multiple namespaces. (I won't promise that's my only reason — I probably need to sleep on that some.)
There is no dichotomy - databases are flat/global, and yet hierarchical/nested, much like the WWW is flat/global and hierarchical/nested. Categorisations form webs. Webs are physical categorisations - that is - a collections searches through categorisations stored physically separate. Webs also form namespaces - places to look for more named things. Separate namespaces however also allow multiple definitions for the same thing - this however is much like having sections through a single definition - much like dictionaries have multiple definitions - but they do it on a single page. Furthermore a web also indicates a realm of interest - of all the topics on TWiki.org, by specifying "Codev", we state a wish to limit internal links to just those categorised Codev (currently physically) - it clearly does not have to specified that way - as the find elsewhere plugin typifies. Ok, then — another reason I prefer to use webs to create different namespaces is because I can easily change namespaces (webs) in the browser address bar — if I can remember a page name I can just change the webname, I don't have to go through a search (or callup any other intermediate page).
My vision is to have the most usable wiki. Not a wiki by geeks, for geeks only. The ultimate test of usability: You can demo wiki to your company's vicepresident without blush and explaining "you know, it's open source, free, these hackers are sometines freaks and hard to manage". Not a single time. It means among other:
- usable skin with professional-looking logo
- cleanup terminology: rename web ==> ???, topic ==> page, TWikiForms ==> category
Changing topic to page hardly strikes me a part of a vision - it's more a matter of personal choice. Form to category is slightly bizare. People know what forms are and to be honest I think this is a more natural term than category. Meaning of category is something like "A specifically defined division in a system of classification; a class". Meaning of form "A document with blanks for the insertion of details or information". Whilst TWikiForms can be use for categorisation, it has other uses.
- I'd like to see a TWiki in which all Markup was implemented externally in plugins, the only part left in the core would be linkage via WikiWords. This would allow swappable mark-up - for example, use of pure HTML via HtmlAreaEditor, TWikiML or ReStructuredText.
- I'd like to see a decent NotificationsFramework, such that requesting or breaking of locks are notified in real time.
- For TWiki to be the defacto Perl Wiki, for it to attract PerlMongers as a web ApplicationServer platform for everything they write.
- It would be cool to integrate Tk, so that plugin writers and topic writers alike could embed Tk controls into pages.
- For mail-in and mail-out to be seemless, for an extensible core into which verbs such as comment could be cleanly added to the logs
- For easy install and upgrade to be a reality
For me, TWiki is a way to have perennial data: I will put data as text in it, and it will be usable for years, decades, centuries...
The engine and skins will change to adapt
to the changing world, specs, but the text format is in use for thousands of years.
Word processing formats, SGML & XML formats come and go, but text is immortal.
I use the twiki to support my Bussiness and SDLC ideas and methedologies. Its become an important management and information tool at my current Employer, and I hope to work towards integrating it into the documentation, revision document control and project management tool
Basically, i want to be able to use to as the one stop shop for everything from TimeSheets, Contract tracking, Task Planning, Software design......
-- SvenDowideit - 23 Aug 2003
Some more thoughts: What is the unique value of a wiki to a collaborating community?
- It's basically a document repository.
- Anyone can edit the contents of a website through a web browser, and have it appear professionally presented.
- Needs no special tools, and only limited training.
- It comes with a prepackaged democratic use model that works well in the early stages of development of ideas.
- It adds basic data control mechanisms (access control, version control).
- The addition of highly flexible data structuring takes it into the realm of an application platform (not many applications work on unstructured data).
- I find that refactoring thread-mode pages, so that they retain the essential thread mode structure but incorporate selected parts of the arguments into the original thesis while still recognising all the contributors, is incredibly difficult. I want tools to help me do this.
- I want to have links to related information suggested to me. I may not close the links, but I want the hints.
- I want to be able to transition "unstructured" data into "structured" painlessly. If I think a discussion would benefit by being treated as a thread, I should be able to make it one - and vice-versa.
- Chaotic data often contains most of what I need to derive ordered data (e.g. a bug report). I want support in making this transition.
- The WorldWideWiki needs to be able to connect to the outside world. By this I mean:
- it must be able to speak the languages of other applications (e.g. "give me a CSV of this table")
- it must be able to speak to websites (e.g. optionally auto-link proper nouns to a google search)
why is there a hand written list of contributors at the end of this page (that was supposed to be in DocumentMode?) we should generate it from meta data... as a %CONTRIBUTORS% tag...
should we have a DocumentModeEnhncements topic? And if the signature list is auto-generated, could the date on the signature be a link to the diff associated with that person's edit? Although I don't know how it would work if they edit multiple times on a single day, maybe a date entry for each edit?
And maybe instead of a %CONTRIBUTORS% tag at the bottom, there should be a %DOCUMENT_MODE% tag at the top of the page. Topics with the %DOCUMENT_MODE% tag could apply a document mode style sheet/twiki rendering template, automatic appending of the contributors list, etc.
mmmm, yummy pie-eyed dreaming.... I want painless spousal installs and upgrades for twiki. [spousal: "yes dear. yes dear, yes..." to all prompts] this includes installing plugins and patches. Uninstalling plugins and patches should be just as easy. Flat and/or Heirarchal namespaces, webs, categories, pigeon holes or whatever you want to call 'em -- on demand, according to the needs of the present situation. Sometimes I want nice trees, and others I just want to be able to find the damn thing without having to know what street it lives on. Much more focus on ease of use, at every step of the way using the least expensive mental transaction cost. Everything should be as simple as Mailinator
. Nobody but the administrator should know or care what technology is letting them do their thing.
What's Related - I should be able to click on a link and get a list of all the pages which have a overlap of content with this one. Even better, if this was a:
Visual concept map ala TouchGraph, or granular enough to be based on the selected text or paragraph(s).
TWiki should output nothing but clean structured (x)html out of the box. Skins, plugins, stylesheets or whatever should be able to take it's output and mangle into whatever device is necessary for that service with a minimum of pain.
http://csszengarden.com/ for twiki.
Somebody said "text is immortal". I agree (with the understanding that immortal lies somewhere between a few years from now and the end of the century). The only tool I used everyday 12 years ago which I still use daily is the humble text editor (thank god I don't have to use the same text editor I was using a decade ago though!). I want to see more care and attention given to intelligently extracting markup from plain text conventions before we embark on yet more markup creation. Indeed some of the existing ones need to be backed out.
In spite of this belief, I still yearn for WYSIWYG editing. I'm just not sure if it can be done without sacrificing essential aspects of wikidom like guaranteed longevity and readability without an interpreter (aka txt > html > web browser). If a wysiwyg editor can be built which uses wiki-markup as it's storage format we might have the best of both worlds.
Inline word-level diff - so we can see the added/deleted text in context:
"I still yearn for WYSIWYG editing.I'm just not sure ifI think it can be done without sacrificing essential aspects of wikidom."
Contributors To this Page
-- RandyKramer - 19 Aug 2003-- JohnTalintyre - 19 Aug 2003
-- CrawfordCurrie - 20 Aug 2003
-- PeterMasiar - 20 Aug 2003
-- MartinCleaver - 21 Aug 2003
-- MattWilkie - 11,15 Sep 2003
Topic revision: r26 - 2004-03-10 - PeterThoeny
Site map
Blog web
Create New Topic
Index
Search
Advanced search
My topics of interest
Changes
Major changes only
All tags
Notifications
RSS Feed
Statistics
Preferences
Community 
Readme first
Developers News
How you can help
Community roles
#twiki IRC
Lima Release
Feature Proposals
Bugs Changes
Categories 
Account 
Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.