Club robotique de Sophia-Antipolis

Accueil > POBOTpedia > Programmation > Snippets > Conception d’une interface utilisateur graphique

Conception d’une interface utilisateur graphique

lundi 2 novembre 2009, par Julien H.

Lorsqu’on veut piloter un tel robot, une interface graphique est bien plus pratique qu’une interface en ligne de commande. Mais encore faut-il bien la concevoir.

Et pour ça, au lieu de foncer tête baissée dans le code, on s’interroge sur les besoins (ou "cahier des charges"). Ainsi on ne va pas penser à tout ce qu’on pourrait faire de joli et de clignotant, mais à ce que l’utilisateur (qui peut bien sûr être vous-même) a besoin.

Cahier des charges

Si on reprend le bipède de Easyrobotics, voici les 2 exigences formulées par Nicolas :
 un déplacement autonome : le robot avance en évitant les obstacles
 un déplacement contrôlé : on peut piloter le robot à distance en le faisant avancer, reculer, aller à droite ou à gauche.

Comme je suis aussi un futur utilisateur, je rajoute une exigence :
 un déplacement manuel de chaque mouvement

Interprétation

Il ne faut pas coller aveuglément aux mots qui formulent ces exigences, mais savoir les comprendre, et cela passe par une interprétation, qui donnera lieu à des questions précises qui éviteront toute mauvaise surprise.

Analyse

Ensuite on en déduit le fonctionnement de l’interface, en faisant des listes de spécifications :
 services réalisés par l’interface
 actions utilisateurs possibles
 informations concernées

Services de l’interface

L’interface doit principalement envoyer des commandes au robot. Il faut donc savoir gérer quelles commandes (la source : utilisateur en manuel ou stockage en automatique) et la fréquence (sur déclenchement utilisateur ou de manière régulière, voire paramétrable).

L’interface doit offrir plusieurs modes : il faut pouvoir passer de l’un à l’autre, mais que les commandes restent cohérentes. Ce sera un critère de qualité important qui entrainera des contraintes pour l’utilisateur, il faut donc les prévoir le plus tôt possible.

L’interface doit montrer l’état courant du robot.

Actions utilisateurs

L’utilisateur peut contrôler la position du robot. Il peut intervenir étape par étape dans une séquence de base (avancer/reculer/tourner à gauche/tourner à droite) et visualiser ou changer une position, et sauvegarder sa modification pour les prochaines exécutions.

L’utilisateur ne gère pas le passage en mode automatique, c’est le robot qui détecte une inactivité de 60 secondes et décide de passer en mode automatique. Dans ce cas il est indépendant de l’interface utilisateur (rupture de connexion).

Information utilisée

Cette partie se déduit des précédentes. Il suffit de parcourir les spécifications et de noter toute information entrant en jeu. Attention, cette étape ne considère pas l’implémentation : on peut parler de liste mais on préférera le terme "position courante" à "index courant".

Mais cette partie doit être complétée avec les types de données et les bornes (min/max) des valeurs prises.

Dans notre cas, on détecte :
 la commande envoyée au robot : 4 chiffres de 0 à 9, 1 par moteur, 0 = pas de modification de la consigne précédente
 la position (similaire à la commande, on va les confondre)
 la séquence, composée d’un nombre variable de commandes, commençant toujours par la même (pour la continuité)
 les séquences : il y en a 4, pour avancer/reculer/tourner à gauche/tourner à droite
 une séquence en cours
 une commande en cours
 le mode courant

Résultat

Résultat

Un message, un commentaire ?

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.