On 01/31/2013 09:09 PM, Jeremy Perry 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.
This sounds awesome. I can envision many mobile applications that
consume various services offered by Aeolus. Having something like
"mobile-converge-ui" would be really fantastic (proving we choose to go
down the html5, css3, js route, which I would recommend).
I wonder how much work converting our current converge-ui to target
mobile devices would be.
Regards
Martyn
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
