How best to let a user specify a subsets of a series of really long lists of long titles?

Question

I'm writing a special-purpose CMS. It focuses on brief, rich text content as nodes in a large network of densely interrelated information. There are many different kinds of relationships, like "requires," "suggests," "motivates," "uses," and so on.

I'm designing the UI for specifying these relationships. Users can create and delete relationships from the Create and Edit screens for nodes. Presently, I have something like this:

It's hidden by the auto-complete dropdown, but there is a plus button which lets the user add another row.

The problem, I feel, is that things would quickly grow out of hand when a node related to more than a handful of other nodes. Multiply the interface below by a factor of about 8-15 for the other kinds of relations, and you see my fear: A screen full of text boxes! Ugh.

I've contemplated a sort of "tagging" text box, like the one Stack Exchange sites use to let users tag their questions, but I don't think that will work because node titles will be awfully long, compared to tag names. That about exhausts my inspiration though, aside from textareas that take one title per line, and those are definitely out.

Here's a quick recap of my situation:

Users need to specify lists of related nodes by their titles, which can be lengthy (20-80 characters, usually). The users will know what nodes they want in advance, so they don't need help discovering nodes. There's more than one kind of relation, and users will want to deal with each kind one at a time. Not every relation is guaranteed to be used, and the number of related nodes can vary drastically.

Thanks for your suggestions!

Answer 1

Targeting specifically to your "page full of text boxes", it is (as you have mentioned) very important that you avoid such a situation. Might I suggest another approach where there is just one text box that will be used to add the nodes, and the subsequent nodes are added as text links below it. You may observe the remove icon next to every node, which will be used to remove the node if required.

So as the user keeps on adding a node it will be added within the rectangle restricted to the scope of the page (div size that you want to provide for it). The benefits that it may provide will include: 1. Adding multiple text links will accommodate more nodes in the same space that too in a neat and readable manner. 2. Dynamic rendering of input fields will not be required.

If required you may provide for a transparent scroll bar which will appear when the content exceeds the limit that you have set. Thus may not need to scroll the whole page merely moving within the rectangle may serve the purpose. This may give a better user experience.

Answer 2

I've decided that my approach shall rely on two changes to the above scheme. First, the Add Row button will be moved inline with the text boxes. When there's only one text box, there will be only the Add Row button. When there's more than one, then the Delete buttons will be displayed. Observe:

This tells the user that can always add another row, and they can delete any row, and it does both of these things inside neat, uniform rectangles.

Second, I will use styling to remove the padding between text boxes, causing them to appear as one large element. This will have the effect of removing visual complexity. It will look like a textarea, but it will be more constrained in its behavior, optimized for entering one piece of data per line.