[openstack-dev] How to best make User Experience a priority in every project

Rochelle.Grober Rochelle.Grober at huawei.com
Thu Nov 21 23:24:07 UTC 2013


I think Jesse illustrates *why* we need a program for UX.  SW Developers don't think the same way as UX developers.  UX is working on stuff most of us have never considered across all sorts of project lines.  A warm, understanding home to brainstorm issues before returning to the project trenches is vital for a healthy team.

Beyond that, consider the UX developer.  If you were s/he, would rather work on a project that recognizes the value of UX and puts it on par with the rest of the developers, or a project that says "you can get together and bond, but you need to focus/be on one of our existing projects".  It makes recruiting UX team members much more difficult.

Consider some common behaviors that "engineering services" have seen time and again in the SW industry:  When layoffs happen, Tech Pubs, QA and UX (often along with project managers, and Build/Release) are shed because "the developers can build/test/write docs/design UI along with their dev job".  And yet Jesse has just pointedly demonstrated that UX goes far beyond UI, which is how most of the world views his profession.

+1 Jesse.  UX is important.  Consider how much harder his job would be if no one noticed this needed to be done until a release or two down the line. Or two separate projects each wanted Jesse to adopt *their* formats for APIs -- who would end up adjudicating if there were no UX program?  TC? At least with a program, UX needs to play nice with all the projects.  TC is more likely to dictate if it gets to that point.

Sorry to be so long winded and adamant, but I really think that the role of good UX is sorely undervalued because it is seldom applied to the tools developers use to develop.  If the only computer you've ever used is a PC, it's hard to understand the benefits of Linux or a Mac.

--Rocky

-----Original Message-----
From: Jesse Noller [mailto:jesse.noller at RACKSPACE.COM] 
Sent: Thursday, November 21, 2013 10:00 AM
To: <openstack at nemebean.com>; OpenStack Development Mailing List (not for usage questions)
Cc: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] How to best make User Experience a priority in every project



> On Nov 21, 2013, at 10:43 AM, "Ben Nemec" <openstack at nemebean.com> wrote:
> 
>> On 2013-11-21 10:20, Jesse Noller wrote:
>>> On 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.
>>> 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.
>>> 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 ?
>> Hello again everyone - let me turn this around a little bit, I'm
>> working on proposing something based on the Oslo work and
>> openstack-client, and overall looking at the *Developer Experience*
>> focused around application developers and end-users more so than the
>> individual UX issues (configuration, UI, IxD, etc).
>> I've spoken to Everett and others about discussions had at the summit
>> around ideas like developer.openstack.org - and I think the idea is a
>> good start towards improving the lives of downstream application
>> developers. However, one of the problems (as I and others see it) is
>> that there's a series of disconnects between the needs of the
>> individual projects to have a command line client for administrative /
>> basic usage and the needs of application developers and end-users (not
>> Openstack admins, just end users).
>> What I'd like to propose is a team that's not focused on the
>> overarching UX (from horizon to **) but rather a team / group focused
>> on some key areas:
>> 1: Creating an *application developer* focused SDK for openstack services
>> 2: Unifying the back-end code and common tools for the command line
>> clients into 1
>> 3: Providing extension points for downstream vendors to add custom
>> extensions as needed
>> 4: Based on 1; make deriving project-specific CLIs a matter of
>> importing/subclassing and extending
>> This is a bit of a hybrid between what the awesome openstackclient
>> team has done to make a unified CLI, but takes a step back to focus on
>> a unified back end with clean APIs that can not only power CLIs, but
>> also act as an SDK. This would allow many vendors (Rackspace, for
>> example) to willingly drop their SDKs and leverage this unified back
>> end.
>> In my "perfect world" you'd be able to, as an application developer
>> targeting Openstack providers, do something close to (code sketch):
>> from openstack.api.auth import AuthClass
>> from openstack.api.nova import NovaClient
>> from openstack.api.nova import NovaAdmin
>> auth = AuthClass(...)
>> nova = NovaClient(auth)
>> nova.server.create(... block=True)
>> nova_admin = NovaAdmin(auth)
>> nova_admin.delete_flavor(...)
>> Downstream vendors could further extend each of these and either
>> create very thin shims or meta packages that add provider specific
>> services, e.g:
>> from openstack.vendor.rackspace.api.auth AuthClass
>> ...
>> The end goals being:
>> 1: provide a common rest client back end for all the things
>> 2: Collapse all common functions (such as error retries) into a common lib
>> 3: DO NOT DICTATE a concurrency system: no eventlet, no greenlet. Just
>> Python; allow application developers to use what they need to.
>> 4: Provide a cliff based extension system for vendors
>> 5: Document everything.
>> 6: Python 3 & 2 compatible code base
>> As I said earlier; this would build on work already in flight within
>> openstack, and additionally within vendors such as rackspace to
>> contribute to this effort directly and reduce the proliferation of
>> SDKs/clis/etc. Existing SDKs could be end-of-lifed. The team working
>> on this would be comprised of people focused on working across the
>> openstack projects not just as dictators of supreme design, but
>> actually implementing a consistent backend with resulting front-end.
>> Individual project teams would also be involved and consulted - they
>> would have to be as it would be a group effort.
>> jesse
> 
> I believe this has been at least started in Oslo: https://github.com/openstack/oslo-incubator/tree/master/openstack/common/apiclient
> 
> I don't know how well that fits with what you're planning, but it's something to look at.
> 
> -Ben
> 

Yup! Already been talking to people involved. All of this would build from existing work/teams and efforts


> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list