Given (competitor's product), here are my humble requests.
Posted: Thu Apr 25, 2013 1:06 pm
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:
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
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
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