IF you could design the user interface for the next Kobo Firmware

[jackastor]

Originally Posted by Ken Maltby

"IF you could design the user interface for the next Kobo Firmware"

I must have missed the fine print where it said "But you can't suggest anything
that contradicts Kobo's design philosophy."

It says "If you could design the user interface", now if the "you" being referenced
were Theonna or myself a file browser that functions as well as those we are used
to from our other ereading devices, would be a major part of the changes we would
make. I would ask why some of you think such a suggestion would be out of bounds
for this thread?

There is also the potential source of confusion in the meaning of the term "Kobo
Firmware". Is this intended to mean only for official Kobo Firmware releases or are
we talking about preferences for the firmware for the Kobo devices? No matter who
should develop and release it? Are we supposed to restrict our comments to those
things that Kobo would accept and/or approve of?

I am not holding out much hope that Kobo will be the ones to provide the kind of
"User Interface" or firmware in general, that I feel would be able to take advantage
of the potential of this very good hardware.

Don't ask - then complain about the answers you get. Now a discussion about
what you think of the answers might be of some value, but suggesting that there is
a problem providing an answer that Kobo would never approve of, is going too far
IMHO.

Luck;
Ken

You did not miss the fine print, it just was never there. I think perhaps core design would fall under this thread as well because that's the meat of the user interface is it not?, IMHO.

And yes since Kobo did not start this thread you most certainly can challenge the design philosophy of Kobo.... with out challenge there can never be improvement.




regards

jack

[PeterT]

Originally Posted by speakingtohe

PeterT provided a method for doing this with calibre but I cannot remember what post. Was slightly different but could be easily modified to suit this purpose.

Helen

Try this post ---> https://www.mobileread.com/forums/sho...&postcount=183

[Terisa de morgan]

Originally Posted by speakingtohe

But calibre can do nothing to stop the random page turns or bring back the back bar or make my mini always sort books the same way

About sort, are we taking about shelves? I've noted that, when I go into a shelf, in some cases, although it says "Sort by title", it really is "Last date read". In other cases, it always sort in the same way. Are you talking about any other thing?

[Uschiekid]

Originally Posted by Ken Maltby

OK, as this is "Mobileread" Forums, I guess I should give more consideration to those who are reading on smaller screens, and not format my lines in a manner you of tiny screens may have difficulties with. This approach doesn't help with any tendency I might have for run-on sentences.

Luck;
Ken

I'll give you the advice my 6th grade teacher gave me....if you can't say it with one breath, it's TOO LONG!!

Actually, it was more like a sadistic demand that I read every sentence she'd marked as too long out loud to her.

[Uschiekid]

Originally Posted by DNSB

The ACCESS renderer does handle those text direction directives but some of the other features such as the table of contents displaying correctly even if the default font does not contain the glyphs are handy. Unfortunately, it seems that ability is limited to searching the Kobo supplied fonts and does not extend to sideloaded fonts. A Malayalam table of contents entry does not display but a Devanagari one does for example despite having two sideloaded fonts that handle Malayalam glyphs.

Regards,
David

Ah, ok, I see. I tend not to use the TOC all that much unless I take a longish break from a book and want to remember stuff. But it would annoy me if the TOC displayed a bunch of boxes when I did want to use it. Thanks for the explanation.

[JSWolf]

Originally Posted by haydnfan

I would like the ability to toggle between screen turns per chapter and per book. The current style is per chapter, which I like for long novels but not for short novels.

Before people say sideload epubs, I never liked the faux Adobe page numbers. It has neither the precision of location #s, the reference-ability of real page numbers, nor the intuitiveness of screen turns. Adobe page numbers are garbage.

Actually, Adobe page numbers are a lot better then location # which have no meaning for most people.

[Ken Maltby]

TechniSol;

I agree on the concept you are describing, and we could certainly "have both" but I think you are underestimating both what is accomplished in indexing and in the process of building a menu listing of files.

In concept; the SQL database provides an abstraction of the file system, long one of the original goals of a "true" Operating system. If Kobo had it implemented to the potential of the concept, what would appear to the user as "a full blown file browser" would be the simplest of things to provide. The actual file structure, management and initial construction, would be irrelevant. (That being the point of the abstraction.) Please note that this argument works both ways, an efficient user managed file structure would not be an obstacle to the SQL based features.

Menu Browsing is part of the current FW, you browse search results, you browse the shelves. Providing the ability to browse a hierarchical menu of the files couldn't be that big an issue, except for Kobo's design philosophy.

You seem to see a demanding "need to scour the file system each time it was started up" as something that isn't needed with the existence of the SQL database, but in reality the OS needs to do much of what I presume you are referring to, with or without an SQL database in the mix. Some of what you may be referring to takes place in the menu building process often on a page by page basis, not all at one time, for all the files in the file structure.

I keep getting back to the fact that other much less powerful ereading devices have no problem dealing quickly and efficiently with large file structures, using the simple file browsing approach. But as you mention the database book sorting should be superior to a simple file menu browsing approach. I am encouraged that there is some evidence that Kobo is improving the file processing. Maybe it will get to the point that it functions as well as the other ereaders out there. But, as far as the adding the ability to browse the file structure, they could add that any time.

Luck;
Ken

[DNSB]

Originally Posted by Ken Maltby

In concept; the SQL database provides an abstraction of the file system, long one of the original goals of a "true" Operating system. If Kobo had it implemented to the potential of the concept, what would appear to the user as "a full blown file browser" would be the simplest of things to provide. The actual file structure, management and initial construction, would be irrelevant. (That being the point of the abstraction.) Please note that this argument works both ways, an efficient user managed file structure would not be an obstacle to the SQL based features.

Considering the time and effort that has been tossed into database file systems, it may not be as easy as you think. Microsoft gave up on WinFS as one of the pillars of Windows Vista for example. The only company that seems to have managed to produce a usable product is IBM (see Fortress Rochester for more information). Apache's Hadoop and the very off the beaten track Google File System have some database file system concepts included in their design.

Regards,
David

[PeterT]

Originally Posted by DNSB

(see Fortress Rochester for more information).

Sheesh... If you could just have said AS/400 it would have saved me going to look!

[speakingtohe]

Originally Posted by Terisa de morgan

About sort, are we taking about shelves? I've noted that, when I go into a shelf, in some cases, although it says "Sort by title", it really is "Last date read". In other cases, it always sort in the same way. Are you talking about any other thing?

My shelves do not always sort the same way. Sometimes title seems totally random. I think I may be the only one who has noticed this, as most often they do sort correctly.

Strangely enough if you have a collection with all of the books in it the last read sort might occasionally sort by last read.

When I got my mini, I made a collection with all books (843) in it. The purpose was to see if it would sort by last read as there were both last read and recently added options under the shelf sort menu. The first time I tried it it worked perfectly. Then I got a firmware update and it didn't work so I thought they had destroyed that ability. Unfortunately a collection of 843 slows down the shelf opening quite a bit.

Now, thanks to Davidfor and PeterT, I will no longer be whining about the recent read sort, as today I got Davidfor's new GUI plugin working which gives us a finished and have both a finished and reading shelf on the Kobo

Helen

[PeterT]

Ah what I have seen in the past is this; when a shelf is opened initially, it is not always sorted by the selected view. Try changing the sort order after opening the shelf, even if the sorting claims to be doing what you wanted.

[speakingtohe]

Originally Posted by PeterT

Ah what I have seen in the past is this; when a shelf is opened initially, it is not always sorted by the selected view. Try changing the sort order after opening the shelf, even if the sorting claims to be doing what you wanted.

True. But it has sometimes taken two or three tries for me to get it to sort correctly. Maybe I use the sorting more than others as I almost always want it sorted by author because this is where I add my series info with calibre plugin.

Helen

[TechniSol]

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.

[Ken Maltby]

Originally Posted by DNSB

Considering the time and effort that has been tossed into database file systems, it may not be as easy as you think. Microsoft gave up on WinFS as one of the pillars of Windows Vista for example. The only company that seems to have managed to produce a usable product is IBM (see Fortress Rochester for more information). Apache's Hadoop and the very off the beaten track Google File System have some database file system concepts included in their design.

Regards,
David

It is not the implementation of a "database file system" that I said would be easy. I said that "If Kobo had it implemented to the potential of the concept, what would appear to the user as "a full blown file browser" would be the simplest of things to provide." Perhaps the posts between your's and mine suggest Kobo has yet to accomplish that. Even without much more improvement Kobo should be able to extract a menu listing, from its database, that conforms to the hierarchy of a user maintained file structure.

Luck;
Ken

[rem736]

instead of a file browser, how about just a "view by file name" organizational scheme (shows a listing of books/documents by file name in a-z/z-a order while disregarding the layer(s) of folders containing the files)? it would still use the sqlite database. just fix the programming for the sqlite database (it's probably true that programming for the database is not optimized; otherwise, it would be so much faster).