Aller au contenu
Guide8 min de lecture

Vidéo de relecture d'application Firebase Studio

Prouvez que la réalisation correspond au brief avec l'application déployée.

Donnez à un relecteur un flux qui prouve qu'une réalisation Firebase Studio correspond au brief, avec l'application déployée, pas l'espace de travail.

Voir comment ça marcheLes 60 premières secondes de vidéo sont gratuites, avec un filigrane. Vérifiez votre adresse e-mail pour la télécharger.

Une présentation guidée de relecture Firebase Studio existe pour combler l'écart entre une mise à jour de statut disant qu'une fonctionnalité est terminée et une preuve réelle qu'elle fonctionne. Un relecteur lisant « la fonctionnalité d'export est terminée » ne peut pas dire à partir de cette phrase si cela signifie que le bouton produit un fichier correct ou que quelqu'un l'espérait. Une courte vidéo de l'export se produisant réellement, se terminant par un fichier que le relecteur peut voir, élimine cette ambiguïté d'une manière qu'une mise à jour écrite ne peut pas.

GogoScreen produit cela à partir d'une URL d'application publique et d'une indication d'une ligne, renvoyant un MP4 narré en environ deux minutes, avec zooms sur les clics, lissage du curseur, temps morts supprimés, et sous-titres incrustés. Si le flux nécessite une connexion, un compte de démonstration peut être fourni, chiffré, utilisé pour un seul rendu, puis supprimé. Si un storyboard est planifié en premier, les identifiants restent chiffrés pendant cette session et sont supprimés au plus tard deux heures après leur dernière utilisation. C'est la preuve d'un flux qui a été vérifié, pas une affirmation que tout dans la réalisation a été relu ou qu'un rendu est garanti de réussir au premier essai.

Pourquoi enregistrer l'application déployée plutôt que l'espace de travail ?

L'aperçu de l'espace de travail à l'intérieur de Firebase Studio est lié à quiconque a accès au projet Google Cloud sous jacent, ce qui est souvent seulement la personne qui construit l'application, pas le relecteur qui attend d'approuver. Envoyer ce lien à un relecteur échoue purement et simplement, ou signifie lui accorder un accès au projet bien au delà de ce qu'une relecture requiert. Déployez la réalisation vers son URL publique Firebase Hosting et enregistrez depuis là afin que le relecteur voie exactement ce qu'un utilisateur final verrait éventuellement.

Cela a aussi un avantage secondaire à garder à l'esprit. Un flux qui ne se comporte correctement qu'à l'intérieur de l'espace de travail de développement, s'appuyant sur des variables d'environnement ou une configuration de test qui ne se reporte pas sur la version déployée, n'est pas réellement terminé même s'il paraît terminé dans l'espace de travail. Enregistrer depuis l'URL déployée fait apparaître cet écart avant que le relecteur ne le fasse.

Exigence de relecturePourquoi l'URL déployée la satisfaitPourquoi l'aperçu de l'espace de travail ne le fait pas
Le relecteur peut regarder sans accès supplémentaireL'URL d'hébergement publique ne nécessite aucune connexion au projetL'aperçu de l'espace de travail nécessite le même compte Google que la réalisation
Confirme le comportement livréMontre ce qu'un utilisateur final verra réellementPeut différer de l'espace de travail en raison de différences d'environnement
Preuve réutilisable pour le briefUn artefact enregistré durable lié à une demande précisePas une référence stable et partageable par la suite

Que doit exactement prouver l'enregistrement ?

Relisez la ligne précise du brief avant de choisir le flux, pas l'ensemble des fonctionnalités de l'application. Si le brief disait « un administrateur peut approuver une soumission et elle apparaît dans la liste publique », la présentation guidée doit montrer précisément cela, en commençant par l'action de l'administrateur et en se terminant par l'apparition publique de la soumission. Tout ce que la présentation guidée montre au delà de cette demande précise est superflu, et tout ce qu'elle omet de montrer que le brief demandait laisse la relecture incomplète.

  • Faites correspondre le flux de l'enregistrement au libellé exact du brief.
  • Commencez l'enregistrement à l'état juste avant le déclencheur décrit.
  • Terminez l'enregistrement une fois le résultat décrit visible, ni plus tôt ni plus tard.
  1. Relisez le brief et choisissez le seul flux qui prouve que la demande précise a été satisfaite.
  2. Préparez l'application déployée dans l'état juste avant le déclencheur, en utilisant des données de démonstration sûres.
  3. Enregistrez la présentation guidée et notez tout ce qui, dans le brief, reste ouvert ou non résolu.

Quel flux prouve réellement que le brief a été satisfait dépend de ce qu'est la réalisation. Si l'application en relecture est un portail client, le guide de la vidéo de démo de portail client couvre le choix du seul statut qu'un client consulte réellement en se connectant, ce qui est le même genre de preuve précise autour de laquelle cette présentation guidée est construite. S'il s'agit d'un CRM, le guide de la vidéo de démo CRM couvre le choix d'une affaire ou d'un contact qui traverse une action réelle plutôt qu'une visite de chaque onglet. S'il s'agit d'un tableau de bord interne, le guide de la vidéo de démo de tableau de bord interne couvre le choix de la seule vue de métrique qui répond à la question à laquelle le tableau de bord était censé répondre.

Comment l'application doit elle être configurée avant l'enregistrement ?

Amenez l'application déployée dans l'état qui se trouve juste avant le déclencheur décrit, en utilisant des données préparées à l'avance plutôt qu'en enregistrant la configuration elle même. Si le flux dépend d'un enregistrement déjà existant ou d'un utilisateur déjà connecté, arrangez cela avant de demander le rendu afin que l'enregistrement s'ouvre directement sur le moment pertinent. Un relecteur n'a pas besoin de regarder la création de compte avant de voir la fonctionnalité qu'il relit réellement.

Si les données d'un vrai client seraient normalement présentes à ce point du flux, substituez des données inventées mais crédibles. Un relecteur évaluant si la logique fonctionne n'a pas besoin de voir quoi que ce soit de sensible pour arriver à ce jugement, et l'utilisation de données inventées évite toute question ultérieure sur la présence de quelque chose de privé dans un fichier enregistré.

Gardez une brève note écrite à côté des données inventées expliquant ce qui remplace quoi, au cas où un second relecteur rejoindrait le processus plus tard et aurait besoin de comprendre pourquoi un nom dans la vidéo ne correspond à rien dans le vrai projet. C'est une petite habitude, mais elle évite une conversation confuse des semaines plus tard quand plus personne ne se souvient quelles parties d'un flux enregistré ont été préparées pour la relecture et lesquelles faisaient véritablement partie du comportement de l'application.

Que se passe-t-il quand la présentation guidée révèle un problème ?

Il arrive que la préparation de l'enregistrement fasse apparaître le vrai problème : le flux ne fait pas tout à fait ce que le brief décrivait, ou il fonctionne dans l'espace de travail mais pas sur l'URL déployée. Ne masquez pas cela avec une indication qui contourne la partie cassée. Notez l'écart clairement, aux côtés de toute preuve partielle existante, et traitez la relecture comme incomplète plutôt qu'approuvée. Une présentation guidée envoyée pour faire paraître un problème plus petit qu'il ne l'est mine la capacité du relecteur à faire confiance à la prochaine.

Environ un rendu sur cinq a besoin d'une nouvelle tentative indépendamment du fait que l'application sous jacente fonctionne correctement ou non, donc prévoyez une petite marge dans toute échéance de relecture plutôt que de supposer que le premier rendu reviendra toujours utilisable.

Traitez un rendu échoué ou retenté comme une partie normale du processus plutôt que comme un signe que quelque chose ne va pas avec la réalisation elle même. Les deux ne sont pas liés. Un flux qui fonctionne parfaitement peut quand même avoir besoin d'une deuxième tentative de rendu, et un flux véritablement cassé peut occasionnellement se rendre proprement et montrer quand même l'écart. Jugez l'application sur ce que la vidéo montre réellement une fois revenue, pas sur le nombre de tentatives que cela a pris pour y arriver.

Où cela s'inscrit il dans le reste du processus de relecture ?

Cette présentation guidée intervient généralement après une vérification interne et avant que la réalisation n'atteigne un client ou le public. Le guide de la vidéo de démo Softr, le guide de la vidéo de page de destination Softr, le guide de la vidéo de lancement Product Hunt Softr, le guide du partage Softr avec un client, et le guide de la démo de portfolio Softr couvrent les étapes comparables sur une plateforme de création différente, utiles pour voir quelle étape de relecture une vidéo donnée est censée servir, puisqu'une entrée de portfolio, une remise client, et une présentation guidée de relecture interne sont trois tâches distinctes même quand l'application sous jacente est la même. Le guide de la démo README d'un agent IA est un actif de documentation connexe pour un relecteur technique qui veut un compagnon écrit à la vidéo. Pour une réalisation produite en grande partie par un agent de codage autonome plutôt que par une personne travaillant directement dans l'éditeur, le guide de la présentation guidée de fonctionnalité d'agent IA couvre la preuve équivalente pour une seule capacité, et le guide de la vidéo de démo de remise d'agent couvre l'enregistrement qui suit une fois qu'un relecteur a validé et que le travail passe à qui le possède ensuite.

Si la réalisation en question provient d'une invite générée plutôt que d'un travail manuel dans l'éditeur, le guide de la vidéo de démo d'application créée par invite et le guide de la démo de page de destination d'agent IA couvrent ce cadrage plus directement. Pour un flux qui n'existe que derrière une connexion, le guide de la vidéo de démo d'application connectée couvre les spécificités de cette configuration, et le guide de l'indication de vidéo de démo d'agent IA couvre la rédaction de l'indication d'une ligne assez précisément pour correspondre à ce que le relecteur vérifie réellement. Comparez GogoScreen à un outil d'enregistrement dédié sur GogoScreen contre Loom, consultez les tarifs pour les forfaits et recharges, parcourez la bibliothèque complète de guides et les pages de comparaison, ou commencez depuis la page d'accueil de GogoScreen pour le flux de travail de l'URL et de l'indication lui même.

Précisions

Avant de commencer

Une présentation guidée de relecture Firebase Studio doit elle être enregistrée depuis l'espace de travail ou l'application déployée ?

Enregistrez la depuis l'URL publique déployée si possible. L'aperçu de l'espace de travail nécessite généralement le même accès au compte Google que la réalisation elle même, ce que le relecteur peut ne pas avoir et ne devrait pas avoir besoin pour une relecture.

Que doit prouver la présentation guidée ?

Que le flux de travail précis décrit dans le brief fonctionne de bout en bout et produit le résultat que le brief décrivait, pas que l'application paraît généralement finie.

Une présentation guidée de relecture remplace-t-elle la lecture du code ?

Non. Elle remplace le fait de demander à un relecteur non technique de lire le code ou de cliquer lui même dans l'application. Un relecteur technique peut toujours vouloir examiner l'implémentation séparément.

Collez une URL, décrivez un parcours et obtenez une vidéo de démonstration de votre application web.

Les 60 premières secondes de vidéo sont gratuites, avec un filigrane. Vérifiez votre adresse e-mail pour télécharger la vidéo.