Sujet de projet collectif niveau M1 ou sujet de stage M2
Encadrants : Philippe.MARTIN (AT univ-reunion.fr), 0262 48 3330, Jérémy BÉNARD
BUT : voir titre + permettre une navigation plus intuitive et efficace que dans les pages
Web actuelles.
Si possible, imiter les menus déroulants de Mozilla.
1) Faire une ontologie (correcte, semi-complete, en anglais) des paramètres de
présentation
pour pourvoir présenter tous les menus "possibles". Communication par Google site.
2) Montrer à Ph. Martin à quoi ces menus (en anglais) ressemblent
(-> use a free Web hosting site where Javascript works), et donc
implémenter dans un navigateur avec une bibliothèque de menus en Javascript
(e.g., Google API).
3) Ecrire un rapport dans les règles
(cf. ce guide)
ce qui inclut un état de l'art (e.g., citez "Fresnel" de Pietriga),
et
une structure d'argumentation formelle et informelle.
IMPLÉMENTATION : en HTML + CSS + Javascript, avec pour format HTML et/ou JSON
RESSOURCES :
* discussions
- article "Organizing Linked Data Quality Related Methods" pour l'explication de
description_content_quality, description_medium_quality, ... dans le "brouillon de template"
- exemple de notation formelle pour représenter/sauvegarder un menu
- exemple - au sujet d'une école -
d'arbre de décision pour aider la recherche d'informations
(dans ce sujet de projet M2, les menus doivent aussi être des arbres de
décision, i.e., offrir des choix exclusifs ou, du moins, permettant de savoir
dans quelle branche rechercher une information, mais non seulement il n'y a pas de
domaine (-> "interface générique") mais il ne s'agit pas que de recherche
d'informations : des types de commande/requêtes doivent pouvoir être
retrouvées et partiellement construites par navigation ; en complément
à la navigation, pour aller plus vite, l'utilisateur doit aussi pouvoir rentrer
du texte et, si ce texte est formel, ceci doit pouvoir lui permettre de se placer
dans une partie d'un menu, comme s'il avait fait la navigation au lieu d'entrer le
texte - ce dernier point peut être ignoré au début du projet car ce
point est facile à spécifier plus tard et ne change rien au reste).
* Amaya
* Exemple de page Web dont quelques
sous-éléments sont des fenêtres.
Chaque élément de document doit pouvoir être converti (via un menu) en fenêtre, frame, iframe ou élement classique, i.e., non-fenêtré/framé.
* ressources Javascript (2 modèles, un tutoriel, cours W3schools sur DHTML)
* ressources HTML+CSS
* liste de bonnes pratiques (pour la
programmation et celles du W3C pour la mobilité, l'universalité et
l'accessibilité)
* la page centrale de WebKB (exemples de menus pour changer des
paramètres de présentation, et exemples de représentation de connaissances
sous forme de liste indentées)
* bibliothèques javascript de génération de menus déroulants
(vieux exemples de test ; d'autres bibliothèques peuvent être utilisées ; une exploration et
compréhension rapide de différentes bibliothèques est une
1ère étape à effectuer)
* éditeur HTML en Javascript
* le texte ci-dessous.
Principes de conception d'interface avec l'utilisateur:
structure, cohérence, simplicité, visibilité, rétroaction,
tolérance, réutilisation ... Il y a
d'autres principes de conception d'affichage.
Le W3C se concentre sur les critères de
mobilité,
d'universalité (internationalisation) et
d'accessibilité.
Un résumé général est le suivant:
prendre en compte les possibilités, limites et problèmes
1) des différents éléments techniques (réseau, langages,
navigateurs, ...) et
2) des utilisateurs (vue, mémoire, compréhension, langues, ...).
Une conception centrée utilisateur
des interfaces, i.e. leur co-conception par l'utilisateur final, est une
bonne idée.
La théorie de l'activité
peut aussi aider la conception d'une interface homme-machine.
Plus important encore, des techniques de
personnalisation doivent être
utilisées pour
1) proposer différents modèles basés sur des groupes/profils,
2) proposer des recommandations basées sur les comportements passés
de l'utilisateur ou basées sur des préférences d'autres
gens (filtrage collaboratif), et
3) permettre aux utilisateurs d'adapter l'interface directement.
Règle: plus les éléments de l'IHM (i.e., de la présentation) et du contenu
sont séparés, plus ils sont fins, adressables et
précisément représentés (organisés),
plus il est possible de permettre leur personnalisation par chaque utilisateur.
Pour réellement supporter la coopération, un logiciel doit fournir une
liste organisée de paramètres de présentation et un
langage adapté pour la présentation.
La caractéristique la plus importante d'une IHM est que tous les objets liés à un objet particulier soient facilement accessibles à partir de lui.
Donc, idéalement, chaque objet "intéressant" doit pouvoir être
sélectionné et sa sélection par un utilisateur conduire à un
menu contextuel
(e.g., via un menu pop-up) permettant à l'utilisateur
d'explorer, de sélectionner et d'ajouter/modifier tous ses objets reliés, e.g., ses propriétés de présentation, des objets informationnels et les actions qui peuvent être faites sur cet objet ou via cet objet
(pour les objets reliés qui n'ont pas trait à la présentation,
les modifications doivent être sans perte).
Dans des éditeurs de documents structurés bien
conçus, cela est possible mais l'ensemble des objets reliés est
limité à ceux identifiés par les schémas de structure,
de présentation et d'interaction/événement associés au
document en cours d'édition.
Pour un meilleur partage/recherche des connaissances et une meilleure
coopération, les objets doivent être représentés dans une
base de connaissances (BC), et donc, le menu contextuel associé à
un objet sélectionné devrait permettre l'exploration de la BC à
partir du point d'entrée constitué par cet objet.
"Brouillon de template" initial pour les items de haut-niveau d'un "menu contextuel"
(dans un pop-up ou répartis en divers endroits : frame, fenêtre, menu de haut de page, ...)
sur un élément de document ("ED" ou "DE") sélectionné par l'utilisateur (DEmeta0)
ou sur chacun des DEs d'un menu (passage au niveau supérieur : "menu pour DEmeta1", "menu pour DEmeta2", ...) :
each DE/menu has the following navigable/collapsed/... parts:
- content assert(edit) / search(set * at top)
lexical/structural internal=part rels (part, ...?)
(espace de noms, entêtes, modèles+notation de description, validation, ...)
description-content_quality (correctness, conformity, ...)
description-medium_ quality (formats standard/concision/uniformity/structure, ...)
note: linguistic rels are both lexical/structural internal and presentation
lexical/structural external=other rels (=, part-of, ...)
lex./struct. transf./copy): open/insert copy/paste buffers save/print/compile
Identification (URIs)
Interaction (coté client, coté serveur, transmission client/serveur)
description-container_quality(storage, assertion, info._retrieval, personalization)
semantics (external=all) rels (descr of) of right-clicked
and of its rel. with its parent/children DEs ? (yes, via URIs)
description-content_quality (correctness, conformity, ...)
description-medium_ quality (formats standard/concision/uniformity/structure, ...)
- presentation constraints for each/current user: visual/spatial linguistic/cultural hardware
- temporal/navigational+user+event constraint //about right-clicked DE(or action pointed by DE),
e.g., current/previous/next/undo
Exemple de DE: kughefmefoif manger mkudmkdf //hypothese: on ne sait pas la langue
____________________________________________________________
"manger" //selected string/DE
(content_relation
> (external_structural_relation
> (directly_embedding_DE: "kughefmefoif manger mkudmkdf")
)_[content_relation: ...,
presentation_relation: ...,
...: ... _[...]
]
(internal_structural_relation
> (string_part: { "m", "a", "n" } )
)_[...]
(lexical_relation: (fr#"manger"
writing: fr#"MANGER", //warning; just for the example
phonetic: ipa#"m-~a-n-j-e'",
.> wn#eating wn#ingest
)
(cn#"manger" .> wn#sitting )
)
(semantic_relation
> (meaning: wn#eating wn#ingest
(wn#sitting //process
relation_from_process_to_spatial_entity : 0..* spatial_entity,
relation_from_process_to_temporal_entity : 1..* temporal_entity,
relation_from_process_to_event : 1..* event,
relation_from_process_to_state : 1..*_state,
relation_from_process_to_process_attribute: 0..* process_attribute,
relation_to_process_participant : 1..* participant,
relation_to_another_process : 0..* process,
relation_to_description : 0..* description
)
)
)
): a thing,
(presentation_relation
> change_the_presentation_of_this_menu_item
change_the_presentation_of_any_item_in_this_menu
): a thing,
(...
): a thing;
"_____________________"
part of: the doc pm#ljhvcd,
meaning: ...;
Exemple of ontology from which this menu should be generated:
Only the types exploited by the above menus are shown here but the ontology has many more types,
e.g., those of a presentation ontology.
thing
> excl
{ (situation (^something that "occurs" in a real/imaginary region of time and space^)
> excl //the next types are 'exclusive'
{ (process (^$(to be put in bold in generic menu)$
situation commonly considered as making a change during some period of time^)
> event (^process considered instantaneous from some viewpoint^)
excl{ (process_that_does_not_modify_its_main_object
> excl{ (description > typing identification)
presentation mental_decomposition perception },
unmodified_object: 0..* thing
)
(process_that_modifies_its_main_object
> excl{ creation destruction modification },
created/modified_object: 0..* thing
)
},
participating_agent: 0..* thing,
modified_agent: 0..* thing
)
state (^$(to be put in bold in generic menu)$ situation that is not a process^)
}
)
(entity (^something that can be "involved" in a situation^)
> excl
{ spatial_entity (^$(to be put in bold in generic menu)$ ^)
temporal_entity (^$(to be put in bold in generic menu)$ ^)
(characteristic_or_attribute_or_measure (^$(to be put in bold in generic menu)$ ^)
> (formatting_characteristic-or-attribute-or-measure
_(thing -> 0..* pm#formatting_characteristic-or-attribute-or-measure)
> excl
{ structure-related_formatting_characteristic-or-attribute-or-measure //XML,XSLT,...
//content (list/table/tree/...) + selection handle + associated menu
event_related_formatting_characteristic-or-attribute-or-measure //E, Javascript
(presentation_related_formatting_characteristic-or-attribute-or-measure //CSS,forms
> excl //position, margin, visibility, color, font, ...
{ (visual-presentation_characteristic-or-attribute-or-measure
> document-element_related_visual-presentation_characteristic-or-attribute-or-measure
window_related_visual-presentation_characteristic-or-attribute-or-measure //frame, pop-up
)
aural-presentation_characteristic-or-attribute-or-measure
} )
}
)
)
description_content/instrument/support (^$(to be put in bold in generic menu)$ ^)
}
)
};
Exemple of generated distinctions for a menu:
systematic_categorisation
relation_with_thing
link_from/to_thing
excl{ link_from/to_situation
link_from/to_creation of_this_link
link_from/to_entity
link_from/to_creator of_this_link
} link_from/to_thing_playing_a_role
excl{ link_from/to_past_thing
link_from/to_creation of_this_link link_from/to_creator of_this_link
link_from/to_present_thing
link_from/to_future_thing
}
excl{ link_to_type
link_to_part
link_to_measure
excl{ link_to_localisation //spatial/temporal
link_to_speed
link_to_acceleration
}
excl{ link_to_situation_measure link_to_entity_measure }
}