The future of Power Management - together with Activities

[Dario Freddi]

2011/10/2 Michael Pyne <mpyne at kde.org>:
> On Sunday, October 02, 2011 19:52:09 Dario Freddi wrote:
>> On Sunday 02 October 2011 19:35:15 Michael Pyne wrote:
>> > And even assuming the user knows how to do this, if they want to change
>> > power  management options we are saying that they need to duplicate an
>> > existing activity, change the power management options in that new one,
>> > and switch to that new activity to do the same thing they were doing
>> > before. The only one doing something different now is the *computer*. This
>> > is my point about orthogonality.
>>
>> But again, it does not make sense. You are failing to provide a valid use
>> case for these situations, expect "the user might want to do that".
>
> I worry about that mentality. Not so much the idea that features shouldn't be
> added without use cases in mind, but the idea that features inadvertently
> present should be removed without "valid use cases". So many software
> applications find use beyond what their developers initially had intended or
> even understood was possible. I don't understand why this should be
> concerning.

Although I generally agree with this mindset, I urge you to notice we
are in a very special case here. We are not talking about a cool
feature in an application, but instead about an important part of the
system the user should not even have to configure - tomorrow I´ll post
the first version of the activity-based UI I am thinking of and my
masterplan will be even more clear. So I think we should focus on
covering the most widely used use cases, or better: only the ones
which technically make sense, as it´s very likely a different use case
could be a consequence of a misunderstanding or a misuse of the
features additionally provided - as this thread shows, this is clearly
the issue with profiles.

>
>> But
>> even leaving that aside, I might say: what's the difference between
>> creating a new activity and configure it and creating a new profile and
>> configure it, if that's the sole purpose of the change?
>
> I'll admit that I've misunderstood much of your proposal, over at least the
> first day this thread was going on. If I'm understanding correctly now, then:
>
> * The ability to change the currently-loaded profile will go away. The
> currently-loaded profile will instead be based on the combination of <current
> Activity> and <condition of battery/AC>.
>
> * It will instead be possible to inhibit all power management functions (e.g.
> for presentation mode).
>
> * It will always be possible to change the screen brightness (most important
> parameter for power savings).
>
> * And, it will be possible at any time to edit the power management settings
> for the current <Activity/power condition>. (This, btw, is the only thing I
> found unclear).

Yes, that´s a very good summary.

>
> If this is true then there is not a large concern, the user is still more or
> less easily able to do what he/she was able to do before (independent of "use
> case analysis"...) and in fact has an easier task if they use Activities.

Exactly.

>
> So to answer your question, I couldn't care less about how easy it is to
> create profiles. I've never created profiles, I've always just changed
> whatever setting was wrong at the time or used one of the default profiles
> that was "close enough". But the fact that you asked the question shows that
> we were not communicating effectively, because you thought I cared at all
> about that, and I thought you seriously intended to prevent changing the
> profile *settings* without going through a new Activity first.

It might as well be that I have been not clear enough in explaining my
proposal, and if so, I apologize for that and for what came out of it.
But back to the point, YES, you got it! The point is exactly that the
average user does not care about profiles at all, and he probably does
not even know how to/he can change them. Again, when I´ll show you my
ideas things will be even clearer in this regard.

>
> Please let me know where I'm wrong on that. And please keep in mind that I
> have been, as far as I know, polite and at least putting in a good-faith
> effort to fully understand the proposal and its impact, and it would be nice
> to have that assumption borne in mind in replies to myself. :)

I know, and I am sorry I had to come to a point where I needed to be
harsh. You also have to keep in mind I am one of the few guys who does
the dirty job, and I mostly get flames more than anything. Usually,
the gratification for a developer is having users saying ¨thanks, your
app rocks¨: my gratification is usually getting no feedback at all
because things work as they should. In addition, I get flamed
everytime I propose a change, because people refuse to accept there
might be better ways of working, and when it´s implemented and
working, I get no ¨sorry,in the end you were right¨ or a ¨thanks¨, or
anything similar for the very rule I stated above.

I wish more people kept that in mind, and understand why I can be more
sensible about some behaviors and ways of facing informal discussion
on technical topics than many others. As I said in a previous mail, I
have to deal with such crap all the time from random users, and I
don´t want this to happen when I talk to fellow developers as well. So
I am sorry and I deeply apologize if I can get easily angry when
discussions start going down these kind of slopes, but at least try
and show some understanding from the other side as well.

>
> Regards,
>  - Michael Pyne