Dear list, FYI, the standard practice at Stanford (and many other universities and Fortune 500 corporations) is to use gender-neutral terms when speaking or writing. Doing otherwise is considered disrespectful.
Of course, everyone has a right to free speech. But, if someone is disrespectful, the reader also has a right to get angry, especially when the writer's comments are deemed insensitive to 50%+ of the population. Fortunately, many on the list have already made this point, so let's move on. Thanks, Yosem, one of the list moderators On Wed, Jun 12, 2013 at 1:48 PM, Brian Conley <[email protected]>wrote: > +1 Micah > > +1 Jillian Anne and Paul. > On Jun 12, 2013 7:24 PM, "micah" <[email protected]> wrote: > >> Eleanor Saitta <[email protected]> writes: >> >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA256 >> > >> > On 2013.06.12 11.54, micah wrote: >> >> I'm constantly hearing from people who complain about the UI in >> >> things like gnupg. I feel your pain, I do not want to argue that >> >> you are wrong. However, I do want to argue that complaining doesn't >> >> help to solve the problem. I've asked every single person who has >> >> complained about this problem to me recently, "have you filed a bug >> >> about your issues?" and everyone's response is: "no". >> >> >> >> I've done this, and guess what? It works! I filed bugs and had >> >> discussions on the gnupg mailing list that have made your >> >> experience with that tool a little bit better. There are many ways >> >> that I think it can be improved still, don't get me wrong, but the >> >> gnupg developers are reasonable people who want to make the >> >> software better, and probably have been hearing these complaints >> >> for years and years and would welcome a way to make people stop >> >> complaining. >> >> >> >> It seems there are a lot of people out there who have a clear idea >> >> of what is good and what is bad UI and are pretty vocal about when >> >> something is bad. How about turning that into clear bugs that >> >> describe better workflow and UI? You dont have to be a crypto nerd, >> >> or a C programmer to make this stuff better and easier to use. >> > >> > Is there any point in filing a bug that says "Please have a >> > professional designer re-work all use flows in this system from >> > scratch"? (No.) >> >> I agree, there is not much point in that. >> >> > Is there any point in filing a bug that says "Please remove features >> > X, Y, Z, Q, R, N, and M because they're too confusing for novice >> > users"? (No, especially when X is "the entire web of trust".) >> >> I somewhat disagree with you on this point. There is a point to filing a >> bug that says, "Please remove the choice of RSA/DSA/Elgamal from the gpg >> --gen-key process and just automatically use the default unless the user >> has passed --advanced. It is confusing for a user who is just learning >> to use the tool to have to make this choice." >> >> > "Filing bugs" isn't enough -- it's an entire design effort. >> >> I do not think that it is one or the other. Don't throw out the bugs or >> usability enhancements because you think that the whole thing needs to >> be redesigned. >> >> > Individuals may see a thing and think "hey, this could be changed", >> > but what's needed is a top-to-bottom redesign, and that does not >> > translate into a simple set of "clear bugs". I don't believe that the >> > GPG designers have the resources available to do this design effort as >> > it stands, and it's not just them, it's the entire ecosystem that >> > needs to be involved and work together. >> >> I disagree. I've been working with people who have been doing this sort >> of iterative changes with the software for years and things have gotten >> better. >> >> It is actually not that hard to make significant usability changes >> without needing to make top-to-bottom changes. >> >> For example, here is a bug I filed which coalesces my experiences doing >> gnupg trainings with different activists and the stumbling blocks that >> we ran into: >> >> >> https://bugs.g10code.com/gnupg/issue1506?@ok_message=msg%204634%20created%0Aissue%201506%20created&@template=item >> >> > We'd love to see this fixed. If it was this easy, it would have been >> > done years ago. >> >> You would be surprised the changes that you can get if you ask for >> them and describe clearly why they are needed. It helps a lot if you can >> also clearly describe a better alternative. If you know how to code and >> have time, then providing a patch will go even further. Although patches >> are always welcome, they are not required. >> >> For a really long time, smart cryptographers have been writing this >> software, their heads are focused on doing the correct technical thing >> and that doesn't always translate into an easy experience. They have >> been doing this so long that they cannot see how this could be any >> different. It is up to us who aren't so deeply stewed in hashing >> algorithms and trust metrics, we who work with people who provide us the >> feedback who can synthesize it and bring that back to those people in >> who know the code so that they can make it more usable. >> >> If we do not do that, it will not happen, ever. No matter how much we >> complain in places where they will never hear us. >> >> My experience has been that software gets better when I point out the >> problems to the appropriate place that the developers have asked for >> those things to be put. Sometimes that takes several years, sometimes I >> get lucky and the change happens in a weekend. It very rarely gets >> better on its own. >> >> You may think that the whole crypto world needs to be thrown out and we >> need to start again, and you see that as an intractably impossible >> problem. I see things differently because I've seen annoying things >> iteratively become usable over time, and I've seen usable things become >> frustrating and unusable after a design overhaul. The only way either of >> those things work is if you involve users in the feedback loop. You >> can't just redesign everything and then throw it out there without doing >> user testing to figure out what design assumptions you made are not >> shared with others. >> >> We are the intermediaries between those who code and those who use, if >> we fail to do our job we have only ourselves to blame. >> >> micah >> >> -- >> Too many emails? Unsubscribe, change to digest, or change password by >> emailing moderator at [email protected] or changing your settings at >> https://mailman.stanford.edu/mailman/listinfo/liberationtech >> > > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at [email protected] or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech >
-- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at [email protected] or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
