HN user
JavaScriptMVC/DoneJS has a pretty long history: http://blog.bitovi.com/longevity-or-lack-thereof-in-javascri...
CanJS, the MVVM part of DoneJS, is currently coming up to its third major/breaking version. I think that’s a pretty good track record for us/Bitovi.
That’s a great question that’s been pondered by philosophers for a while: https://en.wikipedia.org/wiki/Ship_of_Theseus
Here’s a fun video talking about the same thing: https://www.youtube.com/watch?v=nQHBAdShgYI
Brady Haran & CGP Grey recently talked about this (and other things) on Hello Internet (~1:10:25): http://www.hellointernet.fm/podcast/52
With regard to “why do I have to exit messages to scroll through a list of my contacts”: are you aware that you can start a new message and either start typing in the “To” field or tap the + button to bring up your list of contacts? Is there something else you’re looking for?
It’s in the App Store Review Guidelines introduction: https://developer.apple.com/app-store/review/guidelines/
“If you run to the press and trash us, it never helps.”
Unless I’m doing the math wrong, 0.00385% of 10 million is 385.
I was disappointed to see that this was really a list of things that haven’t really worked out well for the author.
As someone who’s having a hard time gaining lots of new users for my service[1], I was really looking forward to some actual lessons in what’s worked. I checked out the Case Studies, but the content wasn’t anything new or particularly relevant to the scrappy startup situation. I think the most useful content on Grow/Hack right now is this post with actual lessons learned in growth hacking: https://news.ycombinator.com/item?id=4603640
[1] It would be remiss of me not to mention it: Iron Money https://ironmoney.com/
Yes, but when it comes to suggestions about standard UI features, I’d be surprised if he disagreed. Apple sets a fairly clear precedent for how standard iOS UIs should work, and whether or not it’s in the Human Interface Guidelines, going against the standard Apple sets feels sloppy.
I would find it more likely that, even though (IIRC) the guy handling Instapaper’s support said he would pass it off to Marco, he simply didn’t see my suggestions or ever do anything with them.
I don’t think that would magically make them upgrade either, although they might be willing to do so since the only thing we can do is not upgrade our apps to support them.
Obviously this will vary from app to app, but I’m surprised that you have such a high number of users with an older version of iOS. Is that across all of your apps/games?
> Imagine if Android’s Gmail app made you click the trash to save something. We would certainly see complaining blog posts and snarky tweets all over the place. So why does Instapaper get a free pass?
I’m not sure that we would. There are some great designers working on Android apps, but I don’t get the feeling that the UIs get the same critical eye, especially because there is less consistency throughout Android.
Marco should probably have the Archive box and the trash icon in the main list view instead of the trash icon that does both. However, I get the feeling that he doesn’t care as much about the polish of Instapaper as some people do. Last year I sent him an email with a list of adjustments to bring Instapaper in line with how iOS apps should behave (e.g. table view cells should fade out with the back-navigation transition instead of after it), but months later, most of the issues aren’t fixed. It’s the little things that really show polish and he doesn’t seem to be responsive to fixing the little things.
I doubt this will ever be fixed by Apple because this issue affects so few people. The overwhelming majority of iOS devices in active use can run at least iOS 4.3[1], and I’d guess that the users that don’t upgrade to the latest iOS version are the same ones that don’t update all their apps through iTunes. I’m guessing that the number of users who update their apps through iTunes but don’t update their device (or can’t update their device) to the latest iOS is very small.
I wasn’t particularly thrilled that I was forced to drop support for iOS 3, but looking at the number of active users of my app[2] that were running the current version, I saw that none of them were on iOS 3. This was probably the right time for Apple to drop support for < iOS 4.3.
[1] I don’t have stats to back this up, but seeing that iPhone 3GS is the lowest hardware to support iOS 4.3, and they’ve sold way more devices since then than original iPhone and iPhone 3G, I think it’s fair to assume that the vast majority of iOS devices in use can run iOS 4.3 or later.
Thanks for your feedback! This is definitely something I overlooked and should add to the homepage, probably as part of the first header or as its own section at the very top.
I recently redesigned the pages promoting the website[1], the iOS app[2], and the Mac app[3], in an effort to make it clear what Iron Money is and how it helps you manage your personal finances. I’m looking for any suggestions in how the copy, screenshots, or overall design can be improved. Thanks!
[1] https://ironmoney.com/ [2] https://ironmoney.com/ios/ [3] https://ironmoney.com/mac/
I think one of the things that separates our points of view is that I see Iron Money, the apps and service, as the product, with the API as a great extension for helping developers build cool stuff on top of their data; I don’t really see the API as the product I’m trying to push. Point for point:
1. This makes sense and is what I thought would be my biggest hurdle. Thankfully, this has never really been an issue. A lot of people are surprisingly willing to trust their finances to a third-party they don’t know that well.
2. I agree, although I think it’s even more valuable to have professionals audit the source code. Both together is probably optimal for security.
3. I realize that, in the example you cite, it was helpful to have the source open, but in the case of a (usually) consumer product, I don’t think this argument holds much weight. Iron Money mainly targets young singles and couples who want their finances on the iOS devices and Macs, and having it be open-source rarely plays into the decision to purchase.
4. I agree. I don’t think Iron Money is really marketed as a closed-source library, but the point stands. In any case, I would probably open the source if the service was shut down.
Thanks for taking the time to write up your thoughts; they definitely provide food for thought.
Hm, interesting. I’ve thought about making Iron Money open-source, but I’ve never thought of a really compelling argument. Other than the transparency of what’s going on behind the scenes, what makes for an eloquent argument for making it open-source?
I don’t work for Square so I can’t talk about their specific implementation, but here’s how it should work:
When a “tab” is set up, the app can register with iOS to receive notifications when a user enters the geofenced region. As usual, the app will be suspended when you close it (i.e. not running), but when iOS detects you’ve entered the region, it’ll move the app into the background so it can run temporarily. In the case of Square, they might get a better GPS fix on you and tell their servers that you’re actually really close to where you have a tab open.
Agreed; it doesn’t feel like instructions to copy, rather recommendations for how the user experience can be improved. I wish the original[1] was the one on the front page right now.
Of note, on page 131: “Strong impression that iPhone’s icon concept was copied” “Directions for Improvement: … Remove a feeling that iPhone’s menu icons are copied by differentiating design.”
Even the evaluator determined that the layout of the home screen was too similar to iOS.
It saddens me to see OAuth 2.0 in this state. As someone who’s made really minor contributions to 2.0 (and thus listed as a contributor in the spec), I have been really looking forward to it being finished and ready for production use (where production use means no more drafts). I stopped following the mailing list last year because most of the threads seemed all too familiar or out of my realm of knowledge to contribute (read: enterprisey).
I run a 1.0a service provider and write clients against it. I’m thinking about wading through the current 2.0 draft, picking out the relevant parts to small startups with an API, and publishing a post about how to implement the sane parts of the 2.0 spec.
I can’t offer a solution for the ultimate workflow, but I can make some suggestions based on what I do. I also use Things, and I have an area for the company where I put all bugs and feature requests. When a user mentions an existing bug or feature request, I can increase the count to track the popularity of an item. For each release, I create a new project and add all the to-do items that I want to complete for that release. I usually schedule items based on when I think I can have them done by, which gives me a pretty strong indicator if I start slipping my schedule.
[As for everything else, I use email for all communication and don’t use Github, so everything stays in email or Things.]
FYI, the term “backward integration” is used in business to talk about a company’s integration with its suppliers, while “forward integration” is used when talking about removing friction with customers. In Cipla’s case, it looks like they purchased manufacturing facilities that were producing their products: http://www.vccircle.com/500/news/cipla-to-acquire-meditab-fo...
I wish I would have done this. I started working on Iron Money[1] during my first year of college, and I even took a year off so I could make it profitable. I don’t regret what I’ve done, but I wish that I had worked for other companies to get experience before starting my own venture.
In the same way that new companies should be an improvement to what is already offered by others, I think there is a lot to be said for learning the successes and failures of how other companies run before starting your own.
In Settings, under General, there are Restrictions that you can place on the device, including disabling In-App Purchase. Every app has their In-App Purchases listed in the store, so you can see which ones have them before buying.
More info on restrictions: https://support.apple.com/kb/HT4213
Yes, hence “RESTful.” The API is definitely not a prime example of a REST API since it doesn’t return the URIs of resources. It does, however, generally follow the other constraints.
Iron Money’s API[1] is RESTful and protected with OAuth 1.0a; since it uses the plaintext signature method, no nonce is used for each request.
I’m not quite sure what your security question is. Since the API and web app use different authentication schemes and have different endpoints, there is no risk of CSRF.
“Once you allow plug-ins that potentially lie then you’ve ruined the entire Siri experience.”
Apple already has a solution in place for this problem: the app review process. When Apple figures out how apps should integrate with Siri, I think they’ll have guidelines/rules for how apps should use the Siri APIs and they’ll be able to enforce those rules with the review process.
Not personal, but this isn’t something that should have made it through the review process. I’ve had a Mac app rejected for a far more minor offense (having a label in the preferences sometimes display incorrectly); an error alert on launch should not have made it past any reviewer.
I’m surprised that this article didn’t talk about doing regression analysis with PHP and R. Using R adds a dependency, but it might be worth it. I’d recommend this article[1] if you’re interested; the “cat file.txt | /usr/bin/R --vanilla” line is particularly helpful in executing R directly from PHP.
[1] https://www.stanford.edu/~mjockers/cgi-bin/drupal/node/25
It’s bizarre, but I’ve had this experience as well. Last October, I started raising the price of my app by $1 every week or two. The total number of purchases per week varied very little, so I ended up leaving the price at $9.99 (the highest I tried).
The black bar signifies the passing of someone important to the community: http://news.ycombinator.com/item?id=2712469