Schema interface requests

[metasj]

• It's confusing to have nodes, attribs, or relationships saved if they have no name or other properties set. These could be someone exploring what happens on clicking the button; it's not clear they've been added to the schema + they render in a confusing way in the data-overview when they don't have a name.
• • Nodes w/ no name show up w/ a different indent level
• Some text other than "Schema changed" before the first data upload to indicate a first upload is waiting to happen
• Permalink to a schema version, one that persists across changes in the uploader's profile-slug (currently a link to a schema page always shows the latest published v by default; and if the uploader changes their slug it redirects to the landing page of the collection)

[octref]

Fixed 1, for 2 the new UI should be clearer. This is what you see after making a schema change for a new collection:

For 3, with what we have, we can permalink to a specific version of data + schema (as both tabs are combined now). @isTravis I'm thinking about either /pine/nyc-pizza-slice-hpaewmncvt/data/${version} or /pine/nyc-pizza-slice-hpaewmncvt/versions/${version}. What do you think?

[isTravis]

I'm not sure we're quite ready to implement permalinks quite yet, but my thinking on this has changed now that the data tab is the only tab that has any versioned data. Discussions, exports, overview all show the same thing regardless of version updates I believe.

So, if the data tab is the only thing that's versioned, I think it makes sense to have the version hang off the end of that:

/pine/nyc-pizza-slice-hpaewmncvt/data/${version}.

This should work as a permalink even if namespace or collection name change. You should be able to do:
/{anything}/{anything}-hpaewmncvt/data/${version} and have it resolve correctly. If it's bumping to the Overview page, that's a bug.

[octref]

I mentioned /versions separately as I think of it similar to GH /releases. I'm trying to think from the users' POV and two things I might want permalinks could be:

• A page for each version, with a list of available/compatible exports, in /versions/${version}
• A page for each specific export, with a list of available versions

But I agree this can wait a bit and need more consideration.