ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Tue, Mar 11, 2014 at 10:05 AM, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thomas Voß wrote on 10/03/14 12:36:
>>
>> On Mon, Mar 10, 2014 at 1:13 PM, Matthew Paul Thomas
>>
>> ...
>>> That would result in you getting cut off a Skype call, for
>>> example, when the person you're talking to gets you to check your
>>> calendar. Or a recording app failing whenever you read the script
>>> or the music that you're trying to record. Assuming that gets
>>> fixed eventually, users would experience less churn if there was
>>> a single design for returning to phone calls before it's fixed,
>>> and returning to other recording apps after it's fixed.
>>
>> I disagree here. We have spent a significant amount of time on our
>> lifecycle story and on establishing, implementing and supporting a
>> strict lifecycle policy on the phone. With that, I'm surprised by
>> such a statement. I would have expected that our designs by now are
>> aligned with such a fundamental platform decision.
>
> Sorry, I'm not sure which part you disagree with.
>

I disagree with the part where we postpone creation of designs for
handling background access to system services/device features and
block on the lifecycle policy implementation. I think we all agree
that a user should be presented with a visual cue no matter if an app
or a system-level component accesses certain features of the device or
the system. With that, I don't get your point about minimizing churn
for the user.

> Is it correct that if recording/listening apps can't run in the
> background, then you would get cut off a Skype call, Google Hangout,
> Yahoo Messenger call, WhatsApp Voip call, or any WebRTC call when you
> switched to a different app?
>

They can't run in the background, correct. We haven't provided a
service, yet, for them to hand over a call (consciously skipping
details here) and keep it alive while they are backgrounded.

> Do you agree that Ubuntu Touch should be a platform on which ISVs like
> those can make apps as useful as their apps on other platforms?
>

Sure, but I think protecting users from malicious apps  (in terms of
wasting battery life or violating a user's private) is at least as
important and surely a delicate balance to strike.

> If so, do you agree that the current lifecycle model would need to be
> only a first iteration, rather than a permanent restriction? Or is
> there some other way around the problem?
>

The current lifecycle policy we choose for the phone (please note:
desktop and tablet will see modified versions of this strict policy)
is strict, yes. I disagree with this being only the first iteration.
instead, we will provide well-defined paths by means of system- and
session-level services to escape the lifecycle trap.

> Perhaps your only disagreement is with the principle of designing in a
> forward-compatible way? That could be bad if we misled people into
> thinking a feature is there when it isn't yet. But in this case all
> we're talking about is *not* assuming that the built-in calls app is
> the only one that will ever listen in the background. Making the
> listening indication app-agnostic, so that other apps can use it later.
>

I fail to understand your argument about designing in a
forward-compatible way. To me, your original comment reads as: Let's
wait with design until the lifecycle policy is less strict. If you are
instead saying that we should not make assumptions about which
component is accessing a system or device feature, I'm in violent
agreement with you.

Thomas

>> At any rate: No matter if an application or a (trusted) helper is
>> accessing system services, I would think that we should put
>> designs that visually surface any sort of background operation to
>> users.
>
> Agreed. Users should never need to know what a "trusted helper" is;
> they should see the name of the app that is doing the recording/listening.
>
> - --
> mpt
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlMe0d8ACgkQ6PUxNfU6ecrUUACgsjYzA3TZ7gLCE0WXCjANAUbr
> zVUAoMJLvbrxEJeQ2yNZBYEyhgq/kSMt
> =xEZ+
> -----END PGP SIGNATURE-----