Thoughts on navigation

Hi! I am using neither next.js nor gatsby so I’m not really sure where to put this.

My question concerns navigation of the site from within the TinaCMS UI. Browsing the surface of your documentation I wasn’t able to find a quick solution but I can think of a number of ways to hack in support.

Do you have a standard way of enabling site navigation from withing TinaCMS instead of completely relying on the sites own navigation?

Is this anything you are working on as a future feature?

From my perspective I think there’s a point in enabling more efficient editorial navigation.

As for showing I have this little test-project: https://github.com/Muthaias/tiny-tinacms-test
It’s not much in ways of presentation since my main goal was to try out the barebones functionality of TinaCMS.

Thank you for your time

1 Like

Welcome @muthaias!

This idea hasn’t come up yet actually, so there is no standard way of doing this.

One approach would be to make a toolbar:widget plugin that gives you some navigation. I don’t think we have docs on them yet, but here’s a really simple example.

Out of curiosity, what kind of situation would you have in mind where you would want the navigation links in the CMS Toolbar/Sidebar rather then as part of the site’s navigation?

1 Like

Thank you for the tip. I’ll look into the toolbar:widget.

And thanks for the question. It made me think twice :slight_smile:!

I am coming at this functionality from the perspective of a multi user site with different roles. Wordpress is the obvious comparision, to me. WP has the roles Editor, Author and Contributor. As I see it, an Author or a Contributor could probably manage quite well using the same navigation as the readers since they generally interact with a smaller number of posts in a mostly linear fashion.

From the editors standpoint though I would say that it could be beneficial to get a quick overview of work that needs review such as written pieces that needs some work back and forth in the review process. Another example could be managing comments or user interactions such as flagged comments.

I can think of a few things that could be formulated from an editors perspective.

As an Editor I would like to:

  • Get a quick overview of what work I have to do
  • Filter through content using parameters relevant to me ex. flagged comments, draft content
  • Pin important content that needs continuous monitoring (obviously this could also be done using browser bookmarks :stuck_out_tongue: )

It could be that my opinions are colored by my experience using WP but in general I think it’s faster to navigate the administrative UI than the actual sites/blogs.

Another advantage of having the administrative navigation tied to the administrative UI is that a change in the navigational model for the end user need not affect the editorial side. Which should make it less painful to roll out those kinds of changes.

Just a few thoughts :slight_smile:

1 Like

Those are great thoughts!

From the editors standpoint though I would say that it could be beneficial to get a quick overview of work that needs review such as written pieces that needs some work back and forth in the review process

This stuff is super interesting and important. Right now, this stuff is sort of higher level then Tina, but it would provide a canvas to build these kinds of workflows. i.e. you could make a Screen Plugin that introduces these concepts, but those concepts are not core to Tina itself

The reason why I say it’s higher-level then Tina, is that the exactly how it works and what’s possible is highly dependent on your backend of choice.

For example, if your using react-tinacms-github we might be able to create a plugin that shows the editor a list of open Pull Requests, makes it easy to checkout that branch, see a list of the pages that were changed, and quickly navigate those pages. But this approach wouldn’t necessarily work for other backends.

This is not to say these ideas will never be part of the TinaCMS Core, but just that it’s not yet. A guiding principle of Tina is to build high-level concepts on top of it first, and only introduce new generalized low-level concepts when we’re extremely confident in them.

1 Like

I totally agree that the high level concept of an editor UI is in a layer on top of Tina. This is why I introduced the idea, primarily, as a navigational problem rather than an editorial one. You could see my above suggestions regarding the editorial bits as more of examples of what I would like to be able to implement using TinaCMS.

What I wanted to communicate was primarily that I see a possible need for navigation that is not necessarily tied to the reader-eperience.

Using fields to do so did not feel quite right though and since I couldn’t find notes on navigation in the docs I thought I would ask.

Thanks again.

1 Like

Totally! Love the idea and the approach your taking. I agree using fields seems a bit weird. Right now screen plugins and toolbar:widget plugins definitely seem like the way to go right now.

I’m excited to see how you solve this problem! :smiley:

I have been experiencing massive feature creep within my own project which have resulted in me not moving forward on this specific topic as of yet. However I did get to try out the screen plugin though only with a very limited feature set (I use it to navigate posts and pages, though atm. without filtering etc.)

I am kind of wondering if there’s a nice way to use TinaCMS to lazy-load content into a form so that I won’t have to load and filter all the content client side. (I know I can update the form fields from but that would require there to be some kind of navigation trigger to forward the pagination)

Maybe I am just going about this the wrong way. Anyways TinaCMS seems to be covering a lot of my needs at the moment and I have a lot of work to do in order try out the complete feature set.

Thanks again. I love seeing Tina improve.

1 Like