Zero-Budget Web Dev: Wechsel von Discord / Drive zu Google Sites

Willkommen zum ersten Teil! Dies ist der Beginn einer Serie, in der ich über meine Webdev- und HTML-Albträume posten werde. Ich hoffe, Sie genießen das Lesen so viel wie ich hasse User Interfaces! Betrachten Sie dies als einen gemeinsamen Lernraum - ich teile, was ich bisher gelernt habe, und ich würde gerne Ihre Gedanken oder bessere Lösungen in den Kommentaren hören. Um die dinge anzustoßen, lassen sie uns darüber sprechen, wie dieses ganze durcheinander begann. Als Solo-Entwickler möchten Sie 99% Ihrer Zeit damit verbringen, die Dinge zu bauen, die Sie lieben. Wenn es also an der Zeit ist, Builds mit frühen Playtestern zu teilen, gehe ich natürlich den Weg des geringsten Widerstands ... einen gepinnten Link in einem Discord-Kanal und einen gemeinsamen Google Drive-Ordner. Und für eine Weile funktioniert es. Bis es plötzlich nicht mehr geht. Das Problem: Die "Easy Way" -Falle Privat, mit einer kleinen Gruppe von Alpha-Testern, ist Discord großartig. Sie können Nachrichten anheften, bestimmte Kanäle erstellen und Personen direkt führen. Aber sobald Sie an die Öffentlichkeit gehen wollen, wird Discord zu einem Albtraum für das Onboarding neuer Benutzer: Die "Tutorial" -Anforderung: Wenn ein neuer Benutzer eine 5-minütige Anleitung benötigt, um auf Ihrem Discord-Server den Launcher oder die neueste Version zu finden, haben Sie sie bereits verloren. Discord ist großartig für community und chat, aber schrecklich als öffentliche storefront oder dokumentationsdrehscheibe. Die Suche nach Nachrichten, das Filtern von Updates oder das Finden von Launcher-Links führt zu massiven Reibungen. Mangelnde Professionalität: Um echte Unterstützung zu bieten, Funktionen zu präsentieren und für ein öffentliches Publikum vertrauenswürdig zu sein, benötigen Sie eine einzige Quelle der Wahrheit - kein Labyrinth von Textkanälen, die in der Leere verloren gehen. Ich hatte keine Zeit, ein übermäßig komplexes benutzerdefiniertes Web-Setup zu verwalten oder hohe monatliche SaaS-Gebühren zu zahlen, aber ich brauchte einen sauberen, wartungsarmen Weg, um an die Börse zu gehen. Ja, ich habe nicht mehr als dreißig Sekunden damit verbracht, dies auf meinem Bambus-Tablet zu zeichnen: Warum Google? (Und die Launcher Evolution) Bevor ich überhaupt über die Website nachdachte, musste ich das Verteilungsproblem für meinen Launcher lösen. Ich habe mit mehreren Download-Pipeline-Prototypen experimentiert: Git Repos / Diversion (für Spiele) / Source Control im Allgemeinen: Großartig für Code, schrecklich für Endbenutzer, die nur klicken und spielen wollen. OneDrive & Self-Hosted SSH-Server: Zu klobig, zu komplex zu pflegen, und es fehlte die richtige Download-Lebenslauf-Funktionalität oder Hash-Diffing, ohne eine massive Backend-Infrastruktur aufzubauen. Schließlich wurde die Google Drive API zum Helden. Es gab mir zuverlässige Speicherung, einfache Zugriffskontrolle und nahtlose Integration für das Update-System des Launchers. Da mein Distributions-Ökosystem bereits in Google verankert war, machte es Sinn, sich Google Sites anzusehen, wenn ich eine öffentliche Webfront brauchte. Während ich Frontend-Tools recherchierte und mit meinem Nemesis (XAML und HTML) ringte, verglich ich weiterhin Web-Builder von Drittanbietern mit Google Sites. Die meisten SaaS-Builder kosten $ 15- $ 30 / Monat. Als Solo-Entwickler mit einem Budget, der nur ein schnelles, kostengünstiges und wartungsarmes Portal wollte, gewann Google Sites. Allerdings ... "Frei und einfach" kommt mit einem Preis. Google Sites eignet sich hervorragend für grundlegende Drag-and-Drop-Seiten, aber sobald Sie versuchen, etwas mit eingebettetem HTML zu erstellen, stoßen Sie direkt in eine Wand mit iframe-Sicherheitsbeschränkungen. Google Sites ist erstaunlich glatt, wenn Sie sich zu 100% an ihre standardmäßigen Drag-and-Drop-Elemente halten. Aber als Entwickler wollen wir immer diese zusätzliche Kontrollebene - einen benutzerdefinierten Tastenstil, ein eingebettetes Widget oder ein maßgeschneidertes UI-Element. Natürlich habe ich den Block "Embed HTML" geöffnet. Und das ist, wenn ich die iframe Wand getroffen. Da Google Sites alle benutzerdefinierten HTML-Dateien in einer Sandbox isoliert, behandelt der Browser Ihren eingebetteten Code als einen nicht vertrauenswürdigen externen Frame. Das Ziel: Ich wollte benutzerdefinierte HTML-Buttons, die nahtlos durch die Hauptwebsite navigieren können, ohne neue Tabs zu laden oder zu öffnen. Der Realitätscheck: Browser blockieren oder rufen in sandboxed Google Sites-Iframes aufgrund von Sicherheitsrichtlinien auf. Standard-Navigationsskripte scheitern einfach leise oder werden blockiert. Der Workaround (Extern vs. Intern) Da ich die Browser-Sicherheitsregeln nicht umgehen konnte, musste ich meine Navigation teilen