MultipleFormsPerTopic

Proposal

There should be a means have MultipleFormsPerTopic. This has been taken up in the companion topics CreateNewTopic and MultipleTemplatesPerWeb, but is somewhat of a distinct idea. The main concept is to allow a topic to have multiple Forms that are selected. It is further proposed that the [Change] button be allowed only in Topic Templates to reduce user confusion.

Goals of this proposal:

• At the time of Topic Template definition, the user would be prompted to select one or more Forms.
• It may still be nice for advanced users to be able to manually associate a form with a given topic, and this is probably best hidden in the More... functions.
• MultipleFormsPerTopic can allow the forms to be split into several logical parts. As an example, suppose you wish to have a standard TopicClassification sorting field, as is used in this Codev web. And only for things that get worked on, a AssignedTo and related fields, as these are not needed for FeatureBrainstorming or DefineTerm templates. Yet, you wish to be able to sort through everything according to these fields.
• MultipleFormsPerTopic can allow somewhat of a relational database structure, where you wish to pull in fields from several tables based on a common key for various views of that data. Of course, now the data is wrapped into the Topic File, but that is not necessarily the implementation, as the Topic File is strictly an implementation detail, and not part of user-level operation.

Proposed Implementation:

• There must be a means to list the Forms that are to be used in a given Topic Template. The creation of the Topic Templates is somewhat of an advanced-user activity, and should not be fully exposed to most users. Therefore, it is proposed that a single Form definition exist within a given Web. The form would list the Forms available for inclusion within a given Topic Template, as follows:

Name	Type	Size	Values	Tooltip message
TopicForms	checkbox	3		Select forms to use with this topic

And then the TopicForms topic would contain a list of the actual Forms that are defined, as follows (for example):

Name	Type	Tooltip message
CommonTrackingForm	option	This form allows for trackign of all topics, included in all topics created.
BookReviewForm	option	Form for creating a Book Review topic
EventForm	option	Form for an Event Topic
FeedbackForm	option	Form for a bug report or change request

The partitioning of data fields into forms will follow the same line of reasoning behing normative forms for data bases.

Each topic would then contain one additional form field, that of TopicForms. This field lists the forms attached to this topic. This field could be modified through the More... administrative functions.

-- RaymondLutz - 08 Dec 2003

Many agree with you - see AllowMultipleForms

I think we need some TopicNamingStandards to lessen the chances of similar but differently named topics.

-- MartinCleaver - 08 Dec 2003

Alternate idea (Warning - not quite thought through)

what if we allow only one WebForm per topic, and consider the TextField as a WebForm. This would mean that you would create a Multi-Form topic by creating several WebForm based topics and then linking them using an INCLUDE mechanism. This is then somwhat more analogous to each topic containing one row of a relational database, and Text based topics allow you to define queries on those tables. To make is simpler for users, the creation of each of the (non-Text)WebForm topics would be done automatically, behind the scenes (and so would the default linking).

-- SvenDowideit - 09 Dec 2003

Allowing only one form per topic was a conscious design choice to keep things simple. It would have been easy technically to store in the topic, but the ramifications looked more messy. I like Sven's idea. If we really need to have multiple forms per topic then it can be done, but let's first be really sure we need that. Another thought. An alternative to multiple forms per topic is to allow forms to be made from other forms e.g. using the %INCLUDE% directive. This might have issues if the feld names are duplicated in the combined forms (analogous to the multiple inheritance issues in OO languages).

-- JohnTalintyre - 09 Dec 2003

I tend to agree with your comments on this, and will accept the conclusions.

A side issue that may also have been discussed:

I am interested in the issue of not knowing that a given topic was discussed in the past, given that I am still trying to understand the discussions that have occurred. Much of this relies on individuals remembering that something was discussed, unless I pore over reams of search output for a simple literal string. Improving the search functionality would improve the ability to pare down the list of results. Perhaps there is some way to compare the statistical usage of terms in the topics and suggest that some of the topics may be similar based on the distribution of terms. Before a new topic would be committed, the user would be notified that there is similarity with some other topics. Then, we would need a way to conveniently unite the topics or abandon the new one. Also, somehow suggesting that some terms could be linked to topics may be a better way to go that using WikiWords. You have to remember them if you want to link to pre-existing topics. All interesting issues that are concerns in any knowledge-base such as this.

-- RaymondLutz - 10 Dec 2003

See RequirementsForMultipleFormSupport for the latest ChangeProposal