Dear all,
we (Bernhard Reiter and myself) have done a short user interface
evalutation of gpa in the current state (CVS 20000620).
This included a comparision with geheimnis and seahorse.
In the following we will discuss some of the results and suggest
a way on how to continue development up to the Linux 2000 conference.
We gave some thoughts about what is actually required
in a typical life with gpg.
a) Keyring management and the management of files management are largely
different tasks. They should be divided into separate tools.
The keyring management is the actual core of a Gnu Privacy Assistant.
It can be called from other modules such as the MUAs.
The mangement of files should be done in the filebrowsers of the window
system you are using. Just as the MUA plug-ins handle the email part.
Note that this might be very difficult in practice.
b) The keyring management dialog should transparently show
all important information in one window.
The interaction with this dialog needs to be more flat, i.e.
less nested dialog windows. Popping up a window for each key is too
much.
One level that can be omitted is the key editor where only
two further information are offered: fingerprint and signatures.
All other information and all actions are already available in
the key ring editor dialog. The two items can be added
in a comfortable way into the key ring editor dialog.
c) key ring editor (towards an application of its own):
1. Menu offering the actions currently available as buttons
(to have them still available via keyboard).
2. Toolbar instead of buttons with nice icons (only
the most common actions).
3. Nice icons in the list e.g. for the trust levels (is supported
by gtk clist).
4. Option to select columns of list to sort by the selected column.
5. Show who the user is (secret key owner or default secret key).
6. Show a nice counter/clock to give a visual impression on the
remaining time of passphrase validity.
7. Automatically disable those buttons that do not make sense
in a specific selection state.
d) Help for novice users:
1. If no gpg is found: tell the user precisely what he/she needs
to do.
2. If no keyring is found: explain precisely the situation and guide
the user through the generation of his/her first key.
3. If a file with an unknown signature is detected, tell the user
precisely what this means and provide or guid through
options to find the corresponding public key and insert
them into the keyring.
So what can we do in the next few days?
I think, we can primarily address the key ring editor and realize some
of the c.n ideas, perhaps not c.6.
d) whould be very nice for Peter's presentation at the LinuxTag,
but I am not sure that it can be established in the short time.
Nonetheless it is what new users are very interested in.
We need the following icons for sure:
general:
Sign
Encrypt
Decrypt
trust levels:
Unknown
don't trust
trust marginally
fully trust
there are many more that we will need, but I am yet not
sure which operation/status we should associated with icons -
certainly it does not make sense to invent an icon for any
operation/status.
My question is now: should I just start working on improvements
as described above and see how far I get until LinuxTag 2000
and should I commit all changes in Exp branch (when they compile
and are stable)?
Cheers
Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/
Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/
we (Bernhard Reiter and myself) have done a short user interface
evalutation of gpa in the current state (CVS 20000620).
This included a comparision with geheimnis and seahorse.
In the following we will discuss some of the results and suggest
a way on how to continue development up to the Linux 2000 conference.
We gave some thoughts about what is actually required
in a typical life with gpg.
a) Keyring management and the management of files management are largely
different tasks. They should be divided into separate tools.
The keyring management is the actual core of a Gnu Privacy Assistant.
It can be called from other modules such as the MUAs.
The mangement of files should be done in the filebrowsers of the window
system you are using. Just as the MUA plug-ins handle the email part.
Note that this might be very difficult in practice.
b) The keyring management dialog should transparently show
all important information in one window.
The interaction with this dialog needs to be more flat, i.e.
less nested dialog windows. Popping up a window for each key is too
much.
One level that can be omitted is the key editor where only
two further information are offered: fingerprint and signatures.
All other information and all actions are already available in
the key ring editor dialog. The two items can be added
in a comfortable way into the key ring editor dialog.
c) key ring editor (towards an application of its own):
1. Menu offering the actions currently available as buttons
(to have them still available via keyboard).
2. Toolbar instead of buttons with nice icons (only
the most common actions).
3. Nice icons in the list e.g. for the trust levels (is supported
by gtk clist).
4. Option to select columns of list to sort by the selected column.
5. Show who the user is (secret key owner or default secret key).
6. Show a nice counter/clock to give a visual impression on the
remaining time of passphrase validity.
7. Automatically disable those buttons that do not make sense
in a specific selection state.
d) Help for novice users:
1. If no gpg is found: tell the user precisely what he/she needs
to do.
2. If no keyring is found: explain precisely the situation and guide
the user through the generation of his/her first key.
3. If a file with an unknown signature is detected, tell the user
precisely what this means and provide or guid through
options to find the corresponding public key and insert
them into the keyring.
So what can we do in the next few days?
I think, we can primarily address the key ring editor and realize some
of the c.n ideas, perhaps not c.6.
d) whould be very nice for Peter's presentation at the LinuxTag,
but I am not sure that it can be established in the short time.
Nonetheless it is what new users are very interested in.
We need the following icons for sure:
general:
Sign
Encrypt
Decrypt
trust levels:
Unknown
don't trust
trust marginally
fully trust
there are many more that we will need, but I am yet not
sure which operation/status we should associated with icons -
certainly it does not make sense to invent an icon for any
operation/status.
My question is now: should I just start working on improvements
as described above and see how far I get until LinuxTag 2000
and should I commit all changes in Exp branch (when they compile
and are stable)?
Cheers
Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/
Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/