Great to get the email and test using the Feral Five login. Super happy to create a playlist. Encountered known issues - some tracks ended up with repeat artwork from another track. Re-ordering would be good. And couldn’t see how to delete a playlist. Congrats everyone on creating these minimal apps though, exciting!
Hey @toba, first of all, thank you for posting, and welcome to Resonate!
I can definitely see how all of the previous posts can be daunting, but don’t worry about reading them. If you repeat anything, I’d just take it as extra emphasis on a particular issue. (@piper any additional thoughts here?)
Thank you for your initial feedback on the process and the Android app, and feel free to dive deeper into this testing and/or leave some more of your thoughts below.
It’s always beneficial to write down thoughts in the forum (when people have the time), and then we can always move them around, reference them later, etc.
Looking forward to hearing more from you on this topic and others.
Thank you all so much for the feedback and for giving our app a try! My first impression is that I’m relieved to see that the new users that tried it didn’t run into the same login issues that @zetto.plus did.
Let me address and go through everything else I’m seeing here:
Both @Sylvia and @KatFive have brought up not being able to delete a playlist above. Unfortunately, there is not currently a way to delete a playlist. This is to be expected.
@toba this is an interesting proposition, thank you for bringing this up. We could certainly have users simply email an account, or make a new account such as feedback@resonate.coop (which then forwards the responses to the dev team maybe). We could also have users create issues here, since the vast majority of issues users will run into will be from the website and not the stream-app wrapper. The downside to responding via email would be the lack of transparency - taking these forums public has been hugely successful in reducing opaqueness with respect to the current status of Resonate and its projects. I’m certainly open to creating new and/or multiple routes via which users may provide feedback, and I’m curious what others in the community have to say about this as well.
Is there a reason why it is not on F-Droid?
If so, are there plans on putting the stable version on F-Droid?
Not only would I prefer not to rely on Play Store for downloading apps, but it might actually help make Resonate more popular, since a professionally developed app on F-Droid will most likely draw more attention than on Play Store.
Great to see that an app is in development for both iOS and Android.
I’m testing on iOS 15.4.1 on an iPhone XR
I logged in using my already existing account. No issues logging in, logging out and in again.
The issues I have found are the following (I’m including screenshots with annotation numbers):
1 - would be way more intuitive to have some kind of arrow to go back to the previous page as in the rest of the app (for consistency in the UX)
2 - is this “Learn” dropdown supposed to do something? It doesn’t have any effect on iOS (both on the app and the streaming webpage)
3 - There should be a way to favourite full albums not just artists and tracks and add full albums to playlists.
4 - this works inconsistently. Sometimes pressing it opens the options sometimes it does nothing and I have to click multiple times for it to respond.
5 - the volume has no effect.
6 - it would be more intuitive from a UX perspective to be taken to the track page when one presses on the track title both in the player section and in the track list.
7 - from a UX perspective, one would expect the profile options to close when one presses on the profile picture a second time
8 - I stumbled upon tracks that don’t play
9 - for some reason, my artist profile appears twice in the search results (one of them has no discography)
Hey @piper, I think my login issue had to do with the fact that I entered the wrong email address initially when signing up, and it was actually for an account that hadn’t yet been created.
Not sure what this means for users who enter the wrong email address when signing up and are trying to continue creating an account, but one factor to consider regarding user error, I think.
Hi, I’ve played around with the latest (as of today) test version of the Resonate app. I’m glad that this app exists! I’ve been a Resonate member for years and it’ll be nice to tinker with it on my phone as well.
Here’s my feedback, for what it’s worth:
Overall, the app looks like a web site that was converted into an app. It does not have the native look-and-feel of the platform that I would expect from an Android app. I have to be honest that I almost never continue using apps that feel this way–it gives off a sketchy vibe, and I find web-to-Android apps tend to be buggy, crash prone, and generally unreliable. That’s obviously just my own experience and opinion so take it for what it’s worth.
Aside from this, I think the navigation is awkwardly placed, and the main purpose of the app–to play music!–is obscured because there are large-font messages, navigation options etc. that take up most of the screen real estate.
Here are some more specific points:
Cookie consent is annoying–this is an app, not a web page, and I don’t want the cruft and annoyance of today’s web apps translated to my phone!
Tapping the Enable native notifications button does nothing
“The cooperative streaming platform” message in large font when first launching the app is distracting and confusing–I expect to see music when I launch a music playing app, not big text
Similarly, the list of tags under the message is distracting and confusing. Get me to the music as fast as possible after launch
The Browse/Discover/Releases toolbar at the bottom of the page is strange. I don’t expect there to be menu-like options down there. Android usually has these in a hamburger menu at the top right. Having to hit X to get out submenus is also weird–it’s easy to get lost in there
Checking in for another round of going through this feedback. Thank you all for providing your thoughts.
@snuffles, I’d not heard of F-Droid until now, I like that it’s for open source software. I think it would be good to get the app up on there.
I’ve implemented a fix for this, once that code goes live on the website it will be fixed on your end. Also, if you swipe from the left to right (as you would in your browser) you should be able to go back (and forward as well).
Unfortunately it’s an iOS/mobile only bug, which impacts the viewing the player in the browser on iPhones as well. Something to do with Offen creating an invisible box in front and making the area not clickable. I think I will do the same as I did the Notification settings and simply hide the menu for iOS/mobile users, since these links are still accessible if you scroll all the way to the bottom anyway.
I agree, that would be awesome.
You’re unfortunately running into a bug where the options menu is tiny on iOS/mobile, which I fixed here (check the link to see the screenshot of what the UI will look like when the code goes live). the grid of nine circles that you’re probably clicking on some of the time represents how many times you’ve played a track, when the grid is all filled in, you own the track.
It’s not working for me either. Ideally that should work as well as the volume control on your phone. If Android testers could please let me know if the volume control next to the play button at the bottom is working for them or not, that’ll help me hone in on the problem.
We actually have a fix for the song title UX, it’s not exactly as you describe but addresses a similar problem - the play buttons to play a track are way to small on mobile. These changes do a few things, but the main one is addressing some core UX confusion around how to play a track when looking at an album where the play buttons are the numbers on the left side. Your suggestion of pressing the title to go to the track page does make sense too, so maybe the number = play button UI should be revised.
I agree, we should do the same thing with that that we did here with the tag/search menu closing.
This seems similar to this issue. The first six tracks on that album The Trip by Sommon Cense both don’t load for me either in the mobile app or web browser as of right now (both on my actual phone and in the simulator), but the rest of the album does. I’m not set up to run the server locally yet so I can’t see more details about the server error that is happening though. I’m curious if Android users can load it on their phones. I wonder if these to two tracks are in a different (and unsupported on mobile) filetype? This is the first time I’ve seen this error myself. The tracks play fine in the web player so it’s weird the server would handle a request from the app differently (it uses your phone’s default browser to make the request), and again, the same issue is also present when I try to play that album in my phone’s browser.
Not sure if I should tag @upcoord here or who, but maybe they know how remove duplicate artist profile entries? And maybe they might know who could check the filetypes of the two songs mentioned in point #8 above?
@abucci totally agreed, documented here. This is an alpha version which wraps the current current web player in an app with a few bells and whistles like continuous background playback for iOS. A native app will be the next step (which wouldn’t need cookie consent as it wouldn’t be directly based off of the current web player.
Yeah, since it’s technically pulling from the stream web player’s discover page on load, maybe going to the library first would be preferable. Might be more of a “this will be fixed in the native app” situation.
Same as above.
That’s true, hamburger menus are pretty standard these days, and users tend to expect that UX at this point on mobile.
I took a quick look at this and it’s inconclusive.
The ‘1058’ artist profile - Resonate - is associated with a gmail email address and appears to be the ‘correct’ artist account (and has track plays/stats etc.)
The ‘3979’ artist profile - Resonate - is associated with an @resonate.is email address. Historically, these seem to have been set up to deal with some of the past limitations of various artist/band/label accounts and personas. This therefore might be safe to delete but without knowing why it was set up in the first place I’d be reluctant.
Also, there’s no simple way, from the dashboard, to see if any tracks are ‘owned’ by the 3979/resonate.is account (and which would need switching to the 1058/gmail account).
I think we’ll need an @dev to look at this (@auggod ? if has some spare time to take a look).
Filetypes would also possibly be @auggod ? In my basic understanding, I’d be surprised if it’s a filetype issue though. We accept wav/flac/aiff for upload but at some point when they go up to backblaze storage a transcoded copy is made which is what is streamed. I’d be surprised if we have different streaming versons/filetypes knocking about but I don’t know anything for sure.
I just tested on an Android device and the volume control on the app is working for me.
I can confirm that it is an independent volume control than the phone volume control. I don’t know if this is meant to be like that, or if this is due of the way the app is built (mobile adaptation of the web player).
It seems to me that (most ?) music apps tend to tie together the volume control of the phone and of the app, for consistency I guess, and ease of use (“why can’t I hear anything, the volume is up !” > yeah but one of the volume control is down…).
Took a little time to test out the Android app and I found it to work quite well.
My feedback:
After switching to dark mode, then back to auto, The ( x / ^ ) icon in the bottom right corner that allows me to close the menus and access my light/dark mode settings disappeared.
To try to play a song, I first clicked on the title a couple times and thought it was perhaps not working before discovering I had to click the number to play it. Maybe a box around the number could be added to indicate it is clickable. That location also feels kind of small and far to the left for comfortable use.
I’d like to have a progress bar somewhere which indicates how far through the track I am.
Having a Tags option in the “browse” menu at the bottom might be good, even if it were to extend off the screen and require me to swipe to find it. I expected to find that as an option there, however I did find it easily underneath “discover” after looking into it more, and I do think it makes sense for it to be under Discover.
On the add/create playlist screen, I misinterpreted the box where the auto-filled name for the playlist is. It was not clear to me that was the purpose of that box (I thought it might be a box to search for existing playlists) so when I clicked the “create” button beside it, I was surprised to have generated a playlist with that name. Then, there was not a way to easily delete my unintentionally-created playlist. I would suggest perhaps changing the label text for that field to “New Playlist Title”.
I’d also like to see this made available on F-Droid, as I have friends who use Android but prefer to avoid engaging with Google whenever possible.
Hope this is helpful. I’m thankful for Resonate and this early version of the app, and appreciate all who are working on these!
Thank you for taking the time to report your feedback @kcterry!
This is a new one for me. Would you mind taking a screenshot please so I can see what you’re seeing? (Feel free to edit your original post or just post below )
I ran into this problem myself, and have devised a fix to address it. Once this code is rolled into live, playing tracks will be significantly more intuitive!
A mobile status bar would be awesome. I totally agree.
Also totally agreed, that would be a lot more intuitive for users!
I completely agree, the user experience for that modal is pretty chaotic and should be improved. @psi’s beam app does it a bit better and actually, as of recently, thanks to some help from @auggod, now allows playlist deletion.
I want to try to the app on F-Droid as soon as possible, I have been digging/researching how to do that. It seems I’ll have to move or upload the repo or bundle to GitLab instead of GitHub. I will be sure to post here when it’s up (and try to tag the users who’ve been requesting/suggesting it to notify them).
@zetto.plus, that’s a great idea. Here’s a generalized update:
With the exception of the Unable to login on localhost issue (stream#225), here is the list of all issues impacting the stream repository (the web player that the stream-app pulls from currently) that also are impacting the stream-app.
Here is an exhaustive list of everything that impacts just the stream-app that needs to be fixed, and here is the project for the stream-app if you’d like a better visualization from a project management side of things. As you can see, the vast majority of problems we have with the app will need to be fixed in the original web player’s code to be properly addressed. For a good bit of the feedback we’ve received in this thread, the bugs are either already documented or the fix is actually already been figured out and it just needs to be rolled into live, which is really good news!
I’d also like to mention that with the advent of the beam app, we are making eventual aims to have the stream-app pull from the online version of the beam app, or, better yet, provide a local bundle of the beam app. The beam app, due to a lot of hard work from @psi, has implemented quite a few more features than the web player at this point. With a little bit more visual enhancements and once Resonate’s new login system is fully underway, I foresee switching over the stream-app to pull from beam as its direct source (and have been in discussions with @psi regarding this eventual potentiality). Also, if we are able to bundle it locally, it will behave much more like a phone app and less like a website, as all of the images and interface files would live on your phone and you wouldn’t have to send a network request to retrieve them in addition to any music you’re trying to play, so load times would be significantly improved, and we’d be able to better service those with slower connections. On the technical side of things, the beam app is written in React and TypeScript, which I’m personally a bit better than developing in as well, so I know I would be more of an asset at fixing problems if that codebase were the central source of truth for the stream-app.
Also, the way @psi has built the beam app (React and TypeScript), could also set us up for a fully native app in React Native and TypeScript - it probably wouldn’t be too hard to convert, though it would take some time. That being said, for now, I think the best possible scenario would be locally bundling the beam app inside the stream-app, and then there would be less dev overhead having to fix various issues in multiple codebases instead of having just one central source of truth where most everything would be fixed (and new features could be added) and those fixes and features would naturally populate throughout Resonate’s ecosystem, for web playback, desktop, mobile and tablet.
Overall, it’s really exciting that there’s so much action and development on Resonate’s tech side as of late. We’ve come an incredibly long way just in the past few months since I’ve joined, and it’s been awesome to watch the ecosystem is now becoming flush with apps and tech that use Resonate’s API.
This is amazing, @piper, and thank you so much for your recent contributions, @psi.
In reaching out to recruit more volunteer coders, what are some things you’d say I (along with others) should stress or emphasize at this stage? In the fewest amount of words possible?
bullet 1 → just testing is low-effort and generally gets people playing with the platform (this is also what I’m doing, psychologically I’m trying really hard not to get sucked into a programming side-project)
bullet 2 → some people might be nervous about jumping in and turns out they don’t like a project. A bite-size “good first issue” is non-threatening
Great, we really appreciate your efforts on this. Here’s a short blurb describing Resonate’s code and needs:
Resonate is in need of front-end and back-end developers to help build out its ecosystem. Its main tech stack is JavaScript for the web player and a server/API written in Go and JavaScript, and its desktop and mobile apps are written in TypeScript and React. Any contributions and any degree of involvement would be greatly appreciated. Thank you!
EDIT: @boopboop posted while I was drafting my message so I didn’t see that til after, I think her framing above is super on point (and nice and short, like you asked for). For the third bullet point, you could grab screenshots from this page, since they look pretty nice.
EDIT2: I realized the images from the Android test page I linked above download as .webp files which is slightly sub-optimal. I’ve added a few screenshots to the GitHub page of the app here if you want to grab those (.png files are a bit easier to deal with).
)
