Test sur vrai device...

BooleanneBooleanne Membre
septembre 2014 modifié dans Apple Developer Programs #1

Bon nombre d'entre vous le disent et le redisent : rien ne vaut un test sur vrai device. Ah si j'avais écouté plus tôt ! 


 


J'ai commencé à  développer sur iPad, parce que j'en avais un, et puis, j'ai rendu mon app compatible iPhone... mais finalement, je n'avais pas du tout l'esprit... Résultat, pas motivée par la version iPhone, je la bâclait toujours plus ou moins.


 


Me voilà , enfin, avec vrai iPhone à  ma disposition, et là , je me rends compte que mon appli est vraiment nulle sur iPhone (je me dis d'ailleurs que si je n'ai que peu d'avis négatifs, c'est que les utilisateurs n'ont vraiment aucun goût  ;) ). Les boutons sont trop serrés, on n'appuie pas où il faut, c'est très énervant. 


Avec le simulateur, on a un visu, c'est tout; pas le feeling de l'App. 


 


Avoir un vrai iPhone permet de se rendre compte que l'espace y est vraiment exigu, que les boutons nécessitent de la place pour être agréables à  utiliser... enfin, bref, tout doit être pensé différemment pour avoir une ergonomie confortable.


Je suppose que pour la plupart d'entre vous, c'est plutôt le contraire, vous avez commencé par l'iPhone, puis, vous avez étendu la compatibilité à  l'iPad. Mais je pense que vous avez du rencontrer une problématique similaire : on ne raisonne pas de la même façon au niveau de la navigation. 


 


Voilà , c'était pour faire part de mon expérience à  ceux qui seraient dans le même cas. Pour développer un produit sérieux, je confirme, rien ne vaut un test sur vrai device  :) , sinon, on fait vraiment du bricolage.

Réponses

  • Am_MeAm_Me Membre
    septembre 2014 modifié #2


    J'ai commencé à  développer sur iPad, parce que j'en avais un, et puis, j'ai rendu mon app compatible iPhone... mais finalement, je n'avais pas du tout l'esprit... Résultat, pas motivée par la version iPhone, je la bâclait toujours plus ou moins.




     


    Normal :)


     


     




    Me voilà , enfin, avec vrai iPhone à  ma disposition, et là , je me rends compte que mon appli est vraiment nulle sur iPhone (je me dis d'ailleurs que si je n'ai que peu d'avis négatifs, c'est que les utilisateurs n'ont vraiment aucun goût  ;) ). Les boutons sont trop serrés, on n'appuie pas où il faut, c'est très énervant. 


    Avec le simulateur, on a un visu, c'est tout; pas le feeling de l'App. 




     


     


    Ouai ton appli est nulle !! Qui a dit ça? personne hein :P


    Non pour les boutons j'ai eu le même problème il faut qu'il soit de taille 44x44 minimum. J'avais posté un sujet dessus et quelqu'un m'avait dit que sur la doc 44x44 est la taille minium conseillée ! et ça marche mieux maintenant




  • Ouai ton appli est nulle !! Qui a dit ça? personne hein :P


    Non pour les boutons j'ai eu le même problème il faut qu'il soit de taille 44x44 minimum. J'avais posté un sujet dessus et quelqu'un m'avait dit que sur la doc 44x44 est la taille minium conseillée ! et ça marche mieux maintenant




     


    Moi, je le dis, parce que c'est vrai. Sur iPhone, en tous les cas. Il n'y a pas que les boutons, la logique de navigation aussi, des vues trop petites, enfin ,bref, tout ce qui fait qu'on aime se balader dans une appli bien faite.

  • On voit ça souvent avec les jeux vidéos. Les devs pensent à  l'iPad et font une version iPhone quasiment inutilisable, avec des interfaces minuscules.
  • Ah oui d'accord je fais le lien du coup.


    En tout cas pour l'histoire des boutons tu peux les regrouper dans une liste et quand l'utilisateur clique ça ouvre un accès aux autres.


    Mais c'est vrai que si la maquette n'est pas faite depuis le début c'est chaud patate.


     


    Et là  on est un peu obligé avec l'iPhone 6+ de réfléchir à  la fois pour grand écran et petit. 




  • Mais c'est vrai que si la maquette n'est pas faite depuis le début c'est chaud patate.


    Et là  on est un peu obligé avec l'iPhone 6+ de réfléchir à  la fois pour grand écran et petit. 




     


     


    Oui, comme tu dis, c'est le concept global qui est à  envisager différemment. Mais, bon, en même temps, c'est toujours très formateur. D'autant plus qu'avec la notion de "resizable", il va falloir encore se projeter dans un autre mode de fonctionnement... pour le moment, je ne vois pas trop... pas tout compris.

  • Am_MeAm_Me Membre
    septembre 2014 modifié #7

    C'est sur que si tu fait de la dev iOS juste un "loisir" ou une passion comme moi se prendre la tête sur la nouvelle notion de resizable c'est pas urgent et j'ai même envie de dire c'est même pas grave de ne rien comprendre au final.


     


    Si tu as une entreprise carrément qui fait de la dev iOS oui il faut se soucier dès maintenant des maquettes et changer sa façon de travailler.




  • C'est sur que si tu fait de la dev iOS juste un "loisir" ou une passion comme moi se prendre la tête sur la nouvelle notion de resizable c'est pas urgent et j'ai même envie de dire c'est même pas grave de ne rien comprendre au final.




     


    C'est un peu ça, plutôt une passion, mais c'est aussi le plaisir d'apprendre et d'évoluer... et pourquoi pas d'avoir un produit vivant aussi. J'essaye de comprendre, ça permet de garder les neurones en bon état... enfin, presque  ::) .



  • C'est un peu ça, plutôt une passion, mais c'est aussi le plaisir d'apprendre et d'évoluer... et pourquoi pas d'avoir un produit vivant aussi. J'essaye de comprendre, ça permet de garder les neurones en bon état... enfin, presque  ::) .




     


    Bah c'est pareil sauf que mes neurones sont en bon état pour le moment :o  . Mais je pense qu'en entreprise (je n'y suis pas encore perso à  ce stade) mais tout doit être maqueté je pense.


     


    Avoir un produit vivant :O ??? ce ne sont pas des êtres humains  xd


     


    Bon on a dérivé sur le thème de la conversation  ;D

  • Oups !  ;)


  • Travailler sur maquette n'est pas forcément une bonne idée. Une idée sympathique sur le papier peut s'avérer mauvaise à  l'utilisation. Il ne faut pas hésiter à  faire beaucoup de tests et modifier l'ergonomie plusieurs fois. J'ai eu une très mauvaise expérience avec une maquette conçue par une boà®te de comm psycho-rigide.
  • AliGatorAliGator Membre, Modérateur
    septembre 2014 modifié #12
    Les Size Classes, c'est pas compliqué : c'est exactement la même chose que ce qu'on avait avant avec "Foo~iPad.xib" / "Foo~iPhone.xib" / "Foo~iPad-Landscape.xib" / "Foo~iPhone-Landscape.xib" et toutes ces possibilités de variantes.


    Si vous ne faites qu'une application iPad, ou qu'une application iPhone, vous vous en foutez.

    Si vous faites une application Universelle (iPad+iPhone) mais qui se trouve avoir exactement le même design pour les 2 (en tout cas rien qui ne puisse être fait avec AutoLayout), vous vous en foutez aussi.


    Par contre si vous aviez avant besoin de faire 2 XIBs ou Storyboards différents, un "~ipad" et un "~iphone", parce que dans la version iPhone et iPad c'est vraiment pas du tout les mêmes écrans " c'est pas juste des vues qui s'étirent mais c'est des éléments qui ne sont pas du tout placés au même endroit, sur iPad vous avez des boutons les uns à  côté des autres alors que sur iPhone ils sont dans un menu, ou les uns en dessous des autres, etc... Bah là  vous allez pouvoir passer aux SizeClasses.


    ---


    Les SizeClasses c'est le même principe que ce qu'on faisait avec "~ipad" / "~iphone" / "-Landscape" / "-Portrait" sauf qu'on n'a plus à  gérer 36 fichiers, on met tout dans un seul, et on bascule d'une variante à  l'autre avec un petit menu dans IB. D'ailleurs, si vous ciblez iOS8, ça va compiler ce XIB unique en un seul fichier NIB, mais si vous ciblez iOS7 ou inférieur, ça va compiler ce XIB unique en autant de variantes que nécessaires "Foo~iphone.nib", "Foo~ipad.nib", etc quand ça va générer votre application, histoire d'être rétrocompatible avec les iOS avant iOS8 qui ne connaissaient que ça.


    Les 2 grandes différences entre SizeClasses et l'ancien système c'est que :
    • On peut éditer notre interface dans un seul et même fichier plutôt que de basculer entre plusieurs fichiers. Cela évite de plus de dupliquer tout ce qui est commun, donc le fichier NIB résultant est plus léger
    • Et ça incite à  ne plus raisonner en terme de "iPhone vs. iPad", mais en terme de "classe de taille" (Size Classes), "Compact vs. Regular".

      Un iPad correspond à  la SizeClass "Regular en largeur / Regular en hauteur", un iPhone en mode Paysage correspond à  "Compact en largeur / Compact en hauteur"... sauf un iPhone 6 Plus (5.5") qui lui correspond à  "Regular en largeur / Compact en hauteur" pour mettre en valeur le fait qu'il a une largeur + grande en paysage que les autres iPhones, permettant d'utiliser dans ce cas par exemple des SplitViewControllers comme sur iPad.
    La transition / correspondance entre "iPhone vs. iPad" contre "Compact vs. Regular" ne va pas forcément se faire facilement dans les premiers temps, on va jamais mémoriser ce qui est Compact et ce qui est Regular, mais en même temps l'idée à  terme c'est pas de raisonner en terme de "sur quel device je tourne" mais plutôt "est-ce que j'ai beaucoup de place sur mon écran ou pas". Après tout, qu'on tourne sur un iPhone 6 Plus en paysage ou sur un iPad en paysage, dans les 2 cas on a la place de mettre un SplitViewController.
  • Merci pour ce récapitulatif simple et concis. Je suis dans le cas de 2 interfaces totalement différentes. Ca va alléger le code et effectivement si on essaye de raisonner plus "tailles d'écran", ça devrait aussi fiabiliser dans le temps et alléger la maintenance.


  • AliGatorAliGator Membre, Modérateur
    La correspondance est assez bien résumée par cette image :
    size_classes.png
  • Sauf qu'un écran 3,5 pouces n'est pas un écran 4 pouces.


    Compact/compact 3,5 pouces

    Compact/compact 4 pouces

    Compact/regular 3,5 pouces

    Compact/regular 4 pouces
  • AliGatorAliGator Membre, Modérateur
    septembre 2014 modifié #16
    Et alors ? Pas compris ta remarque Draken.


    Un écran 4.7 pouces n'est pas un ecran 5.5" non plus, pourtant ils ont aussi la même SizeClass en portrait, et alors ?


    Du moment que c'est la même classe de taille justement heureusement ca simplifie les choses sinon bonjour le mal de tête facon Android ;-)

    Tu aurais préféré qu'ils prévoient 6 SizeClasses ? (IPhone 3.5" / iPhone 4" / iPhone 4.7" / iPhone 5.5" / iPad Mini / iPad) ?! Et ce à  la fois pour Landscape et Portrait, donc 12 variantes différentes ? Pitié non ! Et puis c'est pas comme ça qu'il faut raisonner sinon on ne s'en sort plus.



    Et pour le reste, il y a AutoLayout qui suffit amplement pour le delta 3.5" vs 4"
  • * note pour moi-même :


    Fin novembre acheter un MBPr 15 pouces, un iPhone 6, un iPad Air et 127 boà®tes d'aspirine !
Connectez-vous ou Inscrivez-vous pour répondre.