A common theme for us when designing Seed: There is a tradeoff between simplicity and understandability, and expressiveness/flexibility as a publisher.
Finding Documents
It is super important for content creators to be able to navigate their content!
But, sometimes a publisher wants to encourage or discourage their audience from finding some content in their site.
Making an Organized Document Easy to Find
I may have organized a document on my site such as Untitled Document with a path like ev.hyper.media/work/seed-hypermedia , which is a proper URL according to my organization.
Because this is important to me and my audience, I want to emphasize and promote it by including it in my site navigation bar. For me, as a publisher, this is more important to promote than the "Work" section.
This allows me to organize my site with long-lived URLs. I shouldn't need to change any URLs around to update my site navigation bar, because my priorities as a publisher will change more often than my organization.
Publishing a Document without Advertising it
On the other hand, a publisher may be working on a new project that they do not want to advertise in their site header.
For example I have created a page on my site for music, but I don't want to put that into my site navigation bar, because I want people to focus on other things about me, like "Seed Hypermedia"
How a publisher will find their own content
Of course, if we a very powerful and expressive navigation bar, which enables use cases like the ones listed here, we have introduced a problem.
How can the publisher find their own content? If Eric doesn't want to put the music page in his navigation bar, how will he find his own music page?
Conclusion
This may help explain the existing navigation design we have developed in the app. We have priorities that are conflicting:
Allowing an expressive navigation system so that publishers can freely express themselves online, while still having the ability to manage all of their content.
Having a UI structure that is super easy to understand
Our current product emphasizes Priority 1, but maybe we don't think that is most important for the future of SHM, and we want to sacrifice that to support Priority 2.