-
- tEC, the Electronic Confidant, is an Internet service platform for "hands off confidential" interactions. All such interactions follow some formal framework provided in advance to guide end users and prevent abuses to the privilege of true confidentiality.
For readers familiar with spreadsheets, tEC is the equivalent of a spreadsheet program like MS Excel. As often the case in real life operations, end users simply use spreadsheet templates which model how to turn inputs into results. These templates play the same role as tEC formal frameworks.
This manual covers an important type of formal framework, so-called tEC domains, used to set up matching and mailing services in a specific domain of interest. Interest must be defined by a unique combination of criteria such as market (jobs, housing...), geography (Boston, Paris...), topic (baseball, soccer, biofuels, eprivacy...).
The definition and implementation of a tEC domain is the responsability of the tEC domain maker.
-
- A tEC domain maker needs to fulfill three major tasks:
- define the list of "good questions", called the domain "vocabulary", which will enable:
- end users to specify their wishes so as to filter or select desirable correspondents
- and the organizer to exercise a formal control over the interactions.
For example "are you male/female?" is a good question for dating while it is illegal in most hiring situations in the US.
- set up the process according to which end users will access and use the tEC domain
For example will the service offered in the domain be:
- single (e.g. a dating service) or multiple (e.g. a hiring service + a placement service + a mail service)
- permanent (virtual data base) or scheduled (virtual fair)?
- design and release the components with which to present the formal framework to the end users:
- self-profiling questionnaires, to script how end users answer all appropriate "good questions" into a profile
- (wish) templates, to get end users declare the criteria according to which a correspondent is desirable or not
Together with the domain vocabulary to which they provide access, self-profiling questionnaires and (wish templates) make what is called the domain "grid".
| Top |
-
- A tEC domain maker needs to interface both with ePrio, on whose platform services the maker relies, and end users, for whose benefits the matching and mailing service(s) is (are) implemented.
The process describes how to fulfill the requirements for both interfaces, knowing the architecture of the service(s) ties them together in many ways.
-
- Assume the domain which the domain maker wishes to develop an offer is well defined and satisfies ePrio's conditions to be granted exclusivity.
First determine the number and the nature of the services to be offered (see tEC Domain Makers document for definitions)
- is the domain symmetric, senders and receivers all using the same criteria, or not?
( e.g. for dating or finding a roommate),
- if the domain is asymmetric, users being divided into two non overlapping categories
( e.g. buyers and sellers),
- what category will be the receivers, i.e. post their wishes as filters waiting for opportunity alerts?
( e.g. sellers are the receivers)
- should there be a reverse service, i.e. where the senders of the original service become the receivers of the reverse service?
( e.g. this time buyers are the receivers who get alerted to new opportunities)
- will there be a tECMail service associated with the above matching service(s)
In asymmetric domain matching senders and receivers get two different applications: outgoing (senders) & incoming (receivers) mail (*).
So up to five applications can be offered per domain in support of up to three services, the original service, the optional reverse service if applicable and the optional tECMail service.
What follows describes the process for a single service application. Repeat this process for each application while sharing domain commonalities.
(*) remember that in case of matching, the "mail" is not a tECmail but rather a counterFilter carrying the sender's own wishes.
-
- Next determine whether to offer the service:
- on a permanent basis, as a virtual data base
- or according to some public schedule, as a virtual fair,
a format which lends itself to repetition at some convenient interval:
e.g. every Thursday, or the first Wednesday of each month...
Both approaches have merits. Which is the better depends in part on the way the domain maker intends to market the service.
Notice however a unique functionality of the virtual fair format. A tEC Fair Play fair is made of a series of rounds. During each round all participating "senders" are matched against all participating "receivers" per the round public schedule. Under the Hands Off confidentiality shield multiple rounds can therefore implement cross auctions, wherein all "receivers" compete among themselves to find the best matching "senders" at the same time all "senders" compete among themselves to find the best matching "receivers".
Fill up the tEC Domain Parameters form to set up the schedule if any, together with other parameters related to:
- Naming conventions
- Packaging
- Presentation of the Grid to the end users
Save this form according to instructions.
-
- A tEC domain maker interacts with ePrio at three levels:
- commercial: to secure exclusive rights to the domain under consideration (see ePrio's proposal page)
- technical: to implement the service
- operational: to obtain or renew rights
- on behalf of new clients who are not yet tEC users, to invite them to tEC - simply ask for a number of invitations by mail
- on behalf of the clients who want to receive mail - attach the list of their tEC ID's and the service in which they are to be "receivers"
Note that each service requires its own mailbox and that ePrio charges a fixed nominal fee per mailbox per month (see ePrio's proposal page). No mailbox is required for sending mail.
Technical implementation requires the following steps:
- initial packaging, done by ePrio based on the following deliverables from the domain maker:
- the java file containing the domain vocabulary as prepared with the toolkit
- a copy of the tEC Domain Parameters form defining the basic organization
- an optional zip file containing the html interface for the application (*)
- initial receiver right attribution by ePrio upon request to a list of tEC ID's provided by the domain maker
- end user grid access methods (self-profiling questionnaire and wish template), prepared by the domain maker with the toolkit
- the domain maker is responsible for posting the self-profiling questionnaire to the tEC server with the help of the toolkit
- ePrio is responsible for uploading the wish template file as delivered by the domain maker
ePrio will also upload three files provided by the domain maker to give useful online advice to end users on:
- final packaging, done by ePrio based on an updated tEC Domain Parameters form (with grid access parameters)
- testing, using some of the tEC ID's to whom ePrio has previously granted receiver rights
- final release, done by ePrio upon request on its tEC application catalog
and, in the case of a private label (**), by the domain maker on its own tEC application catalog
- updating.
Under a virtual fair format, updating is easy to do as the whole cycle above can be run again if necessary.
Under a virtual data base format, care must be taken to ensure upward compatibility to former users.
for example the vocabulary can be extended but not shrunk nor overwritten as it would invalidate past profile declarations.
(*) it is recommended to keep the default interface provided by ePrio at least until the rest of the service is fully developed
(**) it is recommended to defer requesting a private label until experience has been gained by the domain maker from at least one service
-
- A tEC domain maker interacts with end users on four levels:
- marketing: to make sure potential users know about the service (*)
- commercial: to receive the revenues according to the domain maker's business model
- technical: this covers two aspects
- generation of an invitation to potential users who have not used tEC before (see interfacing with ePrio)
- assistance to all users relative to the service offered by the domain maker
- operational: to grant all interested users receiver rights for the domain service at hand (**)
(*) Note that the release of an application alerts all current tEC users via the tEC application catalog
(**) while ePrio does not impose any business model upon the domain maker, notice the domain maker controls via ePrio the granting of mailboxes to all tEC users in his or her domain.
As a result, a model based on mailbox rental is easy to set up and administer.
| Top |
-
- Since all matching and mailing services follow the same formal pattern, ePrio has implemented this pattern as a meta tEC application. This matching meta application is distributed to all end users bundled together with the tEC platform.
For a given domain, the corresponding formal frameworks merely define how to drive the matching meta application based on the underlying grids .
The tEC domain maker toolkit enables one to declare the grids directly into the format expected by the meta application. It avoids programming in Java, the language used by tEC, and outputs most of the deliverables requested by the implementation process.
-
- It is recommended to create at least two special users to use the toolkit:
Once a domain maker has been invited to use tEC, he or she can create these extra users without any action from ePrio. However the domain maker still need to request receiver rights from ePrio for the one in charge of end user access (see initial receiver right attribution).
These tEC users can download and install the "Domain maker toolkit" as any tEC application. Just click on "New" to access the tEC application catalog from the tEC main menu. Because the toolkit is not a matching/mailing service, it is installed as "special services" on the main menu.
| Top |
-
- A vocabulary is made of the list of "good questions" upon whose answers tEC can fill a user profile and perform its matching and filtering tasks for the domain application at hand. To this list add questions whose answers are relevant to a relationship between two matched and consenting parties, such as name and address.
While strictly speaking each application needs a vocabulary (see overall organization), it is good practice to design a single vocabulary for all applications in a domain.
Since end users only see a vocabulary through the grid access methods of the application, it can be left to these methods to select the subset appropriate to each application within the domain vocabulary.
The toolkit must be used to format a vocabulary as required for packaging. However it is good practice to first prepare a text document, free of format constraints. Such a text document is enough for ePrio to judge whether exclusivity can be granted to the would be domain maker (see ePrio's proposal). Later the text document can be reused as a source for cutting and pasting into the toolkit.
-
- A vocabulary is a list of codes, one per question or fact, laid out into pages for easy visualization.
The domain maker assigns each code a unique number, a data type and a name.
End users only see the code name prefixed by the page name in which it has been filed. Use this convention to shorten code names. e.g. "Purchase Intention: Furniture" uses the page name "Purchase Intention" to qualify an otherwise vague "Furniture".
To present special data types, a vocabulary defines some formats. For the sake of consistency it is recommended to adopt:
- "yes" and "no" for boolean data
- "between ... and ..." for range data
- and the traditional "MM/dd/yyyy" form for dates
The code numbers can be reused from one vocabulary to the next as all vocabularies share the same space. It is good practice however for a domain maker to think ahead of all the domains he or she plans to operate and design some overall code numbering scheme.
In particular imagine several domains within the same geography. The domain maker can create a primary vocabulary and develop all these domain vocabularies from a copy of the primary (*).
(*) For even more powerful ways to manage such a hierarchy of vocabularies, see future documentation.
-
- When accessed through the grid access methods, all domain maker vocabularies incorporate a common root provided by ePrio to avoid duplication of efforts. For example an end user needs to enter his or her name once only for all applications.
Common codes do not "share" the space of domain maker vocabularies and their code numbers do not conflict.
If a common code however does not satisfy the domain maker, it is always possible to declare a new code in shared space to take its function. The grid access methods need only to reference the better code and hide the other. For example the common root currently provides only a token list of "native languages" with the "other" selection left in its native first place instead of being displayed last as it should be after ranking.
The domain maker can also declare three special items to reference through the grid access methods.
- under number 0 (reserved to this effect) and type ID, the "Operator tEC ID" (suggested name) of the end user, a unique profile fact which the end user receives with his or her tEC invitation and cannot edit
- under number 10 (suggested number) and type ADB, an address book of "Know Correspondents" (suggested name) - no other address book (type ADB) should be used in the domain vocabulary
- under number 50 (suggested number) and type ID, the "Recommended Correspondent ID" (suggested name)
These conventions allow for a consistent implementation across all domains of tECMail and recommendations:
- tECMail filters implement white and black lists by checking an unknown correspondent's "Operator tEC ID" against a relevant selection from an end user's "Known Correspondents" address book for the domain (see the Generic mail service bundled with every tEC).
- Match filters implement recommendations by checking an unknown correspondent's "Known Correspondents" address book against a relevant selection from an end user's "Known Correspondents" address book for the domain.
The confirmation exchange allows the latter end user to get the unknown correspondent's "Operator tEC ID" to file in his or her profile as the "Recommended Correspondent ID" for the domain.
A special tECMail filter can then be used by recommenders to match this "Recommended Correspondent ID" to a relevant selection from their "Know Correspondents" address books for the domain.
By asking permission from the special tECMail filter of all acceptable recommenders for the domain, an end user can verify in one click whether the unknown correspondent was indeed recommended as claimed and send a thank you note to the recommender(s) concerned.
-
- To create a new vocabulary with the toolkit, one first create a draft plan:
- "Open" the special service called the "Generic Editor", installed as part of the toolkit
- then click on "Plans", with path and domain parameters set to their default values.
- finally click on "Vocabulary"
The filename of the new vocabulary draft plan must start with "shared " followed by significant details. It is good practice to include language, formal vocabulary name and version (e.g.: shared en Boston_Dates V3).
When the draft is ready for compilation, "Save As" the vocabulary formal name as declared in the tEC Domain Parameters form
Close the draft and "Open" the formal version.
Make sure the directory path to the compiled version to be created exists. tEC will not create it for you.
Finally click on "Compile". The resulting java file needs to be delivered to ePrio for initial packaging.
To update a vocabulary, always create a new copy of the draft, with the appropriate new version number. Delete and recreate the formal copy before each compilation.
| Top |
-
- To use a matching application, one declares one's profile by means of a relevant self-profiling questionnaire. This questionnaire is automatically downloaded the first time one clicks on "My Profile" after having selected this application.
Note that mailing applications do not use self-profiling questionnaires.
Such a questionnaire has a lot in common with other grid access methods in the same domain. To maximize reuse, please follow the arbitrary conventions below, with the understanding they evolved from job recruitment services.
Wait till ePrio has confirmed initial packaging and receiver rights attribution for the corresponding application and start by downloading and installing the new application(s) to be able to access the domain vocabulary. Proceed to use the toolkit to create a base draft plan:
- "Open" the special service called the "Generic Editor", installed as part of the toolkit
- then click on "Plans", with path set to its default value and domain set to the formal vocabulary name as declared in the tEC Domain Parameters form. Assume this name to be "Formal_Domain" in the sequel (e.g.: Boston_Dates or Boston_CAT_Technologists).
- finally click on "Filter"
Assuming the service mnemonic declared in the tEC Domain Parameters form to be "XYZ", use "XYZ_master" as the base plan filename.
If the domain is asymmetric, further assume the mnemonic to be "XYZR" and use "XYZR_master" as the base plan filename.
Once developped (see below), the base(s) are specialized to the relevant applications as follows:
- from the Filter Dialog and Profile Matching menu, click on "Export As", using "Filter_Template" as the new filename.
- close the Generic Editor
- move file "Filter_TemplateExp.html", thus created, from the user directory (*) to the working directory "tec/shared/templates/en/"
- reopen the editor, this time with the domain set to a conventional name defined as follows (**):
- for symmetric domains, with XYZ_master: "XYZHelp_Wanted__Formal_Domain"
- for asymmetric domains, respectively:
- regular service sender's profiling, with XYZ_master: "XYZHelp_Wanted__Formal_Domain"
- reverse service receiver's profiling, with XYZ_master: "XYZRHelp_Offered__Formal_Domain"
- reverse service sender's profiling, with XYZR_master: "XYZRHelp_Wanted__Formal_Domain"
- regular service receiver's profiling, with XYZR_master: "XYZHelp_Offered__Formal_Domain"
- from the Plan Editor screen , click on "Import" (***), followed by click on "Open"
- finally click on "Save As", using the conventional filename:
- for symmetric domains, from XYZ_master: "XYZ_HWmaster"
- for asymmetric domains, respectively:
- regular service sender's profiling, from XYZ_master: "XYZ_HWmaster"
- reverse service receiver's profiling, from XYZ_master: "XYZR_HOmaster"
- reverse service sender's profiling, from XYZR_master: "XYZR_HWmaster"
- regular service receiver's profiling, from XYZR_master: "XYZ_HOmaster"
getting rid of "Filter_Template" after each usage.
(*) To find the user directory, drill down inside the tEC installation directory starting with the directory bearing the user registration.
(**) Notice the two underlines separating the application dependent prefix from the formal domain name
(***) The button color should be red, not blue, since this is a local action.
(****) A useful trick is to write all those names ahead of time into a notepad file. Then cut and paste to input them as needed into the Genenric Editor.
-
- A questionnaire is made of two major parts:
- a script, to list the relevant profile facts and the order in which to put the corresponding questions to the end-user
- a list of tests, with which to control both the script dynamics and the decision about whether accepting the participation of the end user
In view of his or her experience of the domain, the questionnaire overall design should be an intuitive task for the tEC domain maker. Use a word processor or a piece of paper to sketch it in writing.
Some difficulty however is inherent in implementing such an overall design, e.g.:
- to ask an end-user for profile values, the script itself may use tests to skip irrelevant questions based on context
- tests are based on specific profile facts. Obviously tEC cannot perform a test which references a fact whose value remains unknown
To verify questionnaire consistency and completeness, resort to visual inspection and actual testing.
The following questionnaire implementation method has proven to be good in practice:
- start by giving the questionnaire a title to reflect its objective (remember to update the title after each duplication)
- use cut and paste from a word processor to fill up the standard messages used to:
- convey the decision to the end user to accept or refuse him or her (*)
- enrich a positive decision with two optional messages, dubbed the offer and the incentive
- convey instructions and contact information once the user has accepted a positive decision
- declare execution parameters such as the expiration date of the questionnaire (which can be extended through an update)
- specify what end-user profiles qualify for an invitation and derive all the tests needed (**)
- declare the corresponding script profile questions, standard facts from the domain vocaburary or ePrio's common root
- specify the script navigation, to check users' answers for mistakes or to skip irrelevant questions, and derive all the tests needed
- declare the list of simple criteria, tests based on a single profile fact which should be mentioned in the script (more on test types)
- continue by declaring weighted criteria, built from simple criteria previously declared
- continue by declaring compound criteria, built from simple and weighted criteria previously declared
- declare the invitation as a single compound criteria previously declared
- declare the script skips to implement the navigation with unconditional skips and previously declared tests
- declare the comments necessary to the script navigation as custom interactions
- finish the questionnaire script:
- declare the script comments using previously declared custom interactions
- reorganize the script sequence, checking for programming consistency
- add skip targets, using the final script sequence
- declare disclosures, profile elements, if any, end users have to tell the domain organizer to secure their participation (***)
(*) e.g., to reject users too young to participate when, in keeping with the laws, the service is offered above an age threshold.
(**) it is good practice to put in the base the tests used by the participants to qualify a match, accepting all comers by default.
- this anticipates on the design of the corresponding templates and will not be wasted
- since by default these tests accept all comers, they will not influence the decision to accept the participation of an end-user
- but most implementation errors will thus be trapped at an earlier stage
(***) remember that "Hands Off Confidentiality" protects users from being abused as they are asked their explicit authorization knowing they have already been qualified. But domain makers are free to subject participation to any disclosure, such as imposed by the law.
-
- With the exception of the "script break", it is recommended that domain makers turn to these advanced techniques only after having gained field experience with a simpler design.
- script break: assume the domain maker requires end users to disclose certain confidential facts which do not enter into the participation test (e.g. billing information).
Since any extraneous question is a brake upon end user interest, it is best to postpone asking for the facts, let alone for a disclosure authorization until tEC can assure an end user he or she is already qualified.
To achieve this effect, simply put the questions relative to those facts at the end of the script, preceded by a script break. (*)
.
- on line messaging: assume a domain maker has exclusivity over nurse recruitment in Boston but later find more practical to break up the service into more specialized areas such as Emergency Room, Pediatrics... In each smaller domain, an online message can be used to redirect candidates to a neighboring domain more appropriate to their skills.
Use on line messaging whenever:
- the participants can be segmented into non overlapping groups
- each participant should receive a message dependent on the group
- it is preferable to be able to quickly modify such messages online, without having to update the corresponding questionnaire
Simply:
- add to the questionnaire any test necessary to implement the segmentation
- declare this segmentation as a list of online message target audiences
- and insert into the script the orders to download the online messages and show the right one as if it were one more comment.
.
- quotas: assume a domain maker wishes to manage participation subject to some quota system, all in keeping with the laws.
Simply:
- add to the questionnaire any test necessary to implement the possibly overlapping groups on which the quota system is based
- declare this segmentation as a list of quota classes, themselves groupable for greater refinement into super classes
.
- statistic collection: assume a domain maker wishes to know the proportion of female participants between 18 and 50. There is no need to collect such a confidential information as sex and age in order to compile tEC statistics.
Simply declare a quota system with a group for each statistic to be compiled. If the corresponding quota counters (see posting) are set very high, their decrease will not limit participation but register the desired statistics.
.
- custom facts: this advanced feature is mentioned here for the sake of completeness (**). To the exception of tECMail application, it should not be used in regular domain making. Any useful profile fact should be included into the vocabulary so as to be stored permanently, independently from the questionnaire which asked the corresponding question.
(*) this feature is very useful to survey designers, to separate respondent qualification from survey taking proper
(**) this feature is very useful to e-interview designers, to avoid having to design, implement, compile, package and distribute a vocabulary as a separate file when there is no need to store the answers generated on a permanent basis.
-
- Once a questionnaire has been specialized to a final domain (see above), use "Save As" to make a final copy to use in operations:
- for symmetric domains: copy "XYZ_HWmaster" into "XYZCandidate_Profile"
- for asymmetric domains, respectively:
- regular service sender's profiling: copy "XYZ_HWmaster" into "XYZCandidate_Profile"
- reverse service receiver's profiling: copy "XYZR_HOmaster" into "XYZRSociety_Profile" (*)
- reverse service sender's profiling: copy "XYZR_HWmaster" into "XYZRCandidate_Profile" (*)
- regular service receiver's profiling: copy "XYZ_HOmaster" into "XYZSociety_Profile"
Click on "Release" to post the latter copy, in encrypted format, for circulation via the tEC server.
Questionaire circulation has two consequences:
- operational questionnaire management requires switching from the "Generic Editor" to the corresponding application
- for symmetric domains and asymmetric sender's profiling, check for incoming mail and click on "Confirmations"
- for asymmetric receiver's profiling, check for outgoing mail and click on "Confirm Replies"
In both cases find the questionnaire listed and "Open" it for management.
- circulation rights are drawn from the user in charge (see above) and assigned to the operational questionnaire
Operational management includes:
- if applicable, setting and updating online messages
- if applicable, setting and updating quota group allowances
- monitoring circulation and circulation rights
- updating the questionnaire (**)
(*) even for recruitment services, the conventions for the reverse service ignore the reality for the sake of process uniformity.
(**) remember that all updates need to be upward compatible. If it is not possible, good practice requires to create a new application set so as to leave no doubt in users' minds that they should redeclare their profile.
Provided the new vocabulary, if any, is an extension of the older version under the same formal name, users however will not have to reenter previously declared information.
| Top |
-
- Continue to assume the service mnemonic declared in the tEC Domain Parameters form to be "XYZ" and the base plan filename to be "XYZ_master" (see above).
Sender profiling flows into the receiver template and conversely and the same base(s) can be reused.
- from the Filter Dialog and Profile Matching menu, click on "Export As", using "Filter_Template" as the new filename.
- close the Generic Editor
- move file "Filter_TemplateExp.html", thus created, from the user directory (*) to the working directory "tec/shared/templates/en/"
- reopen the editor, this time with the domain set to a conventional name defined as follows (**):
- for symmetric domains, respectively:
- receiver's template, with XYZ_master: "XYZHelp_Wanted__Formal_Domain"
- sender's template, with XYZ_master: "XYZHelp_Offered__Formal_Domain"
- for asymmetric domains, respectively:
- regular service receiver's template, with XYZ_master: "XYZHelp_Wanted__Formal_Domain"
- reverse service sender's template, with XYZ_master: "XYZRHelp_Offered__Formal_Domain"
- reverse service receiver's template, with XYZR_master: "XYZRHelp_Wanted__Formal_Domain"
- regular service sender's template, with XYZR_master: "XYZHelp_Offered__Formal_Domain"
- from the Plan Editor screen , click on "Import" (***), followed by click on "Open"
- finally click on "Save As", using the conventional filename:
- for symmetric domains, respectively:
- receiver's template, from XYZ_master: "XYZ_HWtemplate"
- sender's template, with XYZ_master: "XYZ_HOtemplate"
- for asymmetric domains, respectively:
- regular service receiver's template, with XYZ_master: "XYZ_HWtemplate"
- reverse service sender's template, with XYZ_master: "XYZR_HOtemplate"
- reverse service receiver's template, with XYZR_master: "XYZ_HOtemplate"
- regular service sender's template, with XYZR_master: "XYZR_HWtemplate"
getting rid of "Filter_Template" after each usage.
(*) To find the user directory, drill down inside the tEC installation directory starting with the directory bearing the user registration.
(**) Notice the two underlines separating the application dependent prefix from the formal domain name
(***) The button color should be red, not blue, since this is a local action.
(****) A useful trick is to write all those names ahead of time into a notepad file. Then cut and paste to input them as needed into the Genenric Editor.
-
- Templates for matching applications are derived from copies of self-profiling questionnaires (see above). Their implementation is best explained in terms of modifications of questionnaire structure.
- the title must be adjusted to reflect the new purpose.
- the standard messages must be changed since:
- end-user acceptance or rejection comes from the (c-)filter owner, no longer from the domain maker
- execution parameters are different, e.g. filters must accept (c-)filters, (c-)filters must not
- the invitation must reflect qualification by the (c-)filter owner, no longer from the domain maker (*)
- the script error catching tests, comments and online messages if any should be deleted since template script execution during matching should not require any end-user interaction (**)(***)
- the quota system if any should be deleted
- disclosures must be adjusted to define the end-user feedback to give upon accepting a match rather than mere service participation
- if any disclosure bears on a fact not needed to evaluate the match, e.g. the end-user name or social security number, the script must have a break and the corresponding question(s) must be listed after it (see above).
- finally one must freeze any test which should not be modified by end-users when declaring his or her own wishes, e.g.
- if the end-user should not be able to change the single choice selection from a list of "preferred activities" if this test is meant to check "loves reading",
- assume a test based on the number of options satisfied by a correspondent using a weighted criteria with all weights set to 1. Such a weight list cannot be modified.
Like any programming task, template building presents a learning curve. Look first at the examples of Boston CAT Technologists (recruiter and candidate) and Dating in Boston (participant together with the expansion of scored criteria 17). Then do not hesitate to get going and improve with time. Use the bulletin board to share your experience.
Mailing application templates are built from scratch. Assume again the service mnemonic to be XYZ.
- The XYZ_HWtemplate should be designed as if it were a self-profiling questionnaire, which in fact it is. The end-user invites would be senders to participate into the outgoing service of corresponding with him or her.
Both script and test list are quite simple since at bottom one only needs to ask questions about the "Operator tED ID" and the "Known Correspondents" address book of the would be sender (see special vocabulary items) and declare a "white list" test checking the sender's "Operator tEC ID" against the receiver's "Known Correspondents". After a break point, it is recommended to add a free text custom fact called "Confirmation" to allow the sender a way to confirm a reply as well as questions on identity (e.g. first middle and last name) to carry the equivalent of a formal signature.
- The XYZ_HOtemplate is even simpler.
- its script should ask for:
- the "Operator tEC ID" followed by a break, itself followed by
- a free text custom fact called "Reply" to allow the receiver to send a reply
- questions on identity (e.g. first, middle and last name) to carry the equivalent of a formal signature
- its invitation should be a simple criteria checking whther the "Operator tEC ID" is not 0, i.e. a test always true.
(*) if the tests which define qualification by end-users have not yet been defined (see note (**) in questionnaire structure), they now must be added to the test list
(**) but script navigation tests must be kept since irrelevant facts are still irrelevant
(***)up to a script break if there is any
-
- Once a template has been specialized to a final domain (see above), use "Export As" to make a final copy to use in operations:
- for symmetric domains, respectively:
- receiver's template: export "XYZ_HWtemplate" as "XYZFilter_template"
- sender's template: export "XYZ_HOtemplate" as "XYZCounterFilter_template"
- for asymmetric domains, respectively:
- regular service receiver's template: export "XYZ_HWtemplate" as "XYZFilter_template"
- reverse service sender's template: export "XYZR_HOtemplate" as "XYZRCounterFilter_template" (*)
- reverse service receiver's template: export "XYZR_HWtemplate" as "XYZRFilter_template" (*)
- regular service sender's template: export "XYZ_HOtemplate" as "XYZCounterFilter_template"
Submit the corresponding html files generated in the user directory (*) to ePrio for posting on the server (**)
For mailing services, there are no self profiling questionnaires and the two templates "XYZ_HWtemplate" and "XYZ_HOtemplate" are both developped from scratch before being exported. By convention export the counter-filter template "XYZ_HOtemplate" as "XYZMail_template".
(*) To find the user directory, drill down inside the tEC installation directory starting with the directory bearing the user registration.
(**) While template may be updated and resubmitted at any time, remember updates must remain synchronized with the corresponding self profiling questionnaire and maintain upwards compatibility (see above).
| Top |
|