I have to think about how to explain the feature in the app without overwhelming the user. Always open to suggestions!
> The numbers in the lower right corner of each stack seem like they refer to the number of sub-comments, but in my brief experience this doesn't seem to be the case. Is this a bug, of have I misunderstood what these numbers refer to?
It's the total number of comments in the subtree (including all the child subtrees and their subtrees and so on).
> I'd prefer to be able to tap a comment stack and have it open up. I get that swiping isn't that hard, but I typically one-hand and would prefer if mere tapping did the same thing as swiping (and I can't think of what else a tap would mean, so it shouldn't cause a conflict to have this as an option, right?)
I think it could be a frustrating experience when you mistap upvote or any other button, expanding/collapsing the stack instead. I will try it to see how it feels, it just might be one of those things that look good only on paper, and once implemented it'll be just an extra option that everybody ignores. There's also a good argument for that - accessibility [2], but there are alternatives for the tap gesture.
> I would suggest adding Settings to this menu, as an alternate way of reaching it.
I figured that on average users go to settings only a few times, mostly when they initially set up the app. Adding an entry point on the thread screen would increase the complexity, support and testing efforts, but further down the road when other things are ironed out it can be a good improvement.
Regarding the settings, you're right that many users would only go there once; however, it's likely they would go looking for settings once they're already in a comment thread (or at least I was!).
I agree that mis-tapping could lead to confusion if stacks could be opened that way, but closing requires a swipe. But since you can tap to go into an article, it seems natural to tap to go into a stack also.
Regardless, I'm really enjoying the app's interface. I also sent you a message via your website's Google form, with other ideas. Congrats on the concept and execution!
Thanks! I wanted to read comments in a breadth-first manner, and I knew from the start that using Apple navigation solutions wouldn't work for me, the visual change on the screen between two states would be too big and distracting.
I made a few prototypes, experimented with omni-directional scrolling (comments don't change their relative position to each other, but you kind of move the viewfinder and it sticks to the edges of subtrees), color coding in different patterns and nothing felt good. I gave up and a few months later when I was thinking about a different problem, I just had a light-bulb moment about this one, mind works in mysterious ways I guess. It was unnecessary complicated at first (like dragging the designated "borders" with the comment staying fixed in one place), but I simplified it in the process quite a bit.
It looks pretty straightforward now, but I think a lot of people would be surprised to see how many tricks are there for it to actually look and feel that way.
Do you have more info on the max comment depth by any chance? I did a quick search and, unless the info is outdated, it looks like there's some kind of anti-flamewar mechanism in place, but no set max depth https://news.ycombinator.com/item?id=11429230
I couldn't tell you if it's a set depth or some kind of stochastic system. Many of HN's rules are subtle/invisible, to the point you can't even be sure whether they're being applied by an automatic system or by a moderator. For example, you can post a large number of highly-upvoted comments in a short timespan, but if their score is neutral or negative you'll get muted for an indeterminate amount of time; I've seen between ten minutes and a full 24 hours personally. You can also get muted for stepping on the wrong person's sacred cow; you can tell when that happens because you'll find yourself muted when your last day's comment history is, say, only three comments and all of them have positive scores and no flags. I've found it handy to keep a list of "things mods don't like opinions on".
That's an interesting UX problem. Have you tried Anchors ("#" buttons)? Do you feel like it would be convenient if there was an option to mark all new posts as anchors? You could jump between them with "previous/next" buttons.
> I'd have avoided a free version and just made the basic price at least $6
I would definitely get less heat, but the user would paradoxically end up in a worse position. I feel like there's always a disconnect between the user and developer when it comes to a freemium model. Developer thinks that it's a paid app that the user can actually try and make an informed decision before buying. User thinks that it's a free app with arbitrary annoying restrictions. And I understand the user perspective.
I think things would be better if refunding was less painful for the user and developer both. If there was a zero friction way of refunding things, we could just abandon freemium.
As a user, I've found utility in apps that offer all features and customizations for free, but reset your preferences every time you start the app. It's like a demo except it never stops working and you can see the maximum amount of value the app can provide you.
That's how my app handles customizations - they just get resetted once in a while, but you can use them without paying, Premium just makes them permanent. I wonder if it's not obvious from the UI and people think that you can't use them at all.
Curious if you have an example app for this? I have a stored records based app I work on occasionally and I wonder if an X day storage would fit this bill… but it feels weird to say, “if you want to store data permanently then it’s $y a month”
My personal experience with it is game emulators that reset your customized control layouts and such but I imagine it could work for other sorts of apps.
Thanks! Under the "Sign In" button you can tap "Alternative method", it opens a webview and you can auto-fill you credentials from the keychain. It's a few more taps, because you have to choose from the list of saved credentials, but otherwise that would be a security risk, Apple wouldn't allow that.
> I feel you should be able to tap a comment to expand, rather than just swipe
One frustration that I had with existing apps is collapsing a subtree by accident when tapping the upvote button. I feel like it would be even more frustrating with how my app works, it'd just expand/collapse if you miss the hitbox.
> Also it’d be neat if you just kept the new scroll position when expanding rather than scrolling back
The issue with that is that if you expand a subtree, scroll way way down and then collapse, your scroll position will be so far away from the initial node that you'd get lost.
> The orange flashes when navigating back are distracting. Just use the default system behaviour here (grey)
I'll add an ability yo choose the color in the Settings.
> If you tap the active tab (both in the heading and tab bar), it should scroll to the top
> I can't tell what the hashtag button is for
It's demonstrated in the guide [1]
I have to think about how to explain the feature in the app without overwhelming the user. Always open to suggestions!
> The numbers in the lower right corner of each stack seem like they refer to the number of sub-comments, but in my brief experience this doesn't seem to be the case. Is this a bug, of have I misunderstood what these numbers refer to?
It's the total number of comments in the subtree (including all the child subtrees and their subtrees and so on).
> I'd prefer to be able to tap a comment stack and have it open up. I get that swiping isn't that hard, but I typically one-hand and would prefer if mere tapping did the same thing as swiping (and I can't think of what else a tap would mean, so it shouldn't cause a conflict to have this as an option, right?)
I think it could be a frustrating experience when you mistap upvote or any other button, expanding/collapsing the stack instead. I will try it to see how it feels, it just might be one of those things that look good only on paper, and once implemented it'll be just an extra option that everybody ignores. There's also a good argument for that - accessibility [2], but there are alternatives for the tap gesture.
> I would suggest adding Settings to this menu, as an alternate way of reaching it.
I figured that on average users go to settings only a few times, mostly when they initially set up the app. Adding an entry point on the thread screen would increase the complexity, support and testing efforts, but further down the road when other things are ironed out it can be a good improvement.
[1] https://github.com/devandsev/HackerNews-Support/wiki/Guide#a...
[2] https://github.com/devandsev/HackerNews-Support/issues/1