Closed Bugsbane closed 8 years ago
cosenal
commented
8 years ago This is a nice idea, although I am not sure podcast listening is a use case for a feed reader app. I would rather see this implemented in the Music app, or in a separate app. What do you think, @MorrisJobke @BernhardPosselt @jancborchardt ?
BernhardPosselt
commented
8 years ago Same here.
There are many different edgecases that you need to keep in mind and I dislike autoplay in general
Bugsbane
commented
8 years ago I dislike autoplay in general
Note that I suggested that it be off by default, until the user had been asked if they wanted this behaviour, and that the app supports playing podcasts already. This is only about whether people would have to manually click play at the start of each one or have the option to have it be automatic.
jancborchardt
commented
8 years ago I do think that podcasts should be handled by a News reader. @cosenal a Music app is no place for podcasts – when one shuffles all for example and then a podcast is played, it’s breaking the flow.
A separate app yet again for such similar functionality (subscribing to feeds, reading the shownotes, putting them into folders, etc.) just out of principle will impact the UX. People don’t need more apps, we need ones which work great in their field, and I do think podcasts and News belong together. The News Android app by @David-Development also handles podcasts and it’s great.
Bugsbane
commented
8 years ago From my perspective, it's so tantalizingly close to perfect for my usecase already, which is that I want something I can just hit play and pause on, and have an instant stream of interesting audio that has new content automatically added to it regularly, without having to constantly fiddle with finding specific feed items and pressing play over and over in a single session.
Given that many podcast listeners are commuters, for whom it can actually be dangerous to be fiddling with their device, I don't imagine my use case is that unusual.
BernhardPosselt
commented
8 years ago Given that many podcast listeners are commuters, for whom it can actually be dangerous to be fiddling with their device, I don't imagine my use case is that unusual.
Use the mobile app for that (which is better suited for the task)
After thinking about this further:
You see where this is going :)
Each of the mentioned points basically leads up to building a playlist with multimedia controls. At that point you are basically writing a fully featured audio player inside the News app which is not going to happen.
Like @cosenal mentioned before, this is a task best suited for the Music app. In order to solve this it should therefore interface with it. Think about having the following buttons for each article:
That would generate/fill a playlist in the Music app that you can conveniently reorder and save. The buttons can be created using a clientside plugin https://github.com/owncloud/news/wiki/How-to-write-Plugins#clientside-plugin
You may also want to write backend code for downloading the audio files and setting up the playlists. This can be done by using a serverside plugin (or by simply querying the news database).
In case you want to take up the task you can always ask for assistence (ping me or @cosenal from your GitHub repo) and we can also work on additional interfaces if needed.
TL;DR closing this because this should be done by interfacing with the Music app through plugins.
jancborchardt
commented
8 years ago Use the mobile app for that (which is better suited for the task)
@BernhardPosselt I have the feeling that this issue was closed more because of »I don’t want to implement it« instead of »I don’t think this is a good idea for a News reader«. I’d say leave it open for someone else to take a stab at, you don’t need to bother.
TL;DR closing this because this should be done by interfacing with the Music app through plugins.
Nope – it’s a Music app and podcast feeds have no place there. Or when was the last time shuffling your stuff on Spotify, Rdio etc played a podcast in the middle of a sports or study session?
BernhardPosselt
commented
8 years ago Several Music apps like banshee and iTunes allow you to listen and subscribe to podcasts so I don't really see the issue :)
Like mentioned above: implementing this feature would require a playlist and various multimedia controls and would require to duplicate a lot of music app code which the app itself ulimately does a better job at ;)
So yes, I think it is not a job for a News reader to implement a Music app and thinking further a Video app. KISS, do one thing and do it well.
cosenal
commented
8 years ago Bernard raised very valid points against the OP proposal and in my opinion they are not »I don’t want to implement it«-kind of points at all. Amarok, Rhythmbox, Banshee, they all support podcast, so could the Music app. Counterarguments:
but those are all nerd tools!
Ok, what about iTunes? To be fair, non-nerds either don't listen to podcast or they use mobile dedicated apps (Stitcher). I am sure they don't use Newsblur, Feedly, neither they have ever used the late GoogleReader for podcatching.
but we don't want another app!
well, neither we want to squeeze random functionalities in existing apps. Podcatching has as much to do with catching up with news, as it has to do with listening to music or reading a book.
The News app allows to play media files for the same reason it shows image, they are just part of the item, embedded in it. Now, the equivalent for images of what the op is asking is to embed a Gallery app in News, not really something we want to do, right?
jancborchardt
commented
8 years ago After talking to @cosenal I agree. There’s already the functionality of playing audio files in the app, and that covers the majority of cases.
No further stuff needed, especially because then it gets complicated to decide what is the »next« item, etc.
At the same time, I think both interfacing with Music or developing a separate Podcasts app is overkill.
Bugsbane
commented
8 years ago OK, here's another option to meet the same use case that may be a bit less controversial.
Currently, when there is a media attachment there are two buttons "Play media" and "Download Media" or something like that.
What if we just added a third button "Cue media" which would add that media item to a list of what to play next. This way it's clear. There is no configuration or asking the user needed. Nothing happens automatically without user consent. It matches the UI currently in place.
BernhardPosselt
commented
8 years ago @Bugsbane changes nothing, you're still ending up with a playlist and this is exactly the plugin usecase that I've described before ;)
Bugsbane
commented
8 years ago you're still ending up with a playlist
In essence we already have playlists, ie one (or more if you use folders) list of media in kept in sequential order, while remembering which the user has gone through yet and which they haven't.
It's just now users who want to hear the 20 items in their folder are forced to push play 20 times.
For my use case, I'm more than happy with the idea of a play order exactly the same as the current reading order, with no changes.
That said it seems that this has been decided already, so I'm not sure how useful further discussion on this would be.
Hi there, Currently I'm loving the clean, integrated way that OC News includes play controls for media right in the feed item, especially given that I use news to follow a range of podcasts. Most of the time, when one podcast finishes though, I'd really like to hear the next one without having to stop, find the tab I have news open in, scroll through my feed until I find the next podcast, hit play and then repeat when it gets to the end of that podcast.
What I would like to see, is something similar to YouTube's autoplay, where upon finishing playing one file, OC News marked that idem as read, jumped to the next feed item with a media file and started playing that.
Use case: This way, I could just open "Unread" and click play on the first media file, and then leave my podcasts playing in the background while I work. When I needed to stop (say I finished at work), I could just go back to the tab, and press pause on the currently playing file, as the related feed item would already be open there.
UX In terms of UX, this could be something turned off by default, but was switched on from the configuration section, and possibly that asked users, the first time they got to the end of a playing file, whether they wanted to turn this option on.