|
Ken,
If I contributed to that, I apologize, but we're talking about the user interface, not redesigning the core functionality of the system. I don't think kobo would realistically start over from scratch. Nor do I think a reasonable outside group would either... So I think the database is here to stay.
If properly implemented it is the best way to go, in that information should only need to be read, processed and sorted ONCE, not every time a file browser is started to select a book. Properly implemented it means FASTER times as only pointers or references to data need be manipulated instead of the whole record and assorted fields for a variety of searches, rather than limiting the user to browsing based on the only structure being the file directory structure.
Depending on how you wish to search\browse vs. how you implemented the file structure you'll be grinding a lot of gears looking for what you want. The file structure browser thing seems to have the greatest appeal to people who are convinced they will only ever need to locate things or sort them based on one premise -whether they realize it or not. Isn't it better to have a list of all your mysteries, poly-tics, etc. as well as be able to sift through by author, publisher, "whatever" tags without having to store multiple copies of the same books?
I think if Kobo had the idea of having a simple browser or just a directory input field to allow a user to specify where to start processing files(hell, just specify a "start here" directory and process it's contents first) and changed their programming so they could process files in the background while quickly presenting the user with some choices and a book to read in the meantime would be a great step forward when one must process a huge card full of books not present in the database. Just a wayward thought, Kobo... Not everything must be completed in advance of allowing the user to do something with the device. Linear thinking is not always the best. Outside the box does not mean inside the next vessel instead. Om, mani padme, hum...
I also think that if you want a full blown file browser you should be able to have one, but I don't expect Kobo to provide it, nor do I see how it would be faster than a properly implemented database as it would need to scour the file system each time it was started up... and so would you! I think you'd be a lot better off asking for/developing a pseudo file browser interface that used the information in the database since it is already present and sorted in some fashion -possibly dropping the book covers to speed processing if that truly is the bottleneck. Matter of fact, you'd be way ahead. Why must everyone who wants a file browser wish to force it on everyone else? More importantly why schlog through all that data over and over on a device having limited resources?
But what do I know?
|