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

Tue Feb 19 15:18:33 UTC 2013

It sounds like you and Seamus have started the right discussions, so I
will just add a couple of points related to the HIG.

As you work through the interface, please feel free to ask questions or
suggest improvements to the HIG. The existing doc came out with the
first generation of Commotion, and the project has evolved quite a bit
since then. We have always seen it as a living document, so if something
seems confusing or forced, please bring it to the dev list.

We expect to find idiomatic differences as we add new platforms,
applications, and use cases. Our goal is not really to create identical
implementations, but to provide the tools to build a recognizable
Commotion widget that also works within the widget's native framework.

For instance, if the pin-style icons are too big or the borders are too
heavy for your application (as is often the case in mobile apps with
small screens), you can scale them or suggest alternatives. We just ask
that you bring it to the list so we can update the HIG as needed.

You can see some of this evolution in the new OpenWRT theme:
https://code.commotionwireless.net/attachments/download/240/screenshot24.png

https://code.commotionwireless.net/attachments/download/241/screenshot25.png

https://code.commotionwireless.net/attachments/download/242/screenshot26.png

https://code.commotionwireless.net/attachments/download/243/screenshot27.png

-andrew

On 02/19/2013 08:50 AM, Seamus Tuohy wrote:
> 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
> 
> _______________________________________________ Commotion-dev mailing
> list Commotion-dev at lists.chambana.net 
> https://lists.chambana.net/mailman/listinfo/commotion-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130219/1bb42b3a/attachment.sig>