[Commotion-dev] OSX "Meshbook" app: UX, Tech, and Status

Tue Feb 19 13:50:42 UTC 2013

Hey Brad,

On 02/19/13 03:02, Bradley Greenwood wrote:
> Hi all,
>
> Things are moving along.  I'd like to give project status and possibly ask for
> some feedback / guidance / direction on the UI/UX front (being the ui/ux lover
> that I am).
>
> UI/UX
> I've read through the "Human Interface Guidelines" docs on the Commotion website
> and i'd like to tailor the user experience as closely as I can to:
>
> https://commotionwireless.net/docs/hig/key-processes
> Mobile and desktop are (obviously) much different experiences in this realm so
> its taken me a while to wrap my head around the best course of action on this
> project.   Heres the breakdown of my current user experience (see attached
> screenshot):
>
> 1) User opens app and is displayed a menu(let) with tabbed window.
> 2) A list of available adhoc networks is displayed that a user may connect to.
> (Its my understanding there is no way to tell from a network scan that olsrd is
> running on a remote adhoc).

Josh, can you shoot out a brief overview of what you will gather from 
the current scan function, and possibly an idea of what you see from 
scanning plug-ins in the future?

> 3) The user may choose to connect to an existing adhoc: in this case, the
> network connection is made and the bundled olsrd binary is started.
> 4) The user may also choose to start his/her own mesh network (adhoc): in this
> case, the user has the ability to connect through a given/managed profile or
> he/she can create a new connection "on the fly" (by adding settings). *note:
> this can be seen in screenshot.
>
> Side note: I was able to find a slew of vector images I modified and reused for
> the app.  The pin-style icons I believe you used in the android app so I tried
> to stick with the same idea/flow (just placeholders for now).
>
> Now, please clarify for me (and kindly forgive my ignorance, i'm new)… Its my
> understanding that a profile is for creating a new mesh (adhoc) network that
> people can associate to. I'm also under the assumption that the only way for a
> person to connect to an adhoc network is for me to scan for a list of available
> (open) IBSS networks. Are the profiles used for both creating and joining a mesh
> network? Are there cases where an adhoc network wouldnt be detected on a scan
> (no olsrd)?

In-house we have been thinking of profiles as sets of settings for 
various use-cases. This way a setting file might be a backhaul node, a 
gateway, an application server, a tor-gateway, etc. In this way if a 
user has the correct settings for another network, or scans and gets 
enough information, they can use a profile to connect to a network as a 
specific type of node. I am more than willing to go into much more depth 
if you desire. There are use cases where a user is setting up the node 
outside of range of a network and, as such, won't see a network. 
Otherwise a scan should detect all ad-hoc networks. (I am not 100% on 
this with the current version of the daemon, so Josh correct me if I am 
wrong)

>
> If it fits within this scope, i'd like to make the process (experience) of
> connecting to an adhoc->mesh a little more intuitive by using connection
> "walk-thru" screens for the user. More along the lines of:
> https://commotionwireless.net/docs/hig/key-processes
>
>
> Please tell me if this would be beneficial (or if that is even in scope).  IMO,
> the user needs a helpful way/guide of knowing what to do on program launch
> (connecting to an available adhoc network, knowing what to do when he/she is
> connected to the mesh, what to do after that, etc)… just thinking through this.
> It appears that you've nailed this nicely for mobile but I didn't see any
> commotion HI guidelines for desktop.

Funny you mention this... We are in the first round of testing on the 
"Commotion Quick Start" for the OpenWRT instance. You can find an 
overview here - > 
https://code.commotionwireless.net/projects/commotion/wiki/QuickStart . 
This has been my rabbit hole for a little over a month, and our field 
team is working on creating the best pathing for new users who want to 
set up a network right now. I will make sure that I put up the notes 
from our sessions so you can see them. Also, shoot me an e-mail and we 
can set up a skype call to go over what we have, give a demo, and can 
get your ideas and what you have done so far. (I know, I know, never go 
off list. I will summarize our conversation and put it on the list after 
the fact.)

> TECH
> As for the tech side of things, here's the rundown on how i've implemented.  For
> the Cocoa geeks that are reading, as you know, there are some big differences in
> osx versions between 10.5 and 10.8, especially for the apis we're needing to
> use.  I chose apis (non-private) that we'll be able to refactor if/when we need
> to support 10.5 or 10.8.  I focused primarily on 10.6+10.7 compatibility.
>
> On application launch, I immediately fire a notification to a sharedInstance
> (singleton) that does 3 primary things: a) gets a pid, kills a pid (as root),
> and executes command line with args (as root). I kill off any processes named
> olsrd and execute the bundled olsrd binary.  I originally had tried sending the
> kill signal to olsrd but found that it wouldn't always terminate.  kill -9 seems
> to be the only reliable way to terminate the process but am afraid this might
> lead to a zombie open port?  I'm also passing the interface en1 as a param to
> olsrd -- should this be user configurable?
>
> Also to note, I start olsrd BEFORE connecting adhoc.  I do this because olsrd
> has some startup overhead in terms of time it takes to load it's json plugin.
> Why does that matter?  Because we're executing olsrd as a shell script, there
> are no callbacks and I cannot inform my data sync poller to begin fetching json
> from localhost:9090 until olsrd has begun running.  We must wait for olsrd to
> fully load so we're able to begin polling.  Why are we using a shell script?  In
> order to run as root, we're severely limited as to how we can auth on
> 10.4-10.8.  The 3 options are a) sign our app and use SMJobBless() if >= 10.6,
> b) use applescript (deprecated methods that partially work) or c) use
> AuthorizationExecuteWithPrivileges (now deprecated but fully usable).  I chose
> the lesser of the 3 evils and went with "AuthorizationExecuteWithPrivileges" .
> As of 10.7,  unfortunately, the "right" (and really only) way to auth as root is
> to sign the app and use SMJobBless() or equivalent.  We'll need to figure
> something out if wanting to support 10.8.
>
> Once olsrd is humming, we're able to fire-up our "MeshDataSync" delegate.  We
> use this for polling localhost:9090 using NSTask, NSTimer, NSURLConnection, and
> operation queues.  This allows us to queue up requests on a different thread
> (run loop) so we don't block the main thread (8 second intervals).  Yes, we're
> using multi-threading for this but I may rethink it at a later time.
>
> Next, we use a great lib (CoreWLAN) for network connection and management.  This
> allows us to display and manage WiFi/IBSS data from our interface.  If we want
> to support versions earlier than 10.6, the best way would be to use Apple's
> 80211b.h (private apis).  They aren't very well documented, but in my opinion,
> better than using shell scripts.
>
> -----
>
> These are the big moving parts.  Everything else is around UI, such as the
> profile manager, mesh status display, help, and log.  And like I said above, in
> order for the app to be intuitive, IMO there must be a way to walk/guide the
> user through a connection flow.  Please let me know your thoughts on this.
>
> If any of this seems unreasonable, feel free to yell at me.
>
> Cheers,
> Brad
>
> Bradley Greenwood | bradley at scal.io <mailto:bradley at scal.io> | Scal.io
>
Thanks so much for your work so far.

s2e
>
>
>
>
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev