Support and General Use > User Interface and Voice
Opinions of User-friendliness in rockbox
pondlife:
I think I pretty much agree with Llorean, so I'll quote him...
--- Quote from: Llorean on January 28, 2008, 06:35:29 PM ---quickscreen: Repeat and shuffle often have dedicated buttons on CD players (and actually several MP3 players I own), making them semi-obvious targets for a quickscreen. File view, I think, is arguable for presence on the quickscreen though.
--- End quote ---
I'm happy with the current quickscreen, but if it's to be made customisable, I'd prefer it to point to the existing "Browse CFG Files" option. That would be flexible, customisable and reduce the code size. (If we really have to, there's nothing stopping us shipping some simple CFG files - "Shuffle Off", "Shuffle On" etc., although I'll admit that's not the best UI.)
--- Quote ---right vs select: I personally think "Select" should be the customizable one. "Right" should ALWAYS enter a folder, never insert it, since it's a "navigation" key. Other than that, I wouldn't mind giving "Select" a list of possible options, that list being "Same as right" plus every choice in the Insert / Queue list of options.
--- End quote ---
Totally agree. I'd probably keep SELECT=RIGHT myself, because I'm used to it, but I might try using it to Queue.
--- Quote ---bookmarks: Yeah, they're at least half broken most of the time, aren't they? Maybe a GSoC project could be removing then, and reimplementing them from scratch with a better UI?
--- End quote ---
The main problem with bookmarks is that they are Folder-based. They need to be Playlist-based. I have an "AllRandom" playlist which I can jump to at any time when I don't really know what I'd like to listen to but I end up reshuffling it each time, when I should be able to carry on where I left off, using a bookmark. I'd like to be able to listen to my big playlist until I feel inspired enough to go and choose an album, then later return to where I left off. (Hope that makes some sense.)
The code for bookmark handling is also overcomplicated IIRC; e.g. when I last looked there was different code for bookmark resume and normal resuming. I'd hope that if bookmarks were always per-playlist, we could manage a dynamic.bmark which would handle the normal playback resuming without any code complexity. Of course, this would only be updated on spinup/shutdown, but that could be true of all bookmarks.
--- Quote ---menu: Yeah, I was going to propose a reorganization, but being the lazy sod I am, haven't gotten around to it yet, beyond printing out most of the menu structure. Devcon could be really good for this.
--- End quote ---
I think we're all agreed on this one - perhaps you could delegate some aspects of it?
--- Quote ---Hidden Folders: If a user doesn't want a folder hidden, they SHOULDN'T HIDE IT. The OF quirks that apply JUST to the Sansa shouldn't be coded around. When we have our own USB mode it won't matter anyway.
--- End quote ---
Absolutely. Hidden folders should be hidden. If some braindead OF does silly things, then that's a problem with the OF, not with Rockbox.
--- Quote ---Stop: I think Stop and Select should behave identically in terms of what screen they return you to. Specifically, for blind users, "Stop" is more practical than "Pause, then Select" since pausing stops the voice. If they want to clearly hear the name of the song being played, Stop needs to go to the current file. It's been requested an awful lot by them, and I think "Stop, then Menu" to get to the menu isn't too much of an imposition as opposed to just "Stop" getting to the menu, unless you feel like getting Voice to play while audio is Paused. ;)
--- End quote ---
Yes, STOP and SELECT should behave identically (with the exception of stopping music). I didn't realise this was broken until recently...
pondlife
shotofadds:
--- Quote from: pondlife on January 29, 2008, 03:59:26 AM ---Hidden folders should be hidden. Â If some braindead OF does silly things, then that's a problem with the OF, not with Rockbox.
--- End quote ---
Maybe a cheap solution would be for RbUtil to unhide the Music folder during installation, on those players that need it?
Lear:
--- Quote from: jdgordon on January 28, 2008, 06:28:50 PM ---as for the playlist viewer.... I agree that its one of the more hidden screens and should be fixed up... first thing it needs to hapen is it to stop using the plugin buffer to store track names (why is this done anyway? doesnt playlist.c have a function to get the track name of any track in the playlist?)
--- End quote ---
The plugin buffer is used to buffer the filenames, which are (often) loaded from disk when getting a filename from a playlist. If the dircache is enabled, you might get away with not using the plugin buffer...
--- Quote ---bookmarks... another probably great feature which is a bit horrible (imo) to use which could do with some TLC from anyone with an idea how to do them better *looks around at the blank stares*
--- End quote ---
I think it is very good as it is, actually (for me, it's one of the killer features in Rockbox). True, I don't use the database, nor create dynamic playlists, so I don't really encounter the big limitations... 8-)
Oh, by the way, the bookmark viewer also uses the plugin buffer.
(Hrm, had to google TLC. Naughty, naughty...)
cpchan:
--- Quote from: shotofadds on January 29, 2008, 06:14:25 AM ---Maybe a cheap solution would be for RbUtil to unhide the Music folder during installation, on those players that need it?
--- End quote ---
Unfortunately this won't work at least for the Sandisk players. This is because the brain dead OF rehides it every time.
Charles
GodEater:
--- Quote from: shotofadds on January 29, 2008, 06:14:25 AM ---Maybe a cheap solution would be for RbUtil to unhide the Music folder during installation, on those players that need it?
--- End quote ---
That only works at installation though. The Sansa firmware re-hides it whenever you connect over USB - so would hide it whenever you transfer new music over.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version