[Sugar-devel] #2141 UNSP: Memory and CPU status indicator for the frame.

[Tomeu Vizoso]

On Sun, Aug 29, 2010 at 02:57, Sugar Labs Bugs
<bugtracker-noreply at sugarlabs.org> wrote:
> #2141: Memory and CPU status indicator for the frame.
> ------------------------------------------+---------------------------------
>    Reporter:  m_anish                    |          Owner:  tomeu
>        Type:  enhancement                |         Status:  new
>    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by Release Team
>   Component:  sugar                      |        Version:  Unspecified
>    Severity:  Unspecified                |       Keywords:  r! dextrose
> Distribution:  Unspecified                |   Status_field:  Unconfirmed
> ------------------------------------------+---------------------------------
>
> Comment(by bernie):
>
>  Replying to [comment:13 tomeu]:
>  > I personally don't care much about it, but I think deployers and QA
>  people should be quite concerned about the costs of users being able to
>  change the UX significantly and easily. May be better to discuss it now
>  and figure out some rules about when to use GConf keys than later having
>  to roll back changes that may have proven popular in the field but too
>  expensive to support.
>
>  I agree with your argument, but consider that:
>
>  1) we claim that users can freely modify even the code. If they currently
>  can't, it's mostly because our UX is incomplete.
>
>  2) when given the opportunity, many children are switching to GNOME also
>  because of its UI customization options, such as setting a background
>  picture or choosing a screensaver. As useless as these things may seem,
>  humans of all ages seem to like them, including hackers. (my desktop
>  background is all black, I would refuse to use a computer which comes with
>  a blue sky over a green grass theme ;-).

Well, I was talking about support costs and I don't think nobody is
going to claim to support systems that have been modified past some
point.

But as I'm not a deployer, with regard to on-the-field- support costs,
I'm ok with keep adding gconf keys for UI features until actual
deployers start shouting Stop!.

Though, there are other ways in which optional features' cost need to
be taken into account, such as QA, documentation and ongoing
development. These guys have explained it very well, one from the
platform POV and the other from the UX POV:

http://benjamin.smedbergs.us/blog/2005-07-29/the-testing-matrix/

http://www106.pair.com/rhp/free-software-ui.html

To be clear, I'm not against optional features, it's just that I
believe that at some point it may seem like making something optional
is a good way to avoid a difficult decision but we may be
understimating its cost.

I would also like to suggest looking at the possibility of having
extensions out-of-tree, they have a different set of trade offs and
balance the burden differently on the different agents.

Regards,

Tomeu