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

Tue Feb 19 08:02:43 UTC 2013

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).
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)?

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.

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 | Scal.io

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130219/ee8bc026/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meshbook-image.png
Type: image/png
Size: 176596 bytes
Desc: not available
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130219/ee8bc026/attachment-0001.png>