Tags:
extract_stuff1Add my vote for this tag task_team1Add my vote for this tag create new tag
, view all tags

TWiki Codev Master Refactor

This is an aiming-for-(now)-Jan-2002 mission, to REFACTOR THE ENTIRE CODEV WEB. More precisely, to:

  • refactor all topics of relevance to current and future TWiki dev
  • copyedit and package key content, with intros, summaries, navigation aids
  • consolidate related topics through crosslinking (discover trends, patterns, through ALL Codev topics)
  • dump really outdated, useless topics (devise a practical method for said dumping)

Feel free to pitch in and contribute to this page, as the spirit moves you! Straight notes need no signatures, but do sign your opinions and ideas!


MasterRefactor Overview

Somehow, the direction here suddenly seems pretty clear! So far, five project areas have "naturally" emerged and seem to handle the main Codev issues quite neatly: Changes, Collaboration, Interface, Features, and CodeBase (which could maybe become Modularization). Where there are overlaps, with the same topic appearing in two or more categories, they so far are all useful, not redundant.

The original approach was to come up with subject headings that make sense of the existing topics and discussions, NOT to create familiar or logical categories, and then try to fit everything in them. That seems to have worked. The initial format is whatever it takes - quotes, notes, links - to quickly organize Codev content as a whole; the next step is to optimize the Codev web along those lines. Particularly with the new FormattedSearch, the original manual INCLUDE topic lists can be turned into form meta data and displayed in various compact, customizable formats...

MasterRefactor is a practical dev project, also, a giant test of TWiki usability and practical application... On both counts, it's going quite well.

IDEA! indicates possibly bright ideas & seminal observations.
Launched: 29-Sep-2001
Codev = approx. 800 relevant (non-admin) topics

NOTE: Do sign your contributions below. Some excerpts from existing Codev topics are used without sigs here, but will be credited in any final version.


What is TWiki?

  • "Unconventional" is the short description, compared to products performing equivalent functions. This is synonymous with unstructured, freeform, decompartmentalized (?)
    • "The nature of TWiki is... WabiSabi" - a little arcane as a description, for some, perhaps...

  • TWiki is a Web-based collaboration tool
    • A TWiki site is a simple, satisfying, full-featured open communication environment:
      • people anywhere online can meet
      • rich Web text, images, online multimedia are easily shared
      • documents and other files can be uploaded and downloaded
      • everything works through a regular Web browser
    • TWiki's parsing engine reads a text file, hyperlinks it, and converts TWiki shorthand into standard HTML, on the fly. The point is to:
      • make editing text extremely simple (to see how simple, click on the Edit link at the bottom of the page)
      • let you find information fast (WebSearch)

  • collaborate means "to work together, as opposed to independently, especially in a joint intellectual effort". The secondary meaning is negative, to be a traitor, as in "collaborating with the enemy". * What secondary meaning? Collaborating with the enemy just means working with the enemy, being a traitor has nothing to do with collaboration. May I suggest you drop this and the next statement? Using -3 is like collaborating with the enemies of open Web Standards, or maybe that only applies to the font tag. But this IS nice'n'tiny. "Collaborate" does mean "to cooperate treasonably", especially in WWII movies... It's a little weird...though the comment below actually does seem to apply...and this is all just brainstorming on the way to reduction...
    • It has some relevance, in that a collaboration environment often enough is expected to facilitate communication between parties that don't usually work closely together, if at all - with or without any sort of hostility or reservation involved. Pretty deep...

  • TWiki is a software implementation of a Wiki, a place in which a semantic network can be maintained. In this network, the thoughts of multiple people are correlated by their common use of WikiWords, language constructs that act as placeholders for the identity of ideas. WikiWords are the key landmarks that bind your idea to mine, they are the meeting point at which we discuss characteristics of a thing worth talking about. A wiki primarily offers the ability to find out the "what" of a named thing, the "what" of a noun-phrase.

  • Beyond the relatively simplistic (though worthy) aim of being a place to jointly produce pages on a website, a Wiki provides the ability to expose concepts being used by the collaborating group to the outside world. The usefulness of this exposing process can be seen as an added value to the value of website addresses. Website addresses guarantee a regularity, they offer the user the ability to locate an organisation through a predictable name. Inside the site, however, that guarantee ends. The site is free to structure the addresses according to its own standards. I cannot, on a website know always what to type on the URL to get to a named concept owned by that organisation.

  • A Wiki, on the other hand, offers a further level of guarantee when it comes to noun-phrases. The guarantee is that the noun-phrase will be on a predicably named topic and hopefully on the simplest possible URL. Imagine if every company that made products made the description of that product available on http://wiki.companyname.com/Product/ProductName.


TWiki Core Feature Set

  • It should be possible, given some basic parameters defining what TWiki is not (based on other established tools, like BBS, email, etc), and the basics of CommonWiki, to spec the "perfect" TWiki as far as major functions. This perhaps implies that TWiki has an ultimate perfect evolutionary state, after which major feature development would no longer be "TWiki".

_"Given the large number of clones and ports of Wiki, one would wonder: Could a standard, or base Wiki be made? Assuming the answer is yes, what are some fundamental capabilities that wiki developers need in their copies of Wiki?"CommonWiki_

  • Ability to customize how wiki works, using one's preferred language, to make it well suited for particular tasks.
  • Portable to a range of variously limited platforms - or, at least, the core pieces can be ported. Should be runnable on a "complete" system, and on ones where certain things (rcs, perl5, etc.) are missing.
  • Page changes can be incorporated to a given page in various ways (replacing old page, merging, appending...)
  • Preprocessing is done on the file prior to display to the page user. The file can be preprocessed in a variety of (oft-customized) means. Extra things can be added to the page beyond the editable text.
  • Hyperlinks can be indicated in a variety of ways.
  • What happens when the user clicks the edit or save buttons are often customized.
  • Wiki keeps track of additional information about a page besides just the editable text.
  • One can perform iterative operations on a set of pages in the site.
  • Access to and editing of pages can be controlled in various ways. Wiki knows a little about each user and can act differently depending on who they are.
  • Pages can be grouped into one or more "topics", and different kinds of information can be tracked for different topics.
  • How would one design things to avoid future forks and fragmentation? see Wiki:AvoidingWikiForks
  • What could be done to make it easier to install and configure wiki?
  • Does the current wiki architecture support all of the needs listed above? If not, does a particular architecture suggest itself from the requirements?
  • Would there be any value in considering alternate licenses besides GPL?
  • What should Wiki not be designed to be used for? What are its bounds? (Or are there none?)
  • What could be done about "reading in" various other formats (i.e. mbox, mmdf, etc...)

Core TWiki function Current TWiki method Non-Wiki methods Best method
Easy, rich text formatting notation TWikiShorthand Shorthand (ex: BBS); form-based input -
Topic-based open discussion Freeform thread-style messages Forum/BBS; email/mailing list; newsgroup -
Topic-based subject brief or discussion summary Freeform essay-style text Forum/BBS; email/mailing list; newsgroup -
Relating topics (deliberate branches) inline WikiWord link, HierarchicalNavigation Specialized KB/CMS -
Related topics (separately occurring) manual Related topic: links; HierarchicalNavigation Specialized KB/CMS Automated method?
Tracking changes to topics WebNotify, WebChanges, manual content scan Specialized KB/CMS Many possibilities...
External links Direct URL, Shorthand, HTML URL in form ?
Refinement, refactoring... Manual, spontaneous often limited ability to combine postings ?
Easy, powerful, fast search grep; full text database ?
Categorizing, grouping, sorting, annotating topics Meta Data & forms special fields ?
Authentication & access control Options: SSL, Basic Authentication SSL, Basic Authentication,... -
Revision control/backup RCS ? ?
ongoing table...


Project Development Environment


Open Source & Open Development

  • Open source licensing, especially of the GPL flavor, where all source code and modifications are freely available, can encourage a thriving developer community. This is in great part determined by the nature of the project itself: what does the software do? how large is, and who makes up, the user base? how glamorous/high profile is it? The other factor is the way the dev effort is managed - leadership. "Open source" doesn't necessarily mean "open development". An OSS project can be very closed to suggestions and contributions, either deliberately, or by the nature of the core developer(s). Dev philosophy and practice greatly determine the ongoing health of a project that relies on new contributors.
    • Where does TWiki stand? It's a GPL-ed open source project, energetically led by founder/lead developer PeterThoeny. His prompt and open response to input - requests, problems, criticisms - is well-demonstrated on site. His leadership, working with a small core team, assisted by a larger circle of programming and info-tech professionals who contribute through Codev to specific problems and features, apparently drives TWiki's successful development. The nature of the distinct Wiki community of clones is also important: there is a directly relevant pool of usage ideas, feature dev and overall discussion available from other Wiki projects.


Codev Dev Team Input

  • IDEA! A still-not-fully-formed thought: TWiki Codev is active, with many committed contributors. TWiki is also deployed in an impressive number of prominent companies where collaboration is high-stakes and the choice of collaboration platforms presumably exacting and critical. Although many/most committed installations are no doubt firewalled in all senses - company confidentiality and all that - still, given a good future dev roadmap, many of the Codev'ers could provide a LOT of hardcore feedback, based on observation and heavy, specific real world use, that would have nothing to do directly with its source. A completed MasterRefactor could act as an enabler/catalyst(?), where simple yes/no answers could narrow down a full spec, and allow valuable, concentrated dev planning input that otherwise might not be evident or possible.


Primary Market: The Corporate Intranet

  • The stated TWiki end user target is defined in the TWikiMission statement: "TWiki is a leading-edge, web-based collaboration tool specialized for corporate intranet use. TWiki fosters information flow within a company and eliminates the one-webmaster syndrome of outdated intranet content"
    • What precisely are those needs? TWikiMission outlines broad goals - KISS, low browser requirements, stable code - but doesn't go into detail. Some of these requirements are revealed in the various corporate buy-in mentions. The most noticeable seems to be that IT depts don't want to have to administer TWiki, which means Web-based controls that don't require root permissions... A list of specialized corp intranet parameters would be good (it may be in here somewhere already...).


Three Main User Groups

TWiki users logically fall into three, in many cases overlapping, core groups:

  1. Developers: creating and improving the application and addons/Plugins
  2. Administrators: installing, customizing, training users, maintaining, upgrading, feedback on usability (part of dev loop)
  3. Users: collaborating (incl. content maintenance), feedback on usability (part of dev loop)

How do each of these user groups fit with each other, and into the core feature considerations - or, simply, do any of the user group requirements conflict with each other?

Getting corporate buy-in

As an unconventional collaboration tool (freeform data), an unknown brandname, and an open source project (written in Perl), TWiki has three strikes against it for acceptance by "typical" large corporations. Buy-in by the IT department is crucial - depending on the various human/political factors, IT (and related quality control depts.) can be a formidable block ("we won't get our hands dirty with it; we can't let you tweak it on the network because it could hurt the rest of the system" is a basic Catch 22 argument, driven by policy, or by a hostile, or simply uninterested or unhelpful, IT contingent). References to this problem appear directly and indirectly through many topics and discussion threads and should be compiled:

  • "Someone just mentioned they'd like to turn over their TWiki installation to their network management group, but the group wouldn't take it on until it could be shown that TWiki could be completely administrated from the web."
  • "Currently our IT guys wouldn't support this with a bargepole, since it requires too much hands on administration." ImproveTWikiAdministration

  • I'd like to make this [WebCreateLikeTopicCreate] request (accessed by the TWikiAdminGroup?) as this feature is necessary to ensure minimal involvement of the operations group of my company.

How does this affect development? Obviously, if TWiki is targeting the "corporate intranet market", it has to develop to fit. But what if the requirements of that market demand features that aren't necessarily consistent with collaboration needs?

    • Describe common business scenarios and how Twiki would be use to make each task/procedure more efficient or easier.
    • Twiki's compatibility with ISO9000 standards

  • Need set of "Corporate Buy-in Specs"


TWikis vs. Other Wikis & Related Products

IDEA! There appears to be a strong movement to easy, accessible collaborative content management solutions in Web/Net software - particularly OSS/freeware, and resources for personal and small biz sites (ie: the "masses"). Wikis distinguish themselves from the various other classes by its freeform nature. This is quite remarkable. There is also a, um, convergence of functions that isn't really CreepingFeaturitis, and should be tracked closely and could have fundamental consequences for the future dev of TWiki. (more to follow here: CMS, DMS, Web application servers, PHP... + specific projects)

  • TWiki differs from other WikiClones in that it has:
    • access control
    • (robust) revision control
    • rich feature set - a LOT of tools...

  • IDEA! ScoopMeetsTWiki - "The style of weblogs is very linear - it lends itself well to news, diaries and interesting findings on the web, but it is less suitable for long-term, goal-oriented discussion of a subject, or collaborative content creation. The integration of a wiki into the Scoop codebase would make it possible to use a Scoop site for both purposes."


TWiki in Action

  • How many TWiki installations? Who, where, when, why, what, how?
    • Onsite mentions of TWiki sites with thousands of topics (4-5K?), hundreds of active users, dozens/hundreds of posts daily. More details gatherable...
    • Hardware requirements/use?


What is TWiki being used for?

  • Need details on actual usage... brief survey
    • Knowledge base; help desk; request tracker; trouble ticket; freeform database
    • Project collaboration: development & management
    • Document management
    • Documentation development
    • Project management (probably in conjunction with other tools, ex: spreadsheet applications)
    • Standalone intranet, extranet, Web site
    • Use in conjunction with other, more structured tools (overlaps with all of above)
    • ????


Usability & Usefulness

Off the top of my head, based on only a few minor comments, it occurs to me that TWiki is likely customized most of the time, to quite a degree, down to creating Plugins and addons. and tweaking the core code, that effectively makes each TWiki its own version. This leads to the idea that an out-of-the-box TWiki doesn't really exist - everyone modifies their "stock" TWiki. (Of course, this is an exaggeration, but probably applies to the most sophisticated installations. Is this a characteristic of the "corporate intranet" market?


Collaboration Project

ALERT! After grouping quite a few pages, the two basic Threads/Projects emerged: Collaboration, and Changes. Lots of devilish detail in both, and they seem to be at the core of Ultimate TWiki quest. Key issues:

Collaboration Guidelines

GoodStyle. Free-form collaboration leaves it largely up to Wiki contributors to create value, by posting quality content, and self-maintaining the site over time. This counters most software development, which goes to increasing automation. IOW, essential TWiki is a manual process, following a suggested set of guidelines. How much can be automated? How much must remain amnual?

Ex: A comprehensive set of easy-to-follow CollaborationGuidelines:

  • IDEA! Borrowing wholesale with the greatest respect from the original Wiki web (c2): use the years' worth of Wiki reflection - principles and practice - to outline a core T/Wiki collaboration rule set.

The standard goal is to distill knowledge in units of a topic page, according to a continuous contributing and editing cycle:

  • TentativeSummary - A WikiRefactoring technique:
    1. conduct a discussion in ThreadMode
    2. when the thread cools, add a section titled TentativeSummary at the bottom of the page
    3. when people stop altering the TentativeSummary, move it to the top of the page
    4. refactor the page to reflect the summary.
    • If the TentativeSummary bursts, and threads begin anew, delete the phrase Tentative Summary and wait for cooling again.

  • ThreadMode is a form of discussion [held as] a conversation. It is the beginning of a process of distilling experience that culminates in patterns. There are at least four ways you can contribute to a page in thread mode. See: HowToWriteInThreadMode

  • DocumentMode is written in the third person and left unsigned. It may have multiple and changing authors as it is updated to reflect the community consensus. This is in contrast to ThreadMode, comments which are usually signed and in the first person, and rarely edited by people other than the one who signed them.

See also: UnethicalEditing, DissertationOverDiscourse, PageDeletion

Tracking Changes Project

  • ChangesProject ChangesThread : an easy and individually customizable way to track and identify changes; a complicated area on UI and programming levels; and tied in to CollaborationProject when it comes to how various types of modifications are classified by the editor, and handled by the system


Interface, Navigation & Help Project

First impressions are important. On the other hand, TWikiTemplates make it relatively easy to completely customize the graphic design, rearrange the interface, and add bells & whistles with JavaScript, HTML, just about anything. So, how important in the priority list is developing a refined overall UI.

Also, documentation (which is effectively the Help system as well, at this point), is part of the InterfaceProject. How key is that? Should there we some form of inline help?

Questions:

  • Are MasterRefactors required in all Twiki implementations from time to time?
  • Should page organization be separate or parallel to navigation?
  • How much page organization should be automatic?

  • need for slicker packaging (for CorporateBuyin; better image with the skeptical).

  • out-of-the-box configuration, and organization of configurable variables could use some sorting out: RenameTheMainWeb, ...


Documentation Project

  • A formal TWiki documentation project was launched as separate from code dev, in late Aug-2001, a one-person core effort by MikeMannix, who volunteered and was brought on board by PeterThoeny.
    • (MM's background - non-technical, and probably quite unlike the majority of other Codev contributors - may be relevant in this MasterRefactor...)

  • A fairly complete docs rewrite would be an advantage: docs are minimal and uneven from topic to topic
    • inclusion of numerous how-to examples is a good idea: TWiki by design is technically simple to install, administrate and use - learning by example would be a painless and practical reference alternative


Code Base Project

It's clear that, given the resources, a rewrite of TWiki, modularizing it, would be the major priority.


Current Code Review

  • Stability: Production and Beta What's the current schedule? What criteria for a new Production release (see Development Goals)

  • Programming in Perl: TWiki is written in Perl, a scripting language that is not considered to be a "programming language" in the usual sense, when referring to computer programmers and software design (point-form details to follow). This makes it outside the consideration of many people and organizations as a real or serious piece of software. It also has its inherent advantages and disadvantages from a strictly functional POV.


Performance, Scalability, Security

  • Three common questions about any interactive Web application:
    1. Is it efficient, easy on resource usage?
    2. Can it be efficiently scaled to accommodate ANY NUMBER of clients and traffic load?
    3. How does it hold up against every imaginable type of digital attack or open security holes?
  • These are typically related public Web deployments, and are not always as relevant to TWiki's targeted intranet situations. But they're still basic considerations.

  • AnalysisChangesFrom2000ToSpring2001: part way to 01-Sep-2001, a breakdown by lines of code of the additions - a LOT bigger (not sure how this compares to the final 01-Sep Production release)

  • How big can a TWiki site get? Some intranet reports: thousands of files, hundreds of users, dozens to hundreds of updates daily.

  • TWikiSecurity breaks down installation (server/filesystem) and TWiki user (access to editing, etc) security issues.
    • SecureSetup briefly discusses installation security (file permissions, etc)
    • Use of HTML within pages is considered a security issue by other WikiClones. TWiki permits HTML and even JavaScript to be entered by users into the text of TWiki topics, which is probably a bit too dangerous for Internet TWikis (see GetRidOfJavaScript), since a TWiki page could be used to attack the user's machine or other websites - however, this may be fine for intranets, given TWiki's revision tracking.


Linux/Apache & Cross-Platform Compatibilty

Without additional resources to concentrate on finetuning packages for installation on Windows and other OS platforms, and with various servers, probably best to concentrate beyond the Linux/Apache development.

  • Installation of TWiki is manual. Beyond the base Linux/Apache "standard" environment, installation details are sketchy...
    • Installer script

  • TWikiOnWindows - a fair pile of notes being refactored into a doc procedure, slowly... also lists links to Win topics site-wide
    • Can look for volunteer teams to handle a full Windows implementation project, also, ports to other OS
    • Are all the Win enviroments and other variables too numerous to create a "base" Win install procedure?


Web Standards: Cross-Browser, CSS, etc


Modularization Project

  • TWiki is a WikiClone based on a WikiClone, and the inherited code base has been heavily built upon. It's now in a common situation where, ideally, with the evolved view of what TWiki should do, a clean rewrite would be in order - but in practice, this is difficult, impractical, due to limited resources. Also, the way to restructure TWiki is not clear cut, and the subject of on-doing discussion/debate.

  • TWikiOO
    • "Going OO requires another rewrite of TWiki. However, it should be possible to do the change into OO gradually, reusing most of the available libraries. ... Using a TWikiOO lib besides the provided TWiki lib, ...parts ... now directly call the original functions (thus now only providing a TWikiOO shell). This approach could be used to develop and test a TWikiOO without making the base code unstable again." HowShouldTWikiBeModularized
    • "Refactoring is one way of moving the code base towards a more structured basis. I think though that this will be extremely tricky as given the current interdependances between certain code units in the code any change to say the storage system requires multiple changes to various other aspects of the search and rendering units."
    • "I think there is going to have to be a certain level of will required to "fully objectize" TWiki's code base. Certainly there could be arguements for or against doing this, but in the end I think it will be increasingly hard for people to add their own features to TWiki without understanding the whole/checking the complete code base if it stays as it currently is."


TWiki Development Roadmap

  • Functional improvements and new features - practical issues - ultimately drive everything else. The quality of the product, through feedback, even motivates the dev leadership. What guides the development process?
  • Official development goals, from TWikiMission:
    Further development should have this focus:
    • Enhance TWiki evolutionarily to fit the mission.
    • Easy maintenance is key.
    • KISS (keep it simple) design is preferred over complicated designs.
    • Design for a good "out of box experience"; advanced features are OK as long as they do not distract.
    • Keep CreepingFeaturitis to a minimum.
    • Low requirements on client side and server side as defined in RequiredEnvironmentForTWiki.
    • Keep the quality as high as it is, e.g. few or no bugs for production releases and deployable in many environments.
    • Give broad corporate appeal, without sacrificing above guidelines
  • Are these adequately defined guidelines, with both specificity and broad enough scope? - No - to broad, vague.

Core Development Areas

  • Ways to connect related topics and refactor discussions: key issues may be recognized less quickly than they could be because discussions are spread through various topics, some linked, some not even...
    • IDEA! Moderator/editors could be assigned to subjects at brainstorm level, in the same way a lead developer is assigned to a feature to-do.
      • So far, this has been handled by lead developer PeterThoeny, and is now loosely part of a the documentation project started in late Aug-2001. Also, as a matter of course, various contribs naturally take the informal lead in organizing subjects they're interested in, but this participation is informal.

Five main development areas have emerged so far, from browsing and grouping the first 100 or so topics. In a few clear instances, some areas overlap, but by and large, they're functionally quite distinct. Of course, they're ultimately tightly related, for example, ChangesProject is really a subset of CollaborationProject:

  • ChangesProject - ChangesThread: Functionally, a subset of CollaborationThread, but distinct in that it involves the specific, complex concerns of letting users know what's changed - new topics, edits - based on a variety of user criteria

  • CodeBaseProject - CodeBaseThread: Anything related to programming, modularization, interoperability, incorporation of and integration with third-party products, use of and conformity with standards and protocols


New Functionality & Features

  • The logical idea would be to assemble a definitive list of core TWiki properties, then see how the current TWiki compares with the essential model, handle those core issues, and then consider additional features...

  • How much of the collaborative process can be automated? Freeform editing is the central feature of Wikis - it facilitates the essentially human participation - free association, lateral thinking, whatever. So there seems to be a limit to how far automation can go - CollaborationGuidelines.
    • On the original Wiki creator's site, there is extensive discussion of the Wiki way. The idea that who uses it determines how it's used, and how it's used determines a Wiki's value, is a central theme: "wiki is not WYSIWYG. It's an intelligence test of sorts to be able to edit a wiki page. It's not rocket science, but it doesn't appeal to the VideoAddicts. If it doesn't appeal, they don't participate, which leaves those of us who read and write to get on with rational discourse." Wiki:WhyWikiWorks
    • Wiki:FixYourWiki: "If you want wiki to survive, get into this habit: every day go and find one of your old thready discussions. Delete everything you wrote that has no value. Leave just a paragraph, maybe just a sentence. If your point failed, leave nothing."

  • It's hard to tell what drives new features. There is an explicit dev flow, from brainstorming through to-do queue and dev. But there's no organized ongoing list of TWiki development goals, or description of the ultimate, fully-realized TWiki.
    • Is TWiki ever "done" as far as new major areas of functionality?


Required Resources

  • There's a strong need for graphic design support, particularly Web developers who get the Wiki spirit and can contribute in harmony:
    • simple, basic templates that are immediately usable, and easy to configure for designer and non-designer
      • this includes templates configured so that designers can easily see how to entirely redesing the user interface
    • ongoing resolution of Web standards issues, with regard to CSS, JavaScript, DHTML, XML, and various related and browser cross-compatibility issues

  • It would be great to have more programmers and designers willing, able, and committed to handling specific project areas. This is already the case - or there would be no TWiki. It's also the desire and driving force behind most fairly complex OSS projects. So, it's no difference with TWiki.
    • Currently - Nov-2001 - there is some focussed activity on modularization of TWiki, and transitioning to an OO structure. This is a major milestone area which will in great part determine all future TWiki dev.
    • TWikiPlugins and the Plugin API will in great part determine the future dev. The project is spearheaded by AndreasSterbini. He could no doubt use additional resources, and it must all integrate with overall modularization.
  • The faster modularization and plug-in issues are brought to a clean next level, the faster the Plugins library can grow, which will probably be a major factor in further establishing TWiki.

  • Not nearly as high on the priority list as basic programming and design resources, but definitely with high potential, is having the resources to establish at least two different TWiki live test installations - real-world trials with diverse application requirements. This would entail:
    • a fully-participating business or other organization per test, willing to work through to a fixed program, and openly and regularly contribute data and comments
    • TWiki-side support in the form of liaison and direct programming and design assistance, and active brainstorm and problemsolving for the duration
    • A solid documentation effort, both technical and subjective
  • With the right test cases, surprising results are far from unlikely, given that Wikis are still very underground as far as general use.

  • Less defined, but important, is some sort of formal consideration of the business position of TWiki, as an GPL open source, open development philosophy, project. TWiki development relies on the SourceForge free dev environment, the heavy personal investment of time, energy and skills of originator PeterTheony, and additional significant personal contribution of under a dozen key people, whose level of participation varies over time depending on their own life circumstances. No doubt, siginificant advantage is being derived from these labors, including by some of the largest corporations around. Contributions of course come back from TWiki users, as well. However, when something of definite value has been created, the overall business impact can't be ignored. Various things to consider:
    • Most art, as diverse as fine arts to martial arts, exist and develop due to patronage, the financial contributions of philanthropic supporters.
    • Some OS projects have apparently found a balance between fully open, GPL-style licensing, and profitable business activity. (MySQL comes to mind, though I'm more confident in the principle itself than familiar with practical examples.)
    • Open source GPL projects are vulnerable to some negatives:
      • They can be subject to divisive code forks, where factions split. (PHP-Nuke and Post-Nuke is the dev split of a very popular CMS GPL application, based on profound differences in dev philosophy, that may end up for the better, or not.) Luckily, in the case of WikiClones in general, this seems to be a positive, friendly "family" thing to date.
      • Legally, the various "open source" licenses haven't yet been challenged in a potentially hostile "code takeover" situation, and some concern has be voiced over variations on this possibility.
      • Microsoft has for the past several months been actively campaigned to businesses about the danger to their intellectual property rights posed by "open source" licenses, in no uncertain or veiled language, referring in particular to the GPL.
  • For all of these reasons, and, I believe, in the spirit (hope) of emerging new economic patterns with more equitable distribution of wealth, there should be conscious attention paid to TWiki's position as an economic, value-creating entity. Where this may lead is a matter for discussion...


Prioritized Dev Action List

Does a certain set of features, enhancements and tweaks suggest itself as being clearly in a class of its own as far as apparent demand and usefulness? If so, it'd all be in a list like this...

  • A key area for improvement is usability, in many areas:
    • One of the problems we have had in our installation of TWiki is that people can't track the changes easily. Email is still a good model for collaboration because people get triggered by the email-received event, and can act on it according to different priorities. To incorporate this model into wiki concept is an important challenge. Simple "notify me" won't do it; it should be more than that. The "type of change" as defined above will help in that (i.e. I will subscribe to the topic to notify me for only major changes)... DiffsHardToRecognize
    • For a generation of computer users that are accustomed to WYSIWYG through Windows, Word and Excel, TWiki's reliance on an ASCII-oriented approach to formatting is not good enough for wide adoption, hence initiatives such as JavascriptBasedEditor and AppletBasedEditor to reduce the need to memorise syntax before contributing to TWiki.
    • It also needs to be much easier to create correct links to TWiki topics when editing, which has been implemented at PopupPageIndexForEditing.
    • The most important point, perhaps, is that the TWiki developer community has quite different skills and tastes in user interfaces to the target user community on corporate intranets, where even technical people prefer WYSIWYG and GUIs. Currently, TWiki has a great feature set, but it's not easy to learn or easy to use.


MasterRefactor Final Conclusions

  1. There's no getting away from the fact that a high degree of human participation is required to make a Wiki work. The majority of users have to live by CollaborationGuidelines - structuring content, voluntarily refactoring and generally maintaining, over and above the content of their contributions. This goes against usual software practice, where the emphasis is on filling in the blanks, with as much automated assembly of final product as possible. This point is noted often and often eloquently in on c2.
    • This in no way makes TWiki harder to use - although some people will have a hard time getting over the idea, if ever, this is probably an advantage for the majority. There's a learning curve associated with all software, and Wiki CollaborationGuidelines are a lot more common sense and intuitive than lots of other program controls.
  2. Including lots of basic sample configurations for different uses would provide an extreme advantage.
  3. Considering integration opportunities with complementary applications


Editor: MikeMannix - 07 Oct 2001

COMMENTS

Topic used to be called SeveralIdeas - I have refactored it into DmozCatalogPlugin, PackageTWikiStore, PluginsRegisteringTheirDirectives, LocalizationIsNeeded -- MartinCleaver -17 Nov 2001)

A running MasterRefactor-like page could be generated with some intelligently constructed boiler-plate searches utilizing BookView. For a quick & dirty example

This would help catch new topics which are created by people (like me) who don't always realize there is already an active discussion happening. Of course to really work humans need to be watching for these threads in order to pull them into the "main" topics before the upstarts get going too strongly.

-- MattWilkie - 20 Nov 2001

I'm always qualifying my comments as coming from a non-programmer, simply 'cause I figure most regulars here are, and I don't want a CONCEPT to be mistaken for CLUELESSNESS if it was imagined to be coming from a Master Programmer. So...from an NP POV my take on the Master TWiki Vision:

  1. As a Wiki clone, TWiki has diverged so far from the course of other Wiki clones, without losing essential Wikiness, that it could practically transcend itself. The divergence is in the number and type of features, no doubt driven by the "corporate intranet" focus. TWiki is feature-packed every which way: security, configurability, open to easy integration with just about any protocol.

  2. Meanwhile, TWiki's not the first choice for various non-corporate intranet projects. A high-volume site like Wikipedia is using...UseModWiki. Hmmm... It's interesting: TWiki's around 400-500K (without the data pages and w/o RCS), while UseModWiki is 60K or so.

  3. UseModWiki is the only other Wiki I've installed and played with. And the original Wiki, on c2, is the one I've spent the most time on, reading stuff. I love the simplicity of both. I especially like the reverse indexing click on a title for a related topic list feature. It makes single-window browsing work, you can always back track in a couple of clicks.

  4. So there's this essential Wiki thing, the freeform editing, intuitive navigation, and fast searches, the easy linking and the formatting shorthand, that's universal - Wikiness. In TWiki, the reverse indexing is easily reproduced, with a Ref-By type of precoded search... And TWiki is still fast - it hasn't been bogged down by all the features. BUT, it somehow doesn't have the elegant simplicity of UseModWiki. Part of it is simply the layout, which is a little complicated, busy - interface design is a lot of it. And MAYBE a few key tweaks to the functionality and implementation of core features, control layouts, whatever, would have a significant effect...

  5. Finally, there's TWiki's stated corporate intranet target. The precise requirements aren't specified, but it's safe to assume that meeting formal IT department requirements for "authorized software" used over company networks is one. And simply convincing people - decisionmakers, and potential users - to deviate from the norm of brand-name, non-Open Source products, and familiar, structured interfaces. Clearly, security, easy installation, and self-contained, browser-based operation are basic requirements for the former; a "professional"-looking GUI, straightforward basic controls, and easy user docs__ are probably the basics for the latter. Curiously, while the feature set and relatively easy configurability of TWiki continue to grow, the immediate, out-of-zip experience seems to be far from bulletproof on any of these points, and particularly lacking on the user end of things.

  6. Since TWiki is a great success in its target market, without immediately meeting the apparent obvious requirements, suggests that the people using TWiki now tend to take quite heavy customization - much of it done "privately", GPL or not - as a matter of course. Which means that, although as a package, it could be, TWiki may not be "suitable" for the entire audience it could serve, simply because of a very specific dev focus, that affects docs, final packaging, and relatively minor individual dev prioritizations (which features get tweaked first).

  7. So the core idea behind MasterRefactor - the motivation beyond simply decluttering and organizing - is to see if, with all the many suggestions and thoughts and ideas crammed in there, an UltimateTWikiBlueprint would emerge.

  8. What it would be: Out of the box, a supersimple, fast, minimalist design core application: fast, intuitive, with every tool and capability RIGHT THERE without thought as you need it, for basic text collaboration with easy HTML markup. THEN, bring on this incredible arsenal of "add-ons", meaning, the other standard TWiki features - authentication, templates, supersearches, WebForms, etc, etc - PLUS a sea of Plugins for all occasions, PLUS easy hooks to integrate with open data exchange protocols. And they would all fit in like kit parts, with clear indications of performance costs, and simple configuration, and no conflicts. You start out with a sleek, performance sports coupe and can build it into some sort of monster SUV super tank. Whatever you like.

Hope that makes sense. Right now, TWiki is obviously great. But there are still a lot of little usability annoyances. And the graphic design needs a cool, sleek makeover. Past those practical steps, the NP part makes things fuzzier for me, but I imagine a top shelf TWikiOO makeover, and possibly database connections for data storage, and tighter Perl/Apache integration, whatever.

All this realized as a set of clear comprehensive future dev core specs. I don't think it'd be in any way inconsistent with, and major advantage in fact for, the corporate intranet mission, and it could result in a revolutionary Net Product, FOR THE WORLD...

No? Yes! Maybe?

-- MikeMannix - 21 Nov 2001

clap-clap-clap Mike, I think the effort you've been putting in here to wrap your head around (and organize!) the entire Codev wiki is amazing. At work I've been looking at a similar problem: 5 years of copious documents and thought fragments scattered over 367mb in 1703 files and 141 folders, most of them written before I started working here.

Anyway, I just wanted to say don't get too ...manic... {heheh} about this. That means, remember to sleep once in awhile, go outside, smell the roses, etc. smile

WRT the automatic reverse lookup of other wikis: yes I think that should be a feature of twiki too.

-- MattWilkie - 22 Nov 2001

Above mention is made of:

  • The most important point, perhaps, is that the TWiki developer community has quite different skills and tastes in user interfaces to the target user community on corporate intranets, where even technical people prefer WYSIWYG and GUIs. Currently, TWiki has a great feature set, but it's not easy to learn or easy to use.

How about modifying the upload/attachment code to be able to append an html/text file into the current topic? That way people could use offline WYSIWYG/GUI tools and easily incorporate the info into a twiki page. I'm not sure about issues with embedded javascript and the other cruft that may show up (e.g. strip <html> tags and the like), but is it worth thinking about?

Hmm, now that I think about it I wonder what happens if I upload a suitably stripped externally generated html page and then do a:

% INCLUDE{"% ATTACHURL%/filename.html"}

in the body of the twiki page. Will it work?

Maybe rather that creating new HTML editors, a mechanism for installing html content created via other methods will reduce the need to generate YMHE (yet more HTML editors).

-- JohnRouillard - 23 Nov 2001

Just wanted to pump this topic up, so people working to reorganize t.o have a chance to read this for ideas.

-- RafaelAlvarez - 18 Aug 2008

Edit | Attach | Watch | Print version | History: r54 < r53 < r52 < r51 < r50 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r54 - 2008-08-18 - SvenDowideit
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.