Jump to content
  • entries
    119
  • comments
    5
  • views
    4000

Développement FileMaker Go, la méthode des «Blocs glissants»

Sign in to follow this  
Le Blog FileMaker

346 views

Par Yann Liqueur Salzédo

Nouvelle pratique pour construire des modèles FileMaker Go pour iPad : La technique des «blocs glissants»
Yann Liqueur-Salzédo – infografix – Nice, le 15 mai 2011 Toute reproduction interdite sans accord de l’auteur.

Je détaille dans cet article une technique originale pour construire des modèles adaptés à FileMaker Go et aux impératifs de la rotation de l’écran.

Les outils utilisés :

FileMaker Pro 11.0v3 FileMaker Go pour iPad 1.1.2
FileMaker Go pour iPhone 1.1.2

Pré-requis : Maîtriser le développement FileMaker et l’inspecteur de dimensionnement automatique des objets

J’ai créé cette méthode – que j’ai baptisé « des blocs glissants » (Slide a Block method en anglais) en préparant la session «FileMaker & FileMaker Go – iOS & interface utilisateur» que j’ai présenté le 19 mai 2011 à la FM Conférence FileMaker à la Rochelle (Conférence Française des développeurs FileMaker)

Pour rappel FileMaker Pro est un logiciel de création de base de données (SGBDR) qui permet de réaliser des solutions Mac OS et Windows. FileMaker Go et l’application iOS qui permet d’utiliser ces solutions sur iPhone, iPod Touch & iPad. Cet article s’adresse aux développeurs FileMaker qui sont amenés à créer ou porter des solutions existantes sur plateforme iOS.

Le travail sur l’interface utilisateur d’une solution FileMaker Go et plus spécifiquement la construction des modèles présente un challenge inhabituel pour tout développeur habitué à travailler sur MacOS et/ou Windows. A cause de la rotation de l’écran on doit prendre en compte, pour la première fois, une surface dont les dimensions peuvent varier durant l’utilisation.

 

La pratique actuelle : le dimensionnement automatique

Depuis la sortie de FileMaker Go il y a un peu plus d’un an, la pratique présentée – entre autres par les différents blogs spécialisés et dans les exemples FileMaker Go – quand on veut qu’un modèle FileMaker Go s’affiche parfaitement sur iOS en portrait et en paysage, consiste – en partant d’une taille commune aux 2 vues – à agrandir automatiquement des objets du modèle à l’aide de la fonction de dimensionnement automatique.

Quand on passe d’une vue à l’autre, on a toujours les mêmes éléments à l’écran mais dans des tailles différentes. Le plus souvent pour agrandir verticalement (passage de paysage à portrait) une rubrique note et/ou une image et/ou une table externe….
Pour agrandir horizontalement (passage de portrait à paysage à portrait) on agrandi une rubrique ou une «colonne» de rubriques pour qu’elle s’ajuste automatiquement au nouvel espace.

Mais cette pratique présente de nombreuses contraintes et limites : Pas d’exploitation de toute la surface de l’écran pour afficher plus d’informations
Difficulté/impossibilité de faire des modèles complexes
Limites du dimensionnement automatique
Rubriques avec des tailles différentes d’une vue à l’autre
Eloigné de l’esthétique iOS
etc…

Malgré ces limites, cette méthode conserve un vrai intérêt dans certains cas. Cependant pour un résultat plus proche du look & feel iOS je préfère ma technique des «blocs glissants» et dans certains cas, les 2 approches peuvent être combinées au sein d’un même modèle…

 

La technique des blocs glissants

Le principe général Les combinaisons préconisées
Utilisation de formats précis
Rappel des formats d’affichage
Rappel des tailles d’intersection possibles
Tailles des différents blocs selon les combinaisons sur iPad
Blocs en arrière plan masqués et inactifs
La question de la barre d’état
Avantages et inconvénients de la technique
Je propose une technique qui consiste à montrer ou masquer certains éléments après la rotation du device iOS. Cette technique permet un développement d’interface utilisateur plus riche et plus proche du look & feel iOS avec par exemple l’apparition d’un menu ou d’une liste qui s’affiche en paysage et qui est masqué en portrait…. Cette technique permet aussi la construction de modèles très complexes impossible à faire avec la méthode précédente

Le principe général

J’ai un bloc affiché en permanence au premier plan qui cache des blocs à l’arrière plan chacun avec des ancrage à l’écran différents. La rotation du device fait glisser (et non pas agrandir) les blocs cachés faisant ainsi apparaitre les objets à l’utilisateur
Avec cette méthode je ne modifie pas la taille des objets dans mon modèle pour qu’ils s’adaptent au changement d’écran, mais j’utilise le déplacement de blocs sur différents plans pour que leur combinaison remplisse la surface d’affichage. J’utilise l’outil de dimensionnement automatique de l’inspecteur FIleMaker, non pas pour agrandir un bloc mais pour l’ancrer à un bord d’écran et le déplacer automatiquement lors de la rotation

 

Les blocs symbolisent ici des groupes d’objets , comme un ensemble de rubriques, des textes, des images, etc

 

 

étape 1 rotation de portrait vers paysage
avant la rotation, j’ai un bloc au premier plan (rouge) qui masque un bloc en arrière plan (bleu) avec les attributs suivants :

 

 

Les 2 blocs sont alignés sur leur droite le long de la bordure droite de l’écran.

 

étape 2 rotation de portrait vers paysage
Lors de la rotation et du passage en paysage, le bloc bleu à l’arrière plan va suivre le bord droit de l’écran et apparaître . Le bloc rouge, ancré à gauche reste fixe.

 

Le principe est le même pour le bloc qui doit glisser verticalement… Seuls les attributs d’ancrage changent…

 

Il existent de nombreuses combinaisons à 2 ou 3 blocs… Je propose ci-dessous 4 combinaisons différentes

Les combinaisons préconisées


Utilisation de formats précis
Pour un résultat optimum, il faut que les différents blocs aient des dimensions bien précises pour remplir parfaitement la surface du device et afficher tous les objets des blocs sans chevauchement.

Les dimensions vont dépendre de la plateforme et des paramètres FileMaker go de la barre d’outils et de la barre d’état.

Dans toutes les combinaisons, le bloc en permanence à l’écran (ici en rouge) a un format égal à l’intersection des vues portrait et paysage pour des paramètres donnés….

On part d’abord des formats portrait et paysage pour calculer ensuite les formats «d’intersection» commun aux 2 vues.

Rappel des formats d’affichage
Formats iPad

 

Formats iPhone en mode borne de communication actif

 

Formats iPhone en mode par défaut

 

Ces résultats donnent les «valeurs d’intersection» suivantes :

Rappel des tailles d’intersection possibles
Formats d’intersection iPad

 

Formats d’intersection iPhone en mode de communication actif

 

Formats d’intersection iPhone en mode par défaut

 

Ce sont ces formats que le bloc principal devra avoir. Dans toutes les combinaisons, la taille du bloc principal étant connu, la taille du/des autres blocs est égal à la différence de celui ci avec la taille maximale d’affichage pour un paramètre donné….

Tailles des différents blocs selon les combinaisons pour iPad


Pour une combinaison à 2 blocs, le premier bloc rouge s’agrandit verticalement automatiquement à partir du même format de départ que dans une construction en 3 blocs….

Pour l’iPhone
J’ai donné pour information plus haut les formats de l’iphone mais que je pense que la taille réduite de l’écran ne se prête pas à cette manipulation. Je préconise pour iPhone un découpage modal en listes et formulaire simple final avec utilisation pour tous les modèles de la méthode de l’agrandissement automatique.

Blocs en arrière plan masqués et inactifs
Il est important que le bloc en arrière plan (et les éléments qui le composent) ne vienne pas interférer par erreur avec les éléments manipulés au premier plan. L’arrière plan doit être à la fois masqué visuellement et indépendant des manipulations de l’utilisateur au premier plan.

Par exemple si dans une vue donnée un bloc est caché en arrière plan et qu’il contient des boutons, ceux-ci ne doivent pas se déclencher accidentellement par une manipulation de l’utilisateur au premier plan (ce qui se passe si le masque qui cache le bloc est un simple rectangle).

La meilleure solution est de cacher ce bloc derrière un panneau à onglet situé au premier plan au même niveau que le bloc principal… Cela rend inactif les boutons en arrière plan et présente l’avantage supplémentaire de pouvoir manipuler facilement les éléments de premier plan et de les déplacer en manipulant simplement le panneau à onglets pour accéder aux blocs inférieurs au cours du développement…

La question de la barre d’état


La barre d’état peut être affichée ou masquée par l’utilisateur, selon un réglage dans les paramètres FileMaker Go. Cet élément fait 20 points de haut sur toute la largeur affichée en portrait et en paysage. On ne peut pas gérer ce paramètre par un script FileMaker.

Avec cette technique «des blocs glissants» le fait que l’utilisateur ait des paramètres différents que ceux prévus dans le modèle peut avoir des conséquences variées selon la combinaison choisie, les formats de départ, et l’apparence visuelle du modèle.

1er cas : Le modèle est au format Barre d’état masquée alors que l’utilisateur l’a activé
toutes les combinaisons à 3 blocs vont voir une partie des blocs vert et bleu masquée sur une hauteur de 20pts selon les vues
toutes les combinaisons à 2 blocs connaitront le même problème uniquement en vue paysage
S’ajoutera à cela un glissement de tout le modèle à l’écran selon les manipulations…

2ème cas : Le modèle est au format Barre d’état activé alors que l’utilisateur l’a masqué
Pour les combinaisons à 3 blocs, en vue paysage, une partie du bloc vert d’arrière plan n’est plus complètement masquée

Il y a plusieurs façon de contourner ces problèmes :

La plus contraignante et de construire les modèles en 2 formats pour qu’ils s’affichent parfaitement pour chacun des paramètres de la barre d’état. Le choix de l’affichage du bon modèle se fait grâce à un test «Obtenir (HauteurContenuFenêtre)» par exemple…

Une solution plus simple est de construire les modèles au format le plus petit – barre d’état activée – et de dessiner les blocs pour que le non recouvrement d’une partie de ceux-ci ne soit pas un problème sur le device qui aurait la barre d’état masquée… Par exemple ne pas mettre d’objets sur la bande inférieure (20 pts) du bloc vert
On peut aussi faire une rubrique multimédia calculée qui masque cette bande inférieure dans certains formats d’écrans donnés….

Avantages et inconvénients de la technique
Cette technique présente de nombreux avantages et peu d’inconvénients :

Techniques :

Le développeur a la liberté de créer des modèles en positionant tous ses objets comme il le souhaite et non plus avec la contrainte du dimensionnement automatique.

On peut construire des modèles très complexes identiques dans les 2 vues.

On a plus d’espace utile pour poser nos éléments, puisqu’on a toute la surface de l’écran (combinaison 3 blocs) alors qu’avec la technique du dimensionnement automatique tous nos éléments doivent tenir dans l’équivalent de notre bloc principal…

La rotation devient un nouveau geste de pilotage pour l’utilisateur… le développeur peut donc s’en servir comme élément d’interface

Esthétiques :

On peut enfin réaliser des solutions au look & feel iOS, à l’image de ce que l’on trouve sur l’app store

A l’usages :

On peut trouver de nombreuses utilisation intéressantes de cette construction :

Des outils de navigation qui se masque ou s’affiche… Les blocs glissants peuvent servir à faire apparaitre des listes ou des TE…
Des graphiques,
Des champs éditables si le bloc principal affiche des rubriques bloquées à l’édition

Le seul inconvénient que je trouve est que le modèle n’est plus wysiwyg…
la manipulation des blocs en arrière plan peut être fastidieuse si il y a beaucoup de modifications…

Annexes
fichier FMConf.fp7

La FM Conférence est organisée par La Source multimédia avec la collaboration de FileMaker France, depuis maintenant 7 ans.

La Source multimédia est éditrice de nombreux sites de support comme le forum FileMaker (www.fmsource.com), le blog FileMaker (www.leblogfm.fr), ainsi que le portail FileMaker anglophone (www.fmpro.org), et organise chaque année la FM Conférence (www.fmconf.com).

FileMaker, Inc. développe des logiciels de base de données maintes fois primés. Parmi ses produits, se trouve la légendaire gamme FileMaker Pro pour Windows, Mac et les applications Web, de même que Bento, la base de données personnelle pour Mac, iPhone et iPod touch. Des millions de personnes à travers le monde, aussi bien à titre personnel que pour le compte de grandes sociétés, font confiance aux logiciels de la société FileMaker, Inc pour gérer, analyser et partager leurs informations. FileMaker, Inc. est une filiale d’Apple Inc. (AAPL).
www.FileMaker.fr

Yann Liqueur-Salzédo infografix – Nice
FileMaker Business Alliance

Consultant & Développeur FileMaker (solution de gestion / développement spécifique)

Conférencier à la FM Conférence – Conférence Française des développeurs FileMaker – Sujets présentés :

Avril 2005 Honfleur : FileMaker 7 : Architecture et fondamentaux Mars 2006 Poitiers : Base et optimisation des interfaces utilisateurs
Mars 2007 Lyon : FileMaker & mobilité
Mars 2008 Nice : Interface Utilisateur – vers un «Look&Feel» pro
Mai 2011 La Rochelle : FileMaker & FileMaker Go – iOS & interface utilisateur

Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...