Panic Status Board is being discontinued
panic.com
panic.com
I do this irrational stuff all the time. $15 for a wedge of cheese I haven't tried before - yap totally fine. A $2.59 app - hmm, yeah, not sure, think about for 5 minutes, read reviews, seems expensive, what if I don't like it, pass...
I know it is ridiculous and I see me doing it, but it still happens.
I have paid significantly more than $3 for something that turned out to be garbage (side note: Humble Bundle team, you gave charity a bad name). Haven't encountered anything similar while buying cheese.
That gives me an idea for a startup.
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.
make it a pretty case, and be sure to include a charger.
check my profile
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.
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.
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.
Do you mean that by simply choosing Android as a platform, you're automatically incurring a ton of technical debt?
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...
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.
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.
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...
Agree with the sentiment, very easy to 'armchair quarterback' something like this.
http://xibo.org.uk/ was another player in the field, open source.
They developed and released it years before the Apple TV even had 3rd party apps...
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:
To a lot of people, paying for software is still a pretty weird concept, and evaluating the "worth" of software is quite hard when there is so much free software around.
It's really interesting/sad to read their second reason for shutting down:
> pro users are more likely to want a larger number of integrations with new services and data sources, something that’s hard to provide with limited revenue, which left the app “close but not quite” for many users
Because this is exactly what Zapier, the company I co-founded a year later, provides for free to other companies/products. Integrate once with us and automatically get integrations with hundreds of other apps (750+ and growing).
I love and use several Panic products (Transmit, Prompt, Firewatch) and hope this end-of-life enables them to spend more time on new ideas.
The concept sounded really cool, but then when it came down to actually using in production I had a hard time arguing with myself: "Eh, why not spend a night or two just building out this integration ourselves the exact way we want instead of wasting that much money on something that doesn't even completely fit the bill."
The subscription SaaS cost quickly supersedes the developer cost in a matter of a few months, although I suppose it could have some niche uses with a proof of concept/MVP.
The majority of Zapier users are not engineers. They can't make that trade-off decision. Their trade-off is instead "should I use Zapier or just not do X at all?"
I'd guess many of Panic board's users chose the latter (not do X at all) given they cited lack of integrations as one reason for shutting down.
Not a complaint about Zapier, mind, just that "you can code" isn't a great argument on this point.
That is emphatically not my experience. Developers consistently underestimate how expensive they are and how long things take to do.
Even if you ignore the up-front development cost, I probably spend more than 15 minutes a month on maintaining any integrations I write. That time alone more than covers Zapier's cost ($20/m to start).
[0] https://github.com/Shopify/dashing/wiki/Additional-Widgets
So I don't think it would fit in the use cases from other people in this thread.
While not actively maintained by Shopify anymore it's working really well, has easy setup and allows you to get up and running quickly.
The grid system and basic widgets provide a good and clean starting point, although you probably want to invest some time to make it visually coherent if you're using a large amount of third-party plugins.
Our team is using it for polled data that is updated once an hour up to every minute and it's working great for us.
That's one of the reasons I updated Godot [0] (similar to Ruby's Riemann), a NodeJS stream processor, and re-ported Riemann's dash [1] to match.
You can send any event into the stream processor including any metadata, and receive it into any of the dash widgets, such as Title, List, Grid, Knob, Timeseries, and many more. I use it to monitor anything from active container instances to queue stats to CPU wait times.
It's really similar to Dashing, in fact I ported the Knob directly from Dashing, but it's much much easier to add a data source.
As a bonus any event can trigger a Slack, email, SMS, or webhook.
If you have any trouble getting running just open an issue, the docs still have a few holes.
Our nightly test server generates a lot of performance metrics which are stored in an excel file. We upload the excel to OneDrive and Power BI periodically refreshes a report dashboard which we display on a large screen within a browser.
The designer (Power BI Desktop) is really nice. The data aggregation and shaping is powerful. The only drawback we experienced is that the provided visualizations [2] are sometimes a bit limited, there are custom ones [3] with varying quality though.
You need Power BI Pro for this auto-sync scenario, but we got such a license for free through our msdn account.
[1]: https://powerbi.microsoft.com/en-us/
[2]: https://powerbi.microsoft.com/en-us/documentation/powerbi-se...
(Disclaimer: I'm the developer, happy to answer questions.)
I'm going to check it out when I get some free cycles, maybe over Christmas.
Plenty of commits in 2016 ... seems to be actively maintained: https://bitbucket.org/atlassian/atlasboard/commits/all
Simple Grids to powerful visualizations. Connects with all standard SQL databases
It is a platform for analyzing primarily business data, but it still may be of a lot of value for current statusboard customers.
Disclaimer: I am one of the founders.
Not sure what you mean by separate Apple ID?
EDIT: clarity.
With separate Apple ID I mean that you will have to register a new Apple ID for the iPad you will be hiding behind a TV screen. Somebody will need to manage that, and you have to worry about somebody stealing the iPad and spending thousands on smurf berries.
Now you need a hardware support division, you need to buy, configure, and ship hardware, handle returns, etc. and hardware is low margin compared to software so there's little real profit to be made.
When you sell turn-key integrated products like that, you tend to sell the integrated hardware at a much higher margin than if you were just selling the hardware itself, because you don't break out individual component prices.
The monthly fees could also fund development of more 3rd party integrations.
If all the digital artists in the world buy Photoshop, in order for Adobe to justify continued support, they have to add marketable features. There's not nearly as much of an incentive to support software. It all goes into features.
I found others to look so boring and didn't have time to spend styling it and making new widgets.
Oh, to head off one question at the pass: it’s not feasible for us to open source Status Board. It contains code and frameworks shared among our apps that we’re not quite ready to commit to the public domain. Sorry.
There's not a lot of overlap right now between "pro" and "Apple, Inc." Right now I'd reckon Apple sees the puck heading for the laziest leisure class the world has ever known.