[IAEP] [DESIGN] Re: [Sugar-devel] Sugar Design Meeting/Reunión 21 September at 11 PM UTC IRC Sugar Meeting [DESIGN]

[James Cameron]

On Thu, Sep 21, 2017 at 09:20:27AM -0500, Laura Vargas wrote:
> Good day James,
> 
> Thank you for the feedback and the instructions.
>
> 2017-09-19 21:04 GMT-05:00 James Cameron <[1]quozl at laptop.org>:
> 
>     For the proposed agenda [1];
> 
>     a.  Upgrading Sugar UI; could you please be more specific about what
>     you want the design team to do?  This will encourage participation,
>     although it looks like one of the design team may be challenged by the
>     date you have chosen.
> 
> Sugar Labs community has made several efforts to keep Sugar
> development packages up to date. Unfortunately (for users) the
> design of the user interface (UI) and the care for the user
> experience (UX) has not been significantly improved over the
> years. For 5 years, the Sugar design team has been dormant.
> 
> This is the trend I plan to reverse.

You are using dormancy as a justification for action; yet the reason
for dormancy is ignored; you are putting the cart before the horse.

Design team is dormant because there were no new design issues.

> Sugar Labs needs an active Design Team taking care of Sugar UI and
> UX ( affective aspects of usage).

Of the needs that Sugar Labs has, the need for an active design team
is much lower than other needs.  Sugar Labs needs input from Sugar
users.  Without input, a lone design team will flail around making
wild guesses and bad decisions, and won't have consensus with
development team, and so nothing will happen except talk and noise.

You probably have input from Sugar users that you are not revealing,
as do I, as we are both contractors making money from Sugar, and it is
in our interests to protect our customers from exposure here in this
hostile environment.  One of my customers watches Sugar Labs mailing
lists and said of last week that it was "sad to see so much friction."
I've other customers who watch but don't speak.

For community health of Sugar Labs, it would be better to have direct
input from Sugar users, and have that input drive design and
development.  This has been tried with Sugar Network, ASLOv2 reviews,
and with the Social Help discourse instance.  Sugar Network uses an
old version of Sugar, and is full of spam.  ASLOv2 is dead.  Social
Help is rarely used.

There's also GitHub issues, and trac.  But now that these environments
are even more hostile, the input will dry up like a wet season stream.

> My proposal is to reactivate the Sugar Design Team and lead it to an
> upgraded Sugar User Interface and Sugar User Experience.
> 
> Our main focus needs to be maximizing Sugar and Sugar Web usability
> (understanding usability as the degree to which Sugar can be used to
> achieve quantified objectives with effectiveness, efficiency, and
> satisfaction in a quantified context of use).

I don't fully understand what you mean.  By Sugar Web do you mean the
API for Sugar Web Activities, Sugarizer, or Sugar Network?

How do you propose to quantify usability?  Which standard to use?
Most of the standards are for adult usability, and Sugar target users
are not adult.  Is there a qualified pedagogy team member?

Qualifications are very helpful in selling the idea to customers.

> Today's meeting will be a first exploration of who is interested in
> this matter and how we can all work together.
> 
> I'll try to call for a weekly Sugar Team design meeting.
> 
>     b.  Elimination of gender selection [2]; remove this agenda item, as
>     it is not a design issue.  There is already reasonable consensus that
>     this should be eliminated and left as a GSetting for any deployment
>     that needs the feature, so could you please make a pull request for
>     code review?  I never did like it myself, but Gonzalo and Walter had a
>     customer require it.  That customer no longer uses Sugar.
> 
> Where the Sugar User Experience starts is totally part of the Sugar User
> Experience design.
> 
> Design is not just about eliminating here and there,  we need to rethink the
> whole experience from start to end so that children really benefit from the
> Sugar and/or Sugar Web experience.

Thanks for the comment, but it was not really necessary.

> That said for this case, I plan to follow your procedure
> instructions.

Good, thanks.  When will the pull request arrive in GitHub?

>     c.  Modify main icons; remove this agenda item, as it is not a design
>     issue.  As a patch already exists, please port it to master branch,
>     prepare it as a pull request for review and merging.  Being able to
>     change icon shape as well as colour would be a great improvement.
> 
> How the Sugar UI looks like is also part of the Sugar Experience
> design.

No, not when the subject is user-directed modification of icons.  For
example, the user can change background now, and how the UI looks is
very different to design intent of Sugar Labs.  With customisation
available, Sugar Labs can only set initial impression.

Please confirm you are testing the latest versions of Sugar, either
0.110 or 0.111?  If you are not testing and understanding the latest
version, then you can't really speak about how to change it.  I'm
aware that Sugar Network is locked to an old version of Sugar which
may not have the change background feature.

> I'll keep this one also in the agenda just because we need to be
> open to other proposals for the "by default" main icon (s) and/or
> the logic to define the initial icon and define curse of action and
> responsible parties to make the calls.

No, that's not what a design team does.  You're confusing design team
with development team.  Don't do that.

You should just get the patch ported and merged.

>     Please also add a [DESIGN] tag to the subject, which is part of our
>     mailing list policy for sugar-devel@ [3].  By omitting the tag, some
>     design team members may have missed your meeting announcement, and
>     this would be unfair to them.
> 
>     Thanks.
> 
> I did.
> 
> Again, thanks for your feedback.
>  
> 
-- 
James Cameron
http://quozl.netrek.org/