If the Winged Monkey mobile app is a native application, why wouldn't you just use the server push notification mechanisms that Google[1] and Apple[2] provide?
1 - http://developer.android.com/google/gcm/index.html 2 - https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW9 -steve On Jan 31, 2013, at 3:09 PM, Jeremy Perry <[email protected]> wrote: > This is really cool Angus. From the beginning we have known that mobile and > alerts is naturally important to WM -- It's suggested in the original > wireframes. The interface we've been building has been designed with mobile > in mind - though we had not considered the connection issue you point out. > Anyhow, Jarda has some awesome wires to share soon that show how a responsive > front end will give us an optimized experience mobile phones, at least while > on the same network. > > Personally I love the idea you propose and the idea creating a native app > obviously is really interesting to me from a design perspective. I don't > think it eliminates the need for a mobile-ready web UI, and fortunately, it > won't be a huge leap to make what we have now responsive. > > What about using SMS? I have no idea what this entails server side, but it > would be a natural way to get alerts, or for example, to text STOP to your > application. Good ol' email works too. I actually think email would be useful > in other situations, like after your app is up, you get an email confirming > it is running and with connection and login details, etc. You might also want > a reminder email if your app has been running for a month with no activity. > > That all said, I think the ability to receive alerts over any internet > connection is more important than being able to poll for status or perform > operations. Of course, I want both! > > Jeremy > > > On Jan 31, 2013, at 2:23 PM, Angus Thomas <[email protected]> wrote: > >> This is a problem which I've been thinking about in the context of Winged >> Monkey, but it is more generally applicable. >> >> We want Winged Monkey to be available on people’s phones, tablets etc so >> that they can see the state of running instances, receive notifications >> whenever there’s an outage etc.. >> >> So long as the users are standing fairly near the server which is running >> Winged Monkey, and can get wifi connectivity to the same network that the >> server is on, then it’s all relatively simple. >> >> However, as soon as users step outside the building, it all gets a bit more >> complex. In order for the users’ phone to be able to connect over the >> internet to the Winged Monkey server, then either the phone is going to need >> to have a VPN connection, which is a significant overhead, or the Winged >> Monkey server instance is going to have to be directly accessible over the >> internet. A lot of the organisations which are potential users of Winged >> Monkey wouldn’t be prepared to do that. >> >> >> We could use a social network as a messaging conduit between the Winged >> Monkey server and a client application on users’ phones. >> >> >> For the rest of this mail, I’ll expand in this in the context of Twitter. I >> don’t *think* this use would be a violation the Twitter’s terms of service. >> ( https://twitter.com/tos ). There are several public social networks which >> could serve the purpose... >> >> So, here’s how this could work: >> >> * The Winged Monkey server would register a Twitter account, with protected >> tweets. >> >> * A user would install and run the Winged Monkey phone app. The first run >> would also create a protected Twitter account, and when the user >> authenticates, the two Twitter accounts start following each other. >> >> * Thereafter Winged Monkey and the phone app use tweets to communicate over >> the internet, sending instructions, status updates etc. as strings up up to >> 140 characters. So long as both the server and the client app poll >> frequently for new tweets, the responsiveness should be acceptable to users. >> >> >> Some of the benefits are: >> >> * The communications are authenticated, with access permission which can be >> very quickly revoked by unfollowing an account which is no longer supported. >> >> * The communications are also (moderately) secure, in the sense that tweets >> from and between protected accounts aren’t generally readable. >> >> * The timelines of the accounts constitute an audit history of events etc.. >> It would be trivial to scrape that audit history from Twitter if required. >> >> * The principle benefit, though, is that the requirement for the Winged >> Monkey server to be directly accessible over the internet is removed. So >> long as the Winged Monkey server can make a client connection to >> Twitter.com, stuff just works. >> >> >> I’m not pretending that this is a flawless proposition, but I think there’s >> enough of an idea here to want feedback. I’d love to hear a better way to >> solve the problem. >> >> >> >> Angus >
