GPA development

Jan-Oliver Wagner jan@intevation.de
Tue, 20 Jun 2000 19:00:23 +0200


--h31gzZEtNLTqOjlF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Dear all,

we (Bernhard Reiter and myself) have done a short user interface=20
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=20
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.=20

The keyring management is the actual core of a Gnu Privacy Assistant.=20
It can be called from other modules such as the MUAs.=20
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.=20
The interaction with this dialog needs to be more flat, i.e.=20
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=20
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

--=20
Jan-Oliver Wagner				http://intevation.de/~jan/

Intevation GmbH				  	     http://intevation.de/
FreeGIS						       http://freegis.org/

--h31gzZEtNLTqOjlF
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (SunOS)
Comment: For info see http://www.gnupg.org

iEYEAREBAAYFAjlPoyUACgkQMUxMErvv89rXkACgyGS5NQyr5OerjtY2kDKYryNy
oEkAoIis8mypFLqtM75vW7a4HFf7hjUF
=enPX
-----END PGP SIGNATURE-----

--h31gzZEtNLTqOjlF--