Let’s say you have a library of books subdivided according to collections. One day you have acquired a new book and it will require a new collection as well.
Do you:
A) Go to /collections/add to create a new Collection and then redirect to /books/add/id (where id is the Collection.id)?
B) Go to /collections/add to create a new Collection but make the view file include Book fields and create both at the same time in the Collections controller?
C) Show /books/index organized by Collection and have links next to each that go to /books/add/id (where id is the Collection.id) … and also have one link for (add Book to new Collection) which goes to /books/add/ (no id) that can manage the Collection creation process before adding the new Book (but then you have to find a way to get a new Collection name from the user)?
D) Go to /books/add and when the Collections pulldown menu doesn’t include the needed Collection, redirect to /collections/add and then come back to /books/add to now see the just-added Collection?
E) Go to /books/add and make an ajax “new collection” routine within the view file in order to create the new Collection right there as needed?
F) Go to /books/add-to-new-collection and do it just like (b) above, except that your controller is Books and not Collections?
G) Something else?
Keep in mind:
A collection just a container. Without any books, it is junk data. If the user creates a new collection, it should only be if there is also a new book for it. Likewise, deleting the last book in a collection should delete the collection as well.
A book without a collection is “orphaned” and will lead to extra work in the GUI and for the user, so we’d rather avoid this situation as well.
Moving a book from one collection to another, represents fixing a mistake… so it’s an unusual and rare task that maybe shouldn’t be technically possible which means books should be properly assigned to collections from the moment of creation
The above three points mean many of the above strategies would need some form of “transactional” approach across more than one controller… some means to keep track of when an empty Collection or orphaned Book exist and rollback if that is the case.
If you expect a lot of collections, then maybe /books/add, and use an autocomplete JavaScript widget that lets you either select an existing collection name or type a new one.
If it’s a medium number of collections, then I think I like the first part of C, but have a link on that page to add a new empty collection. That list can also have links to delete empty “junk” collections, right? I don’t see an empty container as being a flaw in the data, but just something waiting to be filled up.
If there will be very few collections, such that creating a new one is a rare thing, then extra bother to do so isn’t much of a concern, so then I’d go with A or D, which seem pretty much the same to me.
This might also depend on whether books can be in multiple collections or just one.
I have a common function that looks for dependencies that would be orphaned if a parent record gets deleted, and prevents deletion of that parent record in such cases (with a summary of what is depending on it). Moving a book should be as easy as editing it and selecting a different collection in the dropdown?
If this is the actual situation, then I am perceiving the book is more important than the collection. (I have the exact same issue with documents in a binder [which is then in a storage box!].)
So I’m seeing the book as the principle. I add a book, but I’m not seeing what collection it belongs to, as its then I decide to make a new collection for it. Maybe I’d like a pop-out screen, or just a edit control where I can type in a description and fill the rest out later (maybe after I finish adding the book it goes back to editing the new collection).
This is my point of view as the end user (not a programmer) so I am not focusing on what’s possible, or even easy, just on the logic flow of entry. So for me its E.
Programmer in me says, if you do E and don’t save the book you’ll have an empty collection - so need to check the same routine you’ve obviously written for delete book which checks empty collections.
You’re absolutely correct that (at least in the way I had envisioned this) the book is more important than the collection. In fact, the collection is simply a way to keep books together much as you might have several different browser windows open, each with lots of tabs open. Then you have your tabs grouped and can minimize a window (entire set of tabs). In that sense, the collection itself is structurally meaningful but not meaningful in the absence of the actual items it contains.
With a browser, opening a new window is synonymous with opening a new tab. This detail doesn’t become apparent until you open at least one more tab to realize you already have a parent container. Likewise, closing your last tab does away with the window. The user is never required to think about this. It just happens for them.