Hacker News Reader

Comment by copperx | Hacker News Reader

That part of the post-mortem is inaccurate.

I was looking recently for a solution to display a status board for a small business on an HDTV. 40" TVs can be found for $180 (you don't have to spend $3000 to have something useful), a mount is $20, and the app is $10. You've got most of the components for $210, but then you have to stomach the $200-400 to buy an iPad which will sit unused taped behind the TV just to display the status board. Not to mention you have to secure it to prevent theft if the TV is on a high traffic area.

The idea that you have to sacrifice an iPad doesn't feel right to me, even though you could get an Apple TV for roughly the same price (< $150), but the Apple TV would provide more functionality (e.g., the Apple TV could be used as an impromptu projector through AirPlay).

They chose the wrong platform for the app. They should have developed it for the Apple TV.

View on HN

I agree that they chose the wrong platfrom. They couldn't port it to to Apple TV because there Apple dropped WebKit from tvOS.

So they not only chose the wrong platform but also the wrong programming environment for that product. I didn't even suspect that the panic board was iOS based, that sounds so obviously the wrong choice I can't even image how they originally came up with that choice.

Of course, if the board would have worked as OSX application (in fullscreen mode or also as webserver serving the board as HTML), you would still need a pricey piece of Apple hardware to run it.

Relying on Apple hardware for a product will likely fuck you over sooner or later but I can see that as a company that only does Apple targeted products, they were either too myopic to chose something else or (IMO more likely) they didn't have the resources or skills to do it otherwise.

> Relying on Apple hardware for a product will likely fuck you over sooner or later

The company I work for feels exactly the opposite, we develop a SAAS POS solution that only runs on iPad. It's a lot easier, because we have a consistent environment, everyone runs almost the same hardware, and the same OS version, unlike Android, where everyone runs different versions of android and different hardware.

Relying on Apple may fuck us over in the future, but Android would be fucking us from the start.

> Relying on Apple may fuck us over in the future, but Android would be fucking us from the start.

Sometimes having it tough from the start is good, especially if it forces you to build something more flexible. Not so good if you go on a crusade to fix every edge case specifically.

I'm speaking generally and definitely not "defending" Android here, as the platform does need too much edge-case-fixing which is usually overwhelming for small shops.

> the platform does need too much edge-case-fixing which is usually overwhelming for small shops

Do you mean that by simply choosing Android as a platform, you're automatically incurring a ton of technical debt?

It depends. If you want to support a lot of devices / screens / versions / defaults / settings / mods / roms / whatever else I forgot, then, yes.

You can always target a sane subset, which makes the number of edge-cases manageable for a smaller team.

I had a WebView that I used to display PDFs in my application then I realized some versions of the internal browser didn't support opening PDFs. For those devices, I tried to create an intent (Was it called that? It has been so long), only to learn that many didn't come with a PDF viewer at all. So I created a service to render PDFs to images server side. A bug in the browser messed up the layout (pages with both orientations existed in documents and even a humble table layout couldn't make them display reliably across the devices). I started loading the images and displaying them in a native view. Then I had memory problems in some devices. Then I started lazy-loading each page. That seemed to work but users from smaller screens complained about double-tap-hold-zoom thing. And so on...

Thanks for the detailed answer. Went through a similar thing myself with a "hybrid" app. Nightmare.

I agree that in cases where a specific hardware is necessary and you don't want to bundle the hardware with your software, the iPad is not a bad choice.

There might be some annoyances when Apple drops older pieces of hardware that would still be able to run your software but you can't offer it anymore as the minimum iOS target has been raised.

In the case of that Panic status board which is apparently not much more than a webview and having that tied to a particular piece of hardware is really unfortunate.

Specifying Raspberry Pi 3 with Raspbian shouldn't be so difficult, and those things are much cheaper to deploy than an iPad.

100% agree with you. I helped develop an app that's like a POS system for a security-conscious community. The preference was to use android because of the low acquisition cost... but that was thrown out almost immediately because of the hoops necessary to meet the various security requirements.

With iOS/iPad, the team had a working MVP type product done in a few days (most of the heavy lifting was already done in a backend available via API). The MDM solution provided an on-demand VPN capability which took a lot of network activity out of the critical path. All infrastructure build cost very little and took about 2 weeks. We literally made a decision to go on the 1st of the month, and had it in front of the key business people on the 12th of the month.

Even if Apple fucked us, it's fine -- Android would have fucked us 3 times already.

Well, the company is an iOS app company. Therefore there was only one possible choice for them, even if it was the wrong one.

They are not. They are mostly an iOS and OSX company. So even within their own niche, there would have been options.

"Only one possible choice" is a golden hammer fallacy. I'd say "false dichotomy", but that one goes for two options with no middle ground.

Also known as X-only programmers.

How do I create some code to show stuff on a big TV? Well, I know X, so, X it is. How do I create code to run in a supercomputer | satellite | desktop | telephone | web server? Well, I know X, so...

Should have developed it to run on a $10 Chinese HDMI Android dongle and sold it as a plug-and-play "dashboard in a box" for $300 a pop.

Nothing stopping you doing that.

Someone got in before me: https://news.ycombinator.com/item?id=13061517

Agree with the sentiment, very easy to 'armchair quarterback' something like this.

The market's definitely there. I used to work at a place that did that.

http://xibo.org.uk/ was another player in the field, open source.

They should've sold HDMI dongles (think Chromecast or Roku), with the app baked in, for ~$100. Its easy to monday morning quarterback though; This idea could've failed as well.

Basically a Raspberry Pi zero ?

Basically, but turnkey. Just like I'd pay twice as much for a Chromecast before I'd ever consider spending a moment of time on a Raspberry Pi.

So a Raspberry Pi in a case with a pre-inserted sdcard running the app? :)

Yes. For $500 (not $100).

make it a pretty case, and be sure to include a charger.

I currently do that for in-store displays. Its easy to setup because you can do a nice GUI with a powerful enough board and habe access through SSH if required. I sell it to small businesses as a turn key solution (just add a tv) for less than four hundred dollars. Most have enjoyed good success with it because it allows automatic upsells. Ive yet to use one as a status board but I might give it a try.

There's definitely the market for it, it was part of a job I had in a previous life. (Almost) every company has an IT department and they and their managers like to see cool status displays. It's a pretty easy sell.

Ive thought about it but it requires a certain level of technical capabilities on the businesse's side. Truth is that most businesses run on shitty old windows machines that dont get updated. Integrating with those systems requires building an infrastructure for them and then selling at a low price because they dont see the value in IT. That's why I sell it as a self contained marketing/sales tool.

That's pretty cool. Do you have a website? I have questions, and you probably have answers. (Like, how do IT-averse businesses manage the text/graphics/etc? ... and so on)

I dont market it online (yet) since it is an upsell to digital marketing I do. You can email me with questions. I'll do my best to answer. Also on Twitter or snapchat. :)

check my profile

I tried to do this with the Chromecast - it isn't powerful enough and has a memory leak causing a crash after around a day.

Yup, for how great the Chromecast could be, it's extremely unreliable. Mine crashes all the time, which makes it about as useful as a brick for my use-case.

> They chose the wrong platform for the app. They should have developed it for the Apple TV.

They developed and released it years before the Apple TV even had 3rd party apps...

https://panic.com/blog/the-future-of-status-board/#comment-6... is why it wasn't ported to Apple TV.

Apple TV doesn't support WebKit, which I bet is pretty important in Status Board.

It could be ported if the potential revenue was high enough, even if it meant rewriting the functionality that used WebKit to use something else. Instead, I think it was more likely the state of the App Stores themselves. The tvOS App Store market is even worse off than the macOS one, and I doubt they would have recovered even a small percentage of the cost of development had they chosen to pursue it.

For those saying they choose the wrong platform, beware of several facts:

1. They released the iOS version in April 2013, long before the Apple TV was open to apps.

2. As mentioned by other's, Panic built the iOS version using web views that are not available on Apple TV.

3. Status Board originated in 2010 as a web app that targeted a Samsung display with embedded Windows XP on which they loaded Google Chrome.

I would not be surprised that Panic is moving their internal Status Board tool back an modernized version of what they used in 2010. If Panic felt there was money in it, they could certainly port Status Board to other platforms.

Links about 2010 version:

https://news.ycombinator.com/item?id=1177227

https://panic.com/blog/the-panic-status-board/

That part seems to be describing what some companies actually did, rather than describing the requirements. If they say companies would buy a $3,000 display, I imagine that's based on some of their customers saying they bought a $3,000 display for the app.

why not a Raspberry Pi?

Reply on news.ycombinator.com