Bugzilla – Bug 12585
+ and play icons on playable menu items
Last modified: 2011-01-13 15:00:20 UTC
related to bug 12358, in our bug meeting there was solid consensus (and by solid, I mean 100% of everyone in the meeting) that touch-hold is going to be very hard to discover, even if we make an attempt to teach the users during a setup slide show. Further, having no visual indication that an item will play immediately on touch was viewed as broken (by QA as well as engineering). Design team has decided buttons and icons on menu items are too visually cluttered, nevertheless we think a demonstration of putting + (for context menu) and play (to play playable items) on menu items is worth seeing in practice. This bug is a placeholder for giving that a shot. I have no doubt this is going to ruffle the feathers of Weldon and Noah. Please note that I'm not trying to have a repeat discussion of the merits of touch-to-play. This bug is solely here for the purpose of exploring the user experience of buttons, particularly the + for CM, on playable menu items.
Understood. We really need to test this with users who have little to no experience with SB products. All a user has to do is press a playable track once (keeping this visual behavior consistent everywhere in the device) and they have "learned," the expected behavior for next time. I do see the rationale/desire to have a CM (+) button or potentially some other visual indicator that an item is special and a context menu can be launched. FWIW there has been a proposal for an edit playlist feature. If we add play, +, etc. icons everywhere how are we to distinguish between normal and edit playlist modes? Need a little time to prove/disprove the proposal. Ben- do you need any additional assets to make your demonstration? Selection PLAY and (+) are already checked in to snv. Do we have the contextual menus complete and testable in the current build - r6276
You guys know my opinion on the absence of the play icon ;-). But I share your concerns on the discoverability of the press + hold. Not as concerned about the other interfaces (remote etc) since they all have a "+" or "more" button. I'd be happy to test this in a build as a potential solution, and give it a fair critique.
I do think a play button on menu items could potentially have a place for non-track items, so that's not exactly apples-to-apples with removing the play icon from tracks. Tom and I have discussed this and while we aren't going to do it for a few weeks, when we get around to it I don't think it will be difficult to put in as an experiment, then remove if need be. I am concerned, however, with the impact this idea would have on Weldon's UI plan for the new "playlist mode", which I think is excellent. Too much higher priority stuff going on right now, but this will be revisited, probably in July.
This is sort of a can-of-worm bug. Budgeting 4.0 hours but that's just for testing some alternatives out...
Moving lower-priority bugs to next target