[WIP] Add landing pages

[nunofmn]

Related #324.

[nunofmn]

📷 Landing Page (IPFS client already running)

[nunofmn]

📷 Landing Page (IPFS Client missing)

[nunofmn]

@lidel where do you think that is the better place to store the landing pages?

In the original issue #324 you mentioned storing it at the same level as add-on/ or tests/.
But this way is necessary to slightly modify the build commands/scripts.

I was thinking about add-on/src/landing-pages/ as a better solution.

[lidel]

@nunofmn that is the question:

• do we ship landing pages with browser extension?
• or do we publish them to IPFS and what browser extension does is to just open IPFS resource at a public gateway?

Personally I was thinking about following an example of WebUI, which is not shipped with go-ipfs but loaded from IPFS instead (go-ipfs has IPFS path of WebUI hardcoded in sources). I am aware that there may be use cases to make it work without internet connectivity (as suggested in #324 (comment)), but Landing Page will be displayed right after install/update, which never happen without working internet connection. So for this specific use case, it is safe to assume connectivity will always be present.

An argument to ship landing page with extension is a risk of public gateway (`ipfs.io) being blocked in some jurisdictions. But then, how user is supposed to install go-ipfs/Station, if links from Landing Page point at a blocked domain? We would have to address it somehow (eg. keep installation packages at different tld than public gw) .

I imagine there are other arguments which I missed, but for now, I think we can assume it will be shipped as webui-like IPFS resource (which means we keep it outside of add-on/ dir).
Just to keep things decoupled and easier to maintain.

Does this sound ok?

[olizilla]

I'm all for this! Seems like we could be doing a lot here to help new users get started and excited about distributing their webs.

I'm mildly in favour of hosting the pages on ipfs, though i don't feel too strongly about it either way.

I have more feels on the design front tho! How about something a little more like the ipfs.io site?

Once the pre-built installers for station land, i'd re-rig it to suggest installing that as per your PR. I think it's helpful to focus the user on just one next step rather than suggesting multiple options at this point in their adventure.

[olizilla]

A bit more context... I feel like I've walked in on this PR waaay late to be all "WHAT ABOUT DIFFERENT!" :-)

I'm working on the UI for ipfs-companion more generally,( see: uploads and menu ) and I'd like to build a style guide for it so we don't have to think too hard about how new features should look.

Would you be interested up for discussing such a thing @nunofmn ?

[olizilla]

....aaaaaaand I was thinking we could use the details section of the "pls install ipfs" page as a place we could explain that we need browsers to open up more apis to make the distributed web easier to use.

[nunofmn]

@lidel sorry for the late reply.

I still feel that shipping the landing pages in the extension is the better option, mainly from a deployment, distribution and user experience perspective.

I understand the approach used in go-ipfs, but in that case you already have the IPFS client and you can load the WebUI. In this case the user may not have the IPFS client/Station installed and if he cannot access "ipfs.io" gateway, the extension will not show the user any page when the extension is installed.

At least if the landing pages are bundled with the extension, you are able to show the user a page showing the the extension was successfully installed, even if he's not able to download IPFS Station through the provided link. This way the user could try to find an alternative source to download IPFS Station, instead of simply dismiss or uninstall the extension because it didn't receive any further instructions on how to use or properly configure it.

Of course this all depends on the userbase that this extension is trying to target right now.
If it is targeting a developer userbase that has a proper knowledge about IPFS and the distributed web, maybe this instructions are not necessary and they will find a way of properly configure IPFS.

But if we want to reach a tech-savvy userbase without a priori knowledge about IPFS and the distributed web, maybe bundling the landing pages with the extension could lead to a smoother on boarding user experience.

The update/changelog pages since are not so essential could be loaded from IPFS directly.

[nunofmn]

@olizilla yeah I think we can workout a style guide for the extension 👍

I also like the page layout you presented, but I have some observations:

1. I think this landing pages will be released after the IPFS Stations packages are released (@lidel please correct me if I'm wrong). So I already built the page taking into consideration that the IPFS Station installers will already be available, which will bring a smoother user on boarding experience.

2. In your details section maybe we could try to mimic the layout and content that I used in the Learn more and Applications sections, while also adding the browser APIs and distributed web topics you mentioned.

But lets build a style guide with a common stylesheet that could be used across the extension. 👍

[lidel]

@nunofmn I agree, this is a valid and quite important concern:

if the landing pages are bundled with the extension, you are able to show the user a page showing the the extension was successfully installed, even if he's not able to download IPFS Station through the provided link. This way the user could try to find an alternative source to download IPFS Station, instead of simply dismiss or uninstall the extension because it didn't receive any further instructions on how to use or properly configure it.

I am guilty of forgetting that we already had an example of a government blocking public IPFS gateway. To work around such events in future we actually have no choice, but to ship post-install landing page with exception itself. Thank you for pointing this out.

---

As for use cases around landing page, yes, we will ship it when Station has one-click install packages for all platforms. So we want to design the message as if all the pieces are ready for use.

[olizilla]

@nunofmn @lidel good points. I agree. Shipping these pages with the addon makes more sense.

As for a style guide, we've been using tachyons as the starting point. It's an implementation of atomic css which is fun, but the killer feature is the amount of research that has gone in to the default values for all of the building blocks. I'm working on an ipfs flavoured theme on top of it.

[nunofmn]

@olizilla nice. So maybe I will restructure the landing pages to use tachyons, and then when you finish the IPFS theme based on tachyons we uniformize the style of the extension. I could help in
the theme if you want.

@lidel since we are shipping the landing pages with the extension, maybe we should move the landing pages folder to add-on/src/?

[lidel]

Agreed, it makes sense now to move them.
I assume we are going to use/share browserified assets such as tachyons, so does something like add-on/src/landing-pages/ sound good?

[nunofmn]

@lidel do you think that we should stick to static pages? Or maybe build the pages using choo?

[lidel]

@nunofmn we will have some context-dependent content, namely a section informing user that Station/go-ipfs should be installed – it will be visible only if browser extension is unable to connect to API.

This is simple enough that could be handled by a static page, but we may want to anticipate future needs for other use cases, such as "displaying some engaging real-time stats about running node".
It may be more future-proof to go with choo (if that is not a big chore), but I don't have a strong opinion yet.

If you choose to use choo, event-based code would be similar to our browser action menu, which shows/hides menu items depending on current tab being IPFS path or not, displays peer count/offline status depending on API connectivity etc.

[nunofmn]

📷 Landing Page using Tachyons (IPFS client already running)

@lidel I also think that building the static pages with choo is a more future-proof solution. When I finish the layout then I will migrate it to choo 👍

[nunofmn]

📷 Landing Page using Tachyons (IPFS client missing)

[nunofmn]

@lidel, the transition to choo is finished.

I think that now the following topics need to be addressed:

• Support i18n?
• Discuss which should be the content that should go into each page.

[olizilla]

very cool @nunofmn !

On i18n, it would be great if these pages could pull their text from the message.json files. You'd use the browser.i18n.getMessage api to load the value for the current locale:

• Example: https://github.com/ipfs-shipyard/ipfs-companion/blob/ce1f767c84d1a3be26e0b6583f2a24a6f1c1508a/add-on/src/popup/quick-upload.js#L105
• API docs: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/i18n/getMessage

[lidel]

@nunofmn 👌 👌 👌

Just a thought: it may be easier to work/comment on text without i18n for now.
We can add translation keys at the very end of this effort, just before final merge, when all kinks are ironed out :)

[ghost]

I am guilty of forgetting that we already had an example of a government blocking public IPFS gateway. To work around such events in future we actually have no choice, but to ship post-install landing page with exception itself. Thank you for pointing this out.

Another concern: people might simply be offline while installing the extension. We should approach this from an offline-first perspective.

There was a great presentation at 34C3 about SNET / Street Network in Cuba [1] but there's plenty of other cases where users are permanently or intermittently disconnected from the internet at large.

Once FlyWeb/mDNS in Firefox is back working, we could have the extension announce itself to the LAN and let more users install it.

[1] https://media.ccc.de/v/34c3-8740-the_internet_in_cuba_a_story_of_community_resilience

[lidel]

Just fyi we started shipping parts of UI Kit in add-on/ui-kit
(Not in git, directory is created from external deps during npm run build:copy:ui-kit):

add-on/ui-kit
├── fonts
│   └── *.woff2
├── ipfs.css
└── tachyons.css

General idea is that UI Kit will be used by both extension GUI and Landing Page (so that it works offline).
If you see anything missing in UI Kit, see links below.

Related Resources

• Designing Styleguide and Language for the UI's: Styleguide and Language for the UI's ipfs-gui#7
  • You can also see it and CSS inspect on Zeplin: https://zpl.io/awyMrgj
    (comment in issue above if you dont have access)
• WIP implementation of the above (UI Kit): https://github.com/ipfs-shipyard/ipfs-css

[lidel]

Closing this, as it got superseded by #565 which just landed :)
Big thank you to everyone contributing ideas, pocs and mockups to both PRs!