DISCUSSION: Nomenclature & related UI - Function mounts, function packs and self-hosted

[wanderslth]

D/A --

I've been noodling over the nomenclature we're using -- internally we've been comfortable with 'function mounts' and 'function packs' and now we have another term dave has added called 'self-hosted [mounts]'

If we're serious about the function pack aspect -- which I think we are -- we're going to turn this app into something zapier-like fairly quickly (ie, we'll have 50+ function pack integrations which will be driving traffic, buzz, etc). Obviously there is plenty off-road we allow (forking packs, execute, and simple lookups and extracts) -- but can imagine we'll be leaning heavily on these external apps for videos, social media etc.

So, with that in mind, it raises the question of how we're utilizing these integrations in our app (and on the main site) from a marketing perspective. Case in point, should our top-level on the website be /examples as I have been proposing or should it be /integrations (more zapier-esque). I am now leaning toward the latter, where its less about examples (these should instead live in /docs as both concepts and examples and, potentially, tutorials again) and more about the connectivity we provide out of the box (function pack integrations + connectors for simple lookups/extracts + connectors to services to mount external functions from)

If that seems to be reasonable logic, then we start to take aim at the UI in the app itself along with its nomenclature. Currently, we're burying the lede by having our 'main' thing called a 'function mount' and then burying it further in a sub-nav calling it a 'function pack' that shares the UI with something called 'self-hosted [mount]. What I'd propose is making 'integrations' or 'apps' more prominent from the menu.

Right now, our 'new' menu looks like this:

New >

Extract
Lookup
Execute
-------
Function Mount (w/sub menu: 'function packs' | 'self-hosted')

Instead, we may consider exposing the integrations/apps in the menu itself. Technically, yes, these are 'mounted' to our static.flex.io area... but this is technical distinction. To the user, these are ' built in' integrations, not 'external mounts'. Further, given how these differ in substance to the user, it seems like we could break these out for the user into different dialogs (this would also assist us from a documentation perspective, as well as # of clicks in a given video demo).

So, following this logic, for the menu, could do something like this:

New >

Extract
Lookup
Execute
-------
Integration
Mount

Surveying other tools -- for these integrations, they seem to use "connectors", "integrations" or "apps" (zapier). I'd probably stay away from 'connectors' as this doesn't really describe what we're doing. 'app' is OK, but seems like 'integration' may be more clear to the user as what we're doing is combining both the connectivity aspect as well as functionality)

Finally, then instead of 'self-hosted', you just call a mount a 'mount' -- and by definition, it is hosted elsewhere (github, website, etc).

What say ye?

[dzwillia]

Yeah... good stuff to figure out now.

Above all else, we need to be clear on what these things are (I wasn't terribly keen on the whole "Self-Hosted" label either).

From a technical perspective, it's easy to implement. I think I'm fine splitting them out in the "NEW" menu. We could even beef this menu out a little bit (maybe add a small blurb below each similar to the member permissions dropdown) if we want.

My only concern with "Integration" is that it might muddy the water a little bit and people think that you are a Zapier clone. I know others use it too. That being said, I think I like it more than "Connectors" and certainly far more than "Apps". I think don't think "Apps" should even be part of the discussion. That's not what these are.

The only other concern I have with "Integration" vs. "Mount" is that a mount technically is the same thing, just something that a user can create on their own (or extend an existing "Integration" by forking on GitHub). Dunno... maybe we re-think the "Mount" nomenclature to get around this...

[wanderslth]

(maybe add a small blurb below each similar to the member permissions dropdown)

I was thinking something similar -- iirc, you were actually planning to do this at some point. With a tidy menu like this, it would be easy to make it chunkier and more informative. Even 'extract' 'lookup' and 'execute' are not necessarily clear just by their naming conventions, so some description would likely help