On 1/4/2011 5:07 AM, sideral wrote:
> [2] I've outlined some problems I've had with the bookmarking system in
> this comment: http://www.rockbox.org/tracker/task/11748#comment37597
>

If I understand correctly, these are your problems with bookmarks:

* Bookmarks can only be found through the file browser, and not through
the database.

-This is something that should be fixed anyway.

* Separate interface to bookmarks, which is different from the usual way
of selecting tracks through the database or the file browser.

-A "Resume last bookmark when file is played" option would cover most of
auto-resume while using the bookmark system. The fact that it's
currently presented the way it is isn't a reason that its UI can't be
made more "natural."

* Sometimes, no bookmark was created on power-off.

-Bug, not a reason to implement a new redundant system. Fix the bug if
it's a problem.

* Sometimes, the recent-bookmarks list was not updated.

-Bug, see above.

* Bookmarks don't work when files have multiple extensions (my
podcast-synchronization software unconditionally adds a file-type suffix
for all downloads, and thus often creates files ending in “.mp3.mp3”,
for instance).

-Bug, see above.

Basically it sounds like your objection to improving bookmarking is
"it's buggy" but those bugs need to be fixed either way, and if they
would address most of your expressed concerns, that's a net win. There's
no reason why the UI for resuming bookmarks couldn't function similarly
to auto resume *plus* having the expanded capability of allowing people
to have multiple bookmarks.

The objection I have to your UI is "it's more complex than necessary to
expose the functionality." If the bookmark UI can be streamlined to
expose the same functionality while being less complex, I'm all for it,
but there's a difference between objecting because "it's complex" and
"it's more complex than necessary."
Received on 2011-01-04