We’ve added a GitHub link to the Cookie Disclaimer as others suggested above. We also now let the user press a button before being prompted after they’ve read the policy, which makes the feel app a bit politer to the user. Again, this screen will only ever be seen by iOS 14+ users who have Tracking toggled on (which is 4% of users per the resource posted above in this thread).
Screenshots of this in action are visible here:
The new build (1.0.9) with this, along with disabling the pull down to refresh the page feature (it interrupts playback in a way that a user would not expect, and shouldn’t be necessary) has been reviewed and released on both Android and iOS platforms in the links in the first post in this thread.
Today, @brndnkng asked if the app was ready/usable enough to post to social media accounts, as it could act as a boon to fundraising efforts.
I know @auggod had some reservations with respect to taking the app official/public on the App store
(perhaps because the UI was very preliminary at the time or because the beta player https://stream.resonate.ninja is not live yet), so I wanted to raise this question in this thread and get everyone’s feedback. Because those changes are not on the main website (namely https://github.com/resonatecoop/stream/pull/182, which makes the player match device theme preference the same as the status bar does) users will not have access to the absolute latest and greatest just yet. Update: as of March 2, 2022, these UI fixes are live!
As of the time of writing this, here’s the current strength/limitations breakdown - The way in which we’re wrapping the React Native code using the Expo platform is providing features that the Progressive Web App (i.e Resonate’s stream website when viewed on mobile) lack:
• Downloadable app from Google Play/Apple App stores and automatically creates a shortcut to the app on the user’s Home Screen
• The feel of the user interaction is improved: buttons and scrolling respond to user input in a less clunky and more app-like manner
• A more immersive user experience as the additional screen space because there is no browser address bar.
• (iOS 15+ only) A functioning Now Playing control visible from when the phone was locked or the user swipes to use their Control Center. (This was already functioning for the Android Progressive Web App [the website on mobile].)
• (iOS only) Playback continues even when the phone is locked, background play functions as expected.
Current limitations we’re currently aware of (which are also impacting the Progressive Web App [the mobile website], and will need to be solved by fixing them there):
• The UX for a listener creating account isn’t as intuitive as we’d like.
• (iOS only) the Learn dropdown in the top center is non-functional, pressing it does nothing.
• (iOS only) Back icon is invisible or tiny.
Edit: It was also emphasized (and I agree) that this a preliminary alpha created by one user, not a full fledged app created by Resonate at a whole. We don’t want to give the false impression that Resonate has a large dev team and does not need funding.
there are two Log In button visible, the one at the bottom gets you to the Log In screen, the one in the middle actually logs you in. Pressing the bottom one while on the Log In screen does nothing.
System “Back” button takes me out of the app back to the launcher when I’d expect it to back away from the current screen / stay inside the app.
Artists/Labels/Releases Browse pages would benefit from having a “list”-like view. If you’d ask me, I’d like having a view similar to what’s on the Track page for those, and an even lighter list view for the the Track page (e.g. group all tracks under a group as a Release, with its associated artwork/artist only shown/listed once for the whole group.)
The Track browser page’s performance feels sluggish on my phone - not a powerful beast, but usually handles anything OK.
On the UX/look and feel side of things, I’m feeling a lack of feedback on button/UI interaction. For example, I would expect buttons to light up as I touch them, indicating interaction has been made. Sometimes during the few moments between a button press and the action actually happening, without any feedback, I’ll be tempted to press the button again (“maybe I missed it?”). Likewise, I cannot know if I misclicked anything as the unwanted action will occur and I won’t know what I did wrong.
This is great feedback @CPacaud, thank you for taking the time to write this all out!
Yes, this is an interesting subject I’d like to hear folks’ opinions on. I didn’t call the app “Resonate” because I didn’t want it to seem like it was an official app put together by a team of people as opposed to merely a contribution from a member of the community. I called it stream-app as it essentially ports Resonate’s stream repository to mobile. I’d be happy to rename it since there aren’t currently any other apps existing yet.
I think I know what’s causing this. I’m going to release a new version of the app with this fixed, and hopefully this will make this behave as expected (should be as simple as changing a true to a false).
According to the current MediaSession Browser Compatibility, I’m suspecting your phone’s default browser may be using WebView Android or a browser that hasn’t implemented MediaSession support yet. @CPacaud, if you want to test the stream player in your phone’s default web browser and let me know whether or not those controls show up for you there, that would be helpful! If they don’t, then it’s definitely a lack of MediaSession support from the browser.
Also, I see that the tracks screen is laggy/sluggish for you. Please let me know if using that page in your phone’s default browser is a lot faster or about the same so we can compare, when you get the chance! The app should be at worst slightly slower than your browser, but shouldn’t be by much.
The rest of your points apply to the player viewed on mobile, and it’s all really good feedback in my opinion. I’m going to add these as issues in that repository so they can be addressed.
Speaking more generally, some improvements went live today to the website player that make the status bar and the app both match the device’s theme preferences, so the status bar should always be dark if a user’s phone is in dark mode and the rest of the app will follow, etc.
I think the name of the app should 100% be “Resonate” once it’s live, if there is consensus amongst members on what we’re left with. For whatever that is worth. Anything else would just be confusing and inconsistent, in my humble opinion.
I agree. @piper you should just go with the confidence that the community validates your work to consider it “official”. We can decide about that through a vote if a formal process makes it feel more legitimate but I’m 100% confident we’re all ok calling it our own, it’s too critical of a feature to not have the official stamp and more basically it just looks good already.
Hi just testing on my iPad now. So far the “Learn” tab in the top left corner doesnt do anything… or is non responsive. There’s also, what I can only assume is a back button? Its a white square just under the resonate logo, once you’ve searched a style of music. Right now it just appears as a white square, but if I click on it it takes me back. However, when it takes me back, while it takes me to the previous page, it orients me to the bottom of the page.
With respect to the app name: that’s great feedback everyone, I totally agree. As of the latest version out today, 1.1.0, the name is Resonate! I suspect the yellow dot next to the name just means it’s in Open Testing and not an official release in the App Store yet. Check it out:
Along with (hopefully) fixing @CPacaud’s session being persisted even after being logged out, this new version also seems to have fixed an issue where clicking the dropdown would turn the user’s status bar text the same color as the background (making the text almost completely invisible to the user). @CPacaud, when you get a second, could you please let me know if version 1.1.0 still keeps you logged in even after you’ve logged out?
Interesting, @KallieMarie, what iOS version is your phone on? It might be Apple being snooty about only letting more recent OS versions use TestFlight. I was able to use it with iOS 14, so I’m guessing you’re on something earlier than that. Note that only iOS 15 supports the Now Playing widget.
Unfortunately, this is a known bug inherent to the player. I’ve been digging into the player code and my knowledge of it has improved in recent weeks, but I still have a long way to go with my understanding of everything. Hopefully we can figure out how to get this one fixed soon!
The functionality of this app is tethered to the functionality of the website player. If we have a bug or UX weakness in the website player’s code it will typically also affect the app. But this can also be a strength - when we fix bugs with the website player we also improve the app for everyone. So it can be bit of a double-edged sword. With the news this week I’m hoping we get a few more software developers keen on volunteering their time to help tackle some of these issues.
@CPacaud that’s unfortunate. According to React Native WebView documentation, it should automatically use your phone’s default browser. I will do some digging and see if we can “force” it to use one we know supports MediaSession, since it appears to be getting confused with your unique setup. Every time I read through their docs I get more ideas for things to implement, so fingers crossed we can get this functionality going for you!
It doesn’t look like React Native WebView lets you set or request a particular browser from the user’s OS. The fact that /e/ OS’s default web browser clearly supports MediaSession but not with the app makes me suspect /e/ is having trouble realizing it’s technically a browser and treating it as such. I believe on Android you can bookmark a webpage and it’s not really differentiatable from an app, so until there’s an update from /e/ that happens to correct this or we finish our native app development, this may unfortunately be the only decent option for /e/ users. I’ve changed a few parameters in this next update (1.1.1), so I’m gonna hope that one of them will happen to make /e/ happy and realize how it should treat this app, but it’s a bit of a shot in the dark.
Status Bar no longer occasionally changes its color to the same color as the background
A lot of changes under the hood were put into place for this version, so I really appreciate everyone’s diligence in testing so we can make sure I didn’t break anything or cause any regressions with this update! Cheers, and happy Friday everyone!
@CPacaud, version 1.1.1 (11) has arrived on the stores now. Along with the other improvements mentioned above, I did manage to enable something that your /e/ browser may need to be enabled to use MediaSession. When you get a chance, please let me know if the most recent version gets your music playback controls showing up in your system notification area.