[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Fwd: Re: make_it_cool: kdenetwork/kmail
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-09-14 7:44:25
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 14 September 2002 01:44, Klas Kalass wrote:
> >  http://urbanlizard.com/~aseigo/kmail_headers/headers_all.html
>
> I think this is much too visible, I would get mad at it very soon I think.
> Maybe it would be better if those Icons were not so dominant, but I do not
> think that this needs to be so visible.

please concetrate on the concept, not the icons used. i just picked two icons 
that were pretty obvious and easy to get at. nicer glyphs can be had.

> What I have been thinking about was putting a submenu in the RMB Menu like
> this:

RMB menus == hidden functionality. switching headers ought to be more visible 
than hidden.

> That would be right where you need it but it never gets in the way. I
> strongly doubt that >80% of users would use the configurable headers stuff.
> The drawback is of course that this menu is over-crowded already.

and filled with useless entries if you can control the headers yourself.

> Well, I thought about that as well, but the amount of shown headers is not
> the only difference between those styles. Take "Brief" for example. I think
> to maintain the possibility to imitate the current styles we would need to
> keep Fancy, Brief, Standard and All - the only one not needed is "Long".

wrong. Fancy, Standard and Long and All are just diferent arrangements of the 
possible headers, nothing more. if you can choose which headers appear, they 
are all unecessary as differnt options. if we agree that the Fancy header 
style isn't totally annoying (meaning that it is unecessary to offer a "plain 
white" version) then we should aim to be rid of them all...

which leaves us with Brief. this too could be integrated into the display 
headers with a little arrow button in the subject line of the header that 
would expand/collapse between brief and normal.

that assumes, again, that brief is even needed. i'm guessing it is for 
extremeley crampt areas? in which case we should build it in to the displayed 
headers as well.. but one step at a time; first: defining headers ...

> And inventing a way for the user to have full control over the layout by
> e.g. making HTML and CSS templates would be a huge overkill IMHO.

i agree.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9gujZ1rcusafx20MRAlQWAJ9jcbyf4l66VRiAGRNOX6QRElGwXQCdHD75
aOpxGG8Bw4G1RJEDFtWBx9c=
=NUIT
-----END PGP SIGNATURE-----

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]