Mobile App pour BSU. Professeur. Rédacteur. Prof. Stefan Hüsemann Université de Fribourg, Suisse Département d informatique. Travail de séminaire

Transcription

1 Prof. Stefan Hüsemann Université de Fribourg, Suisse Département d informatique Travail de séminaire Mobile App pour BSU Professeur Stefan Hüsemann Rédacteur Diego Meschini Route des Vieux-Chênes Fribourg diego.meschini@unifr.ch

2 Table des matières Abstract... 3 Introduction Différents approches pour le développement d applications mobiles Application Native API APIs de bas niveau APIs de haut niveau L interface utilisateur graphique (GUI) Application Web Application Hybride Comparaison Fonctionnalité nécessaires pour BSU Création d un prototype de l application pour BSU Outils et processus pour le développement Résultat du travail Forces, Faiblesses et Futures améliorations Marketplace Analyse des marchés principaux Google Play Store App Store Diffusion de l application BSU Conclusions Bibliografia... 26

3 Abstract Dans ce travail on va chercher de comprendre un univers tous neuf et qu il continu à évoluer : celui des applications mobile. Les thèmes seront traités de manière non-technique dans le but de fournir une explication compréhensible pour ces qui veulent entrer dans ce monde qui attrait toujours plus. Nous nous arrêterons au développement d un prototype statique en expliquant en terme théorique de base le déroulement pour arriver jusqu au là.

4 Introduction Dans le but de faire ce travail de séminaire, on doit se poser la question : «Quelle pourrait être l innovation la plus intéressante pour BSU (Börsenspiel der Schweizer Universitäten)?». En regardant ce qu il y a déjà on peut conclure que la réponse est qu il manque une application mobile pour permettre aux joueurs de se connecter partout avec ses propres Smartphones et contrôler leur portefeuille d actions. Aujourd hui les applications offrent la possibilité de élargir le public cible car presque tout-lemonde a accès à un Marketplace et tous cherchent de trouver l application la plus attractive, la plus utile, la plus efficace. Par syllogisme nous arrivons donc à la conclusion que : «Si l application est sur un Marketplace et si elle est efficace, alors l utilisateur sera content de l avoir». Ce qui est intéressant, c est qu aujourd hui les personnes préfèrent utiliser le Smartphone à la place de l ordinateur pour faire certaines choses, comme par exemple lire les s. La réponse à la question «pourquoi le public préfère le Smartphone?» existe toujours ; parce qu il offre une qualité que l ordinateur ne peut pas offrir : l accessibilité immédiate partout. Cette caractéristique permet de fidéliser encore plus l utilisateur. Exemple : Un utilisateur télécharge l application d un journal quotidien sur son Smartphone, cette application lui donne des satisfactions car il a toujours accès à une grande quantité de nouvelles intéressantes ; le résultat sera qu il continuera à utiliser cette application. Si nous insérons cet exemple dans un cadre ou il y a une multitude d acteurs, nous pouvons noter que cet effet de fidélisation est encore plus fort car les préférences de l individu sont influencées par la société : si tout-le-monde a une certaine application il faut l avoir (ex. : Facebook, Twitter, Spotify, Youtube, Instagram, etc.). Dans ce contexte il faut toujours préciser qu il y a des applications faites pour partager (Facebook) et des autres faites pour être partagées (par exemple les jeux qui permettent de confronter les classements, etc.). Le lien entre ces deux types d application est très fort, et le succès d une application mobile est beaucoup influencé par la possibilité de partager le contenu. Dans notre contexte nous essayons de créer donc le prototype d une application mobile avec comme caractéristiques une bonne accessibilité, des fonctionnalités utiles, une interface intuitive et avec des contenus qui peuvent être. La première partie du travail expliquera les principales différences entre les types d application (native, hybride, web), les avantages et les désavantages, ainsi les principales fonctionnalités nécessaires pour BSU. La deuxième partie mettra en évidence les outils qu un développeur a à disposition et comment un prototype est conçu. Enfin on passera à une analyse des Marketplace pour fermer le cercle.

5 1. Différents approches pour le développement d applications mobiles 1. Différents approches pour le développement d applications mobiles Comme on a vu dans l introduction ici on va aborder les différentes méthodes pour la programmation d une application mobile. Ces types de développement ont des propriétés différentes et si on décide de développer une application il faut bien choisir dans quelle direction on veut aller. Il faut le choix principalement sur les fonctionnalités qu on veut implémenter, les coûts qu on peut soutenir (soit en termes d argent, soit en termes de temps) et surtout sur le niveau des connaissances d informatique. Si on prend par exemple la Figure 1 on peut voir comment les trois approches permettent une interaction différente avec le Smartphone. Figure 1 Schéma des différents types d'approche (IBM 2012) 1.1 Application Native Les applications natives ont des fichiers exécutables binaires qui sont téléchargés directement sur le dispositif et stocké localement. Une application native peut être téléchargée depuis un Marketplace comme Play Store pour Android, App Store pour Apple et App World pour BlackBerry, mais ils existent aussi des méthodes fournis par les différents vendeurs. Après avoir installé l application sur le dispositif, elle sera lancé comme tous les autres services fournis par ceci et l application native aura accès à toutes les fonctionnalités, sans besoin d un intermédiaire ou d un container. Une application native sera libre d accéder à tous les APIs (décrit dessous) que sont mis à disposition par le vendeur de l OS (operating system). Pour créer une application native, les développeurs doivent écrire le code source et toutes les ressources supplémentaires comme les images, les segments audio et les différentes déclarations spécifiques des OS. Les outils 5

6 1. Différents approches pour le développement d applications mobiles fournis par le vendeur de l OS sont parfois lié aux codes et le tout est mis sous forme binaire pour permettre d être exécuté, ensuite ce paquet est prêt pour la distribution. Les outils, avec autres ressources 1 et les dossiers, forment le kit de développement logiciel (SDK) de l OS. Le processus de développement est souvent semblable pour les différents OS, mais les SDK sont toujours spécifiques à son propre OS. La Table 1 présente les différents outils, les langues, les formats et les Marketplace, associés aux principaux OS mobiles. Table 1 Comparaison des différents OS (IBM 2012) La différence entre plates-formes est l inconvénient le plus critiqué de l approche de développement natif des OS, car évidemment un SDK pour un OS ne peut pas être utilisé par un autre et ça rend le développement et la maintenance des applications natives (dans le cas il faut gérer plusieurs mobile OS) très longue et coûteuse. Si on veut développer de façon native, il faut être conscient qu il n y a pas un soutien multiplateforme ; les entreprises rêvent la possibilité d obtenir un accès complète à tous les OS avec une petite dépense, mais malheureusement ça n existe pas encore. Cependant si on prend l exemple d une entreprise qui décide de standardiser son système interne avec un OS spécifique, elle n aura presque aucun problème pour ce que concerne la compatibilité des applications avec l OS car il y en a que un. Même s il y a des nombreux problèmes de coûts et de développement multiplateforme, pour certaine chose on ne peut pas renoncer au développement natif. Si on prend par exemple l application «Viber 2», né pour l OS de Apple et ensuite devenue multiplateforme, elle utilise principalement la technologie VoIP 3 et l accès à la rubrique de l utilisateur, on se rend compte qu évidemment il faut utiliser un langage natif car le langage web n est pas encore si évolue. Un autre exemple lié à l impossibilité de renoncer au développement natif est le jeu «Angry Birds», lequel a la nécessité d accéder aux APIs de l écran tactile et des hautparleurs, en plus elle a une UI (Interface Utilisateur) très riche que ne peut pas être conçu avec un langage web actuel. 1 Normalement autres outils pour la programmation, mais pas spécifiquement liés au OS comme par exemple Java. 2 L application Viber permet de faire des appels et d envoyer des messages. 3 La technologie VoIP (Voice over IP) permet de faire des appels et vidéo-appels en utilisant internet ou toutes sortes de connections. Un autre exemple d application qu utilise VoIP est Skype. 6

7 1. Différents approches pour le développement d applications mobiles API Une fois que l application native est lancée sur le dispositif mobile, elle interagit avec l OS à travers l interface de programmation d application (API) que ceci a implémenté. Ils existent deux groupes d API : les APIs de bas niveau et les APIs de haut niveau APIs de bas niveau Les API de bas niveau permettent è l application de interagir avec par exemple l écran tactile ou le clavier, les réseaux internet, le microphone, le haut-parleur ou les écouteurs, l application pourra aussi utiliser la camera pour photo et vidéo et grâce au accès au GPS recevoir information pour l orientation. De plus elle pourra lire et écrire sur le disque dur et elle aura accès aux hardwares disponibles aujourd hui et dans la future APIs de haut niveau Les APIs de haut niveau permettent l accès aux services de haut niveau de l OS comme par exemple la navigation sur le web, la gestion de l agenda, les contacts, les photos et les vidéos faites avec le dispositif et surtout la possibilité de faire des appels téléphoniques et envoyer des messages. La plupart des OS mobile fournissent un ensemble d applications intégrées qui permettent d utiliser ces fonctionnalité, mais ils rendent aussi disponible l accès aux APIs pour les applications natives que l utilisateur peut télécharger. Ils existent aussi autres type d APIs, qui permettent de télécharger autres application mis à disposition par le vendeur de l OS comme par exemple les push notification 4 où les in-app purchase 5. 4 Application que, même si inactive, grâce aux APIs peut envoyer des notifications au dispositif, ensuite l utilisateur pourra avoir plus d information en ouvrant l application. 5 Application gratuite qui incite l utilisateur à verser des petites sommes d argent pour améliorer l expérience d utilisation comme par exemple certains jeux. 7

8 1. Différents approches pour le développement d applications mobiles L interface utilisateur graphique (GUI) Un autre important ensemble d APIs, sont les interfaces mises à disposition par les OS mobiles, avec ses propres composants, tels que les boutons, les curseurs, les menus, les boîtes de dialogue, et ainsi de suite. Les applications qui font usage de ces composants héritent des caractéristiques et des fonctions propres de l OS, qui rendent l interface standard et facile à utiliser. Cependant chaque OS a sa propre UI (Figure 2, Figure 3) laquelle est unique par ses composants et ses fonctionnalités et donc, pour les applications qui sont conçues pour rouler sur plusieurs OS il faut toujours que le concepteur connaît les différents OS et les respectives UIs. Tout ça ajoute de la complexité au travail et les coûts de développement se multiplient, mais celle-ci est la seule manière d obtenir des applications natives qui puissent utiliser au cent pour cent les nombreuses fonctionnalités que les dispositifs peuvent offrir. Figure 2 UI Android (nngroup 2014) Figure 3 UI Apple (nngroup 2014) 8

9 1.2 Application Web 1. Différents approches pour le développement d applications mobiles Les dispositifs mobiles modernes ont la possibilité d utiliser des browsers puissants qui supportent toutes les nouvelles fonctionnalités données par HTML5, CSS3 et JavaScript. Aujourd hui grâce à HTML5 nous sommes passés d une langue pour créer des sites internet statiques à une formule pour obtenir, à l aide d un navigateur, des applications riches de contenues comme par exemple des composante des UIs, services de géolocalisation et de navigateur, et ainsi de suite. En utilisant ces outils, les développeurs peuvent créer des applications en n utilisant rien d autre que les technologies web. Il faut distinguer entre deux types d applications web. D une côte on a les sites web optimisés pour la navigation avec un mobile (responsive web design), lesquels ont été conçu pour adapter le contenu de la page à la grandeur de l écran du dispositif pour une navigation plus confortable (On peut voir la différence entre la Figure 4 et la Figure 5). Figure 4 Site pas optimisé (nngroup 2014) Figure 65 Site optimisé (nngroup 2014) De l autre on a des véritables applications mobiles web qui ressemblent à des applications natives et qui peuvent être lancées comme ces dernières à travers un raccourci. Les applications web sont une tendance très prometteuse car elles permettent au développeur de créer des UI en apparence native, basées sur un code JavaScript6, ces applications s exécutent entièrement avec le navigateur du dispositif mobile en utilisant les fonctionnalités disponibles 6 Il y a un nombre croissant d outils créés pour construire des UI comme dojox.mobile, Sencha Touch et jquery Mobile. 9

10 1. Différents approches pour le développement d applications mobiles sur ceci. L existence d une grande communauté de support pour le développeur permet d obtenir des résultats de façon plus vite et à coûts moins élevés, mais toutefois, malgré le potentiel, ils restent encore des limites pour les applications Web. Au contraire des applications natives, qui sont exécutables de façon indépendante depuis l interface de l OS et ont à disposition toutes les fonctionnalités du dispositif, les applications web ont besoin du navigateur, lequel est une application native qui a accès à l API de l OS qui permet la navigation. Une application web a accès aux APIs de façon très limité pour non dire nulle et donc, elle ne peut pas utiliser toutes les fonctionnalités disponibles. Le choix de l application web peut être supporté du fait que on veut distribuer l application sans se soumettre aux standards dictés par les Store, lesquels oblige presque chaque fois à un longue processus d approbation ; en plus il y a la possibilité d avoir plus de visibilité car l application sera présente dans les résultats des moteur de recherche, lesquels donnent plus de visibilité par rapport aux marché des différents OS. Une application web peut être aussi utilisé comme prototype dans le but de développer une application, on peut cet application pilote pour voir si elle est convaincante et rentable et une fois testée on pourra réutiliser les codes dans une application hybride ou créer une nouvelle application. 1.3 Application Hybride Une application hybride, comme dit le terme, combine le développement natif avec la technologie web. Dans cette formule, le développeur écrit l application avec un format web, mais il maintient un accès direct avec les APIs. La partie native de l application permet de créer un pont 7 entre le browser et les APIs du dispositif, ce pont permet donc à l application hybride de profiter de toutes les fonctionnalités qu on a à disposition dans le dispositif. La partie native peut être développée de façon indépendant, toutefois elle peut être déjà fournie par le marché sous forme de container qui fais le lien avec les APIs, dans ce cas le développer pourra créer une application avancée en utilisant seulement des langages du web. La partie web de l application peut être une page web qui est sur un serveur ou un paquet de codes HTML, CSS et JavaScript que se trouve stockée localement sur le dispositif. Ces deux approches ont des avantages et des limites. Si le code HTML se trouve sur un serveur, le développeur pourra introduire des mises à jour de l application sans passer par l approbation des marchés d application, en faisant ça il faut que le dispositif soit connecté à un network pour faire l actualisation. Si au contraire le code est stocké sur un dispositif, on aura des performances et une accessibilité meilleures, mais on ne pourra pas bénéficier de l update 7 Ce pont est appelé HTML rendering engine, fait la liaison entre la partie native et les APIs, il traduit les code en HTML pour permettre aux requêtes d être comprises des deux côtes. 10

11 1. Différents approches pour le développement d applications mobiles sans accès au web. Donc la meilleure chose est celle de mélanger les choses en utilisant un serveur pour augmenter la flexibilité et en stockant le code dans le dispositif pour augmenter la performance. En utilisant l approche hybride on peut profiter des qualités des autre deux approches : du côté de la native on peut profiter des APIs grâce au pont qui nous permet d accéder aux fonctionnalités et du côté web on peut partager le code avec autre plateformes mobiles et ça rend les processus de maintenance moins coûteux et plus vits. 11

12 1.4 Comparaison 1. Différents approches pour le développement d applications mobiles Aujourd hui les entreprises sont confrontées avec beaucoup de contraintes dans le but de créer une application : avoir une application qui donne un bon feedback, les coûts de développement, le temps, la possibilité de mis à jour, le contrôle de la diffusion, et ainsi de suite. Tous ces problèmes peuvent être résolus si l entreprise choisira la bonne façon de développer son application sur la base de ces nécessitées, on a vu que les différent approche ont différents qualités et défauts (Table 2). Les applications natives ont une bonne performance et un accès complète au dispositif, mais les coûts de développement risquent d être très hauts à cause de la complexité de l application et du porting 8, de plus les possibilités de mise à jour sont réduites. Les applications web de l autre côté ont des coûts de développement bas et une facilité dans la mise à jour, mais elles n ont pas les mêmes potentialités d accès au dispositif et par conséquence l expérience de l utilisation ne ressentira. Enfin il y a les applications hybrides, lesquelles offrent beaucoup de possibilités surtout si on veut travailler avec plusieurs OS, car même s il faudra calculer des coûts de porting, ces derniers seront plus bas par rapport à ces des applications natives, toutefois l approche hybride n a comme-même pas toutes les solutions. Table 2 Comparaison des forces et des faiblesses des différents approches. (IBM 2012) 8 Processus pour lequel une application écrite pour une certaine plateforme vienne modifiée ou réécrite pour une autre plateforme. 12

13 1. Différents approches pour le développement d applications mobiles 1.5 Fonctionnalité nécessaires pour BSU Après avoir vu les forces et les faiblesses des différents approches il faut prendre une décision pour ce que concerne la réalisation de l application mobile pour BSU. BSU a déjà un site Web qui s adapte aux écrans des dispositifs grâce au travail de responsive web design qui a été effectué, mais on aimerait rajouter des fonctionnalités pour avoir une application qui ne soit pas seulement une application Web: pouvoir participer au jeu sans problèmes (achat, vente, contrôle du portefeuille, etc.), partager les résultats sur les réseaux sociaux et faire si que l application puisse envoyer des notifications au dispositif. Dans ce cas on n a pas des connaissances pour ce que concerne la programmation en Java et C++, donc la voie de l approche native est déjà fermée. On connait HTML5, CSS3 et un peu de JS, on a déjà une application Web et on aimerait ajouter aussi des fonctionnalités pour lesquelles il faut avoir accès aux APIs comme par exemple les notifications sans que l application soit lancée et donc la solution se trouve dans l application hybride. 13

14 2. Création d un prototype de l application pour BSU 2. Création d un prototype de l application pour BSU Dans cette partie on commencera avec la partie de programmation du prototype, il faut dire que la solution qui est proposé ici dessous n est pas une solution unique pour la programmation d un prototype et que chaque développeur a ces préférences en matière. Dans beaucoup de cas une restriction dans la phase de développement est due au fait que on n a pas la possibilité de développer une application pour plusieurs OS. Dans le choix de l outil il faut tester plusieurs outils et le choix final est subjectif. 2.1 Outils et processus pour le développement Avant de commencer avec le développement nous allons choisir les outils nécessaires. Ils existent plein de façon pour la création d une application et il faut analyser chaque méthode en le rapportant avec ce qu on a besoin. La recherche faite par l organisation Gartner (Figure 6) est un très bon point de départ pour faire cet important choix. Il faut vraiment une bonne analyse sur la base de ce qu on veut faire, car si on choisit les mauvais outils on risque de ne pas réussir à partir avec le projet, ou pire d arriver à un certain point et s arrêter. Figure 6 Magic Quadrant for Mobile Application Development Platforms (Gartner 2013) 14

15 2. Création d un prototype de l application pour BSU L organisation Gartner, avec ce travail de recherche, mets en évidence les entreprises qui obtiennent les meilleures résultats dans le développement des application mobile, pour chaque entreprise, il montre les forces et les faiblesses des outils de travail mis à disposition et ça permet d avoir une vision d ensemble et de choisir ce qu on a besoin. Pour résumer notre cas : nous avons besoin d une application avec un certain nombre de fonctionnalités (hybride), nous avons des connaissances dans le domaine de HTML, CSS3 et JS, il faut que l outil soit gratuit ou à un prix bas et le tout avec la possibilité d opérer sur différents OS. Sur la base de ces critères le Magic Quadrant nous offre une bonne possibilité de choix entre différentes entreprises. Entre tous nous allons choisir l outil mis à disposition par Abdobe, c est à dire : PhoneGap/Cordova PhoneGap nous permet de faire tous ce qu on a besoin, il peut être téléchargé de façon gratuite, pour l installation il y a plein de tutorial sur Youtube et il y a une bonne communauté de support. PhoneGap met à disposition l accès aux APIs des différents OS et il nous permet donc de développer une application avec HTML sans avoir besoin de se préoccuper du lien entre l App et les APIs, de plus on peut choisir entre plusieurs émulateurs pour faire tourner l application. Un autre outil indispensable dans notre cas est l Android SDK (Ch.1.1), laquelle est aussi facile à télécharger ( et installer. Dans cette SDK on trouve Eclipse, l outil qu on utilisera pour la programmation mais il faut aussi télécharger l extension Eclipse Helios ( pour avoir un cadre complet et fonctionnel. Pour compléter le cadre des connaissances, avant de commencer à développer, il est utile de faire un tour sur Youtube (par exemple Mindfire Solution, WorklightInc et parakaew sont des canals sur Youtubes qui offrent des tutorial très iteressants ils ne sont pas les seuls-) et sur certains blog et sites internet comme «EvoluzioniWeb», «w3schools» où «Nielsen Norman Group» relatifs aux applications et à la programmation en générale pour apprendre comment faire certains pas. Même si on n arrive pas à faire certaines choses, la communauté du web est très ouverte et la plupart des fois la réponse à nos problèmes est déjà sur internet. 15

16 2.2 Résultat du travail 2. Création d un prototype de l application pour BSU Nous allons utiliser une machine virtuelle Android pour tester notre application. Dans la Figure 8 et la Figure 9 on voit la présentation du dispositif, avec tous les buttons pour naviguer exactement comme dans la réalité. L émulateur que nous utilisons a un écran de 480x800, une CPU ARM (armeabi-v7a, faite pour les émulateurs) et une mémoire RAM dédiée de 512 Mb. Un émulateur plus puissant de celui-ci risque de rendre lent le lancement de celui-ci pour voir les résultats de la programmation sur l ordinateur. Figure 7 Device Control Android Figure 8 Dispositif Android Comme on a dit avant notre application doit permettre aux utilisateurs d accéder avec ses propres donnés du login, et cet écran lui permettra de le faire. La couleur des buttons est la même de celle du logo de BSU, comme ça on va donner un sens d homogénéité à l application. Même si c est seulement un prototype il est importante de bien structurer le design de l application, car ça permettra d avoir une idée bien précise de ce qu ira ressembler cette dernière. Figure 9 Écran login 16

17 2. Création d un prototype de l application pour BSU La Figure 10 nous montre le menu principal de l application, depuis lequel on pourra accéder à notre portefeuille, aux marchés, à la classification. Les trois butons n occupent pas tout l écran, donc il y aura de la place pour une éventuelle publicité. Figure 10 Écran du menu La Figure 11 nous montre un portefeuille avec trois actions dont on peut voir le nom, la variation, le prix actuel et la quantité d action achetée par le joueur. À droite il a un bouton qui permet de vendre les action dans un nouvel écran (Figure 12). Dans l application, à la place de [User Name] il y aura le nom de celui qui a fait le login (Figure 9) Figure 11 Écran du portefeuille 17

18 2. Création d un prototype de l application pour BSU Comme on a déjà parlé dessus, ceci est l écran ou le joueur pourra vendre ces action, le layout de cette page n est pas agréable et en ligne comme le reste du prototype, mais l objectif est ce de chercher de comprendre si on veut une fenêtre d alerte pour la vente des action comme par exemple la Figure 17 ou on cherche plutôt un autre façon comme par exemple celle proposé dans la Figure 12 et la Figure 15. Figure 12 Écran pour la vente des actions Dans la Figure 13 on voit le menu des marchés sur lesquels on pourra travailler pendant le jeu, le layout est le même de ce de la Figure 10 et les fonctionnalités sont aussi les mêmes, cet a dire de permettre d accéder de façon rationnelle aux fonctionnalités de l application. Figure 13 Écran marchés 18

19 2. Création d un prototype de l application pour BSU Dans la Figure 14 on a les premiers titres du marché SMI, dont on peut voir le nom, la variation, la valeur de l action et sur la droite de l écran on a un bouton pour acheter l action que nous intéresse. Dans ce prototype les données sont statiques et ils ont été écrits à la main, dans l application il faudra écrire une fonction avec JS, reliée à la base de données que BSU utilise pour savoir le cours des actions, qui permettra d avoir ces lignes. Figure 14 Écran Swiss Market Index (SMI) Pour la Figure 15, qui nous montre l écran pour l achat des actions, on peut faire le même discours de la Figure 12. Figure 15 Écran pour l'achat des actions 19

20 2. Création d un prototype de l application pour BSU Si dans le menu (Figure 10) on clique sur le bouton «Ranking» on arrive à l écran de la Figure 16 que montre la classification. Aussi dans ce cas toutes les données ont été insérées de fa4on manuel et dans l application il faudra créer une fonction avec JS qui permettra d avoir une classification à jour chaque fois qu on la regarde. Figure 16 Écran de la classification Si on clique sur le boutons «My Rank» (Figure 16) on ouvre une fenêtre d alerte (Figure 17) que, à dépendance de qui a effectué le login (Figure 9), montre le nom utilisateur, son classement et le capital total du joueur en question. Cette fenêtre d alerte permet sois de voir de façon très vite le propre classement sois, si on ajoute le plugin approprié, peut aussi devenir un moyen pour partager les résultats obtenues sur Facebook. Figure 17 Écran de la fenêtre d'avis pour la classification personnelle 20

21 2. Création d un prototype de l application pour BSU 2.3 Forces, Faiblesses et Futures améliorations Sur la base des choix faites pour développer une application en termes de type d application et d outils, on peut évaluer les forces et les faiblesses de celle-ci (Table 3). Même si on fait un prototype et pas une vraie application, il faut faire une évaluation du résultat. On peut d abord résumer les fonctionnalités qu on avait intention d implémenter, voir si on a respecté tout et enfin penser à quelques améliorations. Table 3 Évaluation de l'application Coûts : Les coûts sont sans doute un point de force de cette application par rapport aux applications natives, car une fois qu'elle sera terminée il faudra juste payer les frais des différents Marketplace et des frais de porting, mais celles-ci seront beaucoup moins importantes par rapport au porting d une application hybride.. Développement : pour le développement de l application, vu qu on a utilisé l approche hybride, il n y aura pas des gros problèmes, on pourra utiliser HTML et JS, lesquels sont beaucoup plus faciles à apprendre par rapport à JAVA. Porting : ce point est une faiblesse de cette application, car elle a été conçue comme application Android et pour la mettre sur Apple Store il faudra la développer en utilisant une ios SDK. Maintenance : Pour ce que concerne la maintenance il faut attendre la vraie application. En tous cas il faudra faire de la maintenance soit pour le site, soit pour l application, donc on peut la considérer comme étant une faiblesse due au double travail. Une chose n influence pas l autre directement, mais vu qu elles traitent le même sujet (le jeu BSU), s il y a un changement, par exemple l ajout d une fonctionnalité, il faudra faire un upgrade soit pour le site internet, soit pour l application. Tandis qu avec le «responsive web design» ce problème ne persiste pas. Accès aux APIs : vu que l application sera hybride, l accès aux APIs est garanti et on pourra ajouter des fonctionnalités basée sur les capacités des Smartphones. 21

22 2. Création d un prototype de l application pour BSU Interface : L interface est conçue de façon intuitive et on peut naviguer dans l application sans problèmes. Layout : Le design de l application est un point subjectif, la couleur, la grandeur des buttons, la visualisation des donnés, sont des choses qui nécessitent d une analyse basé sur une enquête, mais dans notre cas on cherche un design standard et en ligne avec les couleurs de BSU et permet à l utilisateur de jouer sans devoir apprendre à utiliser l application. Possibilité de partagé : ce point est certainement une amélioration qu il faudra faire, car comme on a dit dans l introduction, la possibilité de partagé permet d atteindre un grand nombre de personnes. Notifications : celle-ci est une autre fonctionnalité qu il faudra ajouté (elle n est pas indispensable), pour permettre aux joueurs de rester à jour. Expérience de jeu : pour établir si l expérience de jeu est agréable il faudra attendre la vraie application et les feedback des utilisateurs. 22

23 3 Marketplace 3. Marketplace Dans ce chapitre on répondra à la question : «quels sont les avantages d un Marketplace par rapport à un autre?» Ils existent plusieurs Marketplace, dont les principaux sont ce d Android et ce de Apple. Il y en a un troisième en forte croissance, Windows Store, mais il est encore plutôt «petit» par rapport aux principaux. 3.1 Analyse des marchés principaux Google Play Store Né le 28 octobre 2008 comme marché d application pour la plateforme Android à la place d Android Market il a évolué très rapidement en ajoutant chaque mois des nouvelles. La potentialité la plus grande est celle de pouvoir télécharger sois les applications développées par Android, sois celles créées par Google, sois celles qui viennent d être mises sur le marché par de tiers qui utilisent l Android SDK. Pour charger les applications sur Google Play Store il faut tout simplement payer une taxe d inscription de 20$, si on fait une comparaison de ce donné avec les autre Marketplace, on peut voir comment cette taxe est beaucoup plus basse par rapport aux autres (99$ dans la plupart des cas). Google Play Store est devenue en juillet 2013 le marché d application avec le plus grand nombre d application (1 million) en dépassant Apple Store. Figure 18 Évolution du nombre des applications sur Google Play Store (Wikipédia, 2014) Les dispositifs Android et Google viennent d être vendus avec un programme applicatif nommé «Play Store», lequel permet aux utilisateurs de chercher et télécharger toutes les applications disponibles. Figure 19 Téléchargements Google Play Store (Wikipédia, 2014) 22

24 3. Marketplace App Store App Store est le service mis à disposition pour les dispositifs Apple (iphone, ipod Touch, ipad), il a été ouvert le 10 juillet 2008 et il compte depuis octobre 2013 plus d un million d application. Les applications sont développées exclusivement avec une ios SDK ou Xcode et pour les mettre sur le marché il faut payer une taxe annuelle de 99$. Une faiblesse est certainement le fait que pour développer une application et la charger sur le marché de la plateforme ios il faut utiliser un système MacOS On peut aussi installer une machine virtuelle sur un système qui n est pas ios, mais le résultat n est pas grande chose, car si on n a pas un ordinateur très puissant il aura de la peine à tourner normalement. Figure 20 Évolution du nombre des applications sur Google Play Store (Wikipédia, 2014) Même si le marché Apple est très exclusif, il est comme même considéré comme étant un «Status Symbol» de l environnement des applications et ça a porté App Store à plus de 60 milliards de téléchargement en 5 ans. Figure 21 Téléchargement Google Play Store (Wikipédia, 2014) 23

25 3.2 Diffusion de l application BSU 3. Marketplace La meilleure chose pour avoir un control total sur une application, est comme on a dit, de développer une Web App et de régler la diffusion à travers le site internet. Vu que l application sera probablement développée de façon hybride sans doute les canaux de distribution idéals pour celle-ci seront les Marketplace «Play Store» et «App Store» lesquels offre un public cible beaucoup vaste pour un prix assez convenant. Même s il faut faire le porting pour ios et ça nécessite du temps et engendre des coûts, une grande partie de la population a un iphone, et donc c est un pas nécessaire pour avoir une porte d entrée sur presque la totalité du marché. 24

26 Conclusions On a vu les caractéristiques des différents types d OS, on a développé un prototype et on a vu les données relatives aux principaux marchés d application. Au moment où on prend la décision de créer une application il faut tenir compte de beaucoup de facteurs (temps à disposition, investissement, coûts de maintenance, etc.). Si ces facteurs sont sous-évalués on risque d avoir un mauvais produit et l expérience d utilisation sera mauvaise. Dans notre cas on a développé seulement un prototype en utilisant HTML, CSS et JS, le résultat du travail nous donne seulement une idée de ce que sera la vraie application, mais déjà ça prend beaucoup de temps. En tous cas, malgré la difficulté, en développant un prototype on a la possibilité de toucher et apprendre le déroulement de la création et de la distribution des applications ; avec un peu de pratique en programmation on peut arriver à des résultats en très peu de temps. Le choix de l OS, de la façon de développer (native, hybride, web) et du moyen de distribution, sont basés sur le but (et les moyens) qu on veut rejoindre. Dans le cas de l application pour BSU on a des fonctionnalités précises à implémenter (Ch. 1.6) et l intérêt à une diffusion globale au niveau d OS (Ch. 3.2) ; donc le développement devrait être fait de façon native ou hybride. BSU ne peut pas continuer seulement avec le responsive web design du site : en premier lieu parce qu il est moins efficace d une application (soit hybride soit native) en termes de temps de réponse et de facilité d utilisation. Deuxièmement car si on veut rester concurrentiel dans un domaine comme le jeu de bourse il faut offrir quelque chose de plus par rapport au concurrents et une bonne application est surement un atout en ce senslà. Par exemple l HEC de Lausanne à son propre jeu boursier, mais elle n a pas d applications, si on arrive à montrer que c est plus facile et pratique de jouer avec le smartphone on aurait un avantage concurrentiel en ce sens-là. Clairement il y aura la nécessité, comme on a dit au chapitre 2.3 de l entretien du site et de l application, mais c est un «mal» nécessaire pour assurer la qualité et la performance au fil du temps. 25

27 Bibliografia Abdobe. s.d. (consultato il giorno décembre 12, 2013). Android. s.d. (consultato il giorno décembre 12, 2013). Badiu, Raluca. Mobile: Native Apps, Web Apps, and Hybrid Apps (consultato il giorno octobre 20, 2013). Data, Refsnes. w3school. s.d. (consultato il giorno 2014). Eclipse. s.d. (consultato il giorno décembre 12, 2013). EvoluzioniWeb. App: Native, Ibride o web (consultato il giorno janvier 23, 2013). Ian Finley, Van L. Baker, Ken Parmelee, David Mitchell Smith, Ray Valdes, Gordon Van Huizen. Magic Quadrant for Mobile Application Development Platform. Gartner, IBM. «Native, web or hybrid mobile-app development.» New York, nngroup. s.d. (consultato il giorno janvier 16, 2014). parakaew, songsook. s.d. (consultato il giorno janvier 23, 2014). PhoneGap. s.d. (consultato il giorno janvier 20, 2014). Solution, MindFire. s.d. (consultato il giorno 1 23, 2014).. s.d. (consultato il giorno janvier 23, 2014). Solutions, MindFire. s.d. (consultato il giorno janvier 23, 2014). Wikipedia. s.d. (consultato il giorno janvier 26, 2014).. s.d. (consultato il giorno janvier 26, 2014). WorklightInc. s.d. (consultato il giorno janvier 22, 2014). 26

28 27