Max cards? Max Users? Read only viewers? Use case: Huge “tree of knowledge”


I’m intending to use Gingko to gather a LOT of information from a large group of collaborators concerning the United States Constitution.

For instance, imagine a high percentage of Madison’s notes (a book nearly 1,000 pages long) cross-referenced to sections of the Constitution. Add to that the Federalist Papers (700 pages+). Add to that Supreme Court dozens of cases on each portion of the Constitution.

We are talking tens of thousands, if not hundreds of thousands of cards in a HUGE tree created by potentially dozens of collaborators.

The purpose is to build a “hierarchical reference database” from which others can build education and training materials. This will be a multi-year project to gather huge amounts of source material together.

I have been looking for several weeks for a tool which allows multiple collaborators to simultaneously contribute to this “tree of knowledge” on the Constitution. After looking at (and even trying) dozens of collaboration solutions, I keep coming back to Gingko. The key feature which draws me back is mult-user collaboration on chunks of text (cards).

Question: What is the largest tree you now have on the system?
Question: Only you know the internals of the file system. Will it handle such large tree structures?
Question: How many collaborators can we have?
Question: Is it possible to have “read only” viewers?

I value your thoughts and guidance on whether Gingko is the right tool for such a use case. Thanks!!

I’m going to be bold here and suggest something you probably don’t want to hear:

This is the wrong tool for that job.

Not because the underlying system can’t maintain thousands of individual cards with information on them, but because the user experience, the interface, is simply not geared toward dealing with that much intertwined, multidimensional data. It’s just not designed to do that. Very quickly (very quickly), your users are going to start to find that they can’t find anything. Individual trees are strictly that – individual trees. What you want is to really be able to densely cross-link the content of multiple trees.

Gingko doesn’t really do that.

The right tool for the job that you want to do is a wiki, preferably one with an informational sidebar where content can be linked in line from smaller bits of commentary and where larger collections of text (like the Federalist Papers) can be stored as segmented sections and referenced consistently at will.

It won’t be as pretty an interface as Gingko, but it will be a far more functional one for the purpose you want to put it to.

As an alternative, you might want to look at some forms of mind mapping software which have the flexibility to work with multiple trees simultaneously. This goes well beyond the question of “personal information manager,” and up into the field of “reference database.” These are very different things.

Thanks for the comment, SquidLord. Yes, Wiki’s were considered. In fact, we have an existing Wiki with some of the content.

The issue with Wiki’s is that they are incredibly difficult to build and maintain. I can’t get non-technical users to contribute to them in any meaningful way. I’m a tech and even I don’t want to work with any of the Wiki interfaces I have found. Do you know of any which are as easy to use as Gingko?

On the contrary, wikis are far easier to maintain than trying to use a system which is meant to manage a singular tree via scrolling and search. There are at least a dozen wiki services out there so you don’t even have to maintain your own servers. They track access securely as well as easily allow individual pages or sections to be rolled back to arbitrary times before some recent edit.

That is going to be a huge issue for you. If you expect to be managing tens of thousands of individual pieces of information, you’re going to want a secure management architecture with individual account-level tracking, account management, and varying levels of security policy.

What you need is an entire content management system. They are essentially nontrivial by nature and a good one is not cheap. Moreover, they require a significant investment in administration to manage that content.

And that’s before we even get to the user facing interface which is what a wiki provides.

If you’re having trouble getting “non-technical users to contribute in any meaningful way,” the problem is not the wiki (after all, the Marvel universe wiki is one of the most active and detailed wikis on earth, as is Wikipedia – and both of them strongly driven by non-technical users contributing content). It’s managing your user base.

If you are accurately assessing your intended level of content volume, you need a CMS and some sort of dynamic content user interface which a wiki provides. If you can’t get your user base to use something as relatively straightforward as Wikipedia does, then you will never have tens of thousands of bits of information that you need to track – because you don’t have a user base. And perhaps more importantly, you don’t have an administration base.

Use the right tool for the right job. Using the wrong tool for the job may look pretty but it never ends well.