Ha complètement d'accord c'est le besoin fondamental pour une app, je reçois des milliers de retours utilisateurs par jour qui se plaignent d'avoir 5ms en trop de latence sur les clics.
Ha oui le flou en background à 60fps c'est énorme comme ça améliore la qualité de ton app. Pour moi c'est carrément le "second besoin de base" d'une app mobile.
Ces deux phrases a elles seules resument ton ignorance crasse du "appli smarpthone grand public".
1) Personne ne te donnera jamais le moindre feedback sur ce genre de trucs, principalement parce qu'un bon design ne se remarque pas, a moins d'y faire tres attention et d'avoir des affinites avec la discipline. Par contre, quand tu mesure l'écart en A/B test, tu la voit la difference (et pas qu'un peu, on a un peu double la conversion depuis qu'on a commence a faire le choses decemment chez nous, et ya encore beaucoup de taff). Sinon j'ai envie de dire "mais je croyais que c'etait supporte depuis un an et demi que c'etait de la balle ya 30 minutes, et maintenant, tout d'un coup, ca devient completement inutile et superflu, une fois que tu te rends compte que c'est pas supporte"? Si c'est pas en ligne avec ce que je disais ailleurs, ou le HTML5 te limite fortement dans ce que tu peux faire, et que ses partisans acceptent ces limitations avec fatalité (autrement connu sous le nom de "j'suis trop flemmard pour faire mon taff correctemt eud'facons").
2) Cf 1. Ca rejoint ce que je disais, t'as des gouts de chiotte, et par du principe que le design visuel est de la connerie qui ne sert a rien. Ceux qui s'y sont essaye pour de vrai ont un autre avis.
Sur ca, j'arrete pour de bon. On vit sur differentes planetes toi et moi - visiblement ce qui compte le plus pour toi c'est que les developeurs en aient le moins a faire et torchent leur produit vite fait mal fait, et shipper est tout ce qui compte, meme si tu livres de la merde. Perso je shipe pas la merde, avec l'equipe on s'engueule toute la journee au sujet du meilleur design (mais le soir on va boire un godet ensemble).
Et au final, on met la tannee a l'equipe mobile web (meme avec les problematiques de deploiment et une semaine dans la vue en review sur le store), parce qu'on a un tooling et un framework de qualite. Et niveau conversion, on est tellement loin devant que c'est meme plus drôle.
On coute moins cher, pour un produit de meilleur qualite qui rapporte plus. Alors ton write once, kind of run everywhere but not really, hein…
Ensuite si ce que tu cherches à dire est "plus le niveau du language est haut moins il est performant" ce n'est pas la peine de t'égosiller, tout le monde le sait déjà.
Ben visiblement t'as toujours pas compris quel est le coeur du problème - DOM et le manque de reactivite globale.
La vitesse est pas si importante, ce qui compte le plus c'est la latence, et HTML5/JS est un desastre a ce niveau la. D'autres trucs rentrent en compte, notamment les outils de debugging, mais ca c'est des trucs cote developeurs. HTML5/js n'est tout simplement pas capable a l'air actuelle de repondre au premier besoin de base - a savoir un truc qui est "snappy" et qui reagit sur le champ. Meme sur desktop, c'est border line, avec les monstres qu'on a de nos jours.
Ca me rassure (encore une fois) de voir que ton seul argument est une fonctionnalité qui n'est pas encore sortie. Dommage que css sache faire ça depuis un an et demi :
Ben voyons. En appliquant l'effet au background qui defile derriere? a 60FPS? J'aimerais bien voir ca tiens!
sinon, mes couilles sur ton nez, ca fait un skyblog?
Me traiter d'ignorant quand tu t'habilles visiblement chez Gucci Hot et que t'es pas foutu de voir des failles beantes d'UX, c'est pas de l'agressivité?
T'as tellement pas la moindre idee de ce dont tu parles que ca en devient pitoyable.
T'as perdu toute credibilite avec ton histoire de 30 secondes pour sortir du mode fullscreen - mon petit doigt me dit que t'as jamais vu la feature en question.
Pour ce qui est des transitions, tu dois avoir de la merde dans les yeux je me dit, et j'aimerais bien te voir gerer les rotations de facon fluide avec CSS, histoire de rigoler un bon coup.
Nul. Le design n'a rien a voir avec les perfs. Il n'y a pas de limites de design en css moderne.
Ouaiiiis, bien suuuuur. D'ailleurs, les effets de blurs qu'iOS7 introduits sont super simple a faire en CSS.
J'arrete la discussion a ce niveau - si des applis avec plusieurs dizaines/centaines de ms de reactivite et des animations saccadees (quand t'en as!) te conviennent, et que t'as tellement de la merde dans les yeux que t'es meme pas capable de t'en rendre compte, grand bien t'en fasse.
tu confirmes ce que je dit, leur super prototype qui soit disant dechire sa race a l'air peu reactif et a un look de merde. Les rotations/transitions sont vraiments mauvaises (en fait, elles sont inexistantes), et bon courage pour implementer le "flick to exit fullscreen photo" de l'appli FB.
C'est en plein dans ce que je disais dans un autre message: les webeux vivent dans un monde parallele ou les perfs de merde sont une fatalite, et par la meme, acceptables.
Si c'est l'etat de l'art des applis riches html5, ben ca en dit long sur la qualite de la techno.
2.65MB pour une appli avec une vue, une page html + js et toutes les librairies linkees?
J'ai le droit de dire que c'est de la triche et qu'il ya de la ram planquee quelque part?
Rien que le binaire fait probablement pas loin de 3MB…
Heu, ben ouais, pendant 10 ans c'etait un peu la seule jvm reellement utilisee, donc forcement, mais le temps de chauffe est plus lie au jit qu'autre chose.
Ca a pas grand chose a voir avec le fait d'avoir un navigateur charge ou pas.
Safari mobile se demerde admirablement bien, et ca reste super lent et pas reactif par rapport aux applis native, pre charge ou pas.
Sinon, pour les perfs:
- tes applis se font tuer regulierement, des que ca manque de ram en fait
- le temps de demarrage d'une appli mobile est critique. Ios te tue apres 5 secondes, je considere perso plus de 750-800ms inacceptable sur mes applis.
Ya plein de techniques diverses et variees pour rendre le chargement plus rapide (qui tournentntoutes autour du lazy loading et du background processing), mais vu l'ordre de grandeur, et sachant que ya pas mal a faire entre le debut du main et la premiere run loop utilisable, ca laisse pas des masses de marge de manoeuvre.
Pour afficher une interface utilisateur, les perfs de DOM sont tout à fait raisonnables
Non, clairement pas raisonnable du tout. Les webeux vivent dans un monde parallele ou les perfs de chiottes sont acceptables, sortez votre tete du sable - une webview se remarque a des kilometres, ca met un temps fou a charger et a reagir.
Si tu veux faire un simple hello world, je veux bien te croire.
Si tu veux faire un truc un tant soit peu pas trivial, rapide, robuste (comprendre maintenable dans le temps), qui soit pas un monstre memoire ou qui ne mette pas un CPU haut de gamme a genoux, j'ai comme qui dirait de gros doute. Rien qu'a voir le temps que ca a prit aux gars du site mobile pour avoir un flyweight decent sur une table avec 1500 entrées, la ou les applis natives te font ca les doigts dans le nez, je suis sceptique.
Ca depend de quoi tu parles.
Une fois la vm chargee et chauffee, oui, ca va vite.
Mais le temps de chargement + chauffe avoisine la session moyenne d'une appli mobile, et l'overhead memoire de java et de la jvm, gc et tout le tsintsin, c'est pas negligeable.
Rajoute les probleme de gc non deterministe, et quand t'es contraint en memoire, sans swap, c'est loin d'etre un bon choix (et ce malgre tous les efforts que google a pu mettre dna s dalvik).
Si j'ai bien suivi, asm.js est base sur une compile aot (sinon, j'ai du mal a voir l'interet).
Yen a vraiment qui pensent que c'est une bonne idee de retarder encore et encore le pageload quand c'est un des plus gros poblemes des sites mobiles?
Dans le monde mobile, c'est surtout en train de perdre beaucoup de traction face a des sdk matures, flexibles, performants et qui ont au final une productivite bien superieure.
Clair que developer pour un framework ou un bouton est un fait un lien hypertexte qui ne pointe nullepart et a qui on a attache une gros kludge (onclick), ca fait rever.
De meme se taper le dom et ses perfs pourries, batailler contre css pour avoir deux divs cote a cote sans que ca pete des que t'eternues, ca donne super envie.
Bollocks. Ou plutot, c'etait vrai en 2006, mais le monde a change un tantinet depuis, et maintenant c'est bollocks.
Tu fais une appli desktop, une telephone et une tablette.
La tendance responsive design n'est qu'un enrobage elegant, de la meme maniere qu'objc, les nibs et les fat binaries d'ios sont un enrobage elegant de plusieurs applis en une.
Ca ne te dispense pas de faire un bon design 3 fois, ni de penser tes api/usage de resources en fonction de la plateforme. Entre un telephone a usage extremement court et repete et un desktop, ya un monde niveau design.
2) ou utiliser l'appstore. Parait que ca fait un malheur sous ios, mais c'est des on dit. Le mac appstore est pas en reste cela dit.
3) encourager, c'est facile a faire. Forcer, c'est pas trop possible, et faut vivre avec.
Oui, c'est chiant, mais c'est la nature du mode distribution qui veut ca. Et la barriere psychologique au changement, qui fait que les gens n'aiment pas le changement.
Par défaut, et ca se désactive du coup.
Mais sion, oui, 4 doigt vers le haut pour le task tray, et fermer la main a 5 doigt pour revenir au springboard.
Ios propose un mode "locke".
Tu combines ca a une housse en dur, verouillee, qui empeche l'acces au bouton home et ton ipad est en pratique blocke a vie.
C'est ce qu'on fait au taff pour reserver les salles de meeting, avec un ipad visse au mur.
50 ingenieurs a l'etage, dont un certain nombre taquin, et personne a encore reussi a installer angry birds.
Les gens sortent leur telephone 150 fois de leur poche par jour, en moyenne.
Si la montre permet de descendre ce nombre a 75 ou 50 en affichant les titres/apercu des mails, les alertes calendriers et le calendrier de la journee, c'est une avancee.
Cela dit, vu le creneau "bijou" de la montre, pour ceux qui en portent, je suisnpas convaincu du succes, mais apres tout, pourquoi pas.
T'es tellement desinforme/partial que je vais meme pas prendre la peine de repondre a ce niveau la.
Amuse toi bien dans ton univers parallele de feature check list et de constructeur de telephones a l'agonie (Sony et HTC, dans le genre boite en train de crever, ils s'imposent).
Puis en soit l'iPhone niveau matériel n'est pratiquement pas au niveau de ses rivaux depuis 2 ans. Sa force réside dans le fait que c'est un logiciel unique (et qui est cette fois à la hauteru de la concurrence sur de nombreux points).
Ben voyons.
C'est sur qu'un s3 a plus de ram et de CPU, avec toutes les applis qui tournent sur un concurrent GC, t'as interet a charger la mule niveau hardware si tu veux des performances a moities decentes.
Ensuite on peut parler de choses comme la qualite de l'ecran (avec les AMOLED au rendu de couleur excecrable, par design), la reduction de bruit ambiant qui est tout bonnement halluciante sur un iphone 5, ou t'es globalement incapable de dire si la personne est dans un environment bruyant ou pas, la qualite de finition, duree de vie de la batterie et tout ce genre de petits détails.
C'est sur que si tu t'arretes a la frequence/nombre de coeurs du CPU et la quantite de ram, l'iphone est loin derriere. Mais grande nouvelle, c'est pas le monde du pc. Il n'y pas qu'un seul fabriquant de cpu et toutes ces machines ne sont pas equivalentes.
Pas d'expérience dans le client lourd mais ca doit pas être plus méchant.
Ca depend. Sur un telephone, ou tu bosses tres dur pour designer un truc (en anglais evidemment) ou le principal est "above the fold" et que tu te retrouves avec des lignes qui wrappent tout d'un coup, ca devient problematique. Tu peux jouer sur les tournures de phrases etc. mais c'est loin d'etre evident.
Et apres, tu te retrouves au japon, et ta localisation veut dire ajouter deux colonnes a ta table User pour les noms phonetiques, et un changement d'api REST, et ta recherche "free form text" implique un changement au coeur de l'indexeur pour matcher a la fois le katakana et l'hiragana (desole si j'ecorche les noms, tout ca est encore nouveau pour moi).
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à -5.
Ces deux phrases a elles seules resument ton ignorance crasse du "appli smarpthone grand public".
1) Personne ne te donnera jamais le moindre feedback sur ce genre de trucs, principalement parce qu'un bon design ne se remarque pas, a moins d'y faire tres attention et d'avoir des affinites avec la discipline. Par contre, quand tu mesure l'écart en A/B test, tu la voit la difference (et pas qu'un peu, on a un peu double la conversion depuis qu'on a commence a faire le choses decemment chez nous, et ya encore beaucoup de taff). Sinon j'ai envie de dire "mais je croyais que c'etait supporte depuis un an et demi que c'etait de la balle ya 30 minutes, et maintenant, tout d'un coup, ca devient completement inutile et superflu, une fois que tu te rends compte que c'est pas supporte"? Si c'est pas en ligne avec ce que je disais ailleurs, ou le HTML5 te limite fortement dans ce que tu peux faire, et que ses partisans acceptent ces limitations avec fatalité (autrement connu sous le nom de "j'suis trop flemmard pour faire mon taff correctemt eud'facons").
2) Cf 1. Ca rejoint ce que je disais, t'as des gouts de chiotte, et par du principe que le design visuel est de la connerie qui ne sert a rien. Ceux qui s'y sont essaye pour de vrai ont un autre avis.
Sur ca, j'arrete pour de bon. On vit sur differentes planetes toi et moi - visiblement ce qui compte le plus pour toi c'est que les developeurs en aient le moins a faire et torchent leur produit vite fait mal fait, et shipper est tout ce qui compte, meme si tu livres de la merde. Perso je shipe pas la merde, avec l'equipe on s'engueule toute la journee au sujet du meilleur design (mais le soir on va boire un godet ensemble).
Et au final, on met la tannee a l'equipe mobile web (meme avec les problematiques de deploiment et une semaine dans la vue en review sur le store), parce qu'on a un tooling et un framework de qualite. Et niveau conversion, on est tellement loin devant que c'est meme plus drôle.
On coute moins cher, pour un produit de meilleur qualite qui rapporte plus. Alors ton write once, kind of run everywhere but not really, hein…
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à -6.
Ben visiblement t'as toujours pas compris quel est le coeur du problème - DOM et le manque de reactivite globale.
La vitesse est pas si importante, ce qui compte le plus c'est la latence, et HTML5/JS est un desastre a ce niveau la. D'autres trucs rentrent en compte, notamment les outils de debugging, mais ca c'est des trucs cote developeurs. HTML5/js n'est tout simplement pas capable a l'air actuelle de repondre au premier besoin de base - a savoir un truc qui est "snappy" et qui reagit sur le champ. Meme sur desktop, c'est border line, avec les monstres qu'on a de nos jours.
Ben voyons. En appliquant l'effet au background qui defile derriere? a 60FPS? J'aimerais bien voir ca tiens!
sinon, mes couilles sur ton nez, ca fait un skyblog?
Me traiter d'ignorant quand tu t'habilles visiblement chez Gucci Hot et que t'es pas foutu de voir des failles beantes d'UX, c'est pas de l'agressivité?
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à -10.
T'as tellement pas la moindre idee de ce dont tu parles que ca en devient pitoyable.
T'as perdu toute credibilite avec ton histoire de 30 secondes pour sortir du mode fullscreen - mon petit doigt me dit que t'as jamais vu la feature en question.
Pour ce qui est des transitions, tu dois avoir de la merde dans les yeux je me dit, et j'aimerais bien te voir gerer les rotations de facon fluide avec CSS, histoire de rigoler un bon coup.
Ouaiiiis, bien suuuuur. D'ailleurs, les effets de blurs qu'iOS7 introduits sont super simple a faire en CSS.
J'arrete la discussion a ce niveau - si des applis avec plusieurs dizaines/centaines de ms de reactivite et des animations saccadees (quand t'en as!) te conviennent, et que t'as tellement de la merde dans les yeux que t'es meme pas capable de t'en rendre compte, grand bien t'en fasse.
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 0.
tu confirmes ce que je dit, leur super prototype qui soit disant dechire sa race a l'air peu reactif et a un look de merde. Les rotations/transitions sont vraiments mauvaises (en fait, elles sont inexistantes), et bon courage pour implementer le "flick to exit fullscreen photo" de l'appli FB.
C'est en plein dans ce que je disais dans un autre message: les webeux vivent dans un monde parallele ou les perfs de merde sont une fatalite, et par la meme, acceptables.
Si c'est l'etat de l'art des applis riches html5, ben ca en dit long sur la qualite de la techno.
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 4.
2.65MB pour une appli avec une vue, une page html + js et toutes les librairies linkees?
J'ai le droit de dire que c'est de la triche et qu'il ya de la ram planquee quelque part?
Rien que le binaire fait probablement pas loin de 3MB…
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 0.
Heu, ben ouais, pendant 10 ans c'etait un peu la seule jvm reellement utilisee, donc forcement, mais le temps de chauffe est plus lie au jit qu'autre chose.
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 2.
Ca a pas grand chose a voir avec le fait d'avoir un navigateur charge ou pas.
Safari mobile se demerde admirablement bien, et ca reste super lent et pas reactif par rapport aux applis native, pre charge ou pas.
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 0.
Ou est ce que je dit que dalvik utilise hotspot?
Sinon, pour les perfs:
- tes applis se font tuer regulierement, des que ca manque de ram en fait
- le temps de demarrage d'une appli mobile est critique. Ios te tue apres 5 secondes, je considere perso plus de 750-800ms inacceptable sur mes applis.
Ya plein de techniques diverses et variees pour rendre le chargement plus rapide (qui tournentntoutes autour du lazy loading et du background processing), mais vu l'ordre de grandeur, et sachant que ya pas mal a faire entre le debut du main et la premiere run loop utilisable, ca laisse pas des masses de marge de manoeuvre.
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 9.
Non, clairement pas raisonnable du tout. Les webeux vivent dans un monde parallele ou les perfs de chiottes sont acceptables, sortez votre tete du sable - une webview se remarque a des kilometres, ca met un temps fou a charger et a reagir.
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 4.
Ouais, alors, ca, ca se discute.
Si tu veux faire un simple hello world, je veux bien te croire.
Si tu veux faire un truc un tant soit peu pas trivial, rapide, robuste (comprendre maintenable dans le temps), qui soit pas un monstre memoire ou qui ne mette pas un CPU haut de gamme a genoux, j'ai comme qui dirait de gros doute. Rien qu'a voir le temps que ca a prit aux gars du site mobile pour avoir un flyweight decent sur une table avec 1500 entrées, la ou les applis natives te font ca les doigts dans le nez, je suis sceptique.
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à -2.
Ca depend de quoi tu parles.
Une fois la vm chargee et chauffee, oui, ca va vite.
Mais le temps de chargement + chauffe avoisine la session moyenne d'une appli mobile, et l'overhead memoire de java et de la jvm, gc et tout le tsintsin, c'est pas negligeable.
Rajoute les probleme de gc non deterministe, et quand t'es contraint en memoire, sans swap, c'est loin d'etre un bon choix (et ce malgre tous les efforts que google a pu mettre dna s dalvik).
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 0.
Si j'ai bien suivi, asm.js est base sur une compile aot (sinon, j'ai du mal a voir l'interet).
Yen a vraiment qui pensent que c'est une bonne idee de retarder encore et encore le pageload quand c'est un des plus gros poblemes des sites mobiles?
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 0.
Dans le monde mobile, c'est surtout en train de perdre beaucoup de traction face a des sdk matures, flexibles, performants et qui ont au final une productivite bien superieure.
[^] # Re: ça marchera jamais?
Posté par groumly . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 5.
Clair que developer pour un framework ou un bouton est un fait un lien hypertexte qui ne pointe nullepart et a qui on a attache une gros kludge (onclick), ca fait rever.
De meme se taper le dom et ses perfs pourries, batailler contre css pour avoir deux divs cote a cote sans que ca pete des que t'eternues, ca donne super envie.
[^] # Re: Un choix à faire
Posté par groumly . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 4.
T'as remarque qui sont les commiteurs principaux sur clang/llvm et qui les paye?
[^] # Re: Tout dépends de ce qu'on veut
Posté par groumly . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 0.
Bollocks. Ou plutot, c'etait vrai en 2006, mais le monde a change un tantinet depuis, et maintenant c'est bollocks.
Tu fais une appli desktop, une telephone et une tablette.
La tendance responsive design n'est qu'un enrobage elegant, de la meme maniere qu'objc, les nibs et les fat binaries d'ios sont un enrobage elegant de plusieurs applis en une.
Ca ne te dispense pas de faire un bon design 3 fois, ni de penser tes api/usage de resources en fonction de la plateforme. Entre un telephone a usage extremement court et repete et un desktop, ya un monde niveau design.
[^] # Re: Un choix à faire
Posté par groumly . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 2.
Effectivement, c'est la derniere de clang. Et a partir de LOLcat 10.9, ya meme pu gcc-llvm.
[^] # Re: Un choix à faire
Posté par groumly . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 1.
2) ou utiliser l'appstore. Parait que ca fait un malheur sous ios, mais c'est des on dit. Le mac appstore est pas en reste cela dit.
3) encourager, c'est facile a faire. Forcer, c'est pas trop possible, et faut vivre avec.
Oui, c'est chiant, mais c'est la nature du mode distribution qui veut ca. Et la barriere psychologique au changement, qui fait que les gens n'aiment pas le changement.
[^] # Re: Ça m'a fait pareil
Posté par groumly . En réponse au journal Google, apôtre du HTML5. Évalué à 2.
En fait, non, c'est de plus en plus depuis qq semaines.
Ils sont passe en mode super aggressive sur les pubs.
[^] # Re: Intérêt de la chose
Posté par groumly . En réponse au journal A quand la prochaine secousse sismique dans le monde High-Tech ?. Évalué à 1.
Par défaut, et ca se désactive du coup.
Mais sion, oui, 4 doigt vers le haut pour le task tray, et fermer la main a 5 doigt pour revenir au springboard.
[^] # Re: Intérêt de la chose
Posté par groumly . En réponse au journal A quand la prochaine secousse sismique dans le monde High-Tech ?. Évalué à 0.
Ios propose un mode "locke".
Tu combines ca a une housse en dur, verouillee, qui empeche l'acces au bouton home et ton ipad est en pratique blocke a vie.
C'est ce qu'on fait au taff pour reserver les salles de meeting, avec un ipad visse au mur.
50 ingenieurs a l'etage, dont un certain nombre taquin, et personne a encore reussi a installer angry birds.
[^] # Re: Intérêt de la chose
Posté par groumly . En réponse au journal A quand la prochaine secousse sismique dans le monde High-Tech ?. Évalué à 2.
Les gens sortent leur telephone 150 fois de leur poche par jour, en moyenne.
Si la montre permet de descendre ce nombre a 75 ou 50 en affichant les titres/apercu des mails, les alertes calendriers et le calendrier de la journee, c'est une avancee.
Cela dit, vu le creneau "bijou" de la montre, pour ceux qui en portent, je suisnpas convaincu du succes, mais apres tout, pourquoi pas.
[^] # Re: La suite ?
Posté par groumly . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à -10.
T'es tellement desinforme/partial que je vais meme pas prendre la peine de repondre a ce niveau la.
Amuse toi bien dans ton univers parallele de feature check list et de constructeur de telephones a l'agonie (Sony et HTC, dans le genre boite en train de crever, ils s'imposent).
[^] # Re: La suite ?
Posté par groumly . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à 0.
Ben voyons.
C'est sur qu'un s3 a plus de ram et de CPU, avec toutes les applis qui tournent sur un concurrent GC, t'as interet a charger la mule niveau hardware si tu veux des performances a moities decentes.
Ensuite on peut parler de choses comme la qualite de l'ecran (avec les AMOLED au rendu de couleur excecrable, par design), la reduction de bruit ambiant qui est tout bonnement halluciante sur un iphone 5, ou t'es globalement incapable de dire si la personne est dans un environment bruyant ou pas, la qualite de finition, duree de vie de la batterie et tout ce genre de petits détails.
C'est sur que si tu t'arretes a la frequence/nombre de coeurs du CPU et la quantite de ram, l'iphone est loin derriere. Mais grande nouvelle, c'est pas le monde du pc. Il n'y pas qu'un seul fabriquant de cpu et toutes ces machines ne sont pas equivalentes.
[^] # Re: Axiomatique différente = IHM différente
Posté par groumly . En réponse au journal i18n: la langue la plus concise est le chinois. Évalué à 3.
Ca depend. Sur un telephone, ou tu bosses tres dur pour designer un truc (en anglais evidemment) ou le principal est "above the fold" et que tu te retrouves avec des lignes qui wrappent tout d'un coup, ca devient problematique. Tu peux jouer sur les tournures de phrases etc. mais c'est loin d'etre evident.
Et apres, tu te retrouves au japon, et ta localisation veut dire ajouter deux colonnes a ta table User pour les noms phonetiques, et un changement d'api REST, et ta recherche "free form text" implique un changement au coeur de l'indexeur pour matcher a la fois le katakana et l'hiragana (desole si j'ecorche les noms, tout ca est encore nouveau pour moi).