[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-15 20:52:14
[Download RAW message or body]

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

On Saturday 14 September 2002 10:33, Klas Kalass wrote:
> > RMB menus == hidden functionality. switching headers ought to be more
> > visible than hidden.
>
> Who needs this functionality? I am pretty sure that only so-called
> power-users will ever need it, so I do not think that it should be highly
> visible.

even power users aren't interface mind readers. 

> Sorry, but you are wrong. They have a different style of displaying the
> headers (apart from long which I called unneeded above). If you think that
> is unnecessary then OK, but claiming that they are just different
> arrangements is wrong. Just look at them and at things like font-weight and
> font-size (for the subject)...

one word: stylesheet. if we want config of font weights, etc (which i think is 
really unecessary, but there are those who want it), stylesheets are the way 
to go. not 5 hard coded semivariations.

> > 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.
>
> 99.9% of the time this button would be highly annoying and unnecessary.
> Again, this is a preference that people probably set once (if they do it at
> all).

kind of like the View -> Headers menu item. 99.9% of the time that submenu is 
annoying and 100% it's ambiguous (the user needs to provide the meaning 
through having learned its relationship to the program...

> The nice thing about Brief is that it takes minimal space, yes.

i think this too could be integrated into the headers themselves.. i've got a 
few ideas kicking around and will try a few them out...

> But back to the point.
> I missed in your mock-up that all this extra stuff (i.e. the close buttons
> and the "tip") will be shown only after having clicked the small link
> "More...". 

right... 

> I think that would be acceptable even though I still think that
> this option should not be highly visible - it might even scare
> unexperienced users who have no idea about all the information that is sent
> in a mail.

it'll scare them that clicking "More..." (which is all the way out by itself) 
will show more info? maybe if they were recently labotomized.

> But I still think that taking away all possibilities to influence the look
> of the header is a step backwards, not forward.

this is actually a step forwards in that direciton, not backwards. it creates 
a single view system with fewer ad-hoc options. this paves the way forward 
for consistent application of stylesheets.

- -- 
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)

iD8DBQE9hPL/1rcusafx20MRAhHfAJ9EHt7z+4c58CPnGxZzDNeexFEhVACeLrTv
ulRruaoR96GLvW+It5WXoa8=
=6gMw
-----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]