[cc += peace-corps@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel