I was planning to show how various entities might be defined, using the attribute declarations described yesterday… but it’s been a rough week.
Instead, I’ve been cleaning up some of my libraries, and found some features I hadn’t considered that I’d very much like to see in my graphical user interface.
By necessity, because the data entities have very few hardcoded fields (ID for most, and a handful of others for File) and many user-configurable fields, the user interfaces to display and edit the entities must be similarly configurable.
There are several aspects to this.
In the data model, I can see there are places where I’ll want to capture different information about entities that are the same in the abstract.
- Files have some common attributes (location, size, type, format, checksums) but files of different types have different relevant attributes. I can of course
- Images have resolution (number of rows and columns) and color depth. Some image formats (GIF and TIFF) have multiple pages (which can themselves have different resolution and color depth… perhaps better done as subfiles).
- Videos have resolution, runtime, encoding, audio tracks, and so on.
- Audio files have runtime, frequency, encoding.
- Ebooks have a page count.
- Archives have a format and contain files (i.e. subfiles).
- Documents of significantly different subjects (gaming vs. programming vs. cooking) might similarly have different attributes. If nothing else, I might want to keep tag sets separated: Similarly, depending on content-focused extensions I might want to limit which documents they can apply to: ‘code snippets’ might apply only to programming books and ‘characters’ to fiction books and videos.
In some cases and to some degree I can accept the pragmatic approach: all Files are likely to have the same attribute fields available. It probably costs less to ‘waste space’ by having fields on all records that I don’t use (‘resolution’ on a sound file or archive file) than to implement in multiple base tables or have supplementary tables to augment the information (File augmented Image_File and Sound_File and Video_File).
Most of the differences related to Document types can probably be handled much the same way. Yes, my RPG books and my programming library might use totally different tag sets, but (being many:many relationships) those are implemented in external tables already, all I have to do is constrain which attributes I edit in the front end.
Which brings me to the second consideration, how to manage the graphical user interface.
In describing the GUI earlier I said I expected to have three panes (navigation, list, and detail). I imagine I’ll often use this configuration, but I realized there are some things I can do it make it better for me.
- Define List, detail, and editor windows that can vary by entity type and subtype, and by purpose. I probably want to see different things when I’m browsing a list of magazines than when I’m maintaining my library of publishing resources.
- Support multiple configurations of windows. By this I mean not only having multiple views of a type, but multiple arrangements of these windows (incidentally, the topic that prompted this post).
Much of the above can be done by having separate libraries. For instance, by putting all my graphical publisher resources (textures, stock art, etc.) in one library and all my audio game development resources (sound files) in another, I can configure the libraries independently. I’d rather not do this, I’ve found that keeping multiple libraries configured consistently to be very troublesome, and having to switch between them as I look for different material is annoying. I’d very much like to have all my ‘game development’ stuff (audio and graphic resources, and technical references) in one place. I also would like to be able to merge my RPG and comic book libraries again.
Whether I merge the content of the libraries, though, I’d very much like to reduce the number of libraries. This is partly so I can see multiple types of content without changing libraries, but also largely so I can keep them configured consistently more easily.