Mise en production agile de la V2 d'une application

Pourquoi faire une V2 de son application ?

Refonte UX

Migration technique

Pourquoi mettre en production son application rapidement est crucial ?

Utilisable à chaque étape de la production

Les retours utilisateurs !

Retours maquette ou sur prototype

+ Itérable rapidement

+ Peu coûteux à développer

+ Maquettes indispensables

Retours sur produit

en production

+ Satisfaction de l'équipe technique

+ Parcours complets

+ Utilisation en cas réel

+ Détection des incohérences UX

+ Détection des bugs

From Scratch

Progressive

Situation A (actuelle) ---> Situation A' (améliorée) ---> Situation B (désirée)

Situation A (actuelle) ---> Situation B (désirée)

La Situation A' :

• Se rapproche de B
• Permet de mesurer l'amélioration désirée
• Permet de mettre en production le produit (standards de qualité + valeur conservée pour l'utilisateur)

Migration progressive

Retour d'expérience : Ajouter React dans une application Symfony

Site Medium like pour bloggeur professionels

Doit pouvoir itérer rapidement pour prendre en compte les retours utilisateurs

1/2 journée

ArticleCreation.prototype.changeTab = function(element) {

    if (!element.hasClass('lock') && !element.hasClass('on'))
    {

        if (element.hasClass('third'))
        {
            element.off();
            window.open(
              element.find('a').attr('href'),
              '_blank'
            );
            return;
        }

        if (element.hasClass('second'))
        {
            _articleCreation.openMoveModule();
        }
        else
        {
            _articleCreation.closeMoveModule();
        }

        $('.tabs li').removeClass('on');
        $('.ctab').removeClass('on');

        $(element).addClass('on');
        $('#' + $(element)
          .find('a')
          .attr('href')
        ).addClass('on');
        _articleCreation.launchAutowidth();
    }
}

ArticleCreation.prototype.changeTabEvents = function() {

    $('.tabs-second li a').click(function(e){
        e.preventDefault();
        var parentLi = $(this).parents('li');

        if (parentLi.hasClass('lock'))
        {
            return;
        }

        if (parentLi.hasClass('first'))
        {
            $('.tabs li.first a').click();
        }

        if (parentLi.hasClass('second'))
        {
            $('.tabs li.second a').click();
        }

        $('.tabs-second li').each(function(){
           $(this).removeClass('active');
        });
        parentLi.addClass('active');
    });

    $('.tabs li a').click(function(e){
        if (!$(this).hasClass('notab'))
        {
            e.preventDefault();
            _articleCreation.changeTab(
               $(this).parent('li')
            );
        }
    });
}

Javascript

    <ul class="tabs-second"><!--
        --><li class="first
            {% if app.request.get('tab') != 'second-tab' %}active{% endif %}
        ">
            <a href="first-tab">{{ "Info"|trans({}) }}</a>
        </li><!--
        --><li class="second
            {% if app.request.get('tab') == 'second-tab' %}active{% endif %}
        ">
            <a href="second-tab">{{ "Média"|trans({}) }}</a>
        </li>
    </ul>

    ...

    <ul class="tabs" style="display:none;">
        <li class="first
            {% if app.request.get('tab') != 'second-tab' %}active{% endif %}
        ">
            <a href="first-tab">{{ "Les informations"|trans({}) }}</a>
        </li><!--
        --><li class="second
            {% if app.request.get('tab') == 'second-tab' %}active{% endif %}
        ">
            <a href="second-tab">{{ "La story"|trans({}) }}</a>
         </li><!--
         --><li class="third">
             <a href="">{{ "Voir la story"|trans({}) }}</a>
         </li>
    </ul>

Twig

Ce qui rend le code non réutilisable

Code Spaghetti

Logique dans le template Twig et le JS

Process de build pas clair et pas documenté

Situation A = Symfony Twig + Jquery

Situation B = Symfony as API + React front

Cette situation B demande que l'on refasse beaucoup de choses en front qui existent déjà en back : le routing, les traductions, la gestion des utilisateurs, la gestion du state de l'application...

Il va falloir rendre accessible par API beaucoup de contenus qui pour le moment ne le sont que depuis des controllers Symfony.

Situation A' = Symfony Twig + React sur la page d'édition de l'article

Cette situation est bien plus simple à atteindre, elle permet en plus de tester des choses :

• Est-ce que toutes les pages doivent être refaites ou est-ce qu'une simple partie du produit doit être migrée vers une SPA ?
• Est-ce que le téléchargement d'un bundle React à chaque chargement de page est acceptable ?
• Comment estimer le coût de cette migration ?

Comment est-ce que nous avons fait :

• Détermination d'un point d'entrée Webpack par page migrée de l'application
• Dans les templates Twig, on importe le script qui va rendre le contenu

Avantages :

• Le header qui contient la navigation reste à la main de Symfony (ainsi que le controle du user, l'accès au Menu etc...)

Inconvénients :

• Temps de chargement sur la page Article anormalement long du point de vue de l'utilisateur.
• Peut-être corrigé par du server side rendering, ce qui permet de continuer à partager le contenu entre les articles et l'éditeur

UGC viens nous voir et nous dit qu'ils veulent créer une V2 de l'application. Ils ont déjà refait leur site web mobile en accord avec le nouveau design qui correspondra plus ou moins à celui l'application mobile.

Situation A = Application native V1 en PROD

Situation B = Application native V2 en PROD avec les mêmes features que la V1

Parmi ces features, les features standards pour consulter les films en salle, les salles où les films sont diffusés, les cinémas et les films favoris.

Certaines features semblent plus longues : le tunnel de paiement avec le 3D secure, l'utilisation de cartes de fidélités pour payer, l'affichage et la gestion de ses cartes de fidélité.

Situation A' = Application Native V2 affichant le site mobile pour la plupart des pages

Cela permet de mettre l'application rapidement en production sans tout recoder et de remplacer les features faites par des webviews au fur et à mesure sans détruire de valeur pour l'utilisateur

Comment est-ce que nous avons fait :

• Utilisation de Webviews pour afficher le site dans une page de notre routing
• Passage via un paramètre d'URL que nous visionnons le site depuis une webview ce qui cache le header et le footer ainsi que tous les boutons permettant de naviguer dans le site.

Inconvénients :

• Débuggage complexe (avoir le site ouvert en parallèle de l'application)
• Le routing de la webview ne fonctionnait pas (pas possible de cliquer sur back)
• Look and feel natif pas présent