[Sugar-devel] [DESIGN] Reflect internet connectivity in the 'Network' frame icon

[Anish Mangal]

[cc += peace-corps at sl-devel]

I think everyone agrees that 'more (than current)' information can be
conveyed to the user which might actually be of use...

Everyone has raised very valid points... Lets aim to address the
simple issues first, try them out in different (network setup)
environments incrementally and keep (please) this thread alive...

* * * * * * * * * *

Here's my take...

>  "The Sugar UI should make network health discoverable."

>>> Good point in general. To what is trying to get solved, I'd word it as
>>> "Sugar UI should make network _affordances_ discoverable".

Yes! What are the use cases for such information? Michael suggested a
number of mechanisms which can be reliably used to determine 'levels
of network connectivity'

>In particular:
> a) are we trying to expose affordances that are useful when the network is
>    working perfectly or are we more interested in making discoverable those
>    affordances that will be useful when things are broken?

Actually, both.

> In particular, is this the core issue?

No. The core issue is determining the ways that information can or
should be used. That will determine what we implement both at the
backend and UI wise before jumping into finer details.

> b) are we more interested in making indicators (whose status is automatically
>    updated) or in sensors that can be activated to learn about the world?

My intention was to have automatically updating indicators. Are there
good use cases for implementing the feature as a 'sensor'?

> Anish started a thread with a [DESIGN] tag. I took that to mean, in part, that
> he wanted feedback about the interplay of his idea with the Sugar HIG and the
> broader intended Sugar UX and I tried to recast the discussion in those terms.

+1, Exactly

* * * * * * * * * *

== Miachel's proposed implementation ==

For the sake of concreteness, here are some examples of how these
considerations might affect Anish's general idea:

 1) Let's make an autonomous binary internet indicator to be displayed on
 the frame and in the network-view.     The sensor driving the
indicator will periodically make HTTP HEAD requests at
 a deployment-configured rate against a URL chosen uniformly at random from a
 deployment-configured list.
   The indicator will be "happy" when the most recent request succeeded with
 status code 200 and will be "sad" otherwise.

 2) Let's make a three-state autonomous indicator to be displayed on the frame
 and in the network view.

 The sensor driving the indicator will periodically run a complete network
 diagnostic procedure which, at a minimum, checks that we:
     1) have a network interface,
   2) that is up,
   3) with an IP address,     4) that the interface IP is pingable
   5) with default route configured
   6) that the default route is pingable
   7) with a nameserver entry in resolv.conf
   8) that is pingable
   9) that successfully resolves a list of test addresses
   10) such that the resolved IPs are pingable
   11) such that there are HTTP servers running on port 80 on the IPs returned
       from a configured subset of the resolved names that that return status
       code 200 for HTTP 1.0 HEAD requests for url "/"....

 The indicator will be "happy" if all tests past in the most recent test run.

 The indicator will be "sad" if any "hard" tests failed.

 The indicator will be "worried" if all hard tests passed but some soft tests
 failed.

 If the indicator is "sad" or "worried", then hovering or clicking on the
 indicator will display a modal dialog or palette listing all tests, showing
 their pass/fail status, and showing folded blocks of logs for all tests.
 Thoughts?

Michael

[1]: As background, I'm going to assume that an "affordance" is "a quality of
    an object, or an environment, that allows an individual to perform an
    action" (http://en.wikipedia.org/wiki/Affordance). Please correct me if
    you prefer a different definition.

[2]: For example, are all these opportunities included?

      * "to join a shared activity"
      * "to send an object to a friend"
      * "to store or to load a backup" and
      * "to browse the web"
         How about these?
           * "to join #sugar-devel"
      * "to host a web page"
      * "to copy an activity from a friend's journal"
         Or these?
           * "to ping a default route?"
      * "to resolve names to IP addresses?"
      * "to send IP packets to and to receive packets from public IPs?"
      * "to communicate without interference from middlepeople?"

* * * * * * * * * *

I don't have much idea as to what should be the finer details of a
'network indicator' so I won't argue here. We could code something
pretty quickly that implements all or a part of the above.

>>> We can get a rough initial version with a ping to 'schoolserver', and
>>> a ping to a configurable internet host.

* * * * * * * * * *

>> Couldn't we use the presence service (or its equivalent)? I've always
>> wanted to see a schoolserver icon in the mesh view... from which the
>> user could (re-)register, initiate a backup/restore, open a browser on
>> the schoolserver homepage, etc.

Hmm, I don't know how well this fits into the 'network connectivity'
frame indicator. Maybe if we have access to an XS, we can display that
as a palette option.

* * * * * * * * * *

> More than enough <meta> for me this week -- I won't post on this
> thread anymore. Apologies to Anish and to the whole list for soaking
> up everyone's time.

No apologies needed :-) . We are all very passionate about sugar and
not posting will ultimately hurt our eventual users... Kids!

* * * * * * * * * *

Since this discussion has many different areas (Usage goals, Backend
implementation, UI implementation) should we move this to a wiki page?
This way, anyone replying to a specific point won't have to waste time
filtering the points relative to them.

* * * * * * * * * *

I've tried to summarize and address every concern raised in the thread
so far. Apologies if I missed any.

Cheers,
Anish