MobileRead Forums - View Single Post - IF you could design the user interface for the next Kobo Firmware

TechniSol · 06-10-2013, 08:18 PM

I don't see the concept as being all that difficult... It is not a full implementation, only a limited file selection dialog that organizes how it presents the data and pseudo directories to the user. Check me if I'm wrong.

I wonder if much of the problem couldn't be solved by the addition of a single directory simply called "New"...

Anything "New" that needs to be scanned into the database MUST be deposited there, that would be the only place the firmware would look. It eases the burden and time lag of scanning for new data, by eliminating it entirely if nothing is there. Can't for the life of me figure out why it wasn't done originally. Once the system (Kobo firmware) finds something there it changes the pointers to move the file into whatever directory structure the Kobo software wishes to employ and adds it's metadata to the database. Tack on a VERY simple browser interface with a set of metadata fields that define the hierarchy for the way the particular user wishes his pseudo file hierarchy to be browsed and away you go. The user need never directly act upon the library.

Obvious limits are the number of files that can be dumped to that directory at once(but that could be handled by allowing subdirectories to be searched within "NEW" or simply limiting the number transferred at a time.), that the different categories of metadata and whatever actual underlying categorization or structure of filenames would have to probably be pre-defined. ie: Genre:Author:Title to keep the number of actual directories in the real file system from exploding. And I'm sure there are a few others I'm forgetting.

I think this would be quite a reasonable way to eliminate unnecessary thrashing every time the device is rebooted and allows for multiple ways to organize and walk the list to provide just the experience the user wants when browsing. You just specify your sort hierarchy by placing one or more metadata options in order from left to right and click "Show me", or "Shazam!"... If a broad enough field of metadata descriptors were employed it'd be hard to find fault. Further, one could allow for user defined descriptors and corresponding browses or searches as is implemented in Calibre through the shelves field or series field by simply plucking them out of the database or noting them as new books are added. Kobo could likely reuse the vast majority of code already written to display shelves to form the "file selector", and shelves would just be another search organized by metadata...

The beauty of it is they end up with one interface to the library database structure that presents the data as the user would like to see it and probably end up with a net elimination of code by eliminating multiple hard coded ways of presenting the library now. They could even insert a few predefined obvious hierarchy displays like Genre:Author:Title for the uninitiated, or simpler ones like Author:Title, etc.

06-10-2013, 08:18 PM	#118
TechniSol GranPohbah-Fezzes r cool! Posts: 1,056 Karma: 3151024 Join Date: Jul 2010 Device: Nook STRs, Kobo Touch, Kobo Glo	I don't see the concept as being all that difficult... It is not a full implementation, only a limited file selection dialog that organizes how it presents the data and pseudo directories to the user. Check me if I'm wrong. I wonder if much of the problem couldn't be solved by the addition of a single directory simply called "New"... Anything "New" that needs to be scanned into the database MUST be deposited there, that would be the only place the firmware would look. It eases the burden and time lag of scanning for new data, by eliminating it entirely if nothing is there. Can't for the life of me figure out why it wasn't done originally. Once the system (Kobo firmware) finds something there it changes the pointers to move the file into whatever directory structure the Kobo software wishes to employ and adds it's metadata to the database. Tack on a VERY simple browser interface with a set of metadata fields that define the hierarchy for the way the particular user wishes his pseudo file hierarchy to be browsed and away you go. The user need never directly act upon the library. Obvious limits are the number of files that can be dumped to that directory at once(but that could be handled by allowing subdirectories to be searched within "NEW" or simply limiting the number transferred at a time.), that the different categories of metadata and whatever actual underlying categorization or structure of filenames would have to probably be pre-defined. ie: Genre:Author:Title to keep the number of actual directories in the real file system from exploding. And I'm sure there are a few others I'm forgetting. I think this would be quite a reasonable way to eliminate unnecessary thrashing every time the device is rebooted and allows for multiple ways to organize and walk the list to provide just the experience the user wants when browsing. You just specify your sort hierarchy by placing one or more metadata options in order from left to right and click "Show me", or "Shazam!"... If a broad enough field of metadata descriptors were employed it'd be hard to find fault. Further, one could allow for user defined descriptors and corresponding browses or searches as is implemented in Calibre through the shelves field or series field by simply plucking them out of the database or noting them as new books are added. Kobo could likely reuse the vast majority of code already written to display shelves to form the "file selector", and shelves would just be another search organized by metadata... The beauty of it is they end up with one interface to the library database structure that presents the data as the user would like to see it and probably end up with a net elimination of code by eliminating multiple hard coded ways of presenting the library now. They could even insert a few predefined obvious hierarchy displays like Genre:Author:Title for the uninitiated, or simpler ones like Author:Title, etc.