mathwizard1232 / book Goto Github PK

The categorization system is key to the overall idea: being able to mark a book as taking place on Earth (vs Mars or extrasolar, etc), or having FTL and so on.

There will be a lot of work needed on this. I'm not certain yet what the minimum starting point is. Perhaps the system for modifying categories should be built first, to be able to create the categorization. This also starts to imply some of the other future issues (synchronization between different nodes and backups: for the first, looking to avoid duplication of work and how to make sure that data is consistent if there were parallel slightly different categorizations created; for the second, starting to get more than just test data and how to design the overall backup / restore process and how it might interact with syncs, etc. (i.e.: beyond just doing a SQL backup, maybe the system has its own conception of "backup to this node" or "restore from this node" etc)).

So, let's say we've got a local system for creating the categorization of the labels themselves (e.g.: Add technology "cloning").

Then we need the screen to be able to add/edit/review these for a particular book.

When adding, simplest starting point is of course just display all options for categorization. However, this will ultimately get unwieldy, so going to want eventually a "most popular" labels option, or suggest labels, or a user's most commonly used. Probably combine these into "suggested / most common" vs a full view; maybe even have on same page but have second collapsed?

So might look something like:

=========

Categorizing Moon is a Harsh Mistress.

Select any that apply:
[ ] Setting - Earth
[ ] Setting - Moon
[ ] Setting - Mars
[ ] Politics - Libertarian
[ ] Politics - Conservative
[ ] Politics - Communist

You may also expand and select from these options:
(collapsed options)

=======

Maybe user configurable to always see full view if they want?

If we enter an author like "Smith" we have multiple options.

The system should prompt for selection among the options or to enter a new one.

Setup a process for some automated tests on the code

In my mind, there's a clear and sharp distinction between "a copy", which is a physical book which may have various types of damage vs "a Book" which is a conceptual chunk of content which we want to be able to categorize and recommend.

"a copy" is something like an instantiation of "a Book" ideal.

However, so far the system essentially is working with "Book"s (note that "add a book" with an existing book is a no-op rather than recording a duplicate currently, because what's it's adding is a "Book" rather than a "copy")...except that what's imagined when adding a book to a box is adding a copy to a box...so the implication is that the box-book relationship implies the presence of a copy in a box.

So there's a technical side of how to eventually build these representations (for instance: copies need to support recording condition / damage; boxes need to be able to store a particular copy rather than just note it has a particular Book represented) but perhaps even more importantly, I need to think about what a reasonable user experience is behind this, especially when it seems like the distinction is not particularly clearly well established in existing software.

In order to illustrate this, let me first add another intermediate concept, an Edition: like a Book an abstract rather than physical item, but it's a semi-instantiated version of a Book: it's information about a particular set of printings of it: who was the publisher? When was it printed? How many pages is it?

When one searches for a Book on Amazon, for instance, one is really searching among all Editions of all Books. If one looks then at used options, one selects between copies. But there's no process (so far as I know) for first searching among all Books and only then having to decide a particular Edition.

But in our system, we want to be able to have a more streamlined view: if I ask what Books Heinlein wrote, I want the Books; if there were two different editions of a Book, I don't want it appearing twice. Of course, reality doesn't always line up so nicely: there can be collections which duplicate content so that there's not quite this easy distinction. But I think it'll work as a model.

====

But we don't want the user to have to experience thinking through all of this. We want it just presented in such a simplified, logical way that it simply Makes Sense.

So think about it and figure out what we want the final system to look like and what sort of iterative steps will bring us there.

In order to do proper REST semantics and to not have long URIs etc, the forms adding boxes and books should be POST rather than GET. Making them as GET for now just to make it easier to see what's going on and modifying it. Should be changed before any version 1 release / deployment (but not necessarily before various small-scale uses).