{"thread":{"id":"57566","subject":"Let's have a user experience workshop","startedAt":"2022-03-15T21:04:28Z","lastAt":"2022-05-20T16:22:48Z","messageCount":14,"participants":["Alice Merrick","Philip Oakley","Emily Shaffer","Michal Suchánek","Junio C Hamano","Jonathan Nieder","rsbecker@nexbridge.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"451430","messageId":"CA+Yb-VSaeKy-g_ywkZzQuEX=k3EXM+Ky-rHOb2az0SHGVbdaVw@mail.gmail.com","threadId":"57566","inReplyTo":null,"subject":"Let's have a user experience workshop","fromName":"Alice Merrick","fromEmail":"amerrick@google.com","sentAt":"2022-03-15T21:04:09Z","receivedAt":"2022-03-15T21:04:28Z","isPatch":false,"sender":{"key":"amerrick@google.com","avatar":null},"body":"Hello Git,\n\nI’m doing a 20% project with the Git Core team at Google. I've been\nencouraged by Emily Shaffer and Jonathan Nieder to reach out to the\nGit community to help incorporate UX practices into the Git\ndevelopment cycle. My goal is to 1) gauge interest in improving Git's\nuser experience and 2) recruit interested folks in organizing or\nattending a workshop where you can learn more about what UX is and\ndiscuss ways to bake UX into the process of making changes to Git to\nimprove the experience for all users.\n\nSome additional context about me: I am a UX (user experience)\nprofessional at Google. I have experience applying UX and\naccessibility practices[1] to developer tools for searching,\nreviewing, debugging code, etc. For the past couple years I’ve worked\nwith the Golang project on their websites and helped set project\npriorities by collecting community feedback through their annual\ndeveloper survey[2].\n\nInterested?\n* Join the git UX Google group (https://groups.google.com/g/git-ux) if you\nare interested in participating in an event.\n* Reply directly to this email if you are interested in organizing the\nevent to discuss git UX (scheduling the event, sending invites,\ncommunicating with invitees)\n\n\n[1] https://doi.org/10.1145/3411764.3445544\n[2] https://go.dev/blog/survey2020-results\n\n-- \n\nAlice Merrick | UX Researcher | amerrick@google.com | 206-785-7532\n"},{"id":"451489","messageId":"42d8eebd-f987-a24e-e47c-67334583568b@iee.email","threadId":"57566","inReplyTo":"CA+Yb-VSaeKy-g_ywkZzQuEX=k3EXM+Ky-rHOb2az0SHGVbdaVw@mail.gmail.com","subject":"Re: Let's have a user experience workshop","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2022-03-16T17:36:23Z","receivedAt":"2022-03-16T17:36:37Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Alice,\n\nOn 15/03/2022 21:04, Alice Merrick wrote:\n> Hello Git,\n>\n> I’m doing a 20% project with the Git Core team at Google. I've been\n> encouraged by Emily Shaffer and Jonathan Nieder to reach out to the\n> Git community to help incorporate UX practices into the Git\n> development cycle. My goal is to 1) gauge interest in improving Git's\n> user experience and 2) recruit interested folks in organizing or\n> attending a workshop where you can learn more about what UX is and\n> discuss ways to bake UX into the process of making changes to Git to\n> improve the experience for all users.\n>\n> Some additional context about me: I am a UX (user experience)\n> professional at Google. I have experience applying UX and\n> accessibility practices[1] to developer tools for searching,\n> reviewing, debugging code, etc. For the past couple years I’ve worked\n> with the Golang project on their websites and helped set project\n> priorities by collecting community feedback through their annual\n> developer survey[2].\n>\n> Interested?\n> * Join the git UX Google group (https://groups.google.com/g/git-ux) if you\n> are interested in participating in an event.\nI joined the group, but there are no current entries, and, at present I\ncan't post anything.\n\nI am interested in the UX from the perspective of Human Error and how we\nform our mental models of the task at hand (e.g. see historic\ndiscussions about the 'staging area').\n\nGit does have rather a lot of non physical concepts to grasp, and now\nthat it's way beyond being just an SCM for the Linux kernel, the user\nbase has become rather diverse.\n\nI'm a retired systems engineer who worked in defence electro-optics in\nthe UK. I am mainly on Windows.\n\n> * Reply directly to this email if you are interested in organizing the\n> event to discuss git UX (scheduling the event, sending invites,\n> communicating with invitees)\n>\n>\n> [1] https://doi.org/10.1145/3411764.3445544\n> [2] https://go.dev/blog/survey2020-results\n>\n--\nPhilip\n"},{"id":"451491","messageId":"CAJoAoZn91dyFEdMKUj_XU8CjUbh5EtdqjTR3CaAe=Bhii7dt3Q@mail.gmail.com","threadId":"57566","inReplyTo":"42d8eebd-f987-a24e-e47c-67334583568b@iee.email","subject":"Re: Let's have a user experience workshop","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2022-03-16T17:48:57Z","receivedAt":"2022-03-16T17:49:13Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Wed, Mar 16, 2022 at 10:38 AM Philip Oakley <philipoakley@iee.email> wrote:\n\n> > Interested?\n> > * Join the git UX Google group (https://groups.google.com/g/git-ux) if you\n> > are interested in participating in an event.\n> I joined the group, but there are no current entries, and, at present I\n> can't post anything.\n\nI can shed a little light here. I set up the list; for now, it's\nprimarily intended for use as a roster for a future live event\n(similar to, but smaller scale than, the diversity/equity/inclusion\nworkshop we had a couple of years ago). Maybe after the event it will\nbe useful to open that list up for posting, but if I'm being honest,\nI'd personally prefer to keep discussions about Git's UX on git@vger,\nwhere everybody can participate. Hopefully that rationale clears up\nwhy you're unable to post or see anything there. :)\n\n - Emily\n"},{"id":"451510","messageId":"20220316201058.GI163591@kunlun.suse.cz","threadId":"57566","inReplyTo":"CA+Yb-VSaeKy-g_ywkZzQuEX=k3EXM+Ky-rHOb2az0SHGVbdaVw@mail.gmail.com","subject":"Re: Let's have a user experience workshop","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2022-03-16T20:10:58Z","receivedAt":"2022-03-16T20:11:07Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"Hello,\n\nOn Tue, Mar 15, 2022 at 02:04:09PM -0700, Alice Merrick wrote:\n> Hello Git,\n> \n> I’m doing a 20% project with the Git Core team at Google. I've been\n> encouraged by Emily Shaffer and Jonathan Nieder to reach out to the\n> Git community to help incorporate UX practices into the Git\n> development cycle. My goal is to 1) gauge interest in improving Git's\n> user experience and 2) recruit interested folks in organizing or\n> attending a workshop where you can learn more about what UX is and\n> discuss ways to bake UX into the process of making changes to Git to\n> improve the experience for all users.\n> \n> Some additional context about me: I am a UX (user experience)\n> professional at Google. I have experience applying UX and\n> accessibility practices[1] to developer tools for searching,\n> reviewing, debugging code, etc. For the past couple years I’ve worked\n> with the Golang project on their websites and helped set project\n> priorities by collecting community feedback through their annual\n> developer survey[2].\n> \n> Interested?\n> * Join the git UX Google group (https://groups.google.com/g/git-ux) if you\n> are interested in participating in an event.\n> * Reply directly to this email if you are interested in organizing the\n> event to discuss git UX (scheduling the event, sending invites,\n> communicating with invitees)\n\nCan you, please, use a sane mailing list for the discussion?\n\nThe user experience of Google Groups really bad.\n\nAlso it seems it is accessible only to people with a google account.\n\nCould you use a more inclusive technology?\n\nThanks\n\nMichal\n"},{"id":"451517","messageId":"CAJoAoZnKebM4m3AXW6+RBY7dBsQhAcReqd61VtXHNjcnPBeemQ@mail.gmail.com","threadId":"57566","inReplyTo":"20220316201058.GI163591@kunlun.suse.cz","subject":"Re: Let's have a user experience workshop","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2022-03-16T20:41:59Z","receivedAt":"2022-03-16T20:42:27Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Wed, Mar 16, 2022 at 1:11 PM Michal Suchánek <msuchanek@suse.de> wrote:\n\n> > * Reply directly to this email if you are interested in organizing the\n> > event to discuss git UX (scheduling the event, sending invites,\n> > communicating with invitees)\n>\n> Can you, please, use a sane mailing list for the discussion?\n>\n> The user experience of Google Groups really bad.\n>\n> Also it seems it is accessible only to people with a google account.\n>\n> Could you use a more inclusive technology?\n\nGit already uses Google Groups for the security list (e.g. for fixing\npre-disclosure security issues) and for the mentoring list, and it's\nfine to subscribe to one with a non-Google account; it acts just as a\nnormal mailing list in your inbox. Anyway, as I mentioned in\nhttps://lore.kernel.org/git/CAJoAoZn91dyFEdMKUj_XU8CjUbh5EtdqjTR3CaAe%3DBhii7dt3Q%40mail.gmail.com,\nthe list mostly serves as a roster, not as a place for discussion.\n\n - Emily\n"},{"id":"451521","messageId":"20220316213452.GJ163591@kunlun.suse.cz","threadId":"57566","inReplyTo":"CAJoAoZnKebM4m3AXW6+RBY7dBsQhAcReqd61VtXHNjcnPBeemQ@mail.gmail.com","subject":"Re: Let's have a user experience workshop","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2022-03-16T21:34:52Z","receivedAt":"2022-03-16T21:35:01Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Wed, Mar 16, 2022 at 01:41:59PM -0700, Emily Shaffer wrote:\n> On Wed, Mar 16, 2022 at 1:11 PM Michal Suchánek <msuchanek@suse.de> wrote:\n> \n> > > * Reply directly to this email if you are interested in organizing the\n> > > event to discuss git UX (scheduling the event, sending invites,\n> > > communicating with invitees)\n> >\n> > Can you, please, use a sane mailing list for the discussion?\n> >\n> > The user experience of Google Groups really bad.\n> >\n> > Also it seems it is accessible only to people with a google account.\n> >\n> > Could you use a more inclusive technology?\n> \n> Git already uses Google Groups for the security list (e.g. for fixing\n> pre-disclosure security issues) and for the mentoring list, and it's\n> fine to subscribe to one with a non-Google account; it acts just as a\n\nThe link you provided only allows access with a Google account. If there\nis one that allows access in other ways it was not provided.\n\nPlease try to use open technologies that are accessible to everyone, not\nonly people affliated with one specific company.\n\nThanks\n\nMichal\n"},{"id":"451526","messageId":"9bc6368d-cb14-8bd7-f58d-08087258311b@iee.email","threadId":"57566","inReplyTo":"CAJoAoZn91dyFEdMKUj_XU8CjUbh5EtdqjTR3CaAe=Bhii7dt3Q@mail.gmail.com","subject":"Re: Let's have a user experience workshop","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2022-03-16T21:50:55Z","receivedAt":"2022-03-16T21:50:59Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Emily,\n\nOn 16/03/2022 17:48, Emily Shaffer wrote:\n> On Wed, Mar 16, 2022 at 10:38 AM Philip Oakley <philipoakley@iee.email> wrote:\n>\n>>> Interested?\n>>> * Join the git UX Google group (https://groups.google.com/g/git-ux) if you\n>>> are interested in participating in an event.\n>> I joined the group, but there are no current entries, and, at present I\n>> can't post anything.\n> I can shed a little light here. I set up the list; for now, it's\n> primarily intended for use as a roster for a future live event\n> (similar to, but smaller scale than, the diversity/equity/inclusion\n> workshop we had a couple of years ago). \n\nCould you at least add a post to the group (doesn't need to be sent out)\nto that effect, so that the UX of those that register is informative?\n> Maybe after the event it will\n> be useful to open that list up for posting, but if I'm being honest,\n> I'd personally prefer to keep discussions about Git's UX on git@vger,\n> where everybody can participate. \nI'd be reasonably happy with that. An initial event would help clarify\nexpectations.\n\n> Hopefully that rationale clears up\n> why you're unable to post or see anything there. :)\n>\n>  - Emily\n\n"},{"id":"451528","messageId":"xmqqk0ctk0yv.fsf@gitster.g","threadId":"57566","inReplyTo":"CAJoAoZnKebM4m3AXW6+RBY7dBsQhAcReqd61VtXHNjcnPBeemQ@mail.gmail.com","subject":"Re: Let's have a user experience workshop","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-16T22:05:12Z","receivedAt":"2022-03-16T22:05:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Emily Shaffer <emilyshaffer@google.com> writes:\n\n> Git already uses Google Groups for the security list (e.g. for fixing\n> pre-disclosure security issues) and for the mentoring list, and it's\n> fine to subscribe to one with a non-Google account; it acts just as a\n> normal mailing list in your inbox.\n\nI think the groups.google URL is not the one that acts just as a\nnormal mailing list.  <git-ux@googlegroups.com> address may be what\nneeds to be advertised.\n\nI would prefer to see such a discussion on this list, too, not on a\nseparate place people need to subscribe to, though.\n\nThanks.\n"},{"id":"455072","messageId":"Ynndk0L6r9O7jLVU@google.com","threadId":"57566","inReplyTo":"CA+Yb-VSaeKy-g_ywkZzQuEX=k3EXM+Ky-rHOb2az0SHGVbdaVw@mail.gmail.com","subject":"Re: Let's have a user experience workshop","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2022-05-10T03:35:47Z","receivedAt":"2022-05-10T03:38:11Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(bcc-ing git UX workshop attendees as a heads up)\nHi,\n\nAlice Merrick wrote[1]:\n\n>                    My goal is to 1) gauge interest in improving Git's\n> user experience and 2) recruit interested folks in organizing or\n> attending a workshop where you can learn more about what UX is and\n> discuss ways to bake UX into the process of making changes to Git to\n> improve the experience for all users.\n\nThanks, Alice!  I enjoyed the workshop.  There are some notes at [2],\nwhich perhaps someone may want to summarize for the mailing list.\n\nA few bits I took away:\n\n0. Examples\n\nThe examples Alice gave, especially from the Go project (generics as a\nUX project!) were interesting and helpful.\n\n1. Continuing the conversation\n\nI and some others (e.g. David, cc-ed) ended the workshop wanting to\ndiscuss a little more --- when deciding (1) what to work on and (2)\nsettling on a design for that work, what has worked well for us in the\npast?  What didn't work?  What research methods have we tried?  What\nwould we like to try?  We mentioned wanting to continue that\ndiscussion on-list, so trying that now. :)\n\n2. Sharing research\n\nSome of us are already doing some research, in the form of surveys,\nmetrics collection, testing with prototypes, analyzing user issues in\ninternal bug trackers, and so on.  It would be nice to share that\nmore, so different participant's studies can build on each other.\n\nI'm curious about what a good form for that is in an open source\nproject.  Should we send findings as papers to the mailing list?  Do\nwe want some kind of repository (using git, Figma, or some other tool)\nof findings that we build together collaboratively?  Whatever we do is\nlikely to involve some extra work to deal with confidentiality; how do\nwe notice when something is worth the work of jumping through that\nhurdle?\n\n3. Testing ideas with users\n\nIt's not unusual for there to be a question on-list about some facet\nof the UI such as an option name, that ends up being decided as a\nmatter of taste.  Alice mentioned that we have a chance to make more\nuser-focused decisions by just talking to a few users, which can be as\nsimple as recruiting five users from #git on IRC and sending them a\nprivate message asking questions like \"Suppose you have just run this\ncommand; what would you run next? What would you expect that command\nto do?\"  This seems like a straightforward addition to our workflow\nthat we could get better at over time.\n\nDo you agree?  If this is a good idea, how would we like to go about\nit?  (E.g., how do we notice when there's a question that could\nbenefit from that kind of experiment, how do we come up with the\nquestions for users, and how do we present the results?)\n\n4. Stating assumptions about users\n\nAnother theme was that when we choose what to work on and form designs\nfor our work, we regularly make numerous assumptions about users'\ndesires and goals, habits, what will be intuitive for them, and so on.\nStating these assumptions would have a few benefits:\n\n- they would make the rationale behind a design clearer, which makes\n  it easier to continue to honor that design in the future;\n\n- when those assumptions turn out to be false, it would be easier to\n  revisit early design decisions;\n\n- they could give interested people ideas for how to follow up and\n  check those assumptions;\n\n- over time a clearer model of the user would emerge that could be\n  useful to make use of in later designs\n\nThe downside, of course, is that it can be embarrassing to make\nassumptions that turn out to be wrong, but that seems like a small\ndownside relative to those benefits.  So I am thinking it could make\nsense for us to make a concerted effort to describe these kinds of\nassumptions in commit messages more often.  If this seems like a good\nidea, I'd be happy to send or review a patch to SubmittingPatches\nsaying as much.  What do you think?\n\n5. Bug tracker\n\nFor many open source projects, a bug tracker is what allows someone to\nfollow a particular effort without having to \"drink from the firehose\"\nof the full mailing list.  That's particularly likely to be helpful\nwhen bringing in contributors such as designers who do not necessarily\nlive the same mailing list based lifestyle.\n\nIn [3] we (somewhat tongue-in-cheek) suggested using Bugzilla as a bug\ntracker that would be equally undesirable to everyone, but it doesn't\nseem to have gone anywhere.\n\nI suspect GitLab's issue tracker might be fine in that respect as\nwell.  Would it be worth setting up a bug tracker there?  (Just like\nwith the Linux kernel's and with the existing crbug.com/git, I'm\nimagining a bug tracker would mostly consist of pointers to the\nmailing list, but it would still be useful for someone wanting to\nfollowing along and help with an issue.)\n\nThanks,\nJonathan\n\n[1] https://lore.kernel.org/git/CA+Yb-VSaeKy-g_ywkZzQuEX=k3EXM+Ky-rHOb2az0SHGVbdaVw@mail.gmail.com/\n[2] https://docs.google.com/document/d/1KDThcte2NHnzZBVXG7lHlqCQNzict6EIpOe9Z1iXEMg/edit\n[3] https://lore.kernel.org/git/20211021134105.ziqmcknnpdsg6cvc@meerkat.local/\n"},{"id":"455221","messageId":"CAJoAoZ=t=BEfsfHBay1K7CY2MYEwcvPYKYxvgv_BvLL3SMcf_A@mail.gmail.com","threadId":"57566","inReplyTo":"Ynndk0L6r9O7jLVU@google.com","subject":"Re: Let's have a user experience workshop","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2022-05-12T22:23:12Z","receivedAt":"2022-05-12T22:23:29Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Mon, May 9, 2022 at 8:35 PM Jonathan Nieder <jrnieder@gmail.com> wrote:\n> A few bits I took away:\n>\n> 0. Examples\n>\n> The examples Alice gave, especially from the Go project (generics as a\n> UX project!) were interesting and helpful.\n>\n> 1. Continuing the conversation\n>\n> I and some others (e.g. David, cc-ed) ended the workshop wanting to\n> discuss a little more --- when deciding (1) what to work on and (2)\n> settling on a design for that work, what has worked well for us in the\n> past?  What didn't work?  What research methods have we tried?  What\n> would we like to try?  We mentioned wanting to continue that\n> discussion on-list, so trying that now. :)\n>\n> 2. Sharing research\n>\n> Some of us are already doing some research, in the form of surveys,\n> metrics collection, testing with prototypes, analyzing user issues in\n> internal bug trackers, and so on.  It would be nice to share that\n> more, so different participant's studies can build on each other.\n>\n> I'm curious about what a good form for that is in an open source\n> project.  Should we send findings as papers to the mailing list?  Do\n> we want some kind of repository (using git, Figma, or some other tool)\n> of findings that we build together collaboratively?  Whatever we do is\n> likely to involve some extra work to deal with confidentiality; how do\n> we notice when something is worth the work of jumping through that\n> hurdle?\n>\n> 3. Testing ideas with users\n>\n> It's not unusual for there to be a question on-list about some facet\n> of the UI such as an option name, that ends up being decided as a\n> matter of taste.  Alice mentioned that we have a chance to make more\n> user-focused decisions by just talking to a few users, which can be as\n> simple as recruiting five users from #git on IRC and sending them a\n> private message asking questions like \"Suppose you have just run this\n> command; what would you run next? What would you expect that command\n> to do?\"  This seems like a straightforward addition to our workflow\n> that we could get better at over time.\n>\n> Do you agree?  If this is a good idea, how would we like to go about\n> it?  (E.g., how do we notice when there's a question that could\n> benefit from that kind of experiment, how do we come up with the\n> questions for users, and how do we present the results?)\n>\n> 4. Stating assumptions about users\n>\n> Another theme was that when we choose what to work on and form designs\n> for our work, we regularly make numerous assumptions about users'\n> desires and goals, habits, what will be intuitive for them, and so on.\n> Stating these assumptions would have a few benefits:\n>\n> - they would make the rationale behind a design clearer, which makes\n>   it easier to continue to honor that design in the future;\n>\n> - when those assumptions turn out to be false, it would be easier to\n>   revisit early design decisions;\n>\n> - they could give interested people ideas for how to follow up and\n>   check those assumptions;\n>\n> - over time a clearer model of the user would emerge that could be\n>   useful to make use of in later designs\n>\n> The downside, of course, is that it can be embarrassing to make\n> assumptions that turn out to be wrong, but that seems like a small\n> downside relative to those benefits.  So I am thinking it could make\n> sense for us to make a concerted effort to describe these kinds of\n> assumptions in commit messages more often.  If this seems like a good\n> idea, I'd be happy to send or review a patch to SubmittingPatches\n> saying as much.  What do you think?\n\nFor all 4 of the above - I wonder whether it really makes sense to try\nand organize those things asynchronously. If I'm being honest, what\nI'd much prefer would be a monthly-or-so working group meeting with\nother folks interested in performing research, making recommendations,\nlearning how to improve Git's UX, etc. I'd absolutely make time to\nattend such a thing, and I believe it would be the easiest way to\norganize research and concert our efforts. Would other folks be\ninterested in showing up, too?\n\nI'd envision it as something between a working group and a book club -\nwe could learn different aspects of UX design and research, and apply\nthem in various ways. It might be nice to have Alice along for at\nleast the first couple of sessions to answer questions and help us\nlearn in a bit more targeted direction than we got at the workshop.\n\n - Emily\n"},{"id":"455299","messageId":"YoEnsb2UpDwdjDpd@google.com","threadId":"57566","inReplyTo":"CAJoAoZ=t=BEfsfHBay1K7CY2MYEwcvPYKYxvgv_BvLL3SMcf_A@mail.gmail.com","subject":"Re: Let's have a user experience workshop","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2022-05-15T16:17:53Z","receivedAt":"2022-05-15T16:18:04Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(bcc-ing workshop attendees again)\nHi,\n\nEmily Shaffer wrote:\n> On Mon, May 9, 2022 at 8:35 PM Jonathan Nieder <jrnieder@gmail.com> wrote:\n\n>> 1. Continuing the conversation\n>>\n>> I and some others (e.g. David, cc-ed) ended the workshop wanting to\n>> discuss a little more --- when deciding (1) what to work on and (2)\n>> settling on a design for that work, what has worked well for us in the\n>> past?  What didn't work?  What research methods have we tried?  What\n>> would we like to try?  We mentioned wanting to continue that\n>> discussion on-list, so trying that now. :)\n[...]\n> For all 4 of the above - I wonder whether it really makes sense to try\n> and organize those things asynchronously. If I'm being honest, what\n> I'd much prefer would be a monthly-or-so working group meeting with\n> other folks interested in performing research, making recommendations,\n> learning how to improve Git's UX, etc. I'd absolutely make time to\n> attend such a thing, and I believe it would be the easiest way to\n> organize research and concert our efforts. Would other folks be\n> interested in showing up, too?\n\nInteresting!  I'd also enjoy a meet-up, but e.g. for \"3. Testing ideas\nwith users\" I would find it worrisome if getting user input would\nrequire reviews on a given patch stalling out until the next monthly\nmeeting.  (Reviews are already slower than they should be as it is!)\nI don't know that that's what you meant to suggest; I'm just aiming to\nunderstand what you mean about the \"all 4\" above.\n\n> I'd envision it as something between a working group and a book club -\n> we could learn different aspects of UX design and research, and apply\n> them in various ways. It might be nice to have Alice along for at\n> least the first couple of sessions to answer questions and help us\n> learn in a bit more targeted direction than we got at the workshop.\n\nSounds nice to me.  If others turn out to be also interested, then\nwhat would be the next step for making that happen?\n\nThanks,\nJonathan\n"},{"id":"455310","messageId":"CAJoAoZnP47PT9EQYkNib9+_a-Qg=HxhjowgUx7qJ1V7=KY5iiA@mail.gmail.com","threadId":"57566","inReplyTo":"YoEnsb2UpDwdjDpd@google.com","subject":"Re: Let's have a user experience workshop","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2022-05-16T07:43:25Z","receivedAt":"2022-05-16T07:43:44Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Sun, May 15, 2022 at 6:17 PM Jonathan Nieder <jrnieder@gmail.com> wrote:\n>\n> (bcc-ing workshop attendees again)\n> Hi,\n>\n> Emily Shaffer wrote:\n> > On Mon, May 9, 2022 at 8:35 PM Jonathan Nieder <jrnieder@gmail.com> wrote:\n>\n> >> 1. Continuing the conversation\n> >>\n> >> I and some others (e.g. David, cc-ed) ended the workshop wanting to\n> >> discuss a little more --- when deciding (1) what to work on and (2)\n> >> settling on a design for that work, what has worked well for us in the\n> >> past?  What didn't work?  What research methods have we tried?  What\n> >> would we like to try?  We mentioned wanting to continue that\n> >> discussion on-list, so trying that now. :)\n> [...]\n> > For all 4 of the above - I wonder whether it really makes sense to try\n> > and organize those things asynchronously. If I'm being honest, what\n> > I'd much prefer would be a monthly-or-so working group meeting with\n> > other folks interested in performing research, making recommendations,\n> > learning how to improve Git's UX, etc. I'd absolutely make time to\n> > attend such a thing, and I believe it would be the easiest way to\n> > organize research and concert our efforts. Would other folks be\n> > interested in showing up, too?\n>\n> Interesting!  I'd also enjoy a meet-up, but e.g. for \"3. Testing ideas\n> with users\" I would find it worrisome if getting user input would\n> require reviews on a given patch stalling out until the next monthly\n> meeting.  (Reviews are already slower than they should be as it is!)\n> I don't know that that's what you meant to suggest; I'm just aiming to\n> understand what you mean about the \"all 4\" above.\n\nOh, thanks for clarifying. I agree waiting for some monthly user\nfeedback session wouldn't be ideal; rather, I'd like to see that kind\nof meeting establish a process for getting user feedback sooner. Right\nnow I think it's a little intimidating to say \"let's just start\ngetting user feedback\" with no other instruction.\n\n>\n> > I'd envision it as something between a working group and a book club -\n> > we could learn different aspects of UX design and research, and apply\n> > them in various ways. It might be nice to have Alice along for at\n> > least the first couple of sessions to answer questions and help us\n> > learn in a bit more targeted direction than we got at the workshop.\n>\n> Sounds nice to me.  If others turn out to be also interested, then\n> what would be the next step for making that happen?\n\nSeems like we can go the typical route - vote for timezones and put it\non tinyurl.com/gitcal - but I'll wait to see more people than just you\nand I talking about it before we do that ;)\n\n>\n> Thanks,\n> Jonathan\n>\n> --\n> You received this message because you are subscribed to the Google Groups \"Git UX\" group.\n> To unsubscribe from this group and stop receiving emails from it, send an email to git-ux+unsubscribe@googlegroups.com.\n> To view this discussion on the web visit https://groups.google.com/d/msgid/git-ux/YoEnsb2UpDwdjDpd%40google.com.\n"},{"id":"455572","messageId":"CA+Yb-VQx2CMixGh6GExce9n=QxR-esuhPuuHwzfDKYNow4Zyzw@mail.gmail.com","threadId":"57566","inReplyTo":"CAJoAoZnP47PT9EQYkNib9+_a-Qg=HxhjowgUx7qJ1V7=KY5iiA@mail.gmail.com","subject":"Re: Let's have a user experience workshop","fromName":"Alice Merrick","fromEmail":"amerrick@google.com","sentAt":"2022-05-20T16:17:42Z","receivedAt":"2022-05-20T16:17:59Z","isPatch":false,"sender":{"key":"amerrick@google.com","avatar":null},"body":">\"3. Testing ideas\n> with users\" I would find it worrisome if getting user input would\n> require reviews on a given patch stalling out until the next monthly\n> meeting.  (Reviews are already slower than they should be as it is!)\n> I don't know that that's what you meant to suggest; I'm just aiming to\n> understand what you mean about the \"all 4\" above.\n\nI agree, you wouldn't want to wait until something is in review to get\nuser feedback or testing. I think a Lean UX\n(https://www.scaledagileframework.com/lean-ux/) approach would be more\nappropriate especially when there is no designated UX person. You\nmight need to lean more heavily on design standards and\ninstrumentation for feedback, but sessions with users would still be\nimportant for developing standards and could be used as needed if it's\nnot possible to do them on a regular basis.\n\n> > > I'd envision it as something between a working group and a book club -\n> > > we could learn different aspects of UX design and research, and apply\n> > > them in various ways.\n\nI like this idea. A working group could work on developing design\nstandards and work out what to measure and how to measure it.\n\n-- \n\nAlice Merrick | UX Researcher | amerrick@google.com | 206-785-7532\n"},{"id":"455574","messageId":"028801d86c65$d2785db0$77691910$@nexbridge.com","threadId":"57566","inReplyTo":"CA+Yb-VQx2CMixGh6GExce9n=QxR-esuhPuuHwzfDKYNow4Zyzw@mail.gmail.com","subject":"RE: Let's have a user experience workshop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-05-20T16:22:33Z","receivedAt":"2022-05-20T16:22:48Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 20, 2022 12:18 PM, Alice Merrick wrote:\n>>\"3. Testing ideas\n>> with users\" I would find it worrisome if getting user input would\n>>require reviews on a given patch stalling out until the next monthly\n>>meeting.  (Reviews are already slower than they should be as it is!)  I\n>>don't know that that's what you meant to suggest; I'm just aiming to\n>>understand what you mean about the \"all 4\" above.\n>\n>I agree, you wouldn't want to wait until something is in review to get user\n>feedback or testing. I think a Lean UX\n>(https://www.scaledagileframework.com/lean-ux/) approach would be more\n>appropriate especially when there is no designated UX person. You might need to\n>lean more heavily on design standards and instrumentation for feedback, but\n>sessions with users would still be important for developing standards and could be\n>used as needed if it's not possible to do them on a regular basis.\n>\n>> > > I'd envision it as something between a working group and a book\n>> > > club - we could learn different aspects of UX design and research,\n>> > > and apply them in various ways.\n>\n>I like this idea. A working group could work on developing design standards and\n>work out what to measure and how to measure it.\n\nI would imagine that some patch series do not directly impact UX while others do. Figuring out which are what might be a starting point. In some places, an API change would be UX - if the users are developers. Just a thought.\n--Randall\n\n"}]}