Discussion :

[Maludi]

Bonjour,

Est-ce qu'il est possible de faire un controle onglet dans un onglet ?
Tout ce que ça me fait, c'est un nouveau controle au dessus du premier et non pas intégré à un des onglets...

Suis-je assez claire ?

Merci

Ludivine

[FRED.G]

Impossible.

Salut à la Réunion !!

[Maludi]

Ok, merci !!!

Et bonjour aussi

[say]

Bonjour....
y'a-t-il une alternative?

Maludi, comment as tu procéder au final?

je me suis débrouillé mais c pas pratique en mode créa

[FRED.G]

Je vais peut-être me faire incendier mais déjà les onglets eux-mêmes, c'est rare d'en utiliser, alors des onglets imbriqués... Ca doit pas ressembler à une IHM très conventionnelle ton truc.
Pourtant c'est bien de respecter les standards. Ca fait plus pro, c'est plus intuitif et ouvert.

Ils ne savaient pas que c'était impossible alors ils l'ont fait

Par contre ça ne s'applique pas aux onglets imbriqués, cette citation...

[say]

conventionnel, conventionnel...est ce que j'ai une tête de conventionnel

plus sérieusement, l'idée des onglets imbriqués est d'avoir un maximum d'info avec un minimum de form, et un moindre cout par clic.
perso, je bosse sous Access mais également sous C++ Builder, les onglets c'est mortel et mes users adorent.


par ailleurs, je l'ai fait

en fait, je pose des onglets supp, donc imbriqués mais que je rend visible que pour l'onglet principal concerné, c'est nickel à "l'exécution", juste pas super pratique en mode création.

de plus, c'est quoi pour toi, une IHM conventionnelle?

et les conventions, ne serait-ce pas fait pour évoluer?

[gscorpio]

et bam

[Tokay]

[...] mais déjà les onglets eux-mêmes, c'est rare d'en utiliser [...] Pourtant c'est bien de respecter les standards. Ca fait plus pro [...]

n'étant pas un pro (pas encore ), je me demande comment tu fais pour avoir sur un formulaire (tenant sur un écran, donc sans utiliser les ascenseurs) de multiples infos différentes ??

par exemple : un article, un client, une marchandise, ... n'ont rien à voir ensemble, mais appartiennent poutant tous à un même dossier et ont chacun des infos importantes à montrer, sans faire des formulaires pour chaque données.

Comment fais un pro comme toi pour construire une base, sans utiliser les onglets ??

Je croyais, apparement à tort que comme dit say :

[...] les onglets c'est mortel [...]

aspirant au grade de pro, ta facon de faire m'en apprendrais certainement beaucoup. Donc merci, pour tes futurs explications détaillées.

[FRED.G]

On ne va pas lancer le débat ici (y aurait d'autres threads plus propices) MAIS :

de plus, c'est quoi pour toi, une IHM conventionnelle?

Une IHM ou les onglets utilisés avec parcimonie et ne sont pas imbriqués
Idem pour les sous formulaires, NA ! (NA! = argument d'autorité, imparable )

et les conventions, ne serait-ce pas fait pour évoluer?

Une convention, c'est fait pour s'accorder sur quelque chose de stable et pratique pour le plus grand nombre.

Donc pour des besoins spécifiques, on peut sortir des sentiers battus, ou réellement lorsque le modèle standard doit évoluer car les besoins ou habitudes du plus grand nombre ont changés.

Mais il ne faut pas se leurer : il est bien rare (et je pèse mes maux ) d'être si exeptionnel que les standards ne puissent nous contenir, ou carrément, que l'on soit capables de révolutionner (ou même un peu modifier) les standards...

En général, quand on fait un peu à sa façon, c'est parce qu'on a mal compris les standards, qu'on ne sait pas s'en servir pour résoudre ses propres problèmes d'organisation et d'ergonomie.
Je parle par expérience.

[FRED.G]

n'étant pas un pro (pas encore ), je me demande comment tu fais pour avoir sur un formulaire (tenant sur un écran, donc sans utiliser les ascenseurs) de multiples infos différentes ??

Et voilà, le coup classique !
CommentToutFaireTenirDansMonFormulaireQueMêmeIlEstMaximizéEtQueSiLecranDeLutilisateurIlEstPlusPetitBenFaudraEnAcheterUnAutre...

Quant tu met une tonne d'infos sur ton form, c'est forcément confu ou dense. Donc moins intuitif.
D'ailleurs les onglets permettent d'éviter de tout afficher.

Comment fais un pro comme toi pour construire une base, sans utiliser les onglets ??

Jévite les onglets et les ascenceur en me servant des barres d'outils et des formulaires.
tu cliques sur un bouton de la barre (ou dans l'équivalent menu, car y a toujours un équivalent ) et ça t'affiche ton form. Ton form tu peux le positionner par le code et l'utilisateur le déplacer, le fermer l'ouvrir à sa guise.
Il n'aura l'info qu'au moment voulu. C'est quand même mieux.
Et pour le taux de clic : c'est un clic. Au pire un redéplacement du form (donc 2 clic) mais si le tout est bien pensé, le form doit se placer intelligement.

Comment fais un pro comme toi

Qui a dit que j'étais un pro ?

Bon je m'arrête là pour les avantages de faire simple et propre (mais il y en a plein!). La suite dans un prochain épisode...

[Maludi]

Je réagit au sujet de l'utilisation des onglets...

Problème récurrent chez moi , j'avais posé la question au sujet de l'usage des onglets
--> http://www.developpez.net/forums/vie...141&highlight=

Dans le post ci-dessus, il est surtout question de les utiliser à bon escient, mais de les utiliser quand même, pas de les éviter...

Je vais peut-être me faire incendier mais déjà les onglets eux-mêmes, c'est rare d'en utiliser,

Alors je comprend pas trop, pourquoi cette fois ci, on dit le contraire... Quels sont les conventions dans ce cas ?
Pourquoi ne pas en utiliser ? Quel est le problème des onglets ?

[say]

hum...ok, on va pas débattre là.
mais une barre d'outils et des onglets, ça se ressemble un chouille sur le concept (notamment le cout par clic)

ma 'tite exp:
la dernière appli que j'ai livré (en C++ Builder) et celle que je m'apprêtes à livrer (Access) [suis sur tous les fronts 8) ], sont à base d'onglets.

les user sont ravis...[ça fait plaisir!!]

de plus, je m'étais inspiré (jai plagié????rrooooohhh), l'ergonomie d'une appli qui a dix ans que j'ai vu lors d'une présentation.

voilou....

mon mot de la fin....les standards, les users s'en f...., il faut surtout que ça colle à leurs besoins, leurs façons de travailler même si on doit bidouiller ou malmener les standards.

bonne continuation

[FRED.G]

Bon, la conclusion de say me va bien. Je suis peut-être un puriste ou un rigoriste, mais pas un intégriste.
Et surtout j'ai une vie en dehors de dvp, alors biz à tous.
A la prochaine.

[Maludi]

Il n'était pas question de débattre mais de comprendre ... Moi, je suis pas une pro en access ou quoique ce soit, je cherche juste à m'informer et à comprendre...
En ce qui concerne ma base, j'ai beau me triturer le cerveau dans tous les sens, pour l'instant ce sont les onglets (pas imbriqués) qui me semblent les plus appropriés, pour un endroit...

Voilà... rien de bien méchant

[say]

un dernier détail..pour répondre à la question de départ

(je vais faire hurler FRED.G )

j'ai expliqué comment je procédais, que cela marche très bien, mais pas pratique en créa.

j'ai simplifié. j'ai fait un sous-form, dans lequel j'ai placé mes fameux onglets (qui semblent donc imbriqués), c nickel, pratique dans tous les cas, mois de code VBA à gérer. suis très content.

mais je reconnais onglets + sous-form....

[Tokay]

désolé de remettre une couche, mais il y a des éléments que j'ai pas compris. Je vais me faire mais tant pis
Je veux bien écrire dans un post plus approprié, mais j'ai pas vu de discussion qui correspond à cela.

Et voilà, le coup classique !
CommentToutFaireTenirDansMonFormulaireQueMêmeIlEstMaximizéEtQueSiLecranDeLutilisateurIlEstPlusPetitBenFaudraEnAcheterUnAutre...

en plein dans le mille, tu m'as eu, ou presque...

Quant tu met une tonne d'infos sur ton form, c'est forcément confu ou dense. Donc moins intuitif.
D'ailleurs les onglets permettent d'éviter de tout afficher.

les onglets ne sont donc pas intuitif ?? Pour moi ils permettent justement d'afficher "une tonne" d'infos, que l'on retrouve facilement.


mes remarques (ci-dessus et à venir) sont celles de quelqu'un qui a moins de dix bases à son actif, donc qui manque de recule. Aussi pardonné moi, je ne cherche qu'à faire mieux pour le futur. D'où l'importance de vos précisions. merci

je coince déjà ici :

Jévite les onglets et les ascenceur en me servant des barres d'outils et des formulaires. tu cliques sur un bouton de la barre (ou dans l'équivalent menu, car y a toujours un équivalent ) et ça t'affiche ton form.

je comprends pas bien ce que tu veux dire. Tu réalises des barres d'outils "personnalisé" pour chacun de tes applications avec des boutons qui renvoient aux différents formulaire, état, ... :

Il n'aura l'info qu'au moment voulu.

c'est à dire après un click sur un bouton de ta barre d'outils :

Bon je m'arrête là pour les avantages de faire simple et propre (mais il y en a plein!)

tout à fait d'accord, mais donc avec ton expérience tu dirais que les onglets ne permettent pas de faire simple et encore moins de faire propre :

la dernière appli que j'ai livré (en C++ Builder) et celle que je m'apprêtes à livrer (Access) [suis sur tous les fronts ], sont à base d'onglets.

les user sont ravis...[ça fait plaisir!!]

toutes mes félicitations, d'après ton expérience et si je comprends bien, tu mets sur un formulaire un control d'onglet avec plusieurs pages qui contiennent les diverses infos. Sans utiliser les ascenceurs, donc tout tient sur "un écran" (pardonné moi l'expression) :
Cela plaît et ne semble pas indisposer les utilisateurs. :

Je suis peut-être un puriste ou un rigoriste, mais pas un intégriste.

tu as tes méthodes et tes expériences, je ne juge personnes ce que je cherche à savoir c'est d'une "manière générale" ce que les différentes personnes (développeurs) ont eu comme remarques, comme suggestions de la part de leurs clients, utilisateurs.

Et surtout j'ai une vie en dehors de dvp, alors biz à tous.

tien comme moi

Il n'était pas question de débattre mais de comprendre ... Moi, je suis pas une pro en access ou quoique ce soit, je cherche juste à m'informer et à comprendre...

pas mieux, tout pareil

En ce qui concerne ma base, j'ai beau me triturer le cerveau dans tous les sens, pour l'instant ce sont les onglets (pas imbriqués) qui me semblent les plus appropriés

encore tout pareil

bon voilà j'ai mis mon grain de sel, je vous remercie d'avance pour vos réponses précises.

Bonne journée

[FRED.G]

Les onglets, c'est laid...

[FRED.G]

Je ne souhaite pas passer tout mon temps à débattre de l'intérêt des onglets mais vu que la demande est forte, je vais faire un effort.

Je ne vais pas vous faire une synthèse là comme ça, cela me prendrait trop de temps. Je vais donc essayer répondre sur le vif aux questions qui ont été posées.
La synthèse, on verra plus tard.

Avant de commencer, je voudrais préciser que mes propos n'engagent que moi : c'est mon expérience, rien de plus.
Si je me permet de parler et donner mon point de vue, c'est parce que j'ai passé (et passe encore) des heures et des heures à réfléchir sur les questions d'ergonomie des IHM, à me dépatouiller entre le subjectif et l'objectif.
Or peu à peu les choses viennent, et je remarque que j'ai commencé comme la plupart ici par faire certaines "erreurs" classiques. Quant on est spontané et sans expérience, on a tous plus ou moins les mêmes réflexes...

D'un côté, il y a la critique des erreurs, donc, de l'autre les solutions proposées. J'imagine qu'il est plus facile de faire l'unanimité dans un exposé critique qu'en donnant des leçons. Mais dans le fond, tout est lié dans mon esprit tordu. Donc je vous livre mes impressions en vrac et sans garanties...

en fait, je pose des onglets supp, donc imbriqués mais que je rend visible que pour l'onglet principal concerné, c'est nickel à "l'exécution", juste pas super pratique en mode création.

En tant que développeur, devoir faire ce genre d'accrobatie est insupportable. Je l'ai fait moi aussi. J'ai minimisé comme j'ai pu les désagréments en nommant astucieusement les onglets et leurs pages afin de les sélectionner plus facilement dans la zone de liste des contrôles dans la barre d'outils du mode création.
Côté utilisateur, s'ils sont contents, c'est l'essentiel. Surtout que techniquement il n'y a pas de souci à l'exécution si la machinerie est conçue sans étourderies.
Mais je reviens à l'aspect développement et à l'éternel conflit entre principes et pratique.
Dans la pratique imbriquer des onglets aura permi à notre ami de solutionner le problème de l'organisation de ses données. Tant mieux. Et il oubliera vite le temps passé au developpement lorsqu'il n'aura plus que la satisfaction de son client en face de lui. (Et le chèque qui va avec !)
Mais si d'aventure, il faut modifier, ajouter quelque chose... Comment on s'y prend ?
Ben soit on rajoute les infos dans la page existante d'un onglet. Soit on crée une page supplémentaire. Soit un niveau d'imbrication supplémentaire... :neutral:
Mais très vite on se heurtera à un manque de place ici ou là. L'ajout viendra chambouler le bien souvent trop fragile équilibre esthétique de l'appli.
Equilibre esthétique ?
Oui, les plus perfectionnistes sauront de quoi je parle. Et la nature a horreur du vide. Surtout si à côté on a un espace dense et toufu...
Or les onglets provoquent ce genre de difficultés.
D'une manière générale dans son appli, on passe beaucoup de temps à "équilibrer", harmoniser la disposition des contrôles. a fortiori si l'on a pas de "style" défini et qu'on y va selon l'humeur et le goût du moment...
Il est très facile de faire un joli formulaire. Surtout quand il y a peu de matière à mettre en place. Mais il est beaucoup plus difficile de faire quelque chose de joli et qui tienne la route partout dans l'espace de l'application et tout au long de sa durée de vie.
C'est la différence entre un truc bien à condition de ne plus toucher, et un truc bien que l'on peut modeler, adapter à souhait, quasiement à l'infini...
Les principes et les standards servent à ça. Faire des trucs durables et accessibles au plus grand nombre dans sa diversité.
C'est là qu'il y a "conflit" entre principes et pratique : on peut faire un truc pratique sans se soucier de respecter des règles ou des conventions. C'est parfois plus rapide. C'est souvent moins durable...

de plus, c'est quoi pour toi, une IHM conventionnelle?

Une IHM dans laquelle on n'utilise pas de formulaires de saisie immenses avec tout-dedans-à-condition-de-chercher (ou de n'utiliser que certaines parties et les autres quasiement jamais ... et pourtant elles prennent quand même leur place...) et avec rien quand on regarde d'un peu trop loin (et là tanpis pour la "première accroche" ou "approche" de l'utilisateur...).
Enfin bon, il y a "formulaire de saisie" et "formulaire de saisie"...
Je veux dire qu'il y a bien des exceptions. Mais à en croire certains, nous sommes tous des exceptions, ceci est la seule règle et viva che guevara !!!
Donc pour en revenir à "mon idée du standard" : on privilégiera plutôt des petits formulaires "indépendants", pas au sens "non lié" mais au sens de "accessibles facilement et souples comme tout à utiliser". Facile aussi à développer/maintenir...
Enfin il y a aussi le recours aux barres d'outils. Qui se sert de barres d'outils ? Non, je veux dire qui en développe ? Parce que dans Access, tout le monde se sert des barres d'outils et chacun en est très content. Mais dans leur "propres" applis, la plupart colleront un onglet ou un bouton dans le formulaire lui-même. Je n'ai rien contre (et c'est vrai que mon standard est un standard "windows" ). Mais c'est plus simple de respecter le même style en se servant des barres d'outils qu'en utilisant des boutons à sa sauce qui seront bien dans tel contexte et moins bien dans tels autres. Débutants, on a souvent tendance à réinventer la roue... en moins bien !
Les barres d'outils, au moins, tout le monde connait. Et niveau efficacité, ça a fait ses preuves.
Je m'arrête là parce que sinon...

et les conventions, ne serait-ce pas fait pour évoluer?

Posée comme ça la question n'appelle pas une réponse concrète et surtout ne vaut pas comme argument. Mais de toute façon j'y ai déjà "répondu" plus haut.

je me demande comment tu fais pour avoir sur un formulaire (tenant sur un écran, donc sans utiliser les ascenseurs) de multiples infos différentes ??

Je le répète, c'est une erreur de vouloir tout afficher en même temps. il ne faut pas confondre cela avec l'accessibilité de l'infos.
D'ailleurs le recours aux onglet va dans mon sens...
A vouloir tout afficher en même temps, on croit gagner, mais on perd en souplesse au niveau maintenance et au niveau utilisation.

Prenons un cas concret :

par exemple : un article, un client, une marchandise, ... n'ont rien à voir ensemble, mais appartiennent poutant tous à un même dossier et ont chacun des infos importantes à montrer, sans faire des formulaires pour chaque données.

Pourquoi ne pas faire plusieurs formulaires ? Les formulaires ne sont pas nécessairement des gros paquebots (titanic? ) mobilisant tout le traffic et l'énergie de l'appli...
Des petits formulaires légers, ça existe aussi ! Ces formulaires ont, en plus, l'avantage d'être absents quand on en veut pas, faciles à appeler et à positionner...
En jouant avec la propriété visible des sections, on peut offrir différentes versions du form pour traiter une même donnée (généralement un enregistrement d'une table). Et je ne parle même pas de la possibilité (offerte par la méthode Move) "d'éclater" ces mêmes sections en plusieurs mini-formulaires accolés... On obtient une vraie trousse à outil dépliante et bien organisée pour traiter / afficher ses données.
Mille fois mieux à mes yeux qu'un panneau géant fixé devant son nez...

un article, un client, une marchandise, ... n'ont rien à voir ensemble, mais appartiennent poutant tous à un même dossier

Oui. Et bien on sélectionne via un petit formulaire de recherche le dossier qui nous intéresse.
Ceci fait on peut utiliser un petit formulaire étendu en largeur avec très peu de hauteur, positionné en haut à gauche de l'appli, pour indiquer en permanence le nom et/ou autre référence du dossier sur lequel on travaille.
Mais si le dossier n'est qu'un numéro, pas besoin de tout un formulaire (même petit) pour l'afficher : on se contentera d'inquer son numéro via la légende des formulaires de saisie ouverts à son sujet.
Partant de là, on a notre barre d'outil pour travailler sur les infos que l'on souhaite : un article, un client, une marchandise...
En gros, on a un formulaire par enregistrement relatif au dossier.
Avec pour chacun, un style et une ergonomie en commun.
Notamment, on veillera à reprendre les fonctions classiques que sont l'ajout, la suppression, la recherche d'enregistrements et éventuellement leur tri.
C'est ce genre d'outils qui peuvent être affichés seulement sur demande dans un formulaire grâce aux diférentes section que l'on choisira d'afficher ou de masquer.
Je m'arrête là parce qu'il y a encore à dire et c'est long....
Et peut-être tout le monde est mort ou parti avant de devenir fou. (spéciale dédicace à Papy: toi, je sais que tu tiens bon parce que tu es déjà fou. )

Je croyais, apparement à tort que comme dit say :

[...] les onglets c'est mortel [...]

Tennez, ben je suis de vos avis. Les onglets, c'est la mort !! Faut vraiment pas en abuser.

Je réagit au sujet de l'utilisation des onglets...

Problème récurrent chez moi , j'avais posé la question au sujet de l'usage des onglets
--> http://www.developpez.net/forums/vie...141&highlight=

Dans le post ci-dessus, il est surtout question de les utiliser à bon escient, mais de les utiliser quand même, pas de les éviter...

Les utiliser à bon escient, c'est éviter de les utiliser à tors et à travers !
Moi je n'ai jamais rien dit d'autre, et là, j'essaie de montrer concrètement quand il vaut mieux s'en passer, comment, pourquoi...

une barre d'outils et des onglets, ça se ressemble un chouille sur le concept (notamment le cout par clic)

Oui. Certes. Toutefois il y a bien une différence au niveau de la souplesse, de l'esthétique, de la durabilité...
Mais on pourra débattre à l'infini de ce genre de chose tant qu'on restera pris entre les avantages de se plier aux principes (et encore faut-il les connaître, ce qui est loin d'être évident) et les impératifs de faire uniquement en considération d'un contexte et d'un besoin donnés.

mon mot de la fin....les standards, les users s'en f...., il faut surtout que ça colle à leurs besoins, leurs façons de travailler même si on doit bidouiller ou malmener les standards.

Y a des pros et des puristes qui pourraient dire que tu n'es pas un vrai pro. Ne serait-ce que parce que tu prends en compte le point de vue de l'user sans considérer celui du développeur. Tu as une vision figée des besoins du clients et de ton appli.
Mais bon, tu es peut-être un mercenaire : tu fais pour ce qu'on te donne, rien de plus. Et tu n'as eu que des commandes indigentes.

En ce qui concerne ma base, j'ai beau me triturer le cerveau dans tous les sens, pour l'instant ce sont les onglets (pas imbriqués) qui me semblent les plus appropriés, pour un endroit...

Tout d'abord, vive les gens qui se triturent le cerveau dans tous les sens !!
Ensuite, tu fais preuve de plein de bon sens. Mais si l'on devait débattre il faudrait préciser ou développer !

mais je reconnais onglets + sous-form....

Parle pas d'malheur !!! (mais c'est vrai, on l'a tous fait... )

je comprends pas bien ce que tu veux dire. Tu réalises des barres d'outils "personnalisé" pour chacun de tes applications avec des boutons qui renvoient aux différents formulaire, état, ...

A peu près... Je ne fais pas que cela, mais cela je le fais, oui...

Il n'aura l'info qu'au moment voulu.

c'est à dire après un click sur un bouton de ta barre d'outils

Vi.
Enfin pour être exact, les informations sont "présentées" généralement via des listbox et non pas ces affreux sous formulaires dont tout le monde parle ). La liste (filtrée ou non) sert à présenter les enregistrement "côté plusieurs" dépendant de l'enregistrement dont le détail est affiché par le formulaire contenant la liste (et pas dans un onglet SVP!!! ).
En un clic, on obtient un (ou plusieurs) petit(s) formulaire(s) pour tous les détails de/des enregistrement(s) sélectionné(s) dans la listbox.
Je rappelle la règle : un form par enregistrement parent avec une ou plusieurs listes (une par table enfants) pour présenter les enregistrements enfants...
Mais n'allez pas croire qu'il faut des milliers de formulaires !
Point de vue développeur : on multiplie les instances.
Point de vue utilisateur : une listbox suffit pour afficher les infos intéressantes à parcourir sous forme de liste. Et on clique pour éditer, ajouter ou obtenir les infos secondaires du point de vue du form parent.

avec ton expérience tu dirais que les onglets ne permettent pas de faire simple et encore moins de faire propre

Bon, je me risque à tirer une sorte de principe en guise de conclusion...

En général, les onglets ne sont pas le moyen privilégié pour afficher les différents contrôles de saisie utilisés pour alimenter une hiérarchie de tables en relations un à plusieurs.

Je les préfère, par exemple, pour proposer des options (de configuration) regroupées dans différents thèmes. Mais pas pour de l'affichage et de la saisie classique d'enregistrements.

[Tofalu]

Pro ou pas pro ...

Je me demande comment tu as trouvé le temps d'écrire tout ça ....

C'est trop et donc illisible ... tu aurais pas pu mettre des onglets

[FRED.G]

Bon maintenant retourne dans ta cabanne toi ! Ici on cause sérieux ou on dort ! Si tu dors pas c'est que t'as pas tout lu, alors va-t-en, saltimbanque !