Comment by rene_bg | Hacker News Reader

Comment by rene_bg | Hacker News Reader

Parent Full thread

- The site is great, esp. the testimonials :-)

- In the app, cut down the introduction texts and steps. It takes like 30 taps to get the alarm started.

- Also, I found the pulse of the focused area (the circle) annoying and distracting when reading the text just next to it.

- Use briefer descriptions of the things in the guided tour(s). Every word you can remove is often an improvement. And, again, get rid of steps. I'd recommend 3-5 steps tops (and entirely!).

- Somewhere you write "Try to tap here to do something..." => Get rid of the "Try to". As a user, I know how to tap - just write "Tap here to ..."

- Make the sound selections (radio button lists) play the selected sound on tap: by default the top entry is selected. When I tap it—as I initially don't know how it sounds–it doesn't play the sound. I have to switch to the second entry and then back to the first one.

- 42 MB is quite large for "just an alarm clock." Most people won't bother, but keep in mind that even in 2017 software should be performant and, if not necessary, not bloated.

Besides these minor points, I have to say that the idea is great! I am really looking forward to use the app tonight :-)

Hi! Thanks so much for this very detailed feedback and glad you like the testimonials :).

intro/onboarding feedback: I agree with you and will look at ways to cut it down both in length and quality

- I just removed the "Try tapping" and changed it to tap cause I agree with you (it will be pushed out next update)

- you're 100% correct on the sound previews too, I implemented the listener as an onChanged rather than onClick, but will look into fixing that in the near future.

- the 42 MB is almost entirely due to mp3 sound files (the alarm ringtones + sleep engine sounds). I used compression to strike a balance between quality and space and also used seamless looping on the sleep engine to get rid of the need for giant audio files, but there is always room for dramatic improvement on that front and I'll keep working at it. If you have any suggestions please let me know. I think that once I get a back end going what I'd eventually like to do is have users download the tracks based on what they need (this might be a very naive approach though so correct me if that's a bad idea).

For smaller audio files, take a look at the Opus codec. It does way better than mp3 at lower bitrates. Android 5.0 and up can decode it natively and there's a library with NDK that should work on older devices.

Awesome, I'll take a look. My main reason for choosing mp3 was compatibility, but I didn't research it thoroughly, I just chose the cookie cutter option. My app is currently min 5.0 so this seems like a very viable option. Thanks :)

I'm glad I could help and looking forward to the update :-)

IMO the sleep sound feature seems to be something you should analyze whether it's used or not. If not (<5 or 10%?), drop the feature. If it's used, you might want to extend the collection (in the premium version only?), and then the user could download the sounds he/she wants.

ya very fair, I'll look into this after some analysis, thank you!

You could reduce download size by a form of lazy loading, download the files on demand/request in the app, so ship the code without most of the media?

If you're paying for the download bandwidth that might help too, as many will get the app and never use it.

You could use IAP to sell new media packs including high-quality.

Yeah I think this sounds like the eventual goal. And media packs are interesting, but I'll have to provide many, high quality sleep engine sounds to justify that. Thanks for your advice :)

Reply on news.ycombinator.com