Given (competitor's product), here are my humble requests.

Tell us about your wildest feature dreams. Or just harmless suggestions for improvement.
Post Reply
glebec
Junior Member
Junior Member
Posts: 4
Joined: Thu Apr 25, 2013 12:00 pm

Given (competitor's product), here are my humble requests.

Post by glebec »

I have a lot of physical media that I would like to catalogue, and in the past I have tried demo versions of the 'Pedias as well as a certain competitor's product (which we'll call "D"). I apparently ended up purchasing Bookpedia (I think – it's complicated), but with the very recent release of the latest version of that competing product, I am reminded of some quibbles that I have and would like to see worked on.

1. Consolidated library

This is the biggest issue by far. I can see from brief searching that it has been brought up many times before, so I don't hold much hope that you will change your stance on this subject any time soon, but I very much wish all the 'Pedias were housed in one interface.

First of all, it is conceivable that users could pay only for the "branch(es)" that they want (book, game, etc.). Each license would unlock that specific section / support within the main Pedia application. So you do not have to abandon your current pricing structure.

In its most limited form, the different sections would be completely separate tabs housed under the same wrapper GUI. However, ideally at least some functions would be totally integrated:
  • Search would span multiple library types
    Scanning would identify media type and automatically add to the correct section (with the correct edit window)
    Borrowed lists and locations could be made more robust and consolidated, especially with regard to checking what media (of all types) a given person has
    Collections could feature multiple media types
Those are just a few examples, but they are illustrative I think.

I understand concerns regarding the many fields required for each type. That is simple enough in a tabbed / separated view, where each window could have its own fields. In a potential mixed view (e.g. the mixed media collections I mentioned before, or a unified Library view) yes, you would have a great many different fields available. However, you could make a "customize view" options dialogue box that either included media type tabs for categories of fields, or dropdown lists, to keep it organized and sorted. Nobody needs to activate every available field in a mixed media view, right? You save the media-specific fields for single-media views or specific collections.

2. Cover view aesthetics

This is a minor but slightly annoying issue. "D" makes more of an effort for the covers to represent their real-world counterparts in size and layout.

Now, "D's" ridiculously over-the-top, resource-intensive skeuomorphic design is not what I am after. However, there are two issues – cover size and alignment – that, if tweaked, would make browsing by cover more representative of the actual physical media collection, which I would like. It wouldn't even have to replace the current layout engine, but instead could be an elective option (e.g. a checkbox for "more realistic cover view layout"). What would such a layout accomplish?

First, the 'Pedias line up covers by centering them vertically, gallery-style. While this layout traditionally works well for a few large images you want to examine for their artistic merit – say, a photo gallery, or paintings in a museum – it looks messy and harder to browse for emulating small physical objects in a large collection that you want to quickly browse through. Aligning the covers to a baseline by their bottom edge is neater looking (ragged top only, instead of ragged top AND bottom), and makes the covers feel more like gravitationally "settled" objects instead of floating images. EDIT: it also makes the relative size differences more obvious, leading into my next point:

Second, I note that Bookpedia does not attempt to size covers relative to each other (according to dimension data), instead fitting them within a bounding box. Obviously this stems from a desire to display a large-sized image for viewing. "D" however may or may not have hard limits on how big or small it will display a book, but I see that the dimension data is treated much more canonically than it is in Bookpedia. Personally I like this as it is actually easier for me to scan and remember different items by sight – "oh yeah, there's that handbook I got from the used book sale, and that huge coffee-table book, etc." When all the covers are squished into one average size bracket, it actually reduces that view's effectiveness at transmitting information, such as knowing what to look for on my real bookshelf.

Now, I admit that this is a matter of subjectivity and philosophy, which is why I proposed including these two changes as an alternative layout rather than a replacement. It would not even take too much programming, theoretically – establish the largest item size; render each item relative to that size and its dimension data; align everything to baseline instead of centerline.

Is this important? No. But it's one thing preventing me from buying further into the 'Pedia ecosystem.

Conclusion

Sorry for the long rant about relatively trivial matters, but these are only my opinions and I hope you take them as such. I would love to be able to happily buy into a full "Pedia" product that doesn't make me miss features in "D," since the 'Pedias focus on speed and function more than graphics, but I'm not quite there yet.

Best regards,
—G
User avatar
Conor
Top Dog
Posts: 5346
Joined: Sat Jul 03, 2004 12:58 pm
Contact:

Re: Given (competitor's product), here are my humble request

Post by Conor »

Thank you very much for the long and detailed feedback. It's always nice to hear exactly what a user is looking for.

1. As you saw, the question about consolidating all four programs into one has come up in the past and it's still on the back of our minds as a possibility for the future. But it would be such a giant change and we'd essentially have to create a whole new program since everything from UI to features to functions would have to change, that this is unlikely to happen anytime soon. (Remember that there are only three of us here at Bruji and I'm the only one doing programming.)

2. You make an excellent point for the baseline alignment to be on the bottom axis and not centered for the cover view. In fact this is simply something that slipped through the cracks. Almost everything is built from scratch in the Pedias it was easy to find the line that does the alignment:

Code: Select all

cellFrame.origin.y += leftoverHeight /2;
For the next version I have now updated it two to stop the vertical centering:

Code: Select all

cellFrame.origin.y += leftoverHeight;
For taking the book cover size into account relative to other books in the collection I don't think is such a great idea. As you mentioned, the plan is to maximize the viewing details by using the most space possible for the cover. The dimensions, ratio, of the book cover are already built into the image. A coffee table book will be wide and short in comparison to a tall atlas. Taking the relative size into account means you have to be careful with edge case books that are extremely tall or short and would skew the rest of the view. Of course this could be handled by limiting the percentage that a book will resize relative to other books on the shelf. If technically it were simpler I would make it a preference, but the fact that the dimension data is a free form text field means that it can contain all kinds of information that needs to be interpreted correctly by a computer. With the large number of data sources that Bookpedia has this makes it harder than the competitor who only has a single data source with a somewhat standard dimension attribute. I have put these feature request into the long term feature list so that I can look into it at a later date.

As you mentioned the baseline change will now make the ratio of a cover more distinctive and easier to pick out without having to limit the size of the cover for smaller books. So do please try it out in the Bookpedia Beta version and let us know what you think.
glebec
Junior Member
Junior Member
Posts: 4
Joined: Thu Apr 25, 2013 12:00 pm

Re: Given (competitor's product), here are my humble request

Post by glebec »

Thanks for the detailed reply! I tried out the Beta and I am happy that my design theory seems to be borne out in practice; bottom baseline does look neater, to me at least. I'm glad that if nothing else, some of my feedback will have been constructive.

I see what you mean about scaling by size being a tricky proposition with a lot of extra programming attached, and don't bemoan the absence of this feature too greatly. It is something I would like, but not a deal-breaker by any stretch of the imagination.

The separation of 'Pedias on the other hand is unfortunate but understandable. I would not relish being the sole programmer in charge of consolidating multiple programs like that, I can see it being a monumental task for sure.

Thanks for your consideration,
—Gabriel
glebec
Junior Member
Junior Member
Posts: 4
Joined: Thu Apr 25, 2013 12:00 pm

Re: Given (competitor's product), here are my humble request

Post by glebec »

Posting as a second comment so it generates an updated subscription / new post count:

I also notice that in grid view there is padding on the right side of the window, but not the left. I think a little left padding would look better than none.
User avatar
Conor
Top Dog
Posts: 5346
Joined: Sat Jul 03, 2004 12:58 pm
Contact:

Re: Given (competitor's product), here are my humble request

Post by Conor »

You're right that there should be a slightly bigger left margin given the cover border option that touches on the left side when active. This update was more complicated as it involves embedding everything in another view. I also took the chance to take into account the possibility of the user using the new overlay scrollers that are not present all the time and actually leave less of a margin on the right in those cases as those are thinner. New Bookpedia beta up. If anyone has graphical glitches in the cover view with the left margin or the scroller side do let me know as this was a bigger change.
glebec
Junior Member
Junior Member
Posts: 4
Joined: Thu Apr 25, 2013 12:00 pm

Re: Given (competitor's product), here are my humble request

Post by glebec »

I see; I did have the cover border option enabled (actually I didn't notice it was an option). The new Beta looks better and is working fine for me at first blush.

...There's no thumbs up or clapping emoticon... pretend there is one here. ;-)
User avatar
sjk
Addicted to Bruji
Addicted to Bruji
Posts: 529
Joined: Sat Feb 21, 2009 9:01 pm
Location: Eugene

Re: Given (competitor's product), here are my humble request

Post by sjk »

glebec wrote:… a certain competitor's product (which we'll call "D").
I'm guessing Delicious Library (DL). :)
I would not relish being the sole programmer in charge of consolidating multiple programs like that, I can see it being a monumental task for sure.
I just noticed Joel Ares released Library Hunter (LH) last month, essentially merging {Book,DVD,Game} Hunter (aka Hunter Suite) into a single app. Maybe less monumental than doing it with the 'pedia apps, perhaps with more "legacy" codebase and other factors to deal with, would be. And DL, which I'd used v1 of before switching to DVDpedia, originated with the single app, multi-library approach.

DL and now LH are the only OS X apps of this genre I can think of using a unified interface instead of separate apps like the 'pedias and a some others (e.g. the herd of "Collector"s from collectorz.com) do. And some only offer one category (e.g. Coollector Movie Database).
Post Reply