Tu leur avait écrit, chez lepoint.fr ? Ou ils ont choisi ton appli spontanément comme ça au hasard de leur vagabondage sur l'AppStore ? Ils t'ont contacté avant d'écrire l'article ?
Ils auraient pu, à défaut de te contacter avant (puisque leur but n'est pas de t'interviewer), t'informer de l'existence de l'article, ça aurait été sympa :P
Euh, on vois bien que tu n'as pas travaillé dans la presse, toi. C'est la course permanente pour terminer le bouclage à temps, surtout pour une revue sortant toutes les semaines. Les journalistes ont rarement le temps de prévenir les gens pour les petits sujets (hé oui, muqaddar, tu est petit!), d'autant plus qu'il arrive fréquemment qu'un sujet saute, ou soit reporté au prochain numéro.
On ne peut pas toujours avoir raison ! * cours se planquer derrière un tas de sable *
Bon d'accord, je parlais de la manière dont se prépare une revue papier, sujet que j'ai connu intimement. Surtout les bouclages terminés à 4 heures du matin. Mais je ne suis pas persuadé que ce soit très différent avec la version online d'une grande revue papier.
- Refonte de la page principale d'ajout d'un vin pour plus de simplicité lors de la saisie. - Il n'est plus obligatoire de créer ou sélectionner un producteur pour ajouter un nouveau vin. - Le pays et la région du vin se gèrent désormais indépendemment du producteur, dans la fiche vin. - Refonte de la page de recherche des vins par producteur. - Les cépages sont maintenant directement visibles dans la liste générale des vins. - Suppression des synonymies de cépages pour plus de clarté lors de l'ajout des cépages. - Duplication d'un vin pour gagner du temps lors de la saisie de cuvées similaires. - Nouvelle page pour la gestion carafage/décantation avec plus de choix. - Nouvelles rubrique de statistiques : nombre de vins, de bouteilles et valeur de la cave. - Suppression d'un bug sur l'affichage des prix dans la liste des vins (vins sans prix). - Grosse mise à jour sur les régions et appellations américaines prenant en compte les classements par états - Mise à jour automatique de votre base de données de vins avec les nouveaux éléments. - Ajout des pays Luxembourg, Slovénie, République Tchèque (et ses régions), Brésil. - Ajout de 2 appellations en France et en Italie. - Ajout de la contenance 50cl dans les conteneurs.
Si qqch à voir car le JSON est *beaucoup* moins verbeux que le XML. C'est aussi pour ça que c'est une techno de choix pour les devs mobiles genre sur iPhone : à la fois parce que c'est plus simple à manipuler que le XML (le parsing XML sur iPhone tu peux le faire qu'en SAX, alors que le JSON c'est plutôt de l'équivalent DOM, te retournant un objet structuré manipulable), mais aussi parce que ça prend bien moins de bande passante
J'éxécute des requêtes SQL au lancement de l'application. Ces requêtes sont en DUR dans le code. Rien à voir avec XML ou JSON ici... (pas de connexion réseau qui plus est)
Je pense subir un peu la même chose sur le store US. En tapant "Wine", je sors p-e en 200è position... même pas sur la première page (et pourtant "wine" est bien dans les mots-clés). Bref, je pense que décliner un nom en le localisant au moins sur l'AppStore (pas l'executable) ne peut être que bénéfique...
Maintenant, iVinophile ça se localise pas trop...
De plus, je suis en train de faire une version Lite, et je me retrouve avec "iVinoph...Lite" sous l'icone. Pas cool. Je pourrais l'appeller iVino Lite, mais ceux qui vont chercher l'appli à acheter taperont iVino, et iVinophile ne sortira pas forcément... Tout ça n'est pas simple...
Laisse "iVinophile" dans le ProductName (nom sous l'icône) et ne met que la mention "Lite" dans le titre de l'AppStore. C'est ce que font la plupart des apps. Avec en plus un petit bandeau marqué "Lite" en travers de l'icône (en diagonale dans le coin supérieur gauche genre) et basta.
Oui, tu as raison, c'est la meilleure chose à faire.
L'autre question que je me pose c'est : faut-il utiliser le même bundle identifier ?
Exemple : si je limite la version Lite à 10 vins, il serait dommage que le bundle soit différent, et dans ce cas, que l'utilisateur perde ses 10 vins saisis lorsque qu'il passe à la version payante. Dans un cas, la version achetée "écrase l'autre" (et prends sa sandbox), et dans l'autre cas, l'utilisateur aurait 2 applications différentes.
Quelle est le bon choix (je penche pour garder le bundle identifier et donc les vins saisis) ?
EDIT : sauf que je pense qu'Apple n'autorise pas (heureusement) que 2 applis aient le même bundle identifier... (quand on upload sur le store, ils contrôlent) donc je pense que ce n'est pas possible.
Effectivement on ne peut pas mettre deux mêmes bundle id. Ensuite pour faire ce que tu voudrais il est possible de mettre en place un achat intégré pour débloquer la version intégrale.
Effectivement on ne peut pas mettre deux mêmes bundle id. Ensuite pour faire ce que tu voudrais il est possible de mettre en place un achat intégré pour débloquer la version intégrale.
Oui mais pour ce type d'application, je n'aime pas le InAppPurchase... l'utilisateur se sentirait floué (ce n'est pas comme des niveaux dans un jeu...)
C'est bizarre, je pense avoir tout bien fait pour une version Lite, et pourtant, l'iPhone a l'air un peu perdu...
J'ai bien 2 icones, 2 applis, le même nom de produit (et d'executable ?), 2 bundle identifiers différents... et quand je lance une ou l'autre, on dirait qu'il lance la même application... parfois je me retrouve avec le texte de la version Lite sur les 2, et parfois sans texte sur les 2...
A partir du moment où j'ai 2 bundles identifiers, je ne devrais pas avoir de problème non ? (le pire c'est que j'arrive très bien à faire cottoyer 3 versions pour la version normale : debug, adhoc et distri...), donc en tout j'ai 6 bundles identifiers en théorie.
Oui mais pour ce type d'application, je n'aime pas le InAppPurchase... l'utilisateur se sentirait floué (ce n'est pas comme des niveaux dans un jeu...)
Je ne vois pas où l'utilisateur se sentirait floué... l'in-app purchase a été fait pour toutes sortes de choses, pas que pour vendre des niveaux de jeu. Ca sert tout aussi bien pour pouvoir débloquer une version limitée en fonctionnalités, en version complète, il suffit de bien stipuler la possibilité d'achat intégré dans le descriptif, c'est au contraire beaucoup plus propre et permet à l'utilisateur de conserver les données rentrées en version démo.
Oui je vois ce qu'Alex veut dire par "les acheteurs se sentiraient floués" : tu vois dans la liste des apps sur l'AppStore une appli marquée "gratuite" tu te dis "wahou trop top c'est pile ce que je veux et en plus c'est gratuit !"... et ce n'est qu'après coup que tu vois qu'en fait elle est payante (et que la version gratuite ne propose qu'un truc super limité juste pour te donner goût au truc)
Maintenant, si tu l'indiques clairement, dans la description de l'AppStore, tant que ton appli Lite n'est pas payante, ça me choque pas tant que ça. Je veux dire, au pire tu as téléchargé l'appli gratuite pensant que tu aurais la version complète, et tu vois qu'il faut payer pour la version complète... bah tu te dis "ah oui je me disais c'est trop beau, bon en même temps c'est normal, c'est bien foutu comme appli... allez j'achète"... ou alors tu te dis "pfff je vais pas payer pour ça"... mais au moins t'as pas déboursé un kopec.
Je trouve ça quand même vachement moins trompeur qu'une appli vendue 0,79€ ou 1,59€ et qui te déçoit ensuite... alors que tu as dépensé des sous pour elle ;-)
Oui mais pour ce type d'application, je n'aime pas le InAppPurchase... l'utilisateur se sentirait floué (ce n'est pas comme des niveaux dans un jeu...)
Je ne vois pas où l'utilisateur se sentirait floué... l'in-app purchase a été fait pour toutes sortes de choses, pas que pour vendre des niveaux de jeu. Ca sert tout aussi bien pour pouvoir débloquer une version limitée en fonctionnalités, en version complète, il suffit de bien stipuler la possibilité d'achat intégré dans le descriptif, c'est au contraire beaucoup plus propre et permet à l'utilisateur de conserver les données rentrées en version démo.
Pour moi, un utilisateur va être super content de télécharger une appli gratuite, la tester, mais le fait de la brider alors qu'on l'a proposée dans les applications gratuites, et de pouvoir la débloquer depuis l'appli va le frustrer : pour lui c'est du faux gratuit.
Parce qu'on sait bien que mon application est commerciale, et à vrai dire, je ne vois pas ce qu'elle aurait à faire UNIQUEMENT dans les applications gratuites. Imagine si toutes les applications Démo Mac étaient marquées gratuites, et puis on lance et hop on nous incite à acheter parce qu'elles sont bridées... la différence c'est qu'on sait que c'est du payant dès le départ.
Pour moi, les in apps purchases sont faits pour ajouter des fonctionnalités supplémentaires OU des niveaux de jeux MAIS PAS pour débloquer une appli annoncée comme gratuite (même si c'est du test).
Ne pas oublier également de penser que les utilisateurs ne lisent pas aussi les descriptions sur les applications, même si tout est expliqué.
Le coup du Lite et non Lite me paraà®t plus clair pour l'utilisateur, même si ça pollue. Il faudrait qu'Apple crée une section Démo, tout simplement.
Pour moi, un utilisateur va être super content de télécharger une appli gratuite, la tester, mais le fait de la brider alors qu'on l'a proposée dans les applications gratuites, et de pouvoir la débloquer depuis l'appli va le frustrer : pour lui c'est du faux gratuit.
C'est pourtant chose courante dans l'App Store. Le concept du tout gratuit est caduque sur cette plate-forme. Combien de gratuits mais avec nombre de publicités ? Il est plus facile d'acquérir les gratuits sans réfléchir, mais sachant que l'App Store propose de l'achat intégré, il faut tout de même se renseigner un minimum.
Parce qu'on sait bien que mon application est commerciale, et à vrai dire, je ne vois pas ce qu'elle aurait à faire UNIQUEMENT dans les applications gratuites. Imagine si toutes les applications Démo Mac étaient marquées gratuites, et puis on lance et hop on nous incite à acheter parce qu'elles sont bridées... la différence c'est qu'on sait que c'est du payant dès le départ.
Oui, beaucoup de démos sont comme ça, et heureusement, comme ça on sait à quoi s'en tenir. Le shareware a toujours fonctionné ainsi...
Ensuite pour en revenir à l'App Store, tu peux très bien garder ta version payante telle qu'elle, et aussi avoir une version lite transformable en complète via achat intégré. C'est un concept déjà utilisé, et l'utilisateur n'en sera que plus content s'il apprécie le logiciel il n'aura pas à retaper toutes ses données.
Après je te l'accorde, cela change le mode de distribution et peut perturber les résultats que tu connais actuellement, et cela doit aussi influencer ton choix de ne pas prendre de risques de ce côté-là . Mais beaucoup d'utilisateurs ne vont que dans le gratuit. Il y a pleins de paramètres à prendre en compte.
Pour moi, les in apps purchases sont faits pour ajouter des fonctionnalités supplémentaires OU des niveaux de jeux MAIS PAS pour débloquer une appli annoncée comme gratuite (même si c'est du test).
Apple préconise moults utilisations pour l'In-App purchase, ensuite on fait ce que l'on a besoin/envie de faire avec ou pas. Chacun sa façon de voir les choses.
Ne pas oublier également de penser que les utilisateurs ne lisent pas aussi les descriptions sur les applications, même si tout est expliqué.
Une petite alerte au premier lancement et l'utilisateur est tout de suite mis au courant....
Le coup du Lite et non Lite me paraà®t plus clair pour l'utilisateur, même si ça pollue. Il faudrait qu'Apple crée une section Démo, tout simplement.
Apple ne veut pas de version démo, il veut soit du lite soit de l'achat intégré. Je trouve que les versions lite polluent l'App Store, l'achat intégré est là pour répondre à cela. Apple pourrait par contre rajouter un symbole vite identifiable dans le haut de la description si l'appli comporte des achats intégrés.
Oui je vois ce qu'Alex veut dire par "les acheteurs se sentiraient floués" : tu vois dans la liste des apps sur l'AppStore une appli marquée "gratuite" tu te dis "wahou trop top c'est pile ce que je veux et en plus c'est gratuit !"... et ce n'est qu'après coup que tu vois qu'en fait elle est payante (et que la version gratuite ne propose qu'un truc super limité juste pour te donner goût au truc)
Maintenant, si tu l'indiques clairement, dans la description de l'AppStore, tant que ton appli Lite n'est pas payante, ça me choque pas tant que ça. Je veux dire, au pire tu as téléchargé l'appli gratuite pensant que tu aurais la version complète, et tu vois qu'il faut payer pour la version complète... bah tu te dis "ah oui je me disais c'est trop beau, bon en même temps c'est normal, c'est bien foutu comme appli... allez j'achète"... ou alors tu te dis "pfff je vais pas payer pour ça"... mais au moins t'as pas déboursé un kopec.
Je trouve ça quand même vachement moins trompeur qu'une appli vendue 0,79€ ou 1,59€ et qui te déçoit ensuite... alors que tu as dépensé des sous pour elle ;-)
Bien sûr je suis d'accord, on part sur une base d'appli gratuite. Je ne suis pas pour les applis payantes à la base, avec ensuite de l'achat intégré, quoique tout dépend le contexte, regarde les GPS, même si ce sont des cas particuliers c'est vrai.
Réponses
Ils auraient pu, à défaut de te contacter avant (puisque leur but n'est pas de t'interviewer), t'informer de l'existence de l'article, ça aurait été sympa :P
Bon d'accord, je parlais de la manière dont se prépare une revue papier, sujet que j'ai connu intimement. Surtout les bouclages terminés à 4 heures du matin. Mais je ne suis pas persuadé que ce soit très différent avec la version online d'une grande revue papier.
- Refonte de la page principale d'ajout d'un vin pour plus de simplicité lors de la saisie.
- Il n'est plus obligatoire de créer ou sélectionner un producteur pour ajouter un nouveau vin.
- Le pays et la région du vin se gèrent désormais indépendemment du producteur, dans la fiche vin.
- Refonte de la page de recherche des vins par producteur.
- Les cépages sont maintenant directement visibles dans la liste générale des vins.
- Suppression des synonymies de cépages pour plus de clarté lors de l'ajout des cépages.
- Duplication d'un vin pour gagner du temps lors de la saisie de cuvées similaires.
- Nouvelle page pour la gestion carafage/décantation avec plus de choix.
- Nouvelles rubrique de statistiques : nombre de vins, de bouteilles et valeur de la cave.
- Suppression d'un bug sur l'affichage des prix dans la liste des vins (vins sans prix).
- Grosse mise à jour sur les régions et appellations américaines prenant en compte les classements par états
- Mise à jour automatique de votre base de données de vins avec les nouveaux éléments.
- Ajout des pays Luxembourg, Slovénie, République Tchèque (et ses régions), Brésil.
- Ajout de 2 appellations en France et en Italie.
- Ajout de la contenance 50cl dans les conteneurs.
J'essaye de te faire un peu de pub, mais dans mes relations, j'ai
- Des buveurs de vins et amateurs de vins
- Des geeks avec un iphone
Mais peu qui cumule les deux lol
ça me rassure, puisque j'envoie 500 requêtes SQL au lancement.
Json et la toison d'or ?
Rein à voir car dans tous les cas, il aurait fallu générer les requêtes SQL.
C'est aussi pour ça que c'est une techno de choix pour les devs mobiles genre sur iPhone : à la fois parce que c'est plus simple à manipuler que le XML (le parsing XML sur iPhone tu peux le faire qu'en SAX, alors que le JSON c'est plutôt de l'équivalent DOM, te retournant un objet structuré manipulable), mais aussi parce que ça prend bien moins de bande passante
J'éxécute des requêtes SQL au lancement de l'application. Ces requêtes sont en DUR dans le code.
Rien à voir avec XML ou JSON ici... (pas de connexion réseau qui plus est)
http://www.pommedev.com/forum/index.php?topic=3877.msg51268#msg51268
Je pense subir un peu la même chose sur le store US.
En tapant "Wine", je sors p-e en 200è position... même pas sur la première page (et pourtant "wine" est bien dans les mots-clés).
Bref, je pense que décliner un nom en le localisant au moins sur l'AppStore (pas l'executable) ne peut être que bénéfique...
Maintenant, iVinophile ça se localise pas trop...
De plus, je suis en train de faire une version Lite, et je me retrouve avec "iVinoph...Lite" sous l'icone. Pas cool.
Je pourrais l'appeller iVino Lite, mais ceux qui vont chercher l'appli à acheter taperont iVino, et iVinophile ne sortira pas forcément...
Tout ça n'est pas simple...
L'autre question que je me pose c'est : faut-il utiliser le même bundle identifier ?
Exemple : si je limite la version Lite à 10 vins, il serait dommage que le bundle soit différent, et dans ce cas, que l'utilisateur perde ses 10 vins saisis lorsque qu'il passe à la version payante. Dans un cas, la version achetée "écrase l'autre" (et prends sa sandbox), et dans l'autre cas, l'utilisateur aurait 2 applications différentes.
Quelle est le bon choix (je penche pour garder le bundle identifier et donc les vins saisis) ?
EDIT : sauf que je pense qu'Apple n'autorise pas (heureusement) que 2 applis aient le même bundle identifier... (quand on upload sur le store, ils contrôlent) donc je pense que ce n'est pas possible.
Oui mais pour ce type d'application, je n'aime pas le InAppPurchase... l'utilisateur se sentirait floué (ce n'est pas comme des niveaux dans un jeu...)
J'ai bien 2 icones, 2 applis, le même nom de produit (et d'executable ?), 2 bundle identifiers différents... et quand je lance une ou l'autre, on dirait qu'il lance la même application... parfois je me retrouve avec le texte de la version Lite sur les 2, et parfois sans texte sur les 2...
A partir du moment où j'ai 2 bundles identifiers, je ne devrais pas avoir de problème non ? (le pire c'est que j'arrive très bien à faire cottoyer 3 versions pour la version normale : debug, adhoc et distri...), donc en tout j'ai 6 bundles identifiers en théorie.
Je ne vois pas où l'utilisateur se sentirait floué... l'in-app purchase a été fait pour toutes sortes de choses, pas que pour vendre des niveaux de jeu. Ca sert tout aussi bien pour pouvoir débloquer une version limitée en fonctionnalités, en version complète, il suffit de bien stipuler la possibilité d'achat intégré dans le descriptif, c'est au contraire beaucoup plus propre et permet à l'utilisateur de conserver les données rentrées en version démo.
Maintenant, si tu l'indiques clairement, dans la description de l'AppStore, tant que ton appli Lite n'est pas payante, ça me choque pas tant que ça. Je veux dire, au pire tu as téléchargé l'appli gratuite pensant que tu aurais la version complète, et tu vois qu'il faut payer pour la version complète... bah tu te dis "ah oui je me disais c'est trop beau, bon en même temps c'est normal, c'est bien foutu comme appli... allez j'achète"... ou alors tu te dis "pfff je vais pas payer pour ça"... mais au moins t'as pas déboursé un kopec.
Je trouve ça quand même vachement moins trompeur qu'une appli vendue 0,79€ ou 1,59€ et qui te déçoit ensuite... alors que tu as dépensé des sous pour elle ;-)
Pour moi, un utilisateur va être super content de télécharger une appli gratuite, la tester, mais le fait de la brider alors qu'on l'a proposée dans les applications gratuites, et de pouvoir la débloquer depuis l'appli va le frustrer : pour lui c'est du faux gratuit.
Parce qu'on sait bien que mon application est commerciale, et à vrai dire, je ne vois pas ce qu'elle aurait à faire UNIQUEMENT dans les applications gratuites. Imagine si toutes les applications Démo Mac étaient marquées gratuites, et puis on lance et hop on nous incite à acheter parce qu'elles sont bridées... la différence c'est qu'on sait que c'est du payant dès le départ.
Pour moi, les in apps purchases sont faits pour ajouter des fonctionnalités supplémentaires OU des niveaux de jeux MAIS PAS pour débloquer une appli annoncée comme gratuite (même si c'est du test).
Ne pas oublier également de penser que les utilisateurs ne lisent pas aussi les descriptions sur les applications, même si tout est expliqué.
Le coup du Lite et non Lite me paraà®t plus clair pour l'utilisateur, même si ça pollue.
Il faudrait qu'Apple crée une section Démo, tout simplement.
C'est pourtant chose courante dans l'App Store. Le concept du tout gratuit est caduque sur cette plate-forme. Combien de gratuits mais avec nombre de publicités ?
Il est plus facile d'acquérir les gratuits sans réfléchir, mais sachant que l'App Store propose de l'achat intégré, il faut tout de même se renseigner un minimum.
Oui, beaucoup de démos sont comme ça, et heureusement, comme ça on sait à quoi s'en tenir. Le shareware a toujours fonctionné ainsi...
Ensuite pour en revenir à l'App Store, tu peux très bien garder ta version payante telle qu'elle, et aussi avoir une version lite transformable en complète via achat intégré. C'est un concept déjà utilisé, et l'utilisateur n'en sera que plus content s'il apprécie le logiciel il n'aura pas à retaper toutes ses données.
Après je te l'accorde, cela change le mode de distribution et peut perturber les résultats que tu connais actuellement, et cela doit aussi influencer ton choix de ne pas prendre de risques de ce côté-là . Mais beaucoup d'utilisateurs ne vont que dans le gratuit. Il y a pleins de paramètres à prendre en compte.
Apple préconise moults utilisations pour l'In-App purchase, ensuite on fait ce que l'on a besoin/envie de faire avec ou pas. Chacun sa façon de voir les choses.
Une petite alerte au premier lancement et l'utilisateur est tout de suite mis au courant....
Apple ne veut pas de version démo, il veut soit du lite soit de l'achat intégré. Je trouve que les versions lite polluent l'App Store, l'achat intégré est là pour répondre à cela. Apple pourrait par contre rajouter un symbole vite identifiable dans le haut de la description si l'appli comporte des achats intégrés.
Bien sûr je suis d'accord, on part sur une base d'appli gratuite. Je ne suis pas pour les applis payantes à la base, avec ensuite de l'achat intégré, quoique tout dépend le contexte, regarde les GPS, même si ce sont des cas particuliers c'est vrai.