Would you benefit from file manager on your Kobo reader?

Originally Posted by TechniSol

I'm all about choice, and I can see how people might find it convenient to have all their books on the reader. Let's say you're reading a couple of books, but just aren't in the mood to continue a particular title, or you're in the mood for something new...

Prior to ereaders, I was bad for bringing multiple books for multiple moods. The thing is, it would amount to a half dozen books at most for a journey lasting several days. I think the underlying issue is that people are less selective these days: they are used to having choices always available so they demand that choices are always available.

What I don't see is why you'd need a file browser to find it.

I think that this is because of the inherent limitations in Kobo devices. If Kobo allowed you so filter or sort books based upon any criteria, the demand would probably evaporate. Since they don'e allow you to filer and sort based upon any criteria, a directory browser (with a suitable directory structure) would serve the needs of those users better since the directory structure can be created by the user according to the desires of the user.

I'd like a multi level search/browser that lets me select the hierarchy or presentation order or sort.

Personally I agree with that paragraph, including omitted parts.

I'm amazed at how far we've come in 30 years. (snip) Why should we settle for a forty+ year old file browser concept?

If a technology is around for long enough, users will learn about it's benefits and restrictions, as well as how to work around those restrictions. While I currently use the latest in technology, I often wonder if I would be better off settling with something that is older and taking the time to lean it in depth, because innovation usually involves making things easier. Innovation does not guarantee making it more powerful -- indeed, sometimes it seems to make it less powerful.

[moffattm]

Originally Posted by TechniSol

Why should we settle for a forty+ year old file browser concept?

I was wondering exactly the same thing, TechniSol!

Directories (or "folders" for those that grew up with GUI's) were invented back in the 60's for the Multics operating system. They were a handy way of separating and sorting files. Microsoft has realised for a while that directories are actually quite limiting and started work on WinFS (Windows Future Storage) which combined file storage with a relational database for storing meta data about the files. Using this method it would possible to do all sorts of queries to get lists of files (WinFS did a lot more than just this, but this is the part that's relevant to this conversation). Unfortunately WinFS was cancelled, but some parts of it have made it into Windows; Windows 7 introduced the idea of a "library", where a file could reside in one or more libraries, thus allowing you to organise files in different ways.

IMHO accessing the Kobo's library via its database could be very powerful, allowing for all sorts of segmenting and sorting. With "shelves" we've seen some of this come to life, but there's probably a lot more you could do. Accessing the library directly via a simple file system seems like a step backwards to me.

[DNSB]

Originally Posted by BWinmill

I've lived in Vancouver and in stone's throw of the western side of the Rockies (Calgary). I can totally see a Vancouverite burying their nose in a guide book rather than looking at the real world because the Pacific coast is amazing in comparison. The diversity of plant and animals in Vancouver is amazing. You don't even have to leave the city to see animals like coyotes and a much richer variety of birds than you'll see in the wilderness west of the Rockies. I think it's safe to say that you'll see more variety in the plants of a square meter of the lower mainland than you'll see in a square kilometre of most parts of Canada.

So feel free to admit that the hiker engrossed in the guidebook was you.

I still live in the greater Vancouver area. The array of wildlife is amazing -- racoons, bears, coyotes, rats have been seen here in the last couple of days. As for birds, a couple of herons on the mud flats, a bald eagle and the more usual selection of Stellar blue jays, etc. It's a lovely area to live in with the ocean and the mountains in our backyard.

Beats where I used to live when the question was "Where were you the night of Nov. 14th to Jan. 25th inclusive?" An area where we thought Edmonton was in the deep south.

As for the hike, I didn't have my nose buried in a guidebook. I was the guy wearing a couple of cameras taking pictures of anything that stood still for more than 2 seconds and quite a few things that didn't.

Regards,
David

[theonna]

Originally Posted by moffattm

IMHO accessing the Kobo's library via its database could be very powerful, allowing for all sorts of segmenting and sorting. With "shelves" we've seen some of this come to life, but there's probably a lot more you could do. Accessing the library directly via a simple file system seems like a step backwards to me.

As it stands right now, this is irrelevant, because database access is not very powerful yet, it does not allow for all sorts of segmenting and sorting. Even worse, a simple file system is not yet available to compensate for shortcomings of the current state of the database. Kobo does not have prospective great database system working, but it already does not have old reliable file system working either. Where is logic in that?

[ottdmk]

theonna, you're making the assumption that a file browser is a default technology. It's not. If a pre-existing plugin, it must be integrated. If a new piece of software it must be designed, developed and integrated.

All of which adds up to time, and in sixteen years of life in high tech I have never heard of a dev team with enough time to do everything.

So, given that Kobo has adopted database as their file location method... why waste the time on a file browser? The more logical course is to spend the time improving the database experience... or implementing other features they feel will drive people towards purchasing their product.

Sufficient demand will get a company to implement just about anything. Given that even Amazon, the undisputed worldwide leader in e-reader tech, hasn't seen sufficient need to implement a file browser system with directories/folders... why in the world would anyone else see it?

[TechniSol]

Huh? On the library book interface, rather than a drop down list of a couple of simple premade sorts, you'd require a horizontal line at top of about three list boxes, drop downs or buttons to select the sort hierarchies from existing choices like: Genre, Title, Author, Publisher, Shelf, Series, Recently Read, etc., other choices could be pulled from metadata.

Selecting: Genre, Author, Title, from left to right in the new drop downs would yield a list sorted by Genres, within that by Authors and within each Author by Titles A-Z... which would be most peoples's hierarchy if they created a directory/file based hierarchy. If you could not still find your book by title in a sort you drilled down through, you'd then hit a search button, select either a metadata tag to search for or enter a phrase to search from the default book summary metadata field. The advantage is you could quickly narrow down the scope of the search by selecting the level at which you want it performed rather than searching the entire database.

Better yet, forgot the Author, no sweat set the top list sort parameters to Genre then Title and look at every Title A-Z in a certain Genre. Again narrow it further with the Metadata field Search if you can't find it by looking at the Titles for the Genre alone.

Just a simple idea, based on how people usually look for things while leveraging the computer to do the heavy lifting. By narrowing the search you speed things up considerably.

[guma]

There is a fairly easy to implement technical solution that should serve both camps participating in this discussion:

(1) implement multi-level shelf support (something I would consider a huge improvement by itself)
(2) implement an (optional!) feature to auto-create multi-level shelves based on file structure (i.e. each directory becomes a shelf, directory name = shelf name)

That way you'd have a simulated file browser while completely adhering to the general metadata/library based approach as currently implemented.

[TechniSol]

You could do that, but why bother? The method I outlined doesn't care about physical structure except when titles are added and it must record their paths which must be done in the dBASE already. If you wish to browse a "Shelf" set the dropdown lists to create the virtual shelf sorted by whatever criteria you like and voila. Think about how much this can speed up varying waits we experience now. All new titles can be dropped into one folder location and only that location need be checked each time you power cycle as deletions would go through the database as well. The ereader would only need to check for new books in that one location and not have to verify the database on every power cycle. It would move the new submission out of that directory and add it wherever it thought appropriate, or could even be set to preserve your directory/file structures. The actual physical locations are irrelevant, the file structure you see now is merely an abstract illusion represented to you by the file system.

[theonna]

Originally Posted by TechniSol

You could do that, but why bother? The method I outlined doesn't care about physical structure except when titles are added and it must record their paths which must be done in the dBASE already.

The method that you have outlined has not been implemented yet.
File manager is not something that developers team need to develop, the reason Amazon and others don't want file manager has nothing to do with ease or difficulty of its development, because it is already there, it has to do with their desire to protect their content. Operating systems that run reading devices all have file management system, it is a choice of management to close this system from user and offer instead artificial extra layer for "convenience". I am sure designing shelf and database construct is far more laborious than using existing file manager. It is a matter of choice, not resources.

[TechniSol]

Theonna,

Pretty much all of the code necessary to do what I've outlined exists in the various single level sorts they already employ on the Library:Books menu options and pull down. I'm just suggesting a slight interface refinement in the GUI and addition of a multi-level sort and search function like they already have to be used on the results at any given level and downward.

[leslie_ms]

Originally Posted by theonna

leslie_ms
For your use, I'd agree with you completely. You probably won't even need all of the room you got on your Touch. I don't know if you like archiving your books on your computer, if you do, then years later you have a chance to go to your archive and find your old book. And may be Kobo would survive too.
But idea of a large on device collection of books works for extended trips, long hiking vacations, where you know your eink device would have enough charge, but would not have internet access.

Yes, I archive my books on my computer. Computers are made for this purpose and I've successfully transferred those files from one laptop to another. (Although, I probably should get around to copying them to an external backup before disaster strikes. )

And you're right. I don't need all that room on the reader. Before going on vacation, I make sure I have enough reading material. For me one book per week is plenty. When I'm away, for vacation or business, I'm busy doing other things and not reading much.

I should also mention that I read a lot of books from the elibrary. Over the last 12 months, 50% of my reading has been from the library. I anticipate that's it's going to be even higher in the next 12 months.

Leslie

[guma]

Originally Posted by TechniSol

You could do that, but why bother? The method I outlined doesn't care about physical structure except when titles are added and it must record their paths which must be done in the dBASE already. If you wish to browse a "Shelf" set the dropdown lists to create the virtual shelf sorted by whatever criteria you like and voila. Think about how much this can speed up varying waits we experience now. All new titles can be dropped into one folder location and only that location need be checked each time you power cycle as deletions would go through the database as well. The ereader would only need to check for new books in that one location and not have to verify the database on every power cycle. It would move the new submission out of that directory and add it wherever it thought appropriate, or could even be set to preserve your directory/file structures. The actual physical locations are irrelevant, the file structure you see now is merely an abstract illusion represented to you by the file system.

The 'auto-create shelves by directory structure'-approach would cater to users who happen to already have a library well organized by file names and directory structure. Since re-organizing an existing library for metadata based library management is (1) a PITA and (2) not completely independent of how a specific device handles the tags I would consider this a valid use case worth some development effort.

The advantage compared to implementing a 'real' file browser is that, from the use case perspective, it would be reasonable to request a file browser to include file handling functionality. This is something that could NOT easily be implemented while keeping to a general metadata based paradigm for library handling - at least not on a device that takes as long as a KOBO to rebuild/update the database.

Assuming a completely and consistently tagged library there is, of course, no real need for a file browser style interface and I agree that in this scenario refining search, sorting and filtering options would be preferable. But this is a separate use case.

[luigizanotti]

I do have a 'library well organized by file names and directory structure' and I would love to have a 'auto-create shelves by directory structure', but I don't shed tear for its absence.

Also, I don't feel the need of a file browser: I know more or less what's on the device so the search function is all I need at this point in time.

What I would really need is a realiable system for taking notes and making highlights, which I would also love to be far easier to navigate (something like the function on the Paperwhite). As of firmware 2.5.2 notes didn't work at all on sideloaded EPUBs, a function I need since I need to proofread a lot.

[Ripplinger]

I set up Browse Folders on the Home screen of my Sonys originally (an option with PRS+) and thought it would be great to use. However, between Collections (Shelves on the Kobo) and sorting by author, I found I never had a need to use the Browse Folders option, it was just redundant, so I removed it from the Home screen.

So for me, using Shelves or Collections works perfectly so I don't need a Browse Folder option. I sideload all my books through Calibre and sending books to either my Sonys or the Kobo Glo automatically puts all books into Collections or Shelves based on my tags for genres without me doing anything else (and I keep the tags simple, 1 tag per book only).

It would be nice though if everyone had the option to Browse Folders if they choose or not, the way PRS+ has enabled the Sonys. Giving readers options is always the best solution.

[Uschiekid]

Originally Posted by luigizanotti

What I would really need is a realiable system for taking notes and making highlights, which I would also love to be far easier to navigate (something like the function on the Paperwhite). As of firmware 2.5.2 notes didn't work at all on sideloaded EPUBs, a function I need since I need to proofread a lot.

Sideloaded epubs' annotations/bookmarking DO work if on an external SD card. That's one reason I moved mine onto my external SD and left the kepubs on the internal memory. The only exception is library books have to stay on the internal, so I'm always "re-annoyed" when reading them by the uselessness of bookmarks that all say 0%.