Open Stack

On Wed, Nov 20, 2013 at 9:09 AM, Thierry Carrez <thierry at openstack.org>wrote:

> Hi everyone,
>
> How should we proceed to make sure UX (user experience) is properly
> taken into account into OpenStack development ? Historically it was hard
> for UX sessions (especially the ones that affect multiple projects, like
> CLI / API experience) to get session time at our design summits. This
> visibility issue prompted the recent request by UX-minded folks to make
> UX an official OpenStack program.
>
> However, as was apparent in the Technical Committee meeting discussion
> about it yesterday, most of us are not convinced that establishing and
> blessing a separate team is the most efficient way to give UX the
> attention it deserves. Ideally, UX-minded folks would get active
> *within* existing project teams rather than form some sort of
> counter-power as a separate team. In the same way we want scalability
> and security mindset to be present in every project, we want UX to be
> present in every project. It's more of an advocacy group than a
> "program" imho.
>
>
I'm not sure "most of us" is accurate. Mostly you and Robert Collins were
unconvinced. Here's my take.

It's nigh-impossible with the UX resources there now (four core) for them
to attend all the project meetings with an eye to UX. Docs are in a similar
situation. We also want docs to be present in every project. Docs as a
program makes sense, and to me, UX as a program makes sense as well. The UX
program can then prioritize what to focus on with the resources they have.

However, as pointed out in the meeting, the UX resources now are mostly
focused on Horizon. It'd be nice to have a group aiming to take the big
picture of the entire OpenStack experience. Maybe this group is the one,
maybe they're not. The big picture would be:
Dashboard experience
CLI experience
logging consistency
troubleshooting consistency
consistency across APIs like pagination behavior

Just like QA ends up focusing on tempest, UX might end up focusing on
Dashboard, CLI and API experience. That'd be fine with me and would give
measurable trackable points.

What's more interesting is how does the user committee fit into this?
There's an interesting discussion already about how to get user concerns
worked on by developers, is it actually through product managers? What
would an Experience program look like if it were about productization?


> So my recommendation would be to encourage UX folks to get involved
> within projects and during project-specific weekly meetings to
> efficiently drive better UX there, as a direct project contributor. If
> all the UX-minded folks need a forum to coordinate, I think [UX] ML
> threads and, maybe, a UX weekly meeting would be an interesting first step.
>
>
I think a weekly UX meeting and a mailing list (which is probably already
their Google Plus group) would be a good way to gather more people as
contributors. Then we get an idea of what contributions look like.

To summarize my take -- UX is a lot like docs in that it's tough to get
devs to care, and also the work should be done with an eye towards the big
picture and with resources from member companies.

Anne


> There would still be an issue with UX session space at the Design
> Summit... but that's a well known issue that affects more than just UX:
> the way our design summits were historically organized (around programs
> only) made it difficult to discuss cross-project and cross-program
> issues. To address that, the plan is to carve cross-project space into
> the next design summit, even if that means a little less topical
> sessions for everyone else.
>
> Thoughts ?
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Anne Gentle
annegentle at justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131120/f0ec5b5c/attachment.html>