On Sat, 2005-11-05 at 06:13 +0100, Martin Jeppesen wrote: > I think this is a brilliant idea! =) Everybody loves ChangeLogs (NEWS) > and reading about bugs that needs consideration. > > My I suggest that each issue have its own bug, where proposed bugs for > discussion could be submitted to be included in the next issue? First, if you want to discuss a bug on the list, you don't have to wait for an issue. Feel free to post to the list yourself. That said, having it mentioned in an issue will give more emphasis that it is important. I'm also thinking that I should put them up somewhere off-list, but haven't organised it yet; links on the website? Gnome Planet? I don't know if bugzilla would be particularly great for it, but other options like IRC and personal email have drawbacks too. What I think of a good candidates for bugs to include would be: a) Bugs with patches that are obviously good things to do, but need widespread testing, to ensure that they don't horribly break (e.g. gnome-vfs remote and column sizing). b) Bugs with patches that might be a good idea, but might not, and should be debated (toolbar). c) Bugs where discussion has happened in bugzilla, that everyone should know about and be part of. <toolbars> > I am not in particular in flavor for this, but I would say it 100% > depends on the layout strategy of Rhythmbox. > > If Rhythmbox is meant to satisfy iTunes users, then are "buttons in > the toolbar" evil =) While Rhythmbox attracts the same kind of people as iTunes, and is inspired by it, we shouldn't blindly do things just because iTunes does them. Apple employs a heap of usability and UI people, so we should definitely give what iTunes does some weight, but just because iTunes has a good interface doesn't mean we can't have a _great_ one, I'd have to search to find the links, but I've read several pieces that have said not having a toolbar was one of the bigger UI mistakes in iTunes. > If Rhythmbox wants to have structured interface, then is the toolbar a > step in the right direction! > > I only say a step in the right direction, because all global buttons > should be in the toolbar, before it would make sense, i.e. Hide > Browser and the Volume Control most be in the toolbar as well. Moving the volume control is definitely a good idea. Hide Browser probably makes sense too - although that brings up the question of what to do with the search box again, because it then has the entire line to itself. Looking at the "Create Audio CD" button, that end should probably be source-specific. So the audio cd button shows up for playlists, audio cds have Eject and Import buttons, radio and podcast have Add buttons etc. > The bar below the toolbar should be song specific, meaning it should > only contain: song name, artist, album and duration slider. What could be a good idea is to change the layout slight for "normal" mode: move the text onto one line, and put time next to the slider. This would make it take up less vertical space. We probably wouldn't want to do this for small mode though. > > The latest patch also splits the play, pause and stop actions into > > separate buttons, which will warrant some discussion. > > I know the HIG doesn't like the current way, but here would I say lies > a bug in the HIG. The play/pause button in Rhythmbox is no different > from a checkbox or a toggle button. <snip> > Having one button for play/pause is very useful when searching for > something in a song! I use it when I am writing guitar tabs. Here I > can listen to a few seconds, pause, write down the tabs, and play > again. There are two ways of doing it, so that only one is visible at once: 1) have three buttons, but only one visible at once so that it appears to change. 2) have one button which changes icon, name and functionality. (1) causes some accessibility problems, because screen readers (and similar) don't like control appearing and disappearing. As toolbar aren't designed to have thing hidden and shown often, there are also odd visual glitches because you have to go through a state where none or two of the buttons are visible - which causes all the button to shift for a split second. (2) also causes nasty a11y problems, because you have one widget that is completely changing to do three different things. Of course the current non-toolbar buttons also have this problem. The stop button is required for when you are playing something that isn't pausable, e.g. an radio station. For other things it isn't actually needed. Cheers, James "Doc" Livingston -- "Don't these people watch Jackie Chan movies? *Everything*'s a weapon! Next thing, they'll ban ballpoint pens, 'coz you can stab somebody with them. Or laptops, because you could force someone to install Windows 3.1. With a ballpoint pen, presumably." - Eric The Read, in the SDM
Attachment:
signature.asc
Description: This is a digitally signed message part