Re: Design help requested: Certificate Chooser UI.

On Mon, 2016-06-06 at 13:43 +0200, Bastien Nocera wrote:
As nobody has replied, and you asked me to look at the mail, here it
is. Given the long mail and the incredibly specific application of it,
it's unsurprising that there were no answers, and I'll try to explain

Thanks, Bastien.

I've created a page at
for this.

To keep things simple I've reduced the scope — from the overall "cert +
key chooser wizard" flow (which is fairly uncontentious) to just the
internal widget which gets used twice to choose *an* object. That's the
part we really need help with.

The design used in the Red Hat user study was based on a file chooser,
with additional 'shortcuts' in the places_sidebar for the PKCS#11
tokens. It seems quite intuitive for the user, and could be made to
work well:

The problem is that this is non-trivial to implement without access to
internals of the GtkFileChooser widget, and there is understandable
resistance to providing that.

(As a straw man proposal, we can *already* add shortcuts with 'pkcs11:'
URIs, so one way we could implement this is by just adding a way to
register an widget to live in the browse_files_stack for a specific URI
protocol. So 'file:' is built-in, and you can add others. You might
even pretend this is a cleanup and handle things like 'Other Locations'
that way instead of with special cases in the main code).

I've even considered a hack where I register the additional shortcuts
for the PKCS#11 tokens, but when they're selected I flip *away* from
the GtkFileChooser (which can't handle them) to something else which
looks identical to it — with a shadow of the same places_sidebar, but
with the Seahorse-like PKCS#11 object browser in the middle. And when
the user selects a file shortcut again, we flip back to the real
GtkFileChooser. But... ick :)

So for now we've side-stepped the issue by having explicit buttons for
the user to press for 'Choose from file' vs. 'Choose from PKCS#11'.
Once we've finished the cosmetics, we end up with something which is
basically the same as our "ideal" idea above — it's just that the
location pane can only show file locations *or* PKCS#11 locations at
any one time, and you have to "change modes" to flip between them.

It seems hard to justify that from the design/UX point of view; only
from the "oh, it's too hard to do it nicely" point of view.

It's that conflict I'd appreciate help resolving. If anyone can come up
with a design idea that *doesn't* involve "nasty hacks" to the file
chooser, that would be great. I'd also settle for a consensus from the
design side that "we're in this to make it work nicely for the users,
not to make life easy for the implementers. Just get on with it" :)

Perhaps a slightly less intrusive request for GtkFileChooser is "let us
hide this places_sidebar". Then I can put my *own* places_sidebar next
to it and I *can* flip to a more appropriate object chooser when it's
not a file shortcut that's selected?


David Woodhouse                            Open Source Technology Centre
David Woodhouse intel com                              Intel Corporation

Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]