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).
Perhaps if the app were to be re-written as a pure React Native app without the Expo wrapper, it could be included. I have updated the associated issue#46 on the repository to reflect this. I will do some digging to see how feasible this is. Currently we use quite a few functions from Expo APIs but there should be vanilla React Native library based counterparts that could work in their place.
)
