Portal.JS

Vision:

Plan for PortalJS offer.

• If you are a "start with why" person: see Summary then Objectives and Questions then Plan of Work
• If you are a "how" person: see Roadmap of Work in https://github.com/datopian/portals-monorepo/issues/333

Summary

What (Goal)

Single offer and entry-point for our Portals Stack in the form of PortalJS repo and site (portaljs.org)

❗ For our public offer we are going with "PortalJS" rather than "Toolkit" - see discussion in questions below.

Why (Business motivation and goals):

• Build a major new channel for discovering Datopian and our offers (that we fully control so it can rapidly advance etc)
• Make the stack useful and (more easily) developable: we already have a great stack … but stuff is scattered around. Consolidating this material in the open with a clear focus (portaljs) is the most efficient way for us and others to get access to it and refine it

Roadmap of Work

See https://github.com/datopian/portals-monorepo/issues/333

Objectives and Key Results

• Gain business and generate revenue, e.g., we have clients through this getting our professional services
  • New business inquiries because of portaljs
  • Traffic on site itself
• Other organizations building better portals better so that more good portals in world, more attention for portaljs
  • Portals built
  • Enquiries on the forum
  • Contribution back
• We (Datopian) build better portals, better
  • Accelerate creation of our custom portals
    • Metric e.g. quick to spin up simply npm i && npm start dev or similar
  • Improve quality of our custom portals
    • Metric e.g. more beautiful, more features, few bugs (faster to fix bugs etc)

Outputs and Acceptance

• Make it useable and useful for ourselves and others so that people can use it and want to (when they know about it)
  • Metrics
    • Our team are using the docs / sharing links to it
  • It builds / passes tests
  • Can build a dummy portal in 20m
  • Can build a CKAN-backed portal in 1h
  • Can customize the theme
  • How to add custom components
  • Know where to ask questions
• Attention and community: have people talking about it, asking questions, considering it for future etc so that people start using it … so that more portals in world, more attention for portaljs (hence business etc)
  • Metrics
    • Traffic to datopian.com etc from site
    • Forum use (our team and others)
    • package downloads
    • Our team survey
  • Landing page and other marketing content (e.g. features, how different)
    • Launch post / effort (do we silent launch?)
  • Our team know about it: webinar to team
  • Others know about it
    • Webinar
    • (?) CKAN community knows about it

Questions

• Who is our audience (right now)? Is it people building "data portals" i.e. more oriented towards open data portals with some enterprise data catalog or other stuff or … more toolkit for building data fabrics? ✅2023-04-07 more to governments, institutions etc who want to publish data (more) openly
• Do we focus on Toolkit or PortalJS? (as an offer) ✅2023-04-07 PortalJS (see discussion below)
• Where is the primary landing page? e.g. portaljs.org, portaljs.datopian.com, datopian.com/portaljs/ etc (and similar for toolkit). ✅2023-04-07 go with portaljs.org
  • Datopian: ❌ no SEO benefits, confusing with the company (people just want to go landing page), may put off contributors a little
  • DataHub: ❌ confusing with DataHub Next (when that goes up), some SEO benefits (but likely minor for what we want), won't be home page again which is kind of confusing in itself (there seem to be multiple products here)
  • Own site e.g. portaljs.org: ✅ simple landing page, easier to track metrics, clear sense of own project for outside contributors
• How would we integrate commercial offerings etc in the future? ✅2023-04-07 like gatsby or next did. See notes below.

Do we focus on Toolkit or PortalJS? Ans: Focus on PortalJS

Subject: what is the focal offer: toolkit or portaljs?

Hypothesis: go with PortalJS

• Toolkit sounds more complex and more work: "I'm going to have to get the tools out of the box and work out how to use them before i build something"
• PortalJS is clearer and more connected to immediate need both in name and in terms of code. With PortalJS you build a data portal (think nextjs). Simple and works out of the box.
  • If we had toolkit, first thing we would do is tell people to start with Portal.JS … so why not jump straight to that (and invert the order: specific thing first, then more general (toolkit))
  • General point: Start with the more specific thing (portaljs) and then generalize (toolkit)
• Can always have more parts under PortalJS (even things that aren't JS) e.g. we can have data api etc

NB: ultimately either approach will include the other. It is about starting with more focused item and expanding or vice versa.

How would we integrate commercial offerings? Ans: similar to Gatsby or Vercel

Subject: how do we approach this in terms of free open source site vs commercials?

Hypothesis: we can learn from others eg, Next.js / GatsbyJS (Gatsby more even)

• Start with .org site about Portal.js
• If takes off we can evolve to .com with explicit offers like cloud etc
• Have something like a banner that introduces cloud version or similar (aligns with Portal SaaS stuff). See https://nextjs.org/ or how gatsbyjs.org became .com
• Can also have some stuff under an "enterprise" license but still public (like gitlab)v