Re: [openstack-dev] How to best make User Experience a priority in every project
On Wed, Dec 11, 2013 at 4:25 PM, Stefano Maffulli stef...@openstack.orgwrote: On 12/06/2013 02:19 AM, Jaromir Coufal wrote: We are growing. At the moment we are 4 core members and others are coming in. But honestly, contributors are not coming to specific projects - they go to reach UX community in a sense - OK this is awesome effort, how can I help? What can I work on? It seems to me that from the comments in the thread, we may have these fresh energies directed at reviewing code from the UX perspective. Do you think that code reviews across all projects are something in scope for the UX team? If so, how do you think we can make it easier for the UX team to discover reviews that may require comments? Unfortunately, that's probably most patches. However, I imagine most commits with DocImpact also have very obvious UX impact - so I'd start by directing attention to those patches before they merge. /stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
On 12/06/2013 02:19 AM, Jaromir Coufal wrote: We are growing. At the moment we are 4 core members and others are coming in. But honestly, contributors are not coming to specific projects - they go to reach UX community in a sense - OK this is awesome effort, how can I help? What can I work on? It seems to me that from the comments in the thread, we may have these fresh energies directed at reviewing code from the UX perspective. Do you think that code reviews across all projects are something in scope for the UX team? If so, how do you think we can make it easier for the UX team to discover reviews that may require comments? /stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
I love the idea of treating usability as a first-class citizen; to do that, we definitely need a core set of people who are passionate about the topic in order to keep it alive in the OpenStack gestalt. Contributors tend to prioritize work on new, concrete features over “non-functional” requirements that are perceived as tedious and/or abstract. Common (conscious and unconcious) rationalizations include: * I don’t have time * It’s too hard * I don’t know how Over time, I think we as OpenStack should strive toward a rough consensus on basic UX tenets, similar to what we have wrt architecture (i.e., Basic Design Tenetshttps://wiki.openstack.org/wiki/BasicDesignTenets). PTLs should champion these tenets within their respective teams, mentoring individual members on the why and how, and be willing to occasionally postpone sexy new features, in order to free the requisite bandwidth for making OpenStack more pleasant to use. IMO, our initiatives around security, usability, documentation, testing etc. will only succeed inasmuch as we make them a part of our culture and identity. @kgriffs ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
Hi OpenStackers, I am replying to this thread with a smaller delay. I was keeping very close attention to it but I wanted to let the discussion flow without me interfering, so I see the community opinion on the UX effort. First of all, thanks Thierry to starting this thread and the whole discussion. I believe it was/is very valuable. From the discussion I see some hesitations of approving UX as independent program and lot of (strong) opinions that this is important to happen. I appreciate both because from concerns we can learn and from the positive feedback we get a lot of support and also a lot of suggestions where we can continue helping. (BTW: Huge thanks for this, all the listed areas are very important and I am happy that I could have added some new items to the list of future spots where we can help.) As for me, I am (of course) on the side which fights for UX to be an individual program from various reasons. I share the same opinion that we (UX) shouldn't be completely separated team which is 'dictating'. Our purpose is to be strongly integrated with other projects. But on the same time be cross-project wise and one leg out. We should organize and prioritize our efforts as well as very tightly communicate with related project team members (coordinate on planning features, assigning priorities, etc). And that's what we are doing. We started with UIs which is the most obvious output. We have have limited resources, but getting more contributors on board, getting more people interested, we can spread to other areas which were mentioned here. We are growing. At the moment we are 4 core members and others are coming in. But honestly, contributors are not coming to specific projects - they go to reach UX community in a sense - OK this is awesome effort, how can I help? What can I work on? And it is more and more companies investing in the UX resources. Because it is important. We are in the time when not just functionality matters for project to become successful. And showing publicly that OpenStack cares about UX will make our message stronger - we are not delivering just features, we care and invest in usability as well. Contributors who might get interested in UX can be largely from other OpenStack projects, but on the other hand they might be completely outside the project experts. Experts in cloud-solutions, they can have huge amount of feedback from OpenStack users, they can be experts in testing... usability in general. This group of people is not interested in particular project, but in global effort of moving OpenStack closer to users. If we don't have special program about this - whom are they going to reach? Where can they start? How can they be recognized? Their input is as valuable as input from all other contributors. Just a bit different. I don't agree much with the argument that everybody should keep UX in mind and care about it. Well to be more accurate, I agree with it, but this is very ideal case which is very very hard to achieve. We can't say - OK folks, from now on everybody will care about UX. What should they care about specifically? This is area where engineers are not specialized. It takes a lot of time for everybody to do their own search for resources and figuring out how somebody else does that, how it should work for user, etc. And instead of focusing on the architecture or implementation part, people will have to invest big amount of time to research other sources. Yes, it is part of responsibility, but... If there is anybody else helping with this effort, focusing cross-project, thinking user way and proposing solutions it's so big help and support of others work. Of course we can do UIs, APIs, CLIs without specialized group of people, but each engineer thinks a bit differently, each can have different perception of what is valuable for user and the lack of unification will raise. And that's actually what is happening. At the moment we are not the biggest group of people, so I understand the concerns. Anyway, getting the blessing for UX is not a question of us continuing in the effort, but supporting us and spreading out the message - that we as OpenStack care. I am not trying to convince anybody here, I accept the decision 'no' (at least for this moment). I just feel that it was not consensus that most of people thinks that this is nonsense. I don't see any strong reasons why not. In time, I believe more people will see how important it is and hopefully OpenStack will recognize UX efforts officially. Anyway... I want to encourage anybody interested in the UX (any area) - reach us and help us to make OpenStack more usable. Everybody's hand is welcome. Thanks all for contributing to this thread and expressing your opinions. I really appreciate that. -- Jarda --- Jaromir Coufal (jcoufal) --- OpenStack User Experience --- IRC: #openstack-ux (at FreeNode) --- Forum:
Re: [openstack-dev] How to best make User Experience a priority in every project
Hi I've just recently started wetting my feet in openstack, so my opinion is mostly external, and maybe naive, but I think that everybody should think about UX is not in opposition with having a team that focuses on it, just like it's nice to have people who focus on security, although obviously everybody should focus about it, and same goes for performances, for documentation, for community, or for any aspect of the project, if there are improvements to be done, it's always effective to have a focused effort. UX is a broad topic, and of course people will focus on different parts of it anyway (subjects from logging, to web UI, to cli, to config files, etc have been talked about in the discussion), but thinking about it as a whole, as a concept, is important for the project to go forward. Of course a bug can (and will) ruin the user experience, no matter how much effort went into making a nice UI, but UX is not just a matter of being bug-free, so helping people design a global UX so openstack doesn't feel like a dozen of loosely-related projects packaged together, should be an important target, imho, and it's not something easy for people working in each project to think about, because there is a lot happening in all of them, and the project is kind of big. Cheers On Fri, Dec 06, 2013 at 11:19:57AM +0100, Jaromir Coufal wrote: Hi OpenStackers, I am replying to this thread with a smaller delay. I was keeping very close attention to it but I wanted to let the discussion flow without me interfering, so I see the community opinion on the UX effort. First of all, thanks Thierry to starting this thread and the whole discussion. I believe it was/is very valuable. From the discussion I see some hesitations of approving UX as independent program and lot of (strong) opinions that this is important to happen. I appreciate both because from concerns we can learn and from the positive feedback we get a lot of support and also a lot of suggestions where we can continue helping. (BTW: Huge thanks for this, all the listed areas are very important and I am happy that I could have added some new items to the list of future spots where we can help.) As for me, I am (of course) on the side which fights for UX to be an individual program from various reasons. I share the same opinion that we (UX) shouldn't be completely separated team which is 'dictating'. Our purpose is to be strongly integrated with other projects. But on the same time be cross-project wise and one leg out. We should organize and prioritize our efforts as well as very tightly communicate with related project team members (coordinate on planning features, assigning priorities, etc). And that's what we are doing. We started with UIs which is the most obvious output. We have have limited resources, but getting more contributors on board, getting more people interested, we can spread to other areas which were mentioned here. We are growing. At the moment we are 4 core members and others are coming in. But honestly, contributors are not coming to specific projects - they go to reach UX community in a sense - OK this is awesome effort, how can I help? What can I work on? And it is more and more companies investing in the UX resources. Because it is important. We are in the time when not just functionality matters for project to become successful. And showing publicly that OpenStack cares about UX will make our message stronger - we are not delivering just features, we care and invest in usability as well. Contributors who might get interested in UX can be largely from other OpenStack projects, but on the other hand they might be completely outside the project experts. Experts in cloud-solutions, they can have huge amount of feedback from OpenStack users, they can be experts in testing... usability in general. This group of people is not interested in particular project, but in global effort of moving OpenStack closer to users. If we don't have special program about this - whom are they going to reach? Where can they start? How can they be recognized? Their input is as valuable as input from all other contributors. Just a bit different. I don't agree much with the argument that everybody should keep UX in mind and care about it. Well to be more accurate, I agree with it, but this is very ideal case which is very very hard to achieve. We can't say - OK folks, from now on everybody will care about UX. What should they care about specifically? This is area where engineers are not specialized. It takes a lot of time for everybody to do their own search for resources and figuring out how somebody else does that, how it should work for user, etc. And instead of focusing on the architecture or implementation part, people will have to invest big amount of time to research other sources. Yes, it is part of responsibility, but... If there is anybody else helping with this effort,
Re: [openstack-dev] How to best make User Experience a priority in every project
Jaromir Coufal wrote: [...] I am not trying to convince anybody here, I accept the decision 'no' (at least for this moment). I just feel that it was not consensus that most of people thinks that this is nonsense. I don't see any strong reasons why not. In time, I believe more people will see how important it is and hopefully OpenStack will recognize UX efforts officially. [...] It's certainly not consensus, and I don't think anybody said this was nonsense. It's just a delicate balance, and trying to find the most sustainable and efficient way to bring UX concerns within projects. Like I said, the last thing we want is a fight between UX folks on one side asking for stuff to get done and on the other side nobody in projects actually caring about getting it done. That said, I think you made great arguments for keeping a leg out and organize in a cross-project way. After all we have other projects (like QA) which do that very successfully, so I'm definitely willing to consider UX as a separate program. My main concern would be that the UX team is relatively new (the launchpad tracker for example was created on Oct 20) and that we haven't seen you around enough to see how you would interact with projects and get your priorities across. There is no weekly UX team meetings listed on https://wiki.openstack.org/wiki/Meetings, either. Programs are about blessing existing teams and efforts (which already obtain results), *not* to bootstrap new ones. We look into the team's work and results and decide those are essential to the production of OpenStack. So my advice to you would be to organize yourselves as a team, engage with projects, deliver clear results, communicate around those... and then apply again to be a Program if you think that's still relevant. Does that make sense ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
On Fri, Dec 6, 2013 at 8:12 AM, Thierry Carrez thie...@openstack.orgwrote: Jaromir Coufal wrote: [...] I am not trying to convince anybody here, I accept the decision 'no' (at least for this moment). I just feel that it was not consensus that most of people thinks that this is nonsense. I don't see any strong reasons why not. In time, I believe more people will see how important it is and hopefully OpenStack will recognize UX efforts officially. [...] It's certainly not consensus, and I don't think anybody said this was nonsense. It's just a delicate balance, and trying to find the most sustainable and efficient way to bring UX concerns within projects. Like I said, the last thing we want is a fight between UX folks on one side asking for stuff to get done and on the other side nobody in projects actually caring about getting it done. That said, I think you made great arguments for keeping a leg out and organize in a cross-project way. After all we have other projects (like QA) which do that very successfully, so I'm definitely willing to consider UX as a separate program. My main concern would be that the UX team is relatively new (the launchpad tracker for example was created on Oct 20) and that we haven't seen you around enough to see how you would interact with projects and get your priorities across. There is no weekly UX team meetings listed on https://wiki.openstack.org/wiki/Meetings, either. Programs are about blessing existing teams and efforts (which already obtain results), *not* to bootstrap new ones. We look into the team's work and results and decide those are essential to the production of OpenStack. So my advice to you would be to organize yourselves as a team, engage with projects, deliver clear results, communicate around those... and then apply again to be a Program if you think that's still relevant. I too would really like you all to organize as a team very similar to how the Security team organizes itself - very much like what you are doing now. It's interesting, the Security team ended up with a book sprint that produced a book deliverable that is a very valuable piece of documentation, and that wasn't a goal going in. So I think that the more you look for opportunities for UX across projects the more deliverables you could find that we haven't identified yet. So I really want to encourage you to keep looking for those areas where we have need for good experiences. Thanks, Anne Does that make sense ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Anne Gentle annegen...@justwriteclick.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
On 2013/06/12 15:16, Anne Gentle wrote: On Fri, Dec 6, 2013 at 8:12 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Jaromir Coufal wrote: [...] I am not trying to convince anybody here, I accept the decision 'no' (at least for this moment). I just feel that it was not consensus that most of people thinks that this is nonsense. I don't see any strong reasons why not. In time, I believe more people will see how important it is and hopefully OpenStack will recognize UX efforts officially. [...] It's certainly not consensus, and I don't think anybody said this was nonsense. It's just a delicate balance, and trying to find the most sustainable and efficient way to bring UX concerns within projects. Like I said, the last thing we want is a fight between UX folks on one side asking for stuff to get done and on the other side nobody in projects actually caring about getting it done. That said, I think you made great arguments for keeping a leg out and organize in a cross-project way. After all we have other projects (like QA) which do that very successfully, so I'm definitely willing to consider UX as a separate program. My main concern would be that the UX team is relatively new (the launchpad tracker for example was created on Oct 20) and that we haven't seen you around enough to see how you would interact with projects and get your priorities across. There is no weekly UX team meetings listed on https://wiki.openstack.org/wiki/Meetings, either. Programs are about blessing existing teams and efforts (which already obtain results), *not* to bootstrap new ones. We look into the team's work and results and decide those are essential to the production of OpenStack. So my advice to you would be to organize yourselves as a team, engage with projects, deliver clear results, communicate around those... and then apply again to be a Program if you think that's still relevant. Sure Thierry, it all makes sense and I understand that. I am very happy to continue in our efforts and that's actually what I wanted to express that we might ask later. Only thing what I want to make sure though is that we have enough space at design summits, but I will revive this topic closer to the summit itself. I too would really like you all to organize as a team very similar to how the Security team organizes itself - very much like what you are doing now. It's interesting, the Security team ended up with a book sprint that produced a book deliverable that is a very valuable piece of documentation, and that wasn't a goal going in. So I think that the more you look for opportunities for UX across projects the more deliverables you could find that we haven't identified yet. So I really want to encourage you to keep looking for those areas where we have need for good experiences. Thanks, Anne Thanks Anne, what the security team ended up is all awesome. I am eager to find out all the areas where we can help and jump in - hopefully we will get enough resources in time to cover more and more issues. Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
On Wed, 2013-11-20 at 11:06 -0600, Dean Troyer wrote: On Wed, Nov 20, 2013 at 9:09 AM, Thierry Carrez thie...@openstack.orgwrote: 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. Having been working on a cross-project project for a while now I can confirm that there is a startling lack of coordination between projects on the same/similar tasks. Oslo was a HUGE step toward reducing that and providing a good reference for code and libraries. There is nothing today for the intangible parts that are both user and developer facing such as common message (log) formats, common terms (tenant vs project) and so on. I think the model of the OSSG is a good one. After reading the log of yesterday's meeting I think I would have thrown in that the need from my perspective is for a coordination role as much as anything. The deliverables in the UX Program proposal seem a bit fuzzy to me as far as what might go into the repo. If it is interface specs, those should be in either the project code repos docs/ tree or in the docs project directly. Same for a Human Interface Guide (HIG) that both Horizon and OSC have (well, I did steal a lot of OSC's guide from Horizon's). One straightforward example I could imagine from a UX Program is a REST API design guide which captures the current common patterns between our current APIs and points the way for common patterns new APIs should aim to adopt. Same for our CLIs. Or you could imagine a set of terminology/concept definitions - project vs tenant anyone? :) But, I think the basic point is that a group with common interests should work on producing some concrete deliverables before being asked to be recognized as an official program. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
On Nov 21, 2013, at 10:20 AM, Jesse Noller wrote: 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. Blueprint started by Tom Fifield and assigned to me. https://blueprints.launchpad.net/openstack-manuals/+spec/developer-openstack-org Everett ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
On 20/11/13 09:37 -0600, Dolph Mathews wrote: On Wed, Nov 20, 2013 at 9:09 AM, Thierry Carrez thie...@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. ++ UX is an issue at nearly every layer. OpenStack has a huge variety of interfaces, all of which deserve consistent, top tier UX attention and community-wide HIG's-- CLIs, client libraries / language bindings, HTTP APIs, web UIs, messaging and even pluggable driver interfaces. Each type of interface generally caters to a different audience, each with slightly different expectations. As already mentioned in other emails on this thread, I think it'd be valuable to have a member of each project to coordinate with the UX team. I think this is something we all want to have in the projects we're working on and also something that every core member should be keeping in their minds when reviewing patches. I like the idea of having a security akin team for UX. We could also tag bugs - this came up in the last TC meeting - when we think they need the UX team intervention. Also, as part of the review process, when the patch affects the UX, reviewers could add one of the UX core members to the review and request their feedback. The above should guarantees the cross-project UX enforcement to some extent. From my point of view, UX is not just something we need to have experts on but something we all need to care about. Having a UX team will definitely help with this matter. 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. I'd be happy to contribute a design session to focus on improving UX across the community, and I would certainly attend! We also discussed about having a cross-project session at the summit. I think this is becoming more and more important. Cheers, FF -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
On 2013-11-21 10:20, Jesse Noller wrote: On Nov 20, 2013, at 9:09 AM, Thierry Carrez thie...@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
Re: [openstack-dev] How to best make User Experience a priority in every project
On Nov 20, 2013, at 9:09 AM, Thierry Carrez thie...@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
Re: [openstack-dev] How to best make User Experience a priority in every project
On Nov 21, 2013, at 10:43 AM, Ben Nemec openst...@nemebean.com wrote: On 2013-11-21 10:20, Jesse Noller wrote: On Nov 20, 2013, at 9:09 AM, Thierry Carrez thie...@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
Re: [openstack-dev] How to best make User Experience a priority in every project
On Wed, Nov 20, 2013 at 9:09 AM, Thierry Carrez thie...@openstack.orgwrote: 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. ++ UX is an issue at nearly every layer. OpenStack has a huge variety of interfaces, all of which deserve consistent, top tier UX attention and community-wide HIG's-- CLIs, client libraries / language bindings, HTTP APIs, web UIs, messaging and even pluggable driver interfaces. Each type of interface generally caters to a different audience, each with slightly different expectations. 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. I'd be happy to contribute a design session to focus on improving UX across the community, and I would certainly attend! Thoughts ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
On Wed, Nov 20, 2013 at 9:09 AM, Thierry Carrez thie...@openstack.orgwrote: 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Anne Gentle annegen...@justwriteclick.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
On Wed, Nov 20, 2013 at 10:37 AM, Dolph Mathews dolph.math...@gmail.comwrote: On Wed, Nov 20, 2013 at 9:09 AM, Thierry Carrez thie...@openstack.orgwrote: 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. ++ UX is an issue at nearly every layer. OpenStack has a huge variety of interfaces, all of which deserve consistent, top tier UX attention and community-wide HIG's-- CLIs, client libraries / language bindings, HTTP APIs, web UIs, messaging and even pluggable driver interfaces. Each type of interface generally caters to a different audience, each with slightly different expectations. +1 I would add things like configuration file syntax and log file message formats into the UX category. These are a fundamental interface for operators who are setting up and debugging an initial OpenStack deployment. Would love for these interfaces to be treated as first-class entities from a UX perspective. 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. I'd be happy to contribute a design session to focus on improving UX across the community, and I would certainly attend! Me too. Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
Anne Gentle wrote: 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. The key difference between docs and UX is that documentation is a separate deliverable, and is reviewed by the docs core team. UX work ends up in each project's code, and gets reviewed by the project's core team, not the UX team. Blessing a separate team with no connection with the project core team is imho a recipe for disaster, potentially with tension between a team that recommends work to be done and a team that needs to actually get the work coded, reviewed and merged. That's why I see UX more like security or scalability, than like documentation. A design goal rather than a deliverable. And design goals need to be baked in the team that ends up writing and reviewing the code. Making it separate will just make it less efficient. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
On Wed, Nov 20, 2013 at 9:09 AM, Thierry Carrez thie...@openstack.orgwrote: 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. Having been working on a cross-project project for a while now I can confirm that there is a startling lack of coordination between projects on the same/similar tasks. Oslo was a HUGE step toward reducing that and providing a good reference for code and libraries. There is nothing today for the intangible parts that are both user and developer facing such as common message (log) formats, common terms (tenant vs project) and so on. I think the model of the OSSG is a good one. After reading the log of yesterday's meeting I think I would have thrown in that the need from my perspective is for a coordination role as much as anything. The deliverables in the UX Program proposal seem a bit fuzzy to me as far as what might go into the repo. If it is interface specs, those should be in either the project code repos docs/ tree or in the docs project directly. Same for a Human Interface Guide (HIG) that both Horizon and OSC have (well, I did steal a lot of OSC's guide from Horizon's). The interaction with users seems very valuable to me. Frankly, user polls are not my favorite task, even if I always learn a lot about my project watching users bend it in ways I never imagined. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to best make User Experience a priority in every project
Anne Gentle wrote: On Wed, Nov 20, 2013 at 9:09 AM, Thierry Carrez thie...@openstack.orgmailto:thie...@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. +1 UX is, in SW parlance, the next layer above the mechanics of the projects. It is separate from all the projects yet informs them all. To be able to inform all projects consistently, there needs to be a place where all the project based UXs come together to create a consistent, overarching environment. This is what UX does, and this is why it works better than having each project do their own thing. You don't get an environment when you don't have someone architecting an environment. You just get a bunch of projects glued together with more code. Since the current team is so small, as Anne points out, the team, working with the TC should decide which and how many individual projects need their attention first, and they also can prioritize what parts of the UX environment get defined/specified first. 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? The most efficient and effective way to get enduser concerns and issues addressed systematically is through one point of contact, not one for every project. By having one place to collect up all inputs other than bugs and missing features in one place, problem areas are spotted much sooner, but also areas of excellence. 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. +1000 Devs tend to think they know how endusers are going to want to use and interact with their code. Most don't care that some endusers find the interface(s) confusing, opaque, inflexible or unforgiving. The best way to get a unified user experience is to have a *Program* (like Docs and QA) that gives UX legitimacy and some authority beyond just the responsibility they feel to the usability and usefulness of the projects they are unifying. Program status would also bring in more UX participants because it acknowledges that OpenStack is serious about UX and understands its importance (especially in reducing pilot error and
