- Comment width doesn't get narrower no matter how deep in the comment tree you are
- You always see the parent of the comment you're currently reading
- Swiping allows you to move in and out of subtrees with animated transitions that you fully control
- You can easily skip subtrees that don't interest you by scrolling
As a result it's easier to maintain the context and to keep track of where you are in the discussion tree. The app is fully featured, it does all the things that you would expect it to do, and there's extra: custom boards, search, in-thread search, anchors, reading list, recent items.
Video preview: https://imgur.com/a/tzBdpXw
In this case, $6 US for dark mode.
Id rather just have a “donate $6 to help dev” in app purchase as it seems more authentic.
However, maybe there are really people who think dark mode is worth $6. Kids raised on Roblox seem to have no ethical issue with paying $5 for a digital hat that is just flipping a bit.
No other profession probably degrades themselves as much as developers. If his app is worth it, people would pay or else they don't.
No developer need to beg for money if they are good at their craft.
The bit is flipped at runtime or compile time. In the old days you'd pay for an upgrade and get a new binary with the feature compiled in. Nowadays the feature is compiled in and gated at runtime. In the end it's the same.
That’s better than every other pay scheme I can think of since you have the option to do without.
It’s clear you put some thought into pricing and have avoided the subscription route which is what most people will complain about.
I wouldn’t put much stock into the complaints here.
If the author really wishes to put this feature behind a purchase, "follow system settings" should be the free default.
The OG is definitely email. What would really rock would be an IMAP gateway which you subscribe to with your favorite email client which then gives you threading, read/unread markers etc. It could abstract different front-page days as folders and each submission as the root of a thread. Then you could use whatever email client you like the most, with all their decades of polishing. It could even support replying to threads. And it could support different "backends", like HN, reddit, whatnot.
Anybody? That's something I'd pay for. Or do I need to keep dreaming?
I remember reading threads using a UI like this (not my screenshot but this is the client I used, MacSOUP): http://www.fen-net.de/mac/bilder/macsoup/Thread.gif There were also keyboard shortcuts to make navigating efficient.
Having a Usenet gateway seems like it would make a lot more sense from a technical standpoint than an email gateway
This doesn't make sense. Email is a protocol, not a UI. It would be fairly easy to make a UI that displays email like Reddit threads (the hardest part is probably stripping quoted replies). Thunderbird can display the discussion tree, but doesn't inline the message content. GMail inlines message content but linearizes the thread. I am not aware of any clients that inline the discussion content in a tree view.
Run mkdir -p /path/to/some/directory/{cur,new,tmp}, then ./hn2mdir.bash /path/to/some/directory/, and it'll crawl Algolia's HN API to dump a bunch of emails, one for each post/comment. You can read it with mutt -f /path/to/some/directory. Syncing with IMAP left as an exercise to the reader (I'm using mbsync).
Note that it gets large, fast, and may break your IMAP server; I periodically run find ~/Mail/HN -type f -mtime +30 -delete to clear it out.
Edit: should clarify, this is read-only, I've never bothered to set up any kind of response functionality
I'll agree that charging $6 for dark mode does come off as nickel-and-diming. Honestly, I'd have avoided a free version and just made the basic price at least $6, one-time, with options for larger donations to the dev if you really like it.
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.
Not sure if you're a dev yourself, but I don't think yours is an uncommon feeling among developers reacting to pricing.
[TL;DR - I think our expectations are out of whack though]
Why do you think this is, though? As a developer, we know that all code has a carrying cost, and that when building on the sand that is the iOS SDK, that almost mandates at minimum a yearly compatibility update, and possibly occasional significant rewrites if some critical SDK feature is removed or broken. Also, this app is building against a third-party (HN) api as this one does, which could change at any time and require the developer to update the app to be compatible. Having a periodic subscription is the only way to align developer and user interests -- they need to keep earning your money a little at a time, and as long as there is a good audience, there is a matching revenue stream to justify continued maintenance on the app. A one-time unlock front-loads 100% of revenue, making all maintenance work have negative ROI unless the app experiences constant, consistent growth forever. And there's certainly a limit on how many people will ever regularly read HN. Eventually that ceiling will be hit, and the app's revenue could drop to effectively zero, even if a million users count on it daily.
As humans though, especially analytical ones who are keenly aware that $1 a month for the next 10 years is $120, we hate to think of spending an 'absurd amount' like that on any apps unless they fit a certain mental model (it seems things like Spotify fit a profile that we understand comes with monthly bills attached). But I think it's odd that, while we would feel completely fine spending $6 about once a month for an ice cream cone, Starbucks, a package of cookies, etc. we balk at the prospect of paying even $1 a month for an app, even when it's an app we use daily, like a podcast client or, for some, a HN app.
I think I place the blame on the expectations accidentally set up in the 1990s, when software for most consumers was preinstalled (thus invisible in cost) and everything else was "one-time" because both the need and the ability to distribute updates regularly was so much less. I assume companies like Microsoft and Adobe who did need to maintain their software could count on the massive ongoing computer adoption in that era to make them profitable even when many end-users would decline paid updates once the apps reached a certain level of maturity -- which I think was the predominant practice among anyone except certain classes of "professional" users. While I agree some apps are out there that charge say, a $19 monthly subscription to crop images, just exploiting ignorance of customers or preying on children, I think we should normalize apps that receive maintenance having a subscription model.
So release new products or paid updates, the way everyone did before subs.
> A one-time unlock front-loads 100% of revenue
Also known as "buying", which is a thing
> making all maintenance work have negative ROI unless the app experiences constant, consistent growth forever
Unless you release paid updates, which is what a number of developers do.
> Eventually that ceiling will be hit, and the app's revenue could drop to effectively zero, even if a million users count on it daily.
So don't put all your eggs in one basket. Have different products. Explore different things. You're essentially asking to be rewarded for stagnation here.
Subscriptions are about (1) being paid for work you didn't do, since you get paid whether you did anything or not; (2) disrespecting my choice as a consumer, since maybe I don't feel I need any updates and I don't want to pay for them, and (3) encouraging bloat, since there's more pressure to pack in needless features just so you can justify demanding payment every month.
You're basically saying "I need regular handouts because I couldn't make money otherwise." That's a problem with your business plan, and it doesn't justify demanding money for work you didn't do, or requiring me to pay for things I don't need.
I'll agree with you on one thing: years of free or artificially cheap software have conditioned people to not want to pay a lot for software. I always thought $0.99 per app was ridiculously low. I don't have a problem paying tens or even hundreds of dollars for good, powerful software, but I want to own it. If I'm going back through old files a decade or two from now, as a lot of us do, I want to be able to open them. And I don't want to have every one of my apps draining my bank account bit by bit.
If you want to offer a subscription for people who want every update you release, fine. At least they're getting something. But the fairer model is what a number of developers are doing: more money upfront, which includes a lifetime license and one year of updates (which is nice, but I would understand if they didn't include it).
There's a reason why so many people despise subscriptions, and why I doubt that model—while it seems to be the fad now—will ever be normalized. Most of us can't afford it, it denies us long-term access to our own content, and we know on a basic level that it's wrong.
-iPad user
A couple thoughts:
• I can't tell what the hashtag button is for
• 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?
• 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?)
• There's no way to reach the settings from the discussion view. The presence of a ... icon makes this confusing, because that's where I'd expect to be able to change settings and such. I would suggest adding Settings to this menu, as an alternate way of reaching it.
I know some people are upset about the freemium model, but I think you threaded the needle just about right here. You don't actually disable the night mode functionality in free mode — you just make it not a permanent setting. It would be slightly better if you were more explicit about when the temporary setting will expire, but I really don't see how someone can complain about how you've done this. You let people access every single functionality so they can try it out. Unless you're making this a pure hobby (in which case there would be less upkeep, support, and ongoing development), you can't rely on a tip jar.
> 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
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!
I feel you should be able to tap a comment to expand, rather than just swipe. Also it’d be neat if you just kept the new scroll position when expanding rather than scrolling back
The orange flashes when navigating back are distracting. Just use the default system behaviour here (grey)
If you tap the active tab (both in the heading and tab bar), it should scroll to the top
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
Nice idea, I'll add that.
I see you get a lot of comments about the paywall, I suggest you try offering a 7-day trial instead of the nag. Or, better yet, limit it to X number of openings or something like that.
https://play.google.com/store/apps/details?id=com.simon.harm...
I like the app, but there's too many features behind the paywall.
