Support variable category, blockchain, storage and authentication values in app submission form

[stackatron]

"As a developer submitting my dapp, I want to be able to add my own blockchain, storage, etc while submitting, so I'm not limited to an arbitrary list of protocols"

[markmhendrickson]

@hstove Would this require overhauling our current category etc. models in a significant way? Or simply creating new categories etc. on the fly when users submit their own names for them?

I imagine we wouldn't want to show any user-created categories etc. on the site as sections by default, but we could have an approval process for them?

[hstove]

Yeah, I'd probably just implement it like it's an "other" option, with a user-specified issue. We wouldn't want to display these categories as their own pages, like you said, and we'd probably want to just watch what people are submitting, and then add them as official categories. When I say category, I mean blockchain/storage/auth, not actual categories like "Social Networking"

[markmhendrickson]

I like that approach – just let them fill in a string if they pick "Other" and we can see what data we get and map it out later if we see trends.

[markmhendrickson]

@hstove I spoke with @shea256 about this issue today since he raised it as an example of work that we could have done better prioritizing already.

Could you prioritize work on it for immediately after the completion of this project? https://github.com/blockstack/app.co/projects/6

[hstove]

Yes, we can prioritize it. However, my gut feeling is that it's not a high priority, relative to other things like improving app page content. My main reasoning is that we don't even know what other platforms people need for support. We already support more platforms than other dapp stores, and I've never seen a dapp platform that we don't support.

The counterargument is that we don't get submissions from other platforms, because people think it's not supported.

[stackatron]

Same reaction as Hank. Not getting this. I agree we should be encouraging a diversity of protocols but I think we should do this in a technically, and product complexity, cheap way.

• What alternatives were considered? A mailto link that says "Don't see your protocol? We'll add it."
• We have a handful of these that were added that are sitting empty. Why do we want to add others that will have few/1 apps?

[markmhendrickson]

I think it’ll be pretty cheap to add an other field and just start capturing string values, wouldn’t it? We could then decide later how to use them, especially if we spot trends in entries and want to spin up new platforms, etc around them.

[markmhendrickson]

Also, I think @shea256’s main rationale here is that we want to avoid creating an exclusive experience for any developer while they’re submitting an app from across the ecosystem, even if we don’t leverage their custom data specifically.

[hstove]

The work required is:

• Add an 'other' text field for storage, auth, blockchain in the DB
• On the 'submit your dapp' page, add an option for 'other' for these fields. When selected, show the 'other' text field. Submit and save those 'other' fields
• In every place where we display this info (list views, app views), instead of showing the value with a link to that platform page, show a plain text field with that 'other' value
• Admin views to view these new fields with similar UI to the 'submit' page, where we can edit/add the 'other' value

So, not exactly a very quick fix. I definitely like the idea for a mailto link for "Don't see your protocol? We'll add it."

[stackatron]

Challenges I was thinking about are more related to free-form taxonomy. Someone types "Eth" vs. "Ethereum" do we try to stop them? Do we run a search against their entry and prompt them to pick "Ethereum" instead? Let's say we don't, or they don't pick our suggestion, do we display "Eth" as a category?... these corner cases go on and on once you let anyone add new table rows.

[markmhendrickson]

I think the very lean solution here (aimed at simply unblocking submitters who can’t currently find their platform, etc) would be to implement the first two items in @hstove’s list above.

As such, we’d start collecting the data as strings but do nothing with it (at least yet). And we can punt on auto-suggestions until we find that too many devs are submitting “other” values for values we actually support but they somehow missed.

[markmhendrickson]

Per our conversation today during the stand-up, we've decided to move forward with the "first two items" approach above.

@hstove @jeffdomke please let me know if you're remembering the convo differently, but otherwise I think we're good to go with a quick implementation of this.