#1: Starting : how things look like When user accesses the dating system, there is a left margin with following entries: - Tutorial - Profile - Configuration - My photo's public thread (number of new) - New (number) - Trashed - Delayed - Selected (number / number of new) Tutorial is a series of public web pages explaining how things work At every stage of the use of dating system, the interface will display (in left margin and eventually elsewhere) the set of possible functions and, among them, the set recommanded functions (which evolves as operations progress). ============================================================================= #2: Registration: making one's file (parameters and criteria) ================================ The selection criteria of possible partner will happen by a system of negative points, called penalties. For each possible situation concerning the parameters of the other person, the user will affect a number of penalties from 0 to 40. For each parameter, will be a number of penalties, or of common penalties. The computer will consider a person as a possible match so that each can review the other's profile, if the following three conditions are satisfied: - His/her total number of penalties in the user’s criteria is lower than 40, - The user’s total number of penalties in his/her criteria is lower than 40, - The sum of these two numbers and of the common badness penalties is lower than 70. The reason to define common badness and not put all in either part's is that it depends on a common choice, so that if there are for example Option 1 : badnesses 0 / 20 Option 2 : badnesses 25 / 0 sum of everything else: 5 / 20 then Option 2 may be a good compromise (30/20) but Option 1 is not (0/40) while Option 1 would have been kept as the one minimising the sum of penalities for this criteria. Maybe we could try computations to explore the possible compromises but simply define common penalties and use as above is simpler and acceptable. Therefore, for each criteria of selection that is not for a common penalty, the user gives the number 0 to the best possibility in his view, and 40 to what he wants to exclude. Here they are: - Languages: for each possible language the user is asked to enter the skill in the language: 0: not speaking 1: something 2: a little 3: manage well 4: good 5: very good/native The user defines the badness to each possible quality of conversation (gives a number of penalties for each of the six possible qualities of conversation). This must be a decreasing series of numbers, as a poor quality of conversation (0) has a bigger badness than a good one (5). This is not a common (symmetrical) badness but separated (one's badness for the other's criteria) The quality of conversation of 2 people in is their best quality of conversation among all languages. The quality of conversation in some language is defined to be the minimum of the skills of both people in this language, plus possible bonus which depends on either one's willingnesses to learn the language of conversation: there is the question - Are you ready to learn the other's language (check: 0 or 1 or 2) ? This would add this quantity to the quality of conversation in a language where the other's skill is better than yours, but not exceeding the other's skill. For each of the following, the user tells which his situation is, and how many penalties for every possible situation of the other: - Nationality (not sure it is useful) - Gender : M/F/other - drinking habits - Birth year - Marital status - Children already in charge (0,1,several) - Height - Weight - Eyes color (colors should be displayed) - Hair color (idem) - Hair style - Ethnicity - Religion or creed - Education - Income (range) - Handicap : no - a little - yes For each possible hobby or interest, same question: do you like (yes - a little - no) Badness if the other likes - if a little - if no Then, here are common badness criteria: - Geographical criteria: make a table with columns: Region | badness as a place for first meeting | would have an income there if a long-term living (yes/ a little or perhaps /no) | badness if other has | a little | won't have an income - Checkboxes (or active links) in front of divisible regions -> replaces in the table, the line of this region by as many lines as there are subsets of this region. When not divided, it means the same answer for all regions First are displayed the continents: North America - South America - Europe - other western-style regions or islands - Africa - Middle-East - East (ex- soviet union) - China - India Explanation: There are here two different criteria: First, the common badness for first place meeting is defined as the minimum over all geographical areas, of the sum for both people of the badnesses they put for this area. Second, the common badness for long-term living place is defined as the minimum over all geographical areas, of the sum of both badnesses for each other on this area, where the badness of a person A for the other B in an area is the one affected by B to the situation regarding income that A declared in this area. - Type of relationship: for each type of relationship, put the badness: - Holidays: - Correspondence: - Short relationship: - Long relationship : - Marriage: ..... (this list of types of relationship is not fixed, we can discuss possible variants before implementation) - Want children (zero for your choice, badness for the other) ? - No: - Yes: (or 1: , 2: , >2: ) Then will be computed the sums of the numbers of penalties over all parameters/criteria, giving 3 total numbers: the total number of A's penalties for B, of B's penalties for A, and of other common penalties. About changing parameters/criteria: The user is warned to be very careful while filling the fields and especially before he send his profile, as it will apply to the testing of all active users at that time, so it eliminates possible matches who would't fit the present file and the contact won't be established when he performs any changes, until he eventually resends the profile, which can't be done often (see below). Ideally, the user should try to make his file perfect before first sending it, so that then he needs not modify it for years. ============================================================================= #3: Profile configuration page ================================ 1. Configuration for the display of lists of matches. 2. Profile status 3. Upload photo(s). 4. Advices 5. Choose a pseudo. 6. PWP 7. Sending / re-sending profile ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Display configuration for matches lists (also accessible from each of these lists, each only needs to be filled before use). There is a separate display configuration for each of the 4 matches lists as accessed from the left margin. At least for the new matches list, user must mention his preference order among picture types he wants to review. A maximised pop-up is opened to show the different possibilities of picture types and select preference among them. For this, drawings are displayed instead of real pictures, and this provides a test for the available size of the screen. Also, for each of the below lists, is a choice of which parameters to display together with the pictures (by default none). Normally, face pictures would be displayed in 2 rows and 3 or 4 columns while body pictures are displayed in 1 line and 3 or 4 columns, except if user chooses to display additional data that may take its share of the screen. 2. Profile status Here the user can swich his profile status between the following states: - Inactive - Active - Passive - Hidden Before switching, value is Inactive. The first time user comes to this step, he is required to check that all his profile is OK. Then he confirms this by switching status to Active (which here = until first sending, makes no difference with Hidden). This produces immediately the checking of automatic matching of user profile A with other (recent local / remote still in cache) active or passive profiles and remote profiles B in cache (see details below). The matches B that fit appear in A's New matches list. 3. Upload picture(s), or enter their URL. There is a list of picture types. Each type has its own intervals of possibilities for height and width, and is represented to the user in the form of a drawing figuring what kind of pictures it aims to be. - Body picture = height from 50% to 90% of a normal screen; small width (20% to 30% of normal screen width); - Face picture (normal); - with makeup (if user is a woman) - with glasses height from 1/3 to 1/2 of screen; width 20% to 30% of normal screen width (more possibilities can be added in further updates of the program, e.g. with more accurate intervals, to adapt to different screen sizes...) The system should check dimensions before accepting the picture. For each picture type, the user can set a picture or none. He must set at least one picture among the different types. 4. Asking for advice about the photo (yes/no). On every server there are two forums of dating advices: one for men's pictures, one for women's pictures (or how else ??) (both visible by no matter who) with one thread per profile with its picture. Or equivalently you can call them two folders of forums, one forum per picture, but these forums do not need internal divisions into threads. The concerned user is the admin of his own thread, and operates an a priori moderation over messages posted here by others. He can ban users from any access to it. These forums or thread, as you wish to call them, are invisible from the “public forums” folder, but accessible from dating system (including GLS access to peer sites ones). - In the first case (Ask for advices), a thread for the user is created and accessible to the advices' list. Links to it are put everywhere his photo is shown. - In the second case (Don’t ask for advices), a thread is also created but no such link is shown. The thread is only accessible from the Delayed list (see below). It’s even invisible from the list of forum’s threads. Also these entire two forums are accessed from the dating actions menu. 5. The user chooses a pseudo under which to operate his dating account. The user can have an only dating account. In future he won’t have possibility to change this pseudo. Either, he won’t have possibility to remove this pseudo unless the dating account is removed. 6. Creating a personal Web page. This refers to the PWP/wiki part of the project. For each of both S and S+ statuses (see below), user refers to an existing PWP of his, or creates a new one. With respect to the general PWP/wiki system, the features for dating use are: - Its rights system is specific (or at least compatible): editing right is private and displaying right is such that the links to it as defined below (from Selected list) will always be valid. - The header that links to private forum, leads here in particular the visiting selected match user to the corresponding private dating forum 6. Sending profile Before first sending profile, user is asked to : - Re-check and possibly correct one last time all details of his profile (be more selective if he received too many new matches, less if he received not enough). - Choose the profile status between Active, Passive and Hidden (guidelines help make this choice). User is only allowed to send profile as Active or Hidden if there is no more Active matches to review in New matches list. This function, which is permitted only if profile is not Inactive, sends the profile (parameters and criteria) to all servers of the network to be tested against all other profiles. There is no difference whether any two different users are registered in the same site or in two different sites: all happens the same way at the same time. There will be displayed the history (days and times) of profile modifications and of the profile sending already operated. Profile sending must be limited in frequency: for example no more than twice in 4 months. And it can be done only if profile has been modified since last sending. The sending of profile to every other host B should also carry: - the profile status - the URL of the picture (that will just be used as such for other users display) except if the profile is Hidden, in which case this URL will only be sent later, during the switch from N/U to S/N or D/N. - the list of ids of all B's users with any status */N (see below) among the user's maches; in other words, all those who were calculated compatible by automatic criteria but for which it is not yet known by B. This is so that B can recalculate the possible new automatic compatibility, while not wasting its time and the one of the users with what has already been seen automatically compatible and which were already humanly processed or are already on the road to human process. =================== Matches status; role of profile status =========== 1. List of matches statuses 2. Operations done with received profiles 1. We will call "match" any pair (x,y) of dating users that have been calculated compatible in terms of automatic criteria (even if they don't like each other). The reciprocal human choice among matches, will be processed in terms of a pair of two parameters (A/B) attributed to each match (x,y), with the following conditions: - Each of A and B takes values among the following items: U,N,T,D,S,S+, which stand for Unknown, New, Trashed, Delayed, Selected, Selected+ (note: letters U and N are exchanged here as compared to the previous specification text, so it may appear now "wrong" in the existing code) - Saying the status of (x,y) is (A/B) is synonymous to saying that the status of (y,x) is (B/A). - Every match (x,y), it is present in the database of x's host with the information of the full status (A/B) except if A = U or B=T, for which it is absent and only known to y's host (because U/U does not exist and T/T only happens by accident and should still be traced somewhere to be taken account in re-sending profile operation). - The value of A is the expression of x's choice (except if A=U or A=N in which the choice has not been made yet); at every operation of user x concerning y that modifies this choice, the signal must be sent to y's host to update A in the B/A record for match x there, or to update B from U to N according to conditions below, therefore adding x to the y's matches in y's server database. 2. Operations done with received profiles When a user of another host (or another user of the same host) sends the profile, the following operations done for each of local users with a dating profile with status other than Inactive, and such that local and remote profile are neither both Passive nor both Hidden: - First, check if the match is not yet known (with some existing status, so on the human process). If it is already known, do nothing. Otherwise: - Second, check the automatic compatibility criteria as described above. If it is not compatible, do nothing and forget about it. Otherwise: - If local user profile is Active or Hidden and remote profile is not Hidden (so it is either Passive or Active), then the match is given status N/U (so the sender's host is not informed) - If remote (sending) profile is Hidden then it is given status U/N so it is sent back to sending host and locally ignored. - Finally, if local profile is Passive and remote profile is Active, then, it is given status N/N. ============================= Matches lists =============== In every of the 4 lists accessed from left margin, matches are reviewed in a form and their status can be modified using radio buttons. 1. New matches list This list contains matches of the following statuses displayed in this order: N/S+ N/S N/U N/N N/D unless the other is Hidden Matches with the same statuses are shown roughly in the increasing order of the sum (B's penalties according to A's criteria + common penalties + 10 if the other's profile is Passive). But in details, they will be grouped so that pictures of the same sizes (or of the same type ?) appear together, so that they can fill the screen as they should. For better using the screen, we can consider that face pictures with bigger height go above (or below) face pictures of smaller height (i.e. so that the sum of heights is never bigger than the height of the window). The 3 radio buttons for each match are to modify the status into T, D or S. There is no option to keep the N status after review, so that a match will never appear twice in this list (except if the form was not submitted, which the user does not normally do thanks to the Last submit button mentioned below). A display idea would be to give these 3 radio buttons the colors of a traffic light (red=T, orange=D, green=S). Every match is checked T by default (maybe this default can be changed in configuration ?). The present status is not displayed. An idea was that the display was inside two pop-up windows alternatively coming in front: when the users submits his selection in the one, the other comes in front. The idea is to save time: the next pictures are being loaded in the background window while the user is reviewing already loaded pictures in front. But I heard that it is not needed, as it is possible to load in advance the next pictures to the browser memory, to display them only after. There will be 4 buttons for form submission, expressing what to do after submission: Previous - Next - Next&finish - Finish. "Next" displays the next (already loaded) pictures and loads further next ones. "Next&finish" displays the next (already loaded) pictures but does not load anymore pictures; it has only "Previous" and "Finish" buttons. The "Finish" button closes this pop-up after sending the form. The Next and Next&finish buttons disappear when there is no remaining new matches. Together with Next button, is shown the one number of all remaing matches with a status among N/S+, N/S, and N/U if the user profile is Passive, or among N/S+, N/S, N/U and N/N if user profile is Active or Hidden (except that N/N does not exist with a Hidden profile that was never Active...) (so users can see at the end 0 remaining new matches and continue to review them). In the modifications of all match statuses operated in the review, only the first of both letters is modified except for : - The modification of N/U into S, making it S/N instead of S/U (so S/U is not a possible status) - The modification of N/U into D which makes it D/N in the case when both users are Active, and possibly also if present user is Hidden but chose so (option to put in profile configuration) and remote user is Active. Problem : how to cope with unavailable pictures ? Let a user A@B's browser having trouble loading C@D's picture. Then it will automatically warn B and replace it with another match OR leave the space blank (without selecting tool, so it will remain New match). Then the question is how to resolve the problem of the absent picture. B will warn D of the trouble as soon as possible. B will also try to get the picture itself. If it can, then this picture remains in B's cache for a time, so A can see it next. Then C will be warned that there was this problem. The question should be determined (by testing) whether it was a temporary problem that needs no action, or whether the picture must be loaded again, or... According to the situation, C can contact D's admin about it. When the problem is resolved, D will signal this to all B's that contacted D about it. 2. trashed list Here are all T/* matches This can be operated in the same style as the New matches list except that the matches will be displayed in reverse chronological trashing order, and possibly direct jumping to another page. 3. Delayed list Here are displayed the matches with statuses S/N, S+/N and D/*. This can be in a pop-up or not, with either only 3 matches in 1 line and 3 columns, or in more pictures per page to be scrolled down. For each match, user can switch picture display between the different picture types. For each, there are 4 radio buttons for modification of status into S,S+,D and T, with the default checked button to be the current status. Moreover, for each match there is a link to info page displaying the full parameters list but not criteria (the specification details of what to display exactly should still be discussed), and a link to that user's photo advice list. This can be separated into two sub-lists: - S/N, S+/N - D/*. Apart from this, the displaying order can be fixed for example to be the chronological order of arrival into this list, and with possibility to browse thoughout the list at will. 4. Selected matches list Here are listed matches with statuses S/S, S/S+, S+/S and S+/S+. The full status information is displayed. Possibility to browse the list in 3 ways. 1) like in Delayed list (pictures, checkboxes to change status, possible parameters as chosen in configuration), plus the following links: - Info page as mentioned above - The remote user's PWP defined for status S, if such a link or PWP exists - The remote user's PWP defined for status S+, if it exists and the status is either S/S+ or S+/S+. - The private conversation forum between both users, or forum creation if not created yet. This forum displays itself on top, the other person's picture, link to PWP and info page as above. 2) same but with small pictures (either reduced or not face pictures, or reduced body pictures) so they can be manier per page. 3) “Dating forums” folder similar to other folders, that is accessible from user's folders list outside dating system. This includes those such forums that have already been created. ---------------------------------------- I'm still wondering about something in the description of dating system: I said that together with sending profile, some list of existing matches should be sent to avoid repeating the review. While keeping the goal I question the method. For the trashed matches, the T/U must be mentioned as they were unknown until then, but the T/S would not need as they were already known before. So what to do: that they be deleted in between and mention resent with profile sending to save some bytes of hard disk, or that they remain in database to save some bytes of bandwidth, while they should be considered as unknown in any other operation ? ------------------------ 1) nationalities http://drupal.org/node/11614 2) ethnicities http://en.wikipedia.org/wiki/List_of_ethnic_groups http://www.answers.com/topic/list-of-ethnic-groups 4) hair style 1. curly 2. straight 3. wavy 4. afro 5. glamourous 6. spikey 7. platted 8. wacky 9. short-fringed 10. long 11. short 12. skin 5) education 1. no education 2. primary school 3. secondary school 4. undergraduate (college) 5. Bachelor 6. Master 7. Doctor --------- Technical note on datings and translations: Datings should have its own translations files, separate from the translation files of the rest of the interface.