+1 Micah +1 Jillian Anne and Paul. On Jun 12, 2013 7:24 PM, "micah" <mi...@riseup.net> wrote:
> Eleanor Saitta <e...@dymaxion.org> 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 compa...@stanford.edu 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 compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
