ubuntu-phone team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Voß wrote on 12/03/14 10:21:
> 
> On Tue, Mar 11, 2014 at 10:05 AM, Matthew Paul Thomas
> 
> ...
>> 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 did not say that at all, and I disagree with it too. How could we
possibly have a "design for returning to phone calls before it's
fixed" if the design was postponed until after it's fixed? :-)

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

The designers working on phone calls have been designing the
presentation of background calls as a specific task independent of any
other apps.

When other background apps gain the ability to continue listening, by
whatever method, that will need a design too. Hence this thread.

My point is simply that it would be better for those two designs to be
one and the same.

- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMgRwoACgkQ6PUxNfU6ecrIhgCgmceH5OGHW51Dp/ya7ksLIcQd
kG0AnidfcePpYmIOBxbI/W9vx1rhYEdb
=pQz9
-----END PGP SIGNATURE-----