15:01:13 <piet> #startmeeting openstack_ux
15:01:13 <openstack> Meeting started Fri Jul  8 15:01:13 2016 UTC and is due to finish in 60 minutes.  The chair is piet. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:16 <openstack> The meeting name has been set to 'openstack_ux'
15:01:31 <hurgleburgler> o/
15:01:36 <piet> Show of hands
15:01:40 <piet> o/
15:01:40 <robcresswell> o/
15:01:53 <julim> hi all
15:02:02 <uxdanielle> o/
15:02:26 <piet> Morning!
15:02:31 <piet> https://wiki.openstack.org/wiki/Meetings/UX#Next_meeting
15:03:00 <lcastell> o/
15:03:03 <rcaballeromx> Hello
15:03:26 <piet> Any thoughts on how we handle folks who do not attend UX meetings regularly?
15:03:43 <piet> Specifically, cores
15:04:08 <piet> Never mind ;^)
15:04:14 <piet> #topic Research
15:04:18 <robcresswell> Email, ask to be involved, kick if they dont have time
15:04:24 <robcresswell> I'm doing exactly that in Horizon right now :)
15:04:32 <hurgleburgler> and have meetings regularly … at the same time
15:04:56 <piet> Yeah, Shamail was mentioning that I set expectations on time committment
15:05:13 <julim> +1 on expectations and commitment levels
15:05:18 <piet> hurgleburgler Out sick two weeks ago
15:05:26 <piet> Kk
15:05:32 <piet> Will send something out
15:05:38 <piet> #topic research
15:06:07 <piet> Is everyone familar with the application developer recruitment survey?
15:06:15 <uxdanielle> Yes ;)
15:06:33 <piet> Anyone else? If not, I will describe
15:06:43 <lcastell> describe please
15:06:50 <piet> Kk
15:06:51 <lcastell> :)
15:07:45 <piet> There has been a push by the App Ecosystem and Foundation to begin focusing on app devs since they are ultimately our customers.
15:08:54 <piet> The hassle with recruiting app devs for user research studies is that they do not live in the community channels
15:09:46 <TravT> o/
15:09:51 <piet> So, we are distributing a survey to recruit app devs to create a db of available participants.  We are having a sweepstakes for $100 in July and August
15:10:01 <julim> See https://etherpad.openstack.org/p/newton-osux-appsurvey
15:10:25 <piet> Also, see https://www.surveymonkey.com/r/appdev-survey
15:10:56 <piet> We're currently at n=291, but would like to get to 600
15:11:36 <piet> uxdanielle Any comments on the current limitations of the current sample of respondents?
15:11:41 <julim> also https://etherpad.openstack.org/p/newton-osux-appdevinterview
15:12:21 <piet> It's currently heavily biased towards Intel devlopers
15:12:32 <piet> And upstream developers
15:12:56 <julim> if folks know / recommend some twitter channels to tweet it on, I'm happy to promote there
15:13:04 <robcresswell> Need to be reaching out to managers
15:13:15 <julim> I promoted the survey on the #openstack tokyo days
15:13:18 <uxdanielle> We have quite a few people who do not use OpenStack, but I imagine it's hard to find people who use it but aren't actively involved
15:14:02 <piet> robcresswell julim any suggestions on who we should contact?
15:14:28 <julim> we could all try and reach out to our individual organizations
15:14:37 <julim> but seems like it might be somewhat biased
15:14:44 <piet> This one is a big deal because the foundation threw some money at use to use as a sweepstakes
15:14:58 <robcresswell> Well the problem is that most upstream developers live in their own team
15:14:59 <piet> at "us"
15:15:13 <julim> 291 is pretty good though
15:15:21 <robcresswell> Its common for large organisations to have an "upstream team"
15:15:26 <piet> We did try reaching-out to a few schools
15:15:37 <robcresswell> Which isnt useful when you want to reach out to the people building on that stuff
15:15:46 <robcresswell> City meetups are normally a good place to meet people
15:16:00 <piet> robcresswell Good idea
15:16:06 <robcresswell> The London ones at least tend to be all devs who use and build on top of clouds.
15:16:21 <piet> Are they inmeetup?
15:17:40 <piet> So, distribute the link as much as possible
15:17:45 <robcresswell> Yeah
15:17:47 <uxdanielle> Don't know why meetup.com didn't occur to me - I can post a link to it in the Austin OpenStack meetup group.
15:18:16 <piet> uxdanielle coolio
15:18:22 <julim> any thoughts about reaching out to the folks in google summer of code program? could we?
15:18:23 <robcresswell> I just think posting it to upstream devs is a dead end, because they wont know where to send it within their own org
15:18:44 <julim> I've been tweeting to different conferences where there might be developers...
15:19:29 <piet> robcresswell Yep - also trying to avoid devs that contribute to OS because of bias
15:19:57 <piet> I'll plan to make a second push for folks today
15:20:06 <piet> uxdanielle is also recruiting app devs for a series of interviews next week
15:20:27 <piet> Any help recruiting would be epic.
15:20:43 <piet> uxdanielle Can you describe the study?
15:20:46 <uxdanielle> We currently have 1/5, potentially 2. But will need more for sure :)
15:21:04 <rcaballeromx> Have you tried to send it to Android or IOS devs through the Google and Apple develper mailing lists? Or is that an audience you are not trying to reach.
15:21:17 <piet> uxdanielle Did we send out a second email blast?
15:22:01 <piet> rcaballeromx Would like to recruit indiscriminately and then recruit from that list based on specific criteria
15:22:18 <rcaballeromx> Got it.
15:22:23 <uxdanielle> Yes - the goal of the interviews it to capture the opinions/needs of app devs in order to understand them better. The interviews are no longer than one hour and will cover basic background stuff like their current workflow and painpoints while using OpenStack
15:23:01 <uxdanielle> Not yet. I have the email addresses and will send them to Anne today. I think it would be best if we waited until Monday to send the blast out so it does't get buried in their inboxes
15:23:35 <uxdanielle> The interview questions can be found here: https://etherpad.openstack.org/p/newton-osux-appdevinterview
15:24:26 <piet> Excited about uxdanielle study. Lots of interest fromt eh App Dev WG amonf others...
15:24:32 <rcaballeromx> uxdanielle: I'll take a look at those and edit them.
15:25:09 <uxdanielle> Thanks! Appreciate the review.
15:25:34 <rcaballeromx> No problem.
15:25:46 <piet> Ready to change topics? Ready to close?
15:25:54 <uxdanielle> Yep
15:26:20 <piet> #topic operator help study
15:26:56 <piet> This is uxdanielle 's study
15:27:51 <piet> As you know, operators have been noting that finding help or educating themselves on OS has been an issue.  Take a look at the semi annuals user seurvey
15:28:15 <piet> No learn; no adoption of OS
15:28:46 <piet> uxdanielle Can you briefly describe the study?
15:28:55 <uxdanielle> Study planning etherpad: https://etherpad.openstack.org/p/newton-help
15:29:29 <piet> Where is the doodle link?
15:29:55 <uxdanielle> Sure. We are looking to talk to 10 operators to get a sense for how they actually go about finding and consuming information that helps them overcome issues. We'll talk about how they currently get help, as well as how they ideally would like things to be
15:30:33 <uxdanielle> http://doodle.com/poll/396nfcs324yfsd5y
15:32:08 <piet> Please forward to any software architects , devops and operators that you know
15:32:26 <piet> uxdanielle How may have signed-up
15:32:34 <rcaballeromx> How are you choosing the operators?
15:32:38 <uxdanielle> 2/10
15:32:57 <piet> Currently I'm pulling from my contacts
15:33:01 <uxdanielle> Was going to ask about criteria since we had been using convenience sampling...
15:33:36 <piet> rcaballeromx Interesting you mention because I need to create a new operator recruitment survey
15:33:56 <piet> Similar to the app developer recruitment survey
15:34:00 <rcaballeromx> That can be problematic when interpreting the results, but if it cannot be avoided there is some math that might help.
15:34:28 <piet> rcaballeromx How do you mean?
15:34:54 <rcaballeromx> You have to try to include people with many different backgrounds and levels of expertise within a range.
15:35:18 <rcaballeromx> Old, young, multiple geos, etc.
15:36:01 <piet> rcaballeromx It's interesting because I ran into the same issue at another company.  Burned through the operator population in Seattle
15:36:06 <rcaballeromx> Otherwise the results become very limited.
15:36:45 <piet> rcaballeromx However, we did identify a few people that provided good info and did occasionally chose to use them in 2-3 studies
15:37:02 <piet> rcaballeromx But we need more diversity
15:37:03 <rcaballeromx> That is, statistically speaking, not good.
15:37:31 <rcaballeromx> Then your results become only applicable to those few people.
15:37:55 <rcaballeromx> I would try to focus less on the amount of participants and more on their diversity.
15:37:56 <piet> Shoudl send an email to the ops email list
15:38:18 <rcaballeromx> Yes, the mailing lists are a great place to start.
15:38:40 <piet> Kk
15:38:44 <piet> ready to close?
15:38:55 <rcaballeromx> yep.
15:39:13 <piet> 5
15:39:14 <piet> 4
15:39:15 <piet> 3
15:39:16 <piet> 2
15:39:17 <piet> 1
15:39:37 <piet> #topic UI guideline
15:40:07 <piet> rcaballeromx Can you describe?
15:40:27 <rcaballeromx> Yes
15:40:51 <rcaballeromx> The basic idea is to provide devs with non-prescriptive guidelines for their GUIs.
15:40:56 <piet> rcaballeromx you have the floor
15:41:24 <rcaballeromx> The basic components come from Bootstrap, which apparently is being used by Horizon right now.
15:41:30 <piet> Non-prescriptive in a caring and loving way
15:41:36 <uxdanielle> :)
15:41:59 <piet> The bootstrap thing is an interesting discussion
15:42:05 <rcaballeromx> Patterns are going to be defined using a basic graphic unit of 16 by 16 pixels.
15:42:19 <piet> Want to avoid prescribing a UI toolkit
15:42:39 <rcaballeromx> Using those "atoms" devs can proportion the different graphic components consistently regardless of toolkit.
15:42:49 <piet> rcaballeromx But up for review so that can change
15:43:12 <rcaballeromx> Yes, right now the spec is up for review and in the process of being accepted.
15:43:12 <piet> rcaballeromx Re basic graphic unit of 16 by 16 pixels
15:43:31 <rcaballeromx> Once that happens, we can start creating the guidelines with more detailed info.
15:43:48 <piet> Any questions from the group?
15:44:09 <rcaballeromx> That means that your graphic components have to be composed of multiples of those 16 by 16 building blocks.
15:44:53 <rcaballeromx> It allows for a lot of flexibility and creative freedom, but, at the same time, allows us to provide easy to implement guides for devs.
15:45:10 <robcresswell> Whats this 16x16 thing? You've lost me
15:45:23 <rcaballeromx> For example,
15:46:07 <rcaballeromx> One guide could be that the error message and the edge of the error message window has to have a margin of at least three blocks on all sides.
15:46:38 <rcaballeromx> Your error message can be as large as you want, as can your window, but the proportions will always be the same.
15:46:43 <piet> hurgleburgler Any thoughts on this?
15:47:06 <robcresswell> I don't really like the idea of writing down pixel measurements for where things should or shouldnt be
15:47:27 <piet> robcresswell Too prescriptive?
15:47:39 <rcaballeromx> That is not the idea, you can place them anywhere, just keep the proportions.
15:47:40 <robcresswell> High level rules are useful, but when we start getting down to "this thing needs to be >= 48px from this other thing"
15:48:13 <rcaballeromx> Maybe I was unclear.
15:48:45 <hurgleburgler> Not sure why we need to worry about margins?
15:48:55 <rcaballeromx> It would be at least 3 * #of 16x16 blocks.
15:49:07 <hurgleburgler> That's something that is configured in the theme variables
15:49:12 <hurgleburgler> default padding sizes
15:49:19 <rcaballeromx> Where the # of blocks is up to you.
15:49:20 <hurgleburgler> its not something we need to dictate
15:49:31 <hurgleburgler> robcresswell: we wanted to get away from dictating paddings and such, right?
15:49:35 <rcaballeromx> Maybe that was a bad example.
15:49:44 <hurgleburgler> Content, not style or layout
15:49:56 <rcaballeromx> say, the proportions of a button.
15:50:12 <hurgleburgler> Proportions are paddings
15:50:16 <hurgleburgler> that's something that exists int he theme
15:50:21 <rcaballeromx> 2 by 4
15:50:27 <hurgleburgler> and something that has a default value already defined for vanilla bootstrap
15:50:30 <rcaballeromx> Yes, but everyone is doing it differently.
15:50:33 <hurgleburgler> which is what Horizon is gonna use going forward
15:50:44 <rcaballeromx> And that would be the base for everything.
15:50:55 <hurgleburgler> Vanilla Bootstrap is the base for everything
15:51:00 <hurgleburgler> and those proportions are already defined
15:51:05 <rcaballeromx> Of the guideline.
15:51:14 <piet> hurgleburgler When you say bootstrap do you mean that the other projects shoudl use bootstrap?
15:51:32 <piet> hurgleburgler Or just use their patterns?
15:51:32 <rcaballeromx> We would recommend that, yes.
15:51:34 <hurgleburgler> We are using default bootstrap and all of its proportions going forward
15:51:38 <robcresswell> Yeah, we're already just using default bootstrap as the default for everything. I don't have intention of altering that
15:52:01 <rcaballeromx> Horizon is using it but other projects are not.
15:52:09 <robcresswell> The guidelines we want are more like, "you should use a primary button in these X use cases" and "you should use a success alert for these Y cases"
15:52:09 <piet> robcresswell hurgleburgler Should we be telling the other projects to use bootstrap?
15:52:33 <rcaballeromx> That would be part of it.
15:52:45 <hurgleburgler> If they want to conform to looking like Horizon, they would need to
15:52:48 <robcresswell> Horizon and its plugins should all use it. I'm not sure what the ironic standalone is using, or fuel
15:52:57 <hurgleburgler> or OOO
15:53:10 <rcaballeromx> However, you cannot cover all possible use cases, so it would need to be more general.
15:53:22 <hurgleburgler> Having a bunch of highly customized styles for Horizon turned out to be a nightmare and was impossible to maintain and customize
15:53:42 <hurgleburgler> sorry rcaballeromx but these aren't he guidelines that we were looking for really
15:53:46 <rcaballeromx> "You should use the success alert whenever the last change was successfully implemented.
15:53:55 <piet> hurgleburgler robcresswell Pretty heavy-handed to expect other projects to conform to Horizon unless developing plugins
15:54:13 <hurgleburgler> we aren't telling other projects to conform
15:54:15 <piet> hurgleburgler Define "we"
15:54:20 <robcresswell> Well the other suggestion is we conform to UX
15:54:23 <robcresswell> So everyone changes
15:54:25 <hurgleburgler> but, Horizon already has years of using an existing css framework and all of its glory
15:54:56 <rcaballeromx> That is no argument for not changing things for the better, IMO.
15:54:57 <piet> But this isn't a toolkit spec
15:55:04 <hurgleburgler> being someone who has had to customize Horizon over and over again downstream, not using a css framework isn't a possibility for Horizon
15:55:12 <robcresswell> rcaballeromx: "better"?
15:55:26 <rcaballeromx> For all of projects.
15:55:40 <piet> And there has been some acknowledgment that Horizon has the most mature UI and will likely be driving the patterns
15:55:52 <rcaballeromx> The plan is to use Horizon's framework as a basis.
15:55:54 <hurgleburgler> rcaballeromx: we already discussed in great detail the benefits of using vanilla bootstrap at the summit, and came to that conclusion
15:56:06 <rcaballeromx> So Horizon will be the least affected.
15:56:07 <hurgleburgler> 'better' in terms of style is subjective
15:56:45 <piet> hurgleburgler Where did "style" come from?
15:57:00 <hurgleburgler> padding / proportions all relate to style
15:57:02 <rcaballeromx> The idea is to have the same type of component be at the same relative place accross all GUIs
15:57:04 <hurgleburgler> more so than content
15:57:10 <hurgleburgler> or workflowish patterns
15:57:34 <piet> hurgleburgler Like workflow patterns and high level principles
15:57:53 <robcresswell> Right, but saying  "an alert in the top right" is not the same as "an alert should be 16 px from the next thing"
15:58:03 <rcaballeromx> So the success alerts across all projects will appear in the same place under the same of similar circumstances.
15:58:16 <hurgleburgler> or even an alert should have padding of 1em, 2em, etc
15:58:18 <rcaballeromx> But you need a unit to define "top right"
15:58:21 <piet> rcaballeromx Felt like we were being to specific on prescribing the number of px
15:58:42 <rcaballeromx> No, only the unit to define relative positions and proportions.
15:58:49 <hurgleburgler> placement doesn't  have to dictate units of padding
15:59:03 <piet> feel like we go into the weeds before having a high level discussion of what this thing is...
15:59:12 <rcaballeromx> Yes.
15:59:21 <piet> And what it isn't
15:59:37 <rcaballeromx> This thing is about driving consistency across guis.
15:59:38 <piet> KK one minute
15:59:56 <piet> rcaballeromx Agreed.
16:00:12 <rcaballeromx> How we do that is very much up to debate, and all ideas are on the table.
16:00:27 <piet> Good discussion - let's close
16:00:34 <piet> Calling time
16:00:38 <piet> 5
16:00:39 <piet> 4
16:00:41 <piet> 3
16:00:43 <piet> 2
16:00:44 <piet> 1
16:00:48 <piet> .....
16:00:50 <piet> #endmeeting openstack_ux