Rockbox Technical Forums

Support and General Use => User Interface and Voice => Topic started by: zajacattack on January 25, 2008, 06:21:20 PM

Title: Opinions of User-friendliness in rockbox
Post by: zajacattack on January 25, 2008, 06:21:20 PM
Now, this is a topic for throwing ideas around for a slight (perhaps bigger?) revamp of rockbox in favor of user-functionality:
First off, the Files menu: I have no trouble, but I know many users have problems with hidden files, perhaps someway to make turning them on easier? Suggestions?
Title: Re: Opinions of User-friendliness in rockbox
Post by: AlexP on January 25, 2008, 06:29:53 PM
So the quick menu (one button press on targets I have experience with) isn't quick enough?  I'm really struggling to think how you would make it easier.
Title: Re: Opinions of User-friendliness in rockbox
Post by: MarcGuay on January 25, 2008, 07:39:53 PM
Perhaps the question should be rephrased to "How can people be forced to read the manual?", but an option for this might be to default the setting to "view all files" if it isn't already.  Of course that might just lead to more people asking "How do I hide the files I can't use?"...

The only thing about the user interface I think could use a looking-over is the organization of the settings menus; sometimes I feel like they're a little awkward or go too deep, but given the number of options it's hard to keep that aspect simple.  

I get the impression that most people's confusion doesn't lie so much with the interface but with the installation process, navigating the website (a.k.a. having the necessary information presented to them before the forums, IRC, mailing list, etc), and understanding the terminology.


Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 25, 2008, 07:45:31 PM
I've got a full printout of most/all of the options menus, I want to reorganize them, but it's not a small project. Maybe one day I'll post a patch that'll piss off hundreds of users because I put the wrong options high up, much like the keymap changes. ;)

I'm curious the reasoning behind "All" being a possible default for file view. Why would you need to see files you can't use?
Title: Re: Opinions of User-friendliness in rockbox
Post by: MarcGuay on January 25, 2008, 08:18:47 PM

I've got a full printout of most/all of the options menus, I want to reorganize them, but it's not a small project. Maybe one day I'll post a patch that'll piss off hundreds of users because I put the wrong options high up, much like the keymap changes. ;)


I can tell your really anxious to deal with the blowback from that one... :)

Quote

I'm curious the reasoning behind "All" being a possible default for file view. Why would you need to see files you can't use?


I was really just responding to Zajac saying that a lot of people have asked "Where's the music folder that the Sansa firmware insists on hiding?".   Like I said, it would probably just redirect the question somewhere else, the real solution is in having people understand the quirks of each target and dealing with them.  

But there might be something to defaulting to "all" now that I think about it... There are files in the .rockbox folder that can be used (I have a backup config.cfg file that I often revert to) and that's only shown if it's set to "all"...  I guess the question on the table here, though, is "Would it make it more user-friendly?", and to that, I can't answer with confidence either way.
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 25, 2008, 08:23:23 PM
There's a "browse config files" option for that. You really shouldn't browse into the .rockbox folder ever.
Title: Re: Opinions of User-friendliness in rockbox
Post by: zajacattack on January 25, 2008, 08:24:06 PM
So, why not separate not showing hidden files from showing supported types? Something like:
-File View
--Show files
---All
---Supported
---Music
---Playlists
---Hidden
----Show
----Hide

Then, the default could be show supported file types and show hidden files.
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 25, 2008, 08:28:46 PM
The ONLY player that anyone even might want to see hidden files regularly is the e200 and c200, and even on that it only matters until the USB stack is working. Any other player, if they want to see the files they can just keep the folder unhidden.

I don't see hacking in extra pointless features as an alternative to "wait until the right solution is done".
Title: Re: Opinions of User-friendliness in rockbox
Post by: MarcGuay on January 25, 2008, 08:29:12 PM

There's a "browse config files" option for that. You really shouldn't browse into the .rockbox folder ever.


You sunk my battleship!  (More like a tugboat, but anyway).
Title: Re: Opinions of User-friendliness in rockbox
Post by: cool_walking_ on January 25, 2008, 08:36:42 PM
I think showing all files (as opposed to just supported files) by default is a good idea.  It's like that stupid "hide file extensions for known types" option in Windows.  I didn't ask to have information taken away, why is it missing?  Of course, hidden files are different, since you did actually ask for them to be hidden.
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 25, 2008, 08:44:06 PM
The files are hidden because Rockbox is an APPLICATION as well as a firmware. By default, when you tell a word processor to open a file, does it show all files, or just files it knows what to do with?
Title: Re: Opinions of User-friendliness in rockbox
Post by: zajacattack on January 25, 2008, 08:48:43 PM
It should show all files because you can often open a file with a different extension than custom dictates, as long as it is in the right format.
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 25, 2008, 08:54:57 PM
Rockbox is designed as a media player. Are there any audio format extensions we've forgotten about, or are you talking about opening strange text files in the text editor?

It's very easy to add any custom formats you want to the viewers.config. And switching to "All" from "Supported" takes less than two seconds.
Title: Re: Opinions of User-friendliness in rockbox
Post by: MarcGuay on January 26, 2008, 02:40:42 AM
Next?  

I think the Database, and the tagnavi_custom file in particular, could be discussed with more gusto.  A simpler way to customize the menu could be something to look into.
Title: Re: Opinions of User-friendliness in rockbox
Post by: cool_walking_ on January 26, 2008, 02:56:46 AM

There's a "browse config files" option for that. You really shouldn't browse into the .rockbox folder ever.
You really shouldn't? Apple thinks you really shouldn't install alternative firmware on their players. Music companies think you really shouldn't rip CDs you purchased and listen to them on an MP3 player.

Why does opening rockbox.ipod load that file if you shouldn't be in .rockbox in the first place?

Some of the most novel uses for things have come about by doing what the creator didn't want you to do.


The files are hidden because Rockbox is an APPLICATION as well as a firmware. By default, when you tell a word processor to open a file, does it show all files, or just files it knows what to do with?
Hrm... since Rockbox is the main interface to the player, I consider it more an OS than an application. I think since the "Files" section is the main interface to looking at the hard drive, it should actually show you everything that's there (at least by default).  Everyone _knows_ the database is an abstraction, so it's alright if not everything is shown, but the "Files" section is your main look at the hard drive.
Title: Re: Opinions of User-friendliness in rockbox
Post by: AlexP on January 26, 2008, 04:33:20 AM


There's a "browse config files" option for that. You really shouldn't browse into the .rockbox folder ever.
You really shouldn't? Apple thinks you really shouldn't install alternative firmware on their players. Music companies think you really shouldn't rip CDs you purchased and listen to them on an MP3 player.

Why does opening rockbox.ipod load that file if you shouldn't be in .rockbox in the first place?

Some of the most novel uses for things have come about by doing what the creator didn't want you to do.


I actually have no idea what you are getting at here.  Are you thinking you might find some revolutionary new way to use rockbox if you browse into /.rockbox?  When do you open rockbox.ipod?  It is loaded on boot, but so?  Are you suggesting we ought not access the files in /.rockbox to load rockbox because we recommend users don't muck about in there?  If you want to browse /.rockbox feel free, but it shouldn't ever be necessary.  When you rip a CD you gain additional use from your music.  I can't see how that applies to browsing /.rockbox.
Title: Re: Opinions of User-friendliness in rockbox
Post by: nls on January 26, 2008, 05:11:43 AM
IMHO arguing about default settings is quite pointless since a) settings are easy to change b) it's just a matter of opinion so people will never agree.

About the "show files" default in particular, I remember it has been discussed before and the reason that it now defaults to "Supported" is that user were complaining that they saw the .rockbox dir among other things while browsing...

Now where are those revolutionary UI ideas?  ;)
Title: Re: Opinions of User-friendliness in rockbox
Post by: cool_walking_ on January 26, 2008, 05:53:59 AM
I actually have no idea what you are getting at here.
I went off on a psychotic tangent there... I just don't like people telling me what to do, and the wording "you shouldn't" annoyed me.  I know I perverted what Llorean actually meant. Sorry Llorean.
Quote
Are you thinking you might find some revolutionary new way to use rockbox if you browse into /.rockbox?
Well you never know.
Quote
When do you open rockbox.ipod?
Sorry, maybe bad wording. I mean when you "play" a rockbox.ipod file, how it loads that firmware.
Quote
If you want to browse /.rockbox feel free, but it shouldn't ever be necessary.
I have done so to fix broken WPSes and load different builds without having to connect to a PC.


IMHO arguing about default settings is quite pointless since a) settings are easy to change b) it's just a matter of opinion so people will never agree.
Yes, but sane defaults should be set according to the principle of least astonishment. Of course you can't please everyone, but for every option there is probably a majority that would be least astonished by a certain default.
Quote
About the "show files" default in particular, I remember it has been discussed before and the reason that it now defaults to "Supported" is that user were complaining that they saw the .rockbox dir among other things while browsing...
Ah...
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 26, 2008, 09:52:30 AM
Because you can place alternative .ipod files (linux.ipod? diskmode.ipod? Apple_os.ipod?) that could be loaded, and not have to be in the .rockbox folder. If you think there are "novel uses" for going into the Rockbox folder, SAY them. Don't hint that they're there. You've not said anything that suggests that. (As a note, it takes TWO SECONDS to switch the file view setting, less if you're not slow. Fixing WPSes is an 'advanced' subject anyway, why should the default be set to the advantage of advanced users who surely know how to change it anyway? Loading an alternative firmware, on the other hand, doesn't require entering .rockbox anyway).

I think it's *more* confusing to a user to have a bunch of files visible, and not know which ones they can simply click on to have them work, and which ones will do nothing at all.

And ".rockbox" is a hidden folder anyway. With the previous suggestion of "show all files, but keep hidden folders hidden" it would still be gone.

It's not more OS than application. It's FIRMWARE. These are not multipurpose computers, they're MP3 players, and Rockbox's primary job, and the one that will always determine its official development path, is Audio (and possibly in the future Media) Player.

This whole thread is supposed to be about USER FRIENDLINESS. Which is more user friendly: A list of files with no clue on which you can click, and which you can't, several pages long, containing a mix of useful files and files that you can't do anything with, or a shorter list of files, where every visible file is one that the device in your hand actually knows what to do with, while all the *unusable* files are a mere two seconds of interaction away?
Title: Re: Opinions of User-friendliness in rockbox
Post by: gratt on January 26, 2008, 06:12:45 PM
Setting a permanent backdrop requires the user to enter /.rockbox/backdrops.
This dependany should be removed to allow a user to keep backdrops anywhere.
GRaTT
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 26, 2008, 07:01:26 PM
Backdrops can also be managed by way of theme files for the backdrop image. So entering that folder is not required if a player is properly set up.
Title: Re: Opinions of User-friendliness in rockbox
Post by: saratoga on January 26, 2008, 07:41:08 PM

Setting a permanent backdrop requires the user to enter /.rockbox/backdrops.


No, I think they can be located anywhere the theme file points to, though obviously the standard place is .rockbox/backdrops.  
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 26, 2008, 07:50:46 PM
He means that if they aren't in the "proper" place, they won't save across reboots (or at least didn't used to). But just because the .bmp image needs to be in a specific place does not mean you need to browse in there, since .cfg files exist.
Title: Re: Opinions of User-friendliness in rockbox
Post by: cool_walking_ on January 26, 2008, 11:50:23 PM
<snipped for boredom and what I was talking about was stupid and unrelating to anything>

This whole thread is supposed to be about USER FRIENDLINESS. Which is more user friendly: A list of files with no clue on which you can click, and which you can't, several pages long, containing a mix of useful files and files that you can't do anything with, or a shorter list of files, where every visible file is one that the device in your hand actually knows what to do with, while all the *unusable* files are a mere two seconds of interaction away?
It doesn't affect me, since as said, the setting can be changed in 2 seconds. I am just saying that to me, showing all files by default is more user-friendly since I see Rockbox as an OS. If more people feel otherwise, then sure, leave it as is.

EDIT: Gah, HTML...
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 27, 2008, 12:17:33 AM
Rockbox isn't a multi-purpose OS though. It's a music player firmware. Besides hiding non-media files, are there other ways we could encourage people to notice that that's the purpose of it? Maybe if people realized that's a major project goal, we'd have to reject less feature requests that are out of the scope in a significant way.
Title: Re: Opinions of User-friendliness in rockbox
Post by: Karce on January 27, 2008, 12:20:36 AM
I'd have to agree with those who say that re-structuring the settings in the menu would be the major thing.

It's fairly user friendly for my player, once you realize how to manipulate the multi use buttons.

Documenting them a bit more clearly (a specific section for the types of menus, i had to search for a while in the manual to figure it out, but then again, I was already used to a certain key designation before it was changed as well) would be helpful
Title: Re: Opinions of User-friendliness in rockbox
Post by: pondlife on January 28, 2008, 03:10:46 AM
There's one change I'd like to see in the Rockbox UI.

From the WPS, when I press STOP or SELECT, I rely on the "Follow Playlist" option to take me to a sensible place in the browser, but this cannot work with the database, and it seems to be a bit buggy/inconsistent anyway.

All I really want is to return to the Playlist Viewer. Whilst I can go into the context menu and View Current Playlist, this UI is rather well-hidden for such a fundamental feature.

I'm not entirely sure how this should best be integrated into the menu/screen structure so as to preserve the existing functionality, but I'd hope that the current idea that STOP/SELECT returns to the previous (non-playing) screen could be maintained with the "Follow Playlist" option only used to mandate that these buttons return to the playlist view instead instead of mucking about with browser selections (should be simpler).

Apologies for these unstructured, early morning thoughts!  Discuss.

pondlife
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 28, 2008, 03:29:31 AM
The reason "Follow Playlist" takes you to the browser is so that you can quickly queue songs from the same album (or delete a song realizing you didn't want it on the player). Neither of these can readily be done from the Playlist list.

One possibility though, could be to have a "Return Screen" option, with choices "Playlist Viewer" "Home" (main menu?), "Current File" and "Don't change" (going back to wherever you invoked the WPS from).
Title: Re: Opinions of User-friendliness in rockbox
Post by: pondlife on January 28, 2008, 04:44:05 AM
A "Browse to file" option in the playlist viewer context menu would be useful anyways, and perhaps a "Delete file" too (alongside the existing "Remove from playlist").

Database users can easily use the "Same album as..." selection.

I like the idea of replacing "Follow Playlist" with the "Return Screen" option though. I think it's clearer as well as more flexible.

pondlife
Title: Re: Opinions of User-friendliness in rockbox
Post by: Bagder on January 28, 2008, 05:48:09 AM

I like the idea of replacing "Follow Playlist" with the "Return Screen" option though. I think it's clearer as well as more flexible.


I think you're confusing subjects.

If I start playing a playlist in the file tree, the file tree is the "return screen" but the "follow playlist" option tells which particular directory it should show when it returns there.
Title: Re: Opinions of User-friendliness in rockbox
Post by: pondlife on January 28, 2008, 02:33:58 PM
I'll admit to being totally confused ;)

Any suggestion to how Rockbox could function with the playlist viewer as the main screen (without losing any existing functionality).  Or is this just a silly idea?

pondlife
Title: Re: Opinions of User-friendliness in rockbox
Post by: bascule on January 28, 2008, 02:43:16 PM

Or is this just a silly idea?


Oh no; it's the only functionality my Rio Karma had that I still miss.

It showed previous track to current +7 or 8 with the current track in bold with full playback/sound controls active.

It was an excellent UI in my opinion.
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 28, 2008, 06:08:02 PM
I think we need to drop the "Follow Playlist" option, since it suggests different things to different people. Instead I'd like an option that just describes where you go when you leave the WPS with "Stop" or "Select" (one option that covers both). Menu should ALWAYS be "The Menu".

This option should then have at least these choices (in my opinion) but named more intuitively hopefully: "Playlist viewer with current song selected", "Filetree with current song selected" and "The screen I called the WPS from".

With that, the confusing "Follow Playlist" option can be removed, and if named well people are more likely to understand "This won't take you to the database" *and* understand whether or not they'll be viewing the playlist vs the actual file.
Title: Re: Opinions of User-friendliness in rockbox
Post by: JdGordon on January 28, 2008, 06:28:50 PM
my UI gripes: (WITH solutions..)
(I'm at work so obviously not in the best of moods....)

quickscreen - imho it is totally useless, the 3 settings that are there might be nice for whoever initially did the screen, but for _me_ they are useless.
solution: let me make the 3 options customizable... 60% of the code is already done and in svn (look at the #if 0 code in gui/quickscreen.c)

pressing stop in the wps goes to the browser instead of the menu, bug is probably my fault, just keep forgetting to find and fix it :p

right and select both do the same thing in the browser, why on earth cant we add the customizable action on right from the insert options? yes, I know ondio doesnt have select, but we have a nice thing called #ifdef which would work fine here.

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?)

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*

menu needs reorganising, I dont think anyone disagrees with that.. I think we need to plan a time in IRC to sort that out... (or leave that for devcon08?)

OH.. for the hidden music folder... what about if in "supported" view we show folders marked hidden except . folders? actually.. scratch that.. we should make it so hidden folders are always shown except .folders (which are only shown in "all")

I think thats all from me for now

*sees lloreans post*
I disagree... stop should always go back to the menu also.. select is the only button which I think should get an option. the rest of the post I agree with
Title: Re: Opinions of User-friendliness in rockbox
Post by: 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.

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.

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?

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.

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.

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. ;)
Title: Re: Opinions of User-friendliness in rockbox
Post by: JdGordon on January 28, 2008, 06:57:16 PM
quickscreen: I dont see why that stops it from being customizable.. I have no problems with people leaving them if thats what they like... I personally never turn on repeat and just as frequently enable shuffle.

right vs select: well the idea is more what I want.. I dont care which is the custmoizable one.

bookmarks: agreed

hidden: well, your right, but I doubht there is anyone who changing this would harm... and it would sure help alot of people, unless you feel like getting usb storage working in rockbox. ;)

stop: I understand the whole thing to make it easier for blind users, but the main menu was put in to be the home/start/main screen.. the one where you would be dumped in when nothing else is happening so you can choose easily where you want to go.  imo it should work like this. stop->menu, select->browser/playlist/file
arg.. I dunno... I dont like stop going to the browser....
Title: Re: Opinions of User-friendliness in rockbox
Post by: JdGordon on January 28, 2008, 07:02:00 PM
Oh no; it's the only functionality my Rio Karma had that I still miss.

It showed previous track to current +7 or 8 with the current track in bold with full playback/sound controls active.


suggestions on how it could work with the various targets?
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 28, 2008, 07:23:51 PM
I think if music stops naturally (end of playlist) it should go back to the Main Menu (right now it doesn't), but if it's stopped by user input, it should go back to some other screen (since a user can VERY easily press Menu too).
Title: Re: Opinions of User-friendliness in rockbox
Post by: cpchan on January 28, 2008, 07:47:56 PM
quickscreen - imho it is totally useless, the 3 settings that are there might be nice for whoever initially did the screen, but for _me_ they are useless.
solution: let me make the 3 options customizable... 60% of the code is already done and in svn (look at the #if 0 code in gui/quickscreen.c)


Totally agree with this. That is why in my personal builds I have this replaced with a customable "Quick Menu" with a modified patch that used to be on the tracker. However, the idea got rejected and the flyspray page is now closed.

Quote
menu needs reorganising.


Agreed.

Quote
OH.. for the hidden music folder... what about if in "supported" view we show folders marked hidden except . folders? actually.. scratch that.. we should make it so hidden folders are always shown except .folders (which are only shown in "all")


Hiding just dot files and directories is a good idea.

Charles
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 28, 2008, 08:54:28 PM
Why should files a user INTENTIONALLY marked as Hidden not be hidden?
Title: Re: Opinions of User-friendliness in rockbox
Post by: JdGordon on January 28, 2008, 09:05:02 PM
because how many users ever INTENTIALLY hide files?
Title: Re: Opinions of User-friendliness in rockbox
Post by: cpchan on January 28, 2008, 09:19:12 PM

Why should files a user INTENTIONALLY marked as Hidden not be hidden?


Because most of of the time it is not intentional, but done by the OF or comes hiidden at factory,. To me this falls under "The principle of least surprise" for the new user. If a user really want to hide a file, then he/she can just rename it to a dot file.

Charles
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 28, 2008, 09:31:43 PM
If it's hidden by the OF, it won't show up by default on their computer either... How exactly is having Rockbox not hide files marked as hidden (and probably hidden on the original computer) least surprise?

You're talking about solving a problem that is only caused by some OFs, by creating a problem (people asking "how do I hide files") for every other firmware, and for people not using the OF? We should respect FAT32 flags.

Most file browsers respect hidden files, and either require a manual option to show them, or provide visual feedback so you know they're hidden. On the Sansa, how do you put files in a hidden folder without making it visible first?
Title: Re: Opinions of User-friendliness in rockbox
Post by: JdGordon on January 28, 2008, 09:34:49 PM
because most likely the user has set to not hide hidden files.
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 28, 2008, 09:35:17 PM
Then the user knows that hidden files exist, and can do so in Rockbox if they want to see them.

Seriously, you're suggesting taking away the freedom of users to hide files without renaming them (something you CANNOT DO in Windows Explorer) simply because of a strange behaviour in an OF that people WILL NOT HAVE TO USE.

Tell me, how does a clueless windows user choose to hide their files if we always show hidden files?
Title: Re: Opinions of User-friendliness in rockbox
Post by: ryran on January 28, 2008, 09:41:28 PM
Been following all this with interest... chuckling a bit, though.

Gotta say, I'm with Paul on this one.
Title: Re: Opinions of User-friendliness in rockbox
Post by: cpchan on January 28, 2008, 09:50:22 PM

If it's hidden by the OF, it won't show up by default on their computer either... How exactly is having Rockbox not hide files marked as hidden (and probably hidden on the original computer) least surprise?


I believe most tech unsavvy users tends to just sync their players with their music manager, at this point,  in mtp mode with the OF. For those savvy enough to use ums, they should know about the hidden directories. I guess I am just sick of those "I can't find my music folder" posts.

Charles
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 28, 2008, 09:51:14 PM
If you sync a Sansa with MTP mode (at least the C200 on Vista, for me) the files are renamed anyway. Making the folder unhidden won't help much.
Title: Re: Opinions of User-friendliness in rockbox
Post by: cpchan on January 28, 2008, 09:58:27 PM

If you sync a Sansa with MTP mode (at least the C200 on Vista, for me) the files are renamed anyway. Making the folder unhidden won't help much.


Hum, interesting- I didn't know that. I have no experience with either Vista or the c200 series. This is getting as bad as iTunes.

Also, I didn't know about the dot file limitations in Windows Explorer.

Charles
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 28, 2008, 10:01:49 PM
This may be a feature of the original firmware. But I firmly believe the answer to the OF hiding and/or obfuscating files is a "Known Issues" section in the beginning of the manual.

We're always going to have to tell people what iTunes does to songs. Or that the OF might do things to their files. Or other things. Make it clear to the user, instead of simply trying to pretend like it doesn't happen. Otherwise you'll just get "I can see my Music folder on my e200, but I can't get to it on my computer! What do I do?" instead of the other way around.

If we really want to do "least surprise", Rockbox would have to scan OF-specific folders and fix filenames too. Instead we have the database, which will work just fine for hidden files too. ;)
Title: Re: Opinions of User-friendliness in rockbox
Post by: saratoga on January 28, 2008, 10:07:47 PM
Regarding the hidden folders by the OF on the Sansa, its probably reasonable to simply revert the hidden flag on start up since it could be put in Sandisk specific files where it would not clutter the main rockbox source or burden non-Sandisk.  At least if someone submitted a sufficiently well made patch I would consider committing it.

I do agree that any sort of system wide hacks to address this issue are very bad idea though.
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 28, 2008, 10:11:06 PM
If there's an option to unhide that folder automatically, it needs to be optional I think. Just an option "Unhide music on boot", probably defaulting to enabled, and only existing for players that have hidden folders that they put music in by default. Or maybe even simply "Always show MUSIC folder" with "MUSIC" being dependent on what the OF might name it (for future firmwares).
Title: Re: Opinions of User-friendliness in rockbox
Post by: cpchan on January 28, 2008, 10:15:44 PM
Or maybe even simply "Always show MUSIC folder" with "MUSIC" being dependent on what the OF might name it (for future firmwares).


I second this solution.

Charles
Title: Re: Opinions of User-friendliness in rockbox
Post by: JdGordon on January 28, 2008, 10:23:34 PM

Or maybe even simply "Always show MUSIC folder" with "MUSIC" being dependent on what the OF might name it (for future firmwares).


thirded
Title: Re: Opinions of User-friendliness in rockbox
Post by: bascule on January 29, 2008, 03:30:21 AM

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?


...and working from the Database, please...


Oh no; it's the only functionality my Rio Karma had that I still miss.

It showed previous track to current +7 or 8 with the current track in bold with full playback/sound controls active.


suggestions on how it could work with the various targets?


Would a list widget in a viewport work? I *believe* the playlist view is not a simple list widget, but that is how I see it being implemented. You couls then have a full screen viewport containing the 'playlist widget'.
Title: Re: Opinions of User-friendliness in rockbox
Post by: pondlife on January 29, 2008, 03:59:26 AM
I think I pretty much agree with Llorean, so I'll quote him...


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.


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.


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?


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.


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.


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. ;)


Yes, STOP and SELECT should behave identically (with the exception of stopping music).  I didn't realise this was broken until recently...

pondlife
Title: Re: Opinions of User-friendliness in rockbox
Post by: shotofadds on January 29, 2008, 06:14:25 AM
Hidden folders should be hidden.  If some braindead OF does silly things, then that's a problem with the OF, not with Rockbox.

Maybe a cheap solution would be for RbUtil to unhide the Music folder during installation, on those players that need it?
Title: Re: Opinions of User-friendliness in rockbox
Post by: Lear on January 29, 2008, 06:32:32 AM

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?)


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*


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...)
Title: Re: Opinions of User-friendliness in rockbox
Post by: cpchan on January 29, 2008, 06:37:28 AM
Maybe a cheap solution would be for RbUtil to unhide the Music folder during installation, on those players that need it?


Unfortunately this won't work at least for the Sandisk players. This is because the brain dead OF rehides it every time.

Charles
Title: Re: Opinions of User-friendliness in rockbox
Post by: GodEater on January 29, 2008, 06:39:56 AM

Maybe a cheap solution would be for RbUtil to unhide the Music folder during installation, on those players that need it?


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.
Title: Re: Opinions of User-friendliness in rockbox
Post by: cpchan on January 29, 2008, 06:40:34 AM
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-)


Same here, it work rather well for me. But like you I never use the database or create dynamic playlists. I wasn't even aware of the problems.

Charles
Title: Re: Opinions of User-friendliness in rockbox
Post by: AlexP on January 29, 2008, 06:57:41 AM

I think if music stops naturally (end of playlist) it should go back to the Main Menu (right now it doesn't), but if it's stopped by user input, it should go back to some other screen (since a user can VERY easily press Menu too).


I don't really like the main menu, I have start screen set to file tree.  If I start up in the file tree, play some music, it ends, I don't really want to end up back in the menu, only to have to select file tree again every single time.


stop: I understand the whole thing to make it easier for blind users, but the main menu was put in to be the home/start/main screen.. the one where you would be dumped in when nothing else is happening so you can choose easily where you want to go.  imo it should work like this. stop->menu, select->browser/playlist/file
arg.. I dunno... I dont like stop going to the browser....


I know where I want to be - the file tree.
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 29, 2008, 06:13:10 PM
How 'bout "If music ends, go back to the selected 'start screen' unless that screen is also a playback screen of some sort, then go to wherever the WPS was invoked from" or something like that?

I haven't used the bookmark feature myself, so I don't know the advanced bits of it at all, and am not really qualified to speak relating to it. All I need from bookmarks is basically "I click on a file, and it populates the playlist, and resumes from a certain point in a certain file." Basically, what resume on startup does. I'd basically be happy with the ability to dump the current playback state (I assume, something similar to nvram.bin) to a file, whenever I wanted (or automatically when playback is stopped).
Title: Re: Opinions of User-friendliness in rockbox
Post by: JdGordon on January 29, 2008, 06:41:20 PM

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...


oh? that should only be the case when doing "dirplay" though
Title: Re: Opinions of User-friendliness in rockbox
Post by: AlexP on January 29, 2008, 06:54:34 PM

How 'bout "If music ends, go back to the selected 'start screen' unless that screen is also a playback screen of some sort, then go to wherever the WPS was invoked from" or something like that?


Sounds good to me!
Title: Re: Opinions of User-friendliness in rockbox
Post by: Lear on January 29, 2008, 07:00:40 PM

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.)


Huh? Bookmarks are based on folder or playlist, depending what you "played" (a file in a directory or a playlist). I also have a shuffled "All" playlist, and I resume that one all the time. I've had well over a hundred bookmarks for that playlist alone...
Title: Re: Opinions of User-friendliness in rockbox
Post by: Lear on January 29, 2008, 07:12:56 PM


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...


oh? that should only be the case when doing "dirplay" though


The opposite, actually (unless I misunderstood you). When doing dirplay, the playlist is fully stored in memory, so in that case the filenames would not be loaded from disk.

In order to support really big playlists on targets with limited memory, only the file index of each entry in the playlist file is stored in memory (along with some flags).
Title: Re: Opinions of User-friendliness in rockbox
Post by: cpchan on January 29, 2008, 10:02:21 PM
I also have a shuffled "All" playlist, and I resume that one all the time. I've had well over a hundred bookmarks for that playlist alone...


My default playlist is a large shuffled "All" playlist from my music library and, like you, bookmarking works like a charm

Charles
Title: Re: Opinions of User-friendliness in rockbox
Post by: pondlife on January 30, 2008, 02:56:12 AM

Huh? Bookmarks are based on folder or playlist, depending what you "played" (a file in a directory or a playlist). I also have a shuffled "All" playlist, and I resume that one all the time. I've had well over a hundred bookmarks for that playlist alone...


Hmm, I've never found it works reliably for a database generated playlist.  Maybe it was broken last time I tried.

I don't see why there's a need for folder-based bookmarks; aren't folder selections just another method of generating a playlist really?  I see the main job of both browsers to be playlist generation (albeit normally dynamic playlists).

pondlife
Title: Re: Opinions of User-friendliness in rockbox
Post by: pondlife on January 30, 2008, 02:58:49 AM

How 'bout "If music ends, go back to the selected 'start screen' unless that screen is also a playback screen of some sort, then go to wherever the WPS was invoked from" or something like that?


Why not just go back to the last non-WPS screen the user browsed to.  I think that's what's meant to happen at the moment, but it may be slightly buggy.

pondlife
Title: Re: Opinions of User-friendliness in rockbox
Post by: Lear on January 30, 2008, 04:26:16 AM

Hmm, I've never found it works reliably for a database generated playlist.  Maybe it was broken last time I tried.


No, that is a limitation with the current bookmark system.

Quote
I don't see why there's a need for folder-based bookmarks; aren't folder selections just another method of generating a playlist really?  I see the main job of both browsers to be playlist generation (albeit normally dynamic playlists).


Selecting a file in a folder does generate a playlist, yes, but a special in-memory one.

But I think I see what you're after here. A generic bookmark system that can handle any selection by the user, be it a file in a "normal" folder, a file from a database query or a plain old playlist (modified or not).

In that scenario, a folder selection would just be another dynamically generated playlist, to be handled in the same way as the rest.

Should be possible, though I don't see how it could be done without copying the current .playlist_control file somehow (perhaps as a part of the .bmark file, which could make them noticeably larger).
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 30, 2008, 12:39:20 PM
Would larger bookmark files present a problem with disk space, or also with lowmem targets?
Title: Re: Opinions of User-friendliness in rockbox
Post by: Lear on January 30, 2008, 01:35:20 PM
The files could be fairly large, and many of them could be created, so it could waste some disk space (several megabytes). Shouldn't be a problem for lowmem targets as such though.
Title: Re: Opinions of User-friendliness in rockbox
Post by: Llorean on January 30, 2008, 02:50:39 PM
Personally, I'd sacrifice some disk space for a more consistent bookmarking feature, but I'm not sure how others feel.
Title: Re: Opinions of User-friendliness in rockbox
Post by: JdGordon on January 30, 2008, 03:34:50 PM
the resume files arnt that large.. unless you do some serious fiddling with the playlists...
90% of them would just be the 2 or 3 line file saying "this directory/db list was loaded" and imo that is a much better bookmark setup than current
Title: Re: Opinions of User-friendliness in rockbox
Post by: AlexP on January 30, 2008, 03:54:14 PM
I use bookmarking regularly, and it works great (using the filetree so just bookmarking folders + some playlists), but I too would not mind at all if the files became a bit larger for greater flexability (although it seems from what JdGordon says it wouldn't really affect 'current' uses, just database style).
Title: Re: Opinions of User-friendliness in rockbox
Post by: Lear on January 31, 2008, 06:06:13 AM

the resume files arnt that large.. unless you do some serious fiddling with the playlists...
90% of them would just be the 2 or 3 line file saying "this directory/db list was loaded" and imo that is a much better bookmark setup than current


Last I checked, any database selection generated a control file with all entries in the current list. So they can be fairly big.