Queue and play options in media browser

[sambuca]

I've fixed the "Queue instead of instant play" option for orbiters in the web-admin. This allows you to choose what action should be performed when pressing "Play" in the media browser. A router reload is necessary to switch options.

I'm contemplating other, more flexible options in addition to the web-admin option.
One suggestion is to add an option to the options screen (UI1, UI2 has menus in the bottom of the media browser to select options). Another is to add a "Queue" button to the media browser.

So, what way would you prefer?

best regards,
sambuca

[darrenmason]

Queue button to media browser (next to play) would be my preference....

[tschak909]

arrrggghhh!

there is no way. guys. don't be stupid, and think like a UI designer for a moment...

If you select something, first time, it will send a playback. If you select something else and something is still playing successive times, it should queue it.

hmm, do you guys honestly not think this stuff through? or realize that :

(1) there isn't enough room for another button on some of the UI variations
(2) it will confuse the hell out of a normal user (not you, you guys ARE NOT NORMAL USERS!)

No.. No argument... what I am saying is sane behaviour. There is no sane reason to do it any other way.

-Thom

[rperre]

no poll vote from me, but what TSCHAK said......................

So if something is already playing and i click on another media, it should queue, i would make this the "default action" and currently just leave it to being able to turn this off in the webadmin.

It would be nice to have certain options like these available through the media browser options, so it's not necessary to go to the webadmin.

Richard

[sambuca]

Currently, if you check the "Queue instead of instant play", media will start playing if nothing is playing atm, but will queue up if anything is playing, so that part is taken care of.

I still think both buttons has a valid use case though..

br,
sambuca

[tschak909]

This is exactly the behaviour needed.

Why would you ever need a queue button?

-Thom

[wierdbeard65]

I'd like options.

One of the most successful media UIs around is the iPod/iPad/iPhone. In that, if you select a new media, it starts to play, replacing the existing media if necessary, it doesn't queue.

I'd like to be able to, if there is something already playing, be able to "on the fly" either replace the current content, or add it to a "play this next" type of queue. (Actually, I'm thinking more of the family when I say "I'd like"!!!)

Anyway, I can see that the UI could become cluttered, which would be bad, so why not a third default option, where if something is already playing, a pop-up asks you if you want to queue/play now (or a sub-menu, or whatever).

That way, folks who want it to queue automatically because that's what makes sense to them (Thom et el) get what they want. Folks who like Apple's approach can have everything just play immediately and folks like me (my family) who can't make up their mind what they want are also catered for

[tschak909]

No.

you'll wind up creating an additional level of UI that people go through every time to play stuff.

I will not implement it. I will not let anyone else implement it. It is a UI no-no. Go read some human interface guidelines, study some user interface designs,  and come back here when you have a more informed opinion.

-Thom

[wierdbeard65]

Thom,

I respect your opinion. I accept you have a large amount of experience in this.

BUT

Apple more or less wrote the original Human Interface Guidelines and they chose the opposite approach. As far as I am concerned, it's about choice. I agree with not forcing people to go through an additional layer every time they play something.

What I am proposing is that there is a choice of 3 default actions (which you would select in WebAdmin).
1. Play it Now (Always) - the Apple approach.
2. If something is already playing, queue it (Always) - your approach.
3. If something is playing, ask.

I have to take offence to your comment "I will not let anyone else implement it". I always thought the philosophy of the project was "he who writes the code, writes the rules", so if someone else implements this, are you saying you will block its submission? This may be a minor issue in itself, but if that is, in fact, what you are saying it represents a very serious shift in the project philosophy. That would deserve, I would respectfully suggest, an open discussion of its own.

[tschak909]

I am trying very hard to make the most of trying to fix serious issues with our UI left over from Pluto.

I can't do that, if every programmer goes his own way and does the UI "as he sees fit."

Sorry fellas, adding options is not always the right course.

-Thom

[tschak909]

Also.. Look at Apple's choice within the construct of the UI structure they used.

They can do this precisely because playlist creation is done entirely within iTunes, with the exception of the on-the-go playlist, and therefore it is safe to assume that you are NOT creating a playlist on the iPod/iPad/etc.

We, however, have to fold that functionality in with playback on our orbiter, it creates a point of contention.

Trust me, Paul. I've spent years doing UI work. And have spent a lot of time thinking these issues through. Until we can completely overhaul the media browser, this will provide the effect that most users will want.

-Thom

[wierdbeard65]

Thom,

Good points, well made. Certainly there is no intent by me to make more work for you (or anyone else!). Sambuca threw a suggestion out there which, I assume, he was planning on implementing. I was trying to suggest a third "compromise" way to keep everyone happy.

Trust me, having seen the way my wife, in particular, interacts with media (especially music) the queue is most definitely the wrong answer for her (and an awful lot of other people I know!!) Often, she listens to a track half way through (or thereabouts) and then selects something new. The kids are even worse! Their boredom thresholds are so low that I honestly don't know why modern artists even bother writing tracks that last longer than 30 seconds! (Gone are the days of such wonders of Hey Jude and Bohemian Rhapsody being popular with the "yoof" )

Personally, however, I think that this is all candy. Rather than mucking around with the detail of the UI, I think it is MUCH more important to get a released, stable system even at the expense of functionality. I know it's difficult, but if there's going to be any form of dictatorial refusal to add stuff to the system or allow edits, it should be pursuant to a feature freeze pending getting what's there working reliably. I understand why 810 has taken so long and have seen comment from, amongst others, yourself that once 810 is released, the tie to a particular Kubuntu version should be weakened, making future upgrades easier. More recent comments about 1004 seem to contradict this.

Just my 10 cents.

[phenigma]

I have to take offence to your comment "I will not let anyone else implement it". I always thought the philosophy of the project was "he who writes the code, writes the rules", so if someone else implements this, are you saying you will block its submission? This may be a minor issue in itself, but if that is, in fact, what you are saying it represents a very serious shift in the project philosophy. That would deserve, I would respectfully suggest, an open discussion of its own.

Another indication of the "Do as I say, not as I do" attitude.  Thom, last I checked, you do not 'own' this system.  No wonder people don't want to step up to help with development work...  The attitude here has to change!

J.

[tschak909]

hmm.
Given the behaviour of the MediaBrowser class at this point, what I have outlined is the most viable option.

If we want something else, the entire Media Browsing/Selection paradigm will need to be changed.

This is why I've asked people to make UI toys for an eventual replacement of Orbiter (the Clutter thread)

And yes, I do feel as if I have a right to have the final say on this issue, seeing as:

(1) I have put more hours into Orbiter, and the Media PlugIn, than all of you put together.
(2) I have almost two decades of UI experience.
(3) I have taken it upon myself, to ensure that the UI experience will eventually be completely consistent across EACH AND EVERY TARGET that Orbiter supports.

Have any of you stepped up to do this?

And no, don't whine and say, "But, you're bullying us!!" ...

Those of you who have actually put code into this system, and have worked with those of us who do the development work KNOW that we value actual work above any and all talk and discussion. _VERY RARELY_ have I explicitly put my own foot down in terms of how things should work. I can count them on my fingers,

and before you say, "But you should never do this!! It's against open source development!"

no, it's not.

Have any of you done Linux Kernel development?

Linus has final word on _EVERYTHING_ that goes into the main line. PERIOD. End of story. He earned this right with the sheer amount of work he has put into the kernel.

If you can thoroughly prove the point that having divergent queueing behaviour would be better than what I am saying should be done, then, I will go along with it.

-Thom

[Marie.O]

Thom, Paul, J.

nobody owns the system.

Please do not water down this thread with uncalled stuff regarding who can and who can not do stuff to the system.

This system is open. People provide patches and we try to include them. Sometimes we argue about them. That's fine. In the end, decisions are made. Case closed. If you want start a flame war, please open a new thread.

If more stuff like this is being posted on this thread, the poster will receive a 24 hour ban to cool down.