Title: Progress for Cuypers Meets Users Creator: Suzanne Little Date.Created: 2002-10-25 Date.Updated: 2002-11-05 Purpose: To describe the architecture so far implemented. Introductry Comments Overview of Architecture User Model MAO Expert Design Expert What's Bothering Me? The Next Steps -------------------------------------------------------------- Introductry Comments Currently the structure as described below is implemented in prolog. The values used (userA, red, 1, etc) are mere place holders and meaningless. Essentially the architecture reflects that described by Susanne Loeber except the optimisation layer which has been absorbed into the Knowledge Server and is called the MAO expert. Requests for values are given directly to the relevant expert from the layer in the generation engine. See the original Cuypers Meets Users in communication.pdf for a discussion of Susanne Loeber's User Model Architecture. BTW, I tend to use 'colour' when I'm discussing it as a concept but I tried to use 'color' in my code to keep it consistent with the rest of the system. Overview of Architecture The 'conversation' between the experts in the system sounds something like this: engine -> design : "color?" design -> user : "opinion for color?" user -> context : "who is the visitor?" context -> user : "visitor is X." user -> design : "color rules are [rule1, rule2, ...]." design -> mao : "color choices are [value1:[rulesList],value2:[rulesList] ...]" mao -> design : "[value2, value1, ...]." design -> engine : "foreground=#xxxxxx, background=#xxxxxx." User Model Purpose: Use information available from the visitor profile to select the most suitable user profile and provide rules indicated by that profile to guide the choice of values for system attributes such as colour, textsize and speed. Input: Visitor profile of the format profile(visitor, Age, CognitiveStyle, KnowledgeLevel, PhyiscalAbilities). This is retrieved from somewhere. How this is created is not covered by the user model. Age is a 2 member list showing the lowest possible age for the visitor and the highest possible age. If the age is known exactly then both values are the same. CognitiveStyle is either audio or visual. KnowledgeLevel is either beginner, historian or curator for historical reasons. PhysicalAbilities are either no_restriction or red-green. Eg: profile(visitor, [13, 130], visual, beginner, no_restriction). The user characteristics, profiles and values currently implemented have just been selected at random to fill the architecture and experiment with structure. Some thought and effort will need to be put into selecting appropriate characteristics and writing user profiles for the system. Output: A list of rules of the format systemAttribute(Persona, Value, Motivation, Ability, Opportunity). Persona: {user|author} Value: either a relative or absolute value for the system attribute Motivation, Ability and Opportunity: {pos|neg|neu} indicating the predicted effect of implementing the value on the user's MAO levels. Again, rules in the system at present have just been made up. The creation of the rules together with correct MAO values should be done along side the writing of the user profiles. Internally: User profiles are implemented in the same format as the visitor profile. These need to be created and hard coded. Eg: profile(userA, [13, 130], visual, historian, no_restriction). Selection of the user profile which most closely matches the visitor profile is done by applying a ranking system to each characteristic, Age, KnowledgeLevel, CognitiveStyle and PhysicalAbility and then summing the results. The best score a profile can get is 0 and if a profile is found with this ranking the comparison is halted. Otherwise the profile which scores the lowest is chosen. Some consideration of the MAO factors occurs here in the comparison rules implemented for the characteristics. For example, a user profile for a person with no physical restrictions is given a much higher score is the visitor is red green colour blind than a user profile with a red-green restriction is given for a visitor with no physical restrictions. It is more debilitating for a visitor with a red-green physical value to be provided with a presentation created for a person without this restriction than for a person with no restrictions to be given a presentation designed for a person with red-green colour blindness. These ranking and comparison rules are coded to ensure that the profile matched to the user is the closest and least likely to negatively effect MAO factors even if they do not effect the factors positively. Each user profile then has a rule which allocates a rule for the profile for each system attribute. For example, color(userA, rule(user, green, pos, pos, neu). The values here should preferably be relative rather than absolute to reduce the chance of conflicts with the device abilities and allow more flexibility in the system. To do: *Content of profiles, profiles to rules and creation of rules - currently rough implementation to test structure and matching technique. *Checking of comparison rules for user characteristics - are the values assigned reasonable? *Testing/evaluation - are the profiles chosen the best ones? General Comments: 1. When creating the comparison rules for the characteristics, my 'gut feeling' was to apply ranking of effect as Ability is more important than Motivation which is more important the Opportunity. This filters through to the MAO expert comparisons and ranking as well. Reasoning was that it is most important for a user to be able to use the system, then to want to use the system and finally to be able to use the system optimally. This should be backed in some way. 2. Essentially all the user profile really does is find what it considers to be the closest stereotype provided. There are many problems with this approach. Frank pointed out that there is no mechanism to apply absolute knowledge about an individual user. For example, if from the user's browser you are able to find set exact colour preferences (thanks, Katherina) there is currently no way to incorporate this information into the rules supplied to the design expert. Ideally, this preference should be translated into rules and given to the design expert but what about conflicts between the chosen profile and the user's set preferences - the user expert has no facilities for determining conflict so should it leave it to be discovered by the MAO expert later? Also how should MAO values be generated for these preferences? Keeping in mind that information other than set colour choices could be retrieved about a specific user. 3. Someone has to create all of the user profiles and the ranking rules for each user characteristic. MAO expert This started as the design expert but rapidly became a method for determining the ranking of design solutions as better for MAO. Sort of a mediator/decision maker, it uses the available rules to decide which solution is best. Purpose: Takes a list of schemes (design solutions) with their applicable rules and returns the one which is more likely to improve the user's MAO levels based on rules provided by the various experts and models. Input: Uses lists of rules provided by the User Model, Design Expert etc. to compare solutions and rank them. [[scheme(ID, Foreground, Background), [rule1, rule2]], ...] Output: Provides the scheme (design solution) that is 'best' for the user's MAO. scheme(ID, Foreground, Background) Internally: Sort of implemented along the lines of the game paper-scissors-rock. First the various opinions (contained in the rules) are combined to produce M, A and O values which are either positive, negative, neutral or unknown. More information available on how this is done in MAOexpert.pl - combineOpinion rules. The new MAO values for each of the solutions are then compared and one of the values is declared as the winner for each of M, A and O. More information how the comparison is done is available in MAOexpert.pl - rate rules. The resulting 'winners' list (winner for M, winner for A and winner for O) is analysed and one of the solutions is declared as superior. See comp rules in MAOexpert for more details. To do: *Evaluation and adjustment of the model. General Comments: 1. Currently the source persona (user or author) of the rule isn't taken into account when combining and comparing rules. This should have an impact, the questions are where, how and how much. 2. Also when combining opinions about a solution the number of positive/negatives has no impact. That is positive and positive is just positive not 2positive or something. This makes pos/pos equal to pos/neu when doing comparisons. 3. This style of comparison relies heavily on having good rules. These rules need to be written by a human and have impact directions (pos, neg or neu) chosen for M, A and O. That creates another point where human effort is required and lots of specific knowledge must be stored. 4. The previous comments are simply some ways in which the implementation of the MAO (roughly equivalent to Susanne's optimisation layer) is done. They are possible changes but the main question which needs to be investigated is the effectiveness of this method. Design Expert Purpose: To provide absolute values for the generation engine to use in building a presentation adapted to the user. Input: Queried by the engine for design system attributes such as color, textsize, speed etc. requestColor(Foreground, Background) Output: Returns an absolute specification for the attribute requested by the system. Eg: RGB colour value Internally: Gets the user's opinion from the user model. This is a list of all rules about colour from the user. Selects the rules which are positive and do not describe a complete scheme or solution (Eg: user likes red) then applies colour rules (Amit's work) to generate suitable matching colours and returns a complete scheme (foreground and background). All positive, complete schemes are then selected and all applicable rules for each scheme retrieved and this is then sent to the MAO expert who chooses the best scheme. This scheme is translated into absolute values which are given to the engine. Some clarification of terms. Value is value(ID, ListOfAbsolutes). For example, value(red, [1,2,3]) where 1,2,3 are RGB values for red. Scheme is scheme(ID, Foreground, Background). For example, scheme(a, red, black) where red and black can be any value or absolute value. Schemes can be complete (previous example) or incomplete, Eg. scheme(c, _, black). So rules for c then apply only to black as a background. Rules can apply specifically to values or schemes or may apply through a sub-relationship. For example, rules which apply to the value red also apply to scheme a and rules which apply to scheme c also apply to scheme a since it too has black as a background. But rules for scheme a don't apply to red since those rules will be for the combination of red and black rather than red alone. Values and schemes simply provide a way to write rules which abstractly describe a potential solution and hide unnecessary information while maintaining some flexibility. The user doesn't need to know about implementation details and the MAO expert doesn't need to know anything at all about what it is comparing. A key point is the representation of values. As long as there is a method for deciding if a rule applies to a given value and a way to turn a value into the absolute format required by the engine then theoretically the MAO expert can handle any type of system attribute from those supplied by the design expert to options from the discourse and content experts. To do: *Amit's work needs to be fitted in which will probably require poking and prodding and lots of discussion. *Real values should be entered rather than made up integers which will mean some related changes. *Real design rules needs to be formulated and entered - discuss with Amit. *All the value information and manipulation is currently contained in a separate file, value.pl. Could be actually moved into the designexpert.pl file rather than just conceptually. General Comments: 1. Currently the whole part that belongs to Amit's work is a small function that returns 42 as the matching colour for anything. :) 2. Hopefully this is fairly standalone. Anything done in the design expert is irrelevant to the User or MAO as long as the information provided to them or required from them doesn't change. See interface.txt in the working directory for an outline of the interface format between the modules. 3. This is possibly the most complex and fragile module. Hopefully by using abstract representations for values/schemes/solutions it should be able to handle changes in system requirements and capabilities and more complex design rules. For example, some rules may apply to font style and colour choices in combination. These combinations can be made explicit in values which then have rules describing how their implementation impacts the user. The rules which have no knowledge of what they describe are then used to make the choice. So the user model and mao expert are unchanged. Internally the design expert needs to know how to figure out which other rules apply to any value, how to 'complete' a solution if the user model supplies rules which apply only to a partial solution and how to turn the chosen value into the absolute format required by the engine. What's bothering me? 1. What happens when the supplied value for the system attribute causes the generation to fail? (Text size might for example) Ideally the engine should backtrack to that point and then ask for a new one - the second best value as determined by the MAOexpert. How is this done? Or more correctly how should the code be structured to let prolog do this? 2. Each time the engine requests a value from the expert, the user model does the whole who-is-the-visitor-&-which-profile-matches-best routine. Is this a 'Good Thing'? Do we want the user profile to potentially change in the middle of a generation or would it be better to somehow store the initially selected profile and then each time a new value is required simply ask the user model expert for the appropriate opinions for this attribute? 3. Does the model work? It relies on a lot of generalisation, layers of it as well as stereotyping. Is the combine, compare, select method a good way to do the ranking? 4. Continuing on from point 3. MAO is fuzzy. The selection is fuzzy, the comparison is fuzzy and the creation of the rules is fuzzy. (Fuzzy: there are no absolute rules or even hard guidelines to select, compare or create) Does all this fuzziness result in something which is good enough? What is 'good enough'? The Next Steps (probably in parallel) 1. Improve the sample profiles and rules. Add some 'real' information and values. 2. Try and fit Amit's work into it. 3. Discuss improving my prolog with someone. 4. Fit it all together and try it out. 5. Start writing.