[Tails-ux] Bits from FOSDEM

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: tails-ux
CC: anonym
New-Topics: [Tails-ux] University design / HCI students [was: Bits from FOSDEM]
Subject: [Tails-ux] Bits from FOSDEM
Hi,

I've spent the biggest part of yesterday in the design room at FOSDEM,
because I wanted to feel like I was on holiday; a good way to do that
was to go hear about stuff that gets me excited these days, rather
than about more nerdy topics that I find slightly more boring every
day. Still, I figured I should share with you folks some of what
I heard there, so now that I'm back from holiday I could write
a report :)

I'm Cc'ing anonym and segfault, who are two developers (on top of Alan
and I, who read this list anyway) who are likely to interact with this
list in the future.

I suggest that follow-ups are split into sub-threads, each with an
adjusted Subject field, so that we don't attempt to have 12 intermixed
discussions in the same thread :)


Design process do's and don'ts
==============================

* Make it clear, early in the process, how (and when) the final
decision will be made. If consensus-based decision making is used,
clarify who's responsible for facilitating the discussion.
If someone is responsible to make the call, state who they are.

 * Make it clear what the timeline is, in particular wrt.:
    - the feedback the designer is waiting for;
    - the decision making process.


* Make it clear what's the expected lifetime of the solution being
designed, and what the constraints about further iterations are.

E.g. if it's OK to do something relatively quickly, and iterate
later, say it: this can avoid endless discussions aiming at the
getting the Perfect Design™, in situations when basically any rough
draft proposed by a skilled designer would be much better than the
current state of things, and can easily be improved on later, e.g.
based on actual data once users are exposed to the first iteration.

OTOH, if for whatever reason it'll be hard to change the design or
its implementation later, put it clearly: this information can
greatly affect the design process.


Help we could get
=================

I think it's useful to have more options, on top of the kind of help
we can currently get from UX / design people. Do we have a place to
compile such contact information? Here are two ways we could get help:


University design / HCI students
--------------------------------

<bernard@???> is setting up a program that puts in touch FOSS
project with people learning design and HCI at some university.

The basic setup is an evaluation of the usability of the current state
of things. We would have to suggest specific areas that we think are
worth evaluating, then we would attend (possibly remotely) sessions
about the findings. I think this could be good for some features that
we have *already* developed and would like to evaluate, e.g. when we
have built them without much input from skilled UX people; it of
course depends on the developers being ready to take the outcome of
this evaluation into account.

This being said, nowadays we try to integrate UX right from the
beginning when we change, or add to, Tails. So I've asked Bernard if
it was an option to collaborate more thoroughly, e.g. when designing
a new thing (several iterations of usability evaluation, from paper
prototypes to the working implementation) or improving an existing one
(evaluation of the initial status, of prototypes of the next one,
etc.). He told me there's some flexibility and this should be doable;
he seemed enthusiastic about me proposing this option.

Open Source Design: jobs
------------------------

(http://opensourcedesign.net/jobs/, I think)

The Open Source Design collective has a web tool where projects can
submit "jobs", i.e. design tasks they need to be done. One can specify
whether the job will be paid or not. And then, designers looking for
a FOSS project to help can pick a task and get in touch with
the project.

(If I got it right, that's how the Tor project found the person who
created their Style Guide last year; I got the contact of the person
who did the Style Guide by the way, and will meet him next month.
Let me know if there's anything I should discuss face-to-face
with him.)

I would like us to try this out, e.g. to get a logo for Tails Server,
so we get a feeling of how it works, and whether it's a good tool
for us. segfault, what do you think?


Improvement ideas
=================

* I hear that it would not hurt to add a *screenshot* to our home
page on the web.

* Rename the "Easy" property on tickets to "Starter". This would
avoid having to explain all the time that these tickets are not
necessarily easy, of for less skilled people: they're simply good
ways to start getting involved in Tails.

* Ensure we have "Starter" tickets for "User interface design"
on Redmine.

I won't track these myself. If you want to take responsibility for one
of these discussions and/or the corresponding changes, please do :)


Miscellaneous resources
=======================

* opensourcedesign.net has a page that lists useful *tools*
* tool for prototyping: the UX box .io

I'll add those to contribute/how/user_interface#resources once I go
online and find the exact URLs. IIRC sajolida did some research about
prototyping tools in the past, but I can't find the results right now;
I'm happy to add them to our doc as well if someone knows where I can
find them.


That's all for today.

Take care,
cheers,
--
intrigeri