Taking advantage of the Fission webnative SDK and platform, the goal is to make a landing page app that is easily customizable / remixable / cloneable.
Description
A landing page skeleton that is optimized to make a single public page whose content / design can be edited by relatively non technical users directly through the browser.
It can be extended on over time to include other backends and integrations, or simply embed HTML for widgets etc.
The RSVP for Events is an example of a widget / backend that could be included in such a landing page.
The swag landing page currently uses Send in Blue as the “back end”.
User Impact
Who would want to use this and why?
Making single web pages for forms, portfolio, about me, events, notices, and so on. Carrd is an example of a commercial service that does this today.
Can be built on by designers (make custom designs, sell them to clients), developers (add a new widget / backend), and users.
Features
basic single page design
configurable / editable elements – hero image / logo, headline, body text – in a YAML file
build on tailwindcss
editable user styles (stretch) – have some logic that looks at userstyles.css or similar
support for Fission customize / remix feature (TBD)
Future
Forms backend – RSVP for Events is a minimal version of that; building a form builder is out of scope – being able to use the webnative SDK to submit form data to / notify the page owner would be ideal
Thinking about the metadata in particular a bit more. These tags will only work when the tags are served, so it really is a special case compared to something like user styles. I like @boris’s idea of changing these fields directly in IPFS.
The easy part is changing the content. That’s a matter of parsing the <head>, finding the right tag, and changing the content, and updating the data root. We can do that client side for sure.
The question is, of course: where does the HTML wrapper of an app live? Well, we’re already doing a bunch of guessing build directories, and letting users pick other locations. Why not do the same? If we infer that it’s Gatsby, use the default location for Gatsby. If elm-pages, use the expected location of the build dir’s index.html. We can always prompt for user help and cache their answer.
I’m trying to infer the exact requirements for this idea.
The first requirement I can gather is:
We need to store the landing page’s .html file in ipfs with meta tags.
The second requirement is a little less clearly defined:
We don’t want the user to have to download something outside their browser.
So, something that requires a build, e.g. elm-pages gets a lot harder to do.
Here are some requirements that one might want, but I’m not sure we’re aiming for:
Do we want to have pre-rendered page content? This might lead to better SEO and UX, since the time to first render is smaller.
Do we want to purge css? By knowing which styles an application uses in advance, the tailwind css files can be reduced by a lot. Note that for this we’d need a tailwind build process somewhere.
Do we want to have static sites only, or also dynamic sites? The fission landing page and swag page both have quite some custom interactivity. This way we e.g. don’t reload the whole page when clicking on links, provide form errors in a matching style or don’t have to load another page when submitting a form.
With these requirements in the back of my mind, I’m thinking of following design:
We have these artifacts:
The fission drive (it’s already built) and everything that allows us to read and write to it from an Elm application (the webnative/webnative sdk?)
The landing page builder (built by us):
An Elm app landing page site builder/editor. It renders normally using elm. It can also render the landing page that the user configured itself. This landing page is supposed to be 90% static. So after rendering, it’s possible to inspect the virtual dom from javascript and render that to an .html file. In this step, it’s possible to add meta tag information.
The aforementioned html file, the landing page itself:
It’s built by some javascript from the landing page builder and saved to the user’s fission drive using the webnative sdk.
Webcomponents for interactive elements in the landing page:
Though most elements in the landing page are static, some will require interactivity. For these, we’ll use webcomponents. They can be written in elm and be used for things like:
wrapping forms, so they don’t reload on submission
custom form input elements which show styled error messages when validation fails
The webcomponents can just be added as script tags added by our landing page builder’s virtual-dom-to-html renderer.
I’d specifically not recommend elm-pages for following reasons:
Elm-pages requires a build process outside the browser. Deep down in it’s dependencies is puppeteer, essentially a headless chromium for running a browser window with the Elm page running inside, waiting for the first render to finish and grabbing all html. It’s possible but infeasible to run this within the browser.
Elm-pages is not built for this: It cares about developer experience. But we don’t want any developers, we want to use it as a tool.
Elm-pages has lots of feature we don’t need for this:
a preconfigured webpack for elm and content files
‘StaticHttp’: The ability to run http requests to fetch data for the pages at build time. We don’t really want a build process. If we want the user to fetch data from http before publishing the page, we’d just do this in the builder. I should note, however, that the landing page uses StaticHttp to fetch the latest blog posts.
generating a metadata.json (with a required configuration) so that the app can be added as PWAs on mobile devices.
Let me know what you think. Does this help?
I feel most uncertainty around webcomponents at the moment. What do they look like when the browser hasn’t loaded javascript yet? How good is SEO?
Maybe it’s better to use Svelte here? @matheus23 points to two thesis that seem relevant:
For the landing page it is better that it is a pre-generated html, 90% static with some web components
It should be possible to create such pages entirely in the browser
So if our approach is entirely serverless, we need kinda compiler in our browser. And there is already Svelte REPL actually!
We could try to build “components combiner” on top of Svelte and some of it’s component libraries. It will produce some Svelte code which will be compiled to html/js/css right in the browser. The generated landing could be a webnative app itself, if I understand the architecture correctly. Anyway we could host all html and images in ipfs someway.
WebNative could be used for such a “components combiner” to store user templates, components, styles etc.
Crazy idea: we could build a Svelte Components plugin for TiddlyWiki, embed REPL and other features there, and then use it with static publishing plugin which I’m developing now. So it would be possible to build both blog and landing from TiddlyWiki environment.
I’ll be revisiting this capability “real soon”
Using the “content writing capabilities” of IndyWiki and the ability to designate
collection of content fragments collated for a specific purpose and the judicious use of TrailMarks that designate desired interpretations Landing Pages, cards, can be generated choosing from a set of templates.
A template editor is out of scope.
Instead of creating content creation capabilities specifically addressing the needs of this capability use the generic content creation capabilities of IndyWiki
(the Genesys App for the IndieVerse of HyperMedia as Capabilities)
and associate specific lively viewSpecs. https://trailmarks.co/ was created using this approach. the difference will be now that the ability to create things like that will be exposed, and thanks to fission it will be instantly available on the web. My current project needs this capability.
“Production of WebNative HyperMedia by means of born interoperable Holonic, WebNative HyperMedia Capabilities composed of (Holonic, WebNative) HyperMedia Capabilities”
