Zum Inhalt springen
Leitfaden6 Min. Lesezeit

Bubble-Portfolio-Demo-Video

Zeigen Sie die laufende Bubble-App, statt einen Prüfer sie sich vorstellen zu lassen.

Verwandeln Sie einen laufenden Bubble-Build in einen Portfolio-Eintrag, der die App in Aktion zeigt, nicht nur einen Screenshot.

Ansehen, wie es funktioniertDie ersten 60 Sekunden Video sind kostenlos, mit Wasserzeichen. Bestätigen Sie Ihre E-Mail-Adresse, um es herunterzuladen.

Ein Bubble-Portfolio-Eintrag hat eine Aufgabe: jemanden, der die App nicht gebaut hat, davon zu überzeugen, dass die Person, die es getan hat, weiß, was sie tut. Ein statisches Bild des Design-Tabs im Editor kann das nicht leisten. Es zeigt Layout, kein Verhalten, und Bubble-Arbeit ist größtenteils Verhalten. Der Workflow, der beim Klick auf einen Button ausgelöst wird, die Datenschutzregel, die entscheidet, welche Datenzeilen ein eingeloggter Nutzer sehen darf, die Responsive-Engine, die Elemente neu anordnet, wenn der Browser schmaler wird: Nichts davon übersteht einen Screenshot. Ein kurzes Video der tatsächlich laufenden App schließt diese Lücke für einen Prüfer, der dreißig Sekunden Zeit hat und nicht vorhat, selbst durch einen Vorschau-Link zu klicken.

GogoScreen nimmt eine Web-App-URL und eine Zeile, die beschreibt, was gezeigt werden soll, und liefert etwa zwei Minuten später ein erzähltes, geschnittenes MP4. Für eine App, die hinter einem Login liegt, kann ein bereitgestelltes Demokonto verwendet werden. Die Bearbeitung ist mechanisch, nicht kreativ: Zooms auf Klicks, Cursor-Glättung, entfernte tote Luft, eingebrannte Untertitel. Das reicht, um einen funktionierenden Ablauf in etwas zu verwandeln, das sich ein Prüfer ansieht, statt etwas, dem er nur vertrauen soll.

Was sollte ein Bubble-Portfolio-Demo tatsächlich zeigen?

Wählen Sie den einen Ablauf in der App, nach dem ein einstellender Kunde oder ein Agenturverantwortlicher zuerst fragen würde. Bei einem Marktplatz-Build ist das meist ein Eintrag, der erstellt wird und dann in einem Suchergebnis erscheint. Bei einem internen Tool ist es meist ein Datensatz, der eingegeben wird, während sich eine nachgelagerte Ansicht aktualisiert, weil ein Workflow gelaufen ist. Widerstehen Sie dem Drang, jede Seite der App abzulaufen. Ein Prüfer, der entscheidet, ob er jemanden einstellt, braucht keine vollständige Tour, er braucht den Beweis, dass eine echte Logik von Anfang bis Ende funktioniert.

Die meisten für ein Portfolio gebauten Bubble-Apps liegen auf der Standard-Subdomain bubbleapps.io statt auf einer gekauften Domain, und das ist in Ordnung, so gezeigt zu werden. Entscheidend ist, ob die URL auf die Live-Version oder auf einen noch intern geprüften Version-Test-Build zeigt. Sagen Sie im umgebenden Seitentext, welche Version es ist, damit niemand annimmt, ein Entwurf sei das fertige Produkt.

Portfolio-EntscheidungWas sie dem Prüfer signalisiertWas zu vermeiden ist
Live-Version gezeigtDer Build ist fertig und wird vertretenVersion-Test so zu präsentieren, als wäre es live
Ein Ablauf, vom Start bis zum ErgebnisEine bestimmte Fähigkeit wurde bewiesen, nicht nur ein LayoutEine Tour durch jede Seite ohne abgeschlossene Aktion
Im Voraus vorbereitete DemodatenDer Prüfer sieht eine glaubwürdige App, keine leere TabelleEchte Kundendaten oder ein leerer Datentyp

Wie gehen Sie mit einem Login-Bildschirm im Ablauf um?

Eine bedeutende Zahl der Bubble-Builds, die es wert sind, in einem Portfolio gezeigt zu werden, liegt hinter dem eingebauten User-Datentyp der App, denn das interessante Verhalten, die personalisierte Ansicht oder der mit einem Konto verknüpfte Datensatz, erscheint erst, sobald jemand angemeldet ist. Stellen Sie ein Demokonto bereit, statt den Ablauf auszulassen oder drumherum zu erzählen. Bei GogoScreen werden bereitgestellte Zugangsdaten verschlüsselt, für genau einen Renderdurchlauf verwendet und danach gelöscht. Wird zuerst ein Storyboard geplant, bleiben die Zugangsdaten für diese Sitzung verschlüsselt und werden spätestens zwei Stunden nach ihrer letzten Verwendung gelöscht. Das ist die tatsächliche Handhabung, klar beschrieben statt untertrieben.

Wenn ein echter Bildschirm hinter Onboarding-Schritten liegt, die für die zu beweisende Fähigkeit irrelevant sind, säen Sie das Demokonto im Voraus über diese Schritte hinaus, sodass der aufgezeichnete Ablauf genau an dem Moment beginnt, der zählt. Ein Betrachter, der zusieht, wie jemand durch fünf Einrichtungsbildschirme klickt, bevor die eigentliche Funktion erscheint, hört auf zuzusehen, bevor die Funktion überhaupt auftaucht.

  1. Wählen Sie einen Bubble-Build aus dem Portfolio, der eine echte Fähigkeit beweist, nicht nur eine Vorlage.
  2. Öffnen Sie die Live-Version der App und bereiten Sie Demodaten vor, die sicher zu zeigen sind.
  3. Schreiben Sie den einzeiligen Hinweis, fordern Sie das Video an und prüfen Sie das Ergebnis, bevor Sie es dem Portfolio hinzufügen.

Welche Daten sollten in der App liegen, wenn aufgenommen wird?

Ein leerer Bubble-Datentyp lässt selbst korrekte Logik defekt aussehen, denn der Betrachter kann nicht erkennen, ob eine Liste absichtlich leer ist oder weil nichts eingegeben wurde. Füllen Sie zwei oder drei Zeilen glaubwürdiger Platzhalterinhalte, bevor Sie den Renderdurchlauf anfordern. Verwenden Sie erfundene Namen und erfundene Organisationen statt echter Kundendaten, selbst wenn der Build für einen echten Kunden gemacht wurde, es sei denn, dieser Kunde hat ausdrücklich zugestimmt, gezeigt zu werden.

Vorbereitete Daten schützen die Aufnahme auch vor einem versehentlichen leeren Zustand. Wenn ein Suchergebnis, eine Dashboard-Zahl oder eine gefilterte Liste nichts anzuzeigen hat, zeigt der Renderdurchlauf genau das, und es gibt danach keine Möglichkeit, das nachträglich zu bearbeiten. Die App vor dem Einreichen von Hand zu prüfen, auf dieselbe Weise, wie jeder Staging-Build vor der Aufnahme geprüft wird, fängt das ab, bevor Zeit für einen Renderdurchlauf reserviert wird, der wiederholt werden muss.

Wie steht das im Verhältnis zu einem statischen Screenshot oder GIF?

Ein Screenshot beantwortet "wie sieht es aus". Ein Video beantwortet "funktioniert es". Die meisten Portfolios profitieren von beidem, wobei das Video die schwerere Arbeit übernimmt. Jeder, der schon versucht hat, einen mehrstufigen Ablauf in ein sich wiederholendes GIF zu pressen, kennt die Kompromisse, und der Guide zur Alternative zum Produkt-Demo-GIF behandelt, warum ein kurzes erzähltes Video auf weniger Raum meist mehr vermittelt als ein animiertes Bild.

Schreiben Sie den einzeiligen Hinweis so, wie Sie einen Kollegen briefen würden, der Ihnen über die Schulter schaut: Benennen Sie den Startbildschirm, die Aktion und das erwartete Ergebnis. Der Guide zum KI-Agenten-Demo-Video-Hinweis enthält mehr Details dazu, wie man einen Hinweis präzise genug formuliert, damit der Renderdurchlauf dem entspricht, was gemeint war, statt etwas Ähnlichem.

Denken Sie auch bei einem Portfolio-Eintrag an den Ton, der wahrscheinlich zuerst mit ausgeschaltetem Ton angesehen wird. Ein Betrachter, der eine Portfolio-Seite auf einem Laptop im Büro durchscrollt, wird nichts stummschalten müssen, also muss die visuelle Abfolge auch ohne Erzählung Sinn ergeben, ein Punkt, der direkt im Guide zum Produkt-Demo-Video ohne Ton behandelt wird. In den Renderdurchlauf eingebrannte Untertitel tragen den Punkt, wenn Ton keine Option ist.

Wie unterscheidet sich das von einem Firebase-Studio-Portfolio-Eintrag?

Die zugrunde liegende Disziplin ist über Builder-Plattformen hinweg gleich, auch wenn sich die Plattformdetails unterscheiden. Ein Firebase-Studio-Demo-Video steht vor einer anderen Frage, da Firebase-Studio-Apps typischerweise auf Firebase Hosting bereitgestellt werden und die Vorschau innerhalb des Workspaces selbst für einen Kunden ohne Projektzugriff nicht zu öffnen ist. Der Firebase-Studio-Landingpage-Video-Guide und der Firebase-Studio-Product-Hunt-Launch-Video-Guide behandeln beide, eine App vor einen Fremden zu bringen, der sie noch nie gesehen hat, was dem Portfolio-Problem nahekommt, aber nicht identisch ist, da ein Portfolio-Betrachter bereits weiß, wer die App gebaut hat, und den Builder beurteilt statt zu entscheiden, ob er sich anmeldet. Der Firebase-Studio-Guide zum Teilen mit einem Kunden kommt noch näher heran, denn Arbeit an jemanden weiterzugeben, der keinen Vorschau-Link anklickt, ist dasselbe Problem, das eine Portfolio-Seite für einen Personalverantwortlichen löst.

Bei einem Build, der mit einem KI-Coding-Agenten statt von Hand im Bubble-Editor erstellt wurde, ändert sich die Prüffrage erneut, und der Guide zum KI-Agenten-PR-Demo-Video behandelt, was ein Prüfer sehen muss, wenn die zu prüfende Änderung aus einem generierten Pull-Request statt von einer Person stammt, die Elemente auf eine Fläche zieht.

Bevor Sie einen fertigen Renderdurchlauf einem Portfolio hinzufügen, sehen Sie ihn sich einmal so an, wie es ein Fremder täte: ohne Kontext, ohne Ton, auf einem Telefon, wenn das Portfolio dort angesehen wird. Wenn der Ablauf dann immer noch Sinn ergibt, ist er bereit. Wenn er eine darunter getippte Erklärung braucht, um Sinn zu ergeben, war der Ablauf zu breit und sollte vor dem nächsten Versuch eingeengt werden. Für alles andere im Workflow, vom Prüfer-Übergabe für einen Bubble-Build bis zu Bubble-Alternativen zu einem geführten Bildschirmaufnahme-Tool, der Preisseite für Pläne und Aufladungen, der vollständigen Guide-Bibliothek, den Vergleichsseiten und der GogoScreen-Startseite für den URL-und-Hinweis-Workflow selbst, behandeln Sie das wie jeden anderen in Prüfung befindlichen Build: prüfen Sie ihn von Hand, bevor es jemand anderes tut.

Klarstellungen

Bevor Sie beginnen

Warum scheitert ein Screenshot als Bubble-Portfolio-Eintrag?

Ein Screenshot zeigt ein Einzelbild eines Design-Tabs. Er kann keinen ausgelösten Workflow zeigen, keine Datenschutzregel, die die richtigen Daten freigibt, und keine Responsive-Engine, die eine Seite über verschiedene Breiten hinweg neu anordnet, und genau das will ein Prüfer eines Bubble-Builds sehen.

Sollte ein Bubble-Portfolio-Video die Live-Version oder die Testversion verwenden?

Verwenden Sie die Version, der der Prüfer vertrauen soll. Eine Live-Version auf der eigenen Domain der App wirkt wie fertige Arbeit. Ein Version-Test-Build ist für einen noch in Prüfung befindlichen Build in Ordnung, aber sagen Sie, welche Version es ist, damit niemand einen Entwurf mit der ausgelieferten App verwechselt.

Was, wenn die Bubble-App einen Login benötigt, um den interessanten Bildschirm zu erreichen?

Stellen Sie über den zugelassenen Prozess ein entbehrliches Demokonto bereit. Bei GogoScreen werden die Zugangsdaten verschlüsselt, für genau einen Renderdurchlauf verwendet und danach gelöscht. Wird zuerst ein Storyboard geplant, bleiben die Zugangsdaten für diese Sitzung verschlüsselt und werden spätestens zwei Stunden nach ihrer letzten Verwendung gelöscht. Geben Sie zu diesem Zweck niemals einen echten Kunden-Login heraus.

Fügen Sie eine URL ein, beschreiben Sie einen Ablauf und erhalten Sie ein Demovideo Ihrer Webanwendung.

Die ersten 60 Sekunden Video sind kostenlos, mit Wasserzeichen. Bestätigen Sie Ihre E-Mail-Adresse, um das Video herunterzuladen.