Re: New archives layout is not an improvement - Mailing list pgsql-www
From | Jonathan S. Katz |
---|---|
Subject | Re: New archives layout is not an improvement |
Date | |
Msg-id | 9DAEBE26-122C-4191-9AE0-08CE8187B47D@postgresql.org Whole thread Raw |
In response to | Re: New archives layout is not an improvement (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Responses |
Re: New archives layout is not an improvement
Re: New archives layout is not an improvement Re: New archives layout is not an improvement |
List | pgsql-www |
HI Alvaro, > On Apr 18, 2018, at 4:56 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > Tom Lane wrote: >> "Jonathan S. Katz" <jkatz@postgresql.org> writes: >>> We’ve made a deploy to help with the browsing and reading experiences >>> that you have mentioned. >> >> This is definitely an improvement, thanks! > > Thanks everyone for working on the new site. I hope it will serve new > users better than the old site -- particularly those coming from mobile. That’s the hope :-) Let’s make sure we make it that way. > As one of the heavy users of the archives, I have four humble > suggestions for that part of our site: > > 1. In the "flat" view, say > https://www.postgresql.org/message-id/flat/20180401011446.GK11627%40technoir#20180401011446.GK11627@technoir > we now have an horizontal line between header and body; but there is no > line between end of previous body and the following header! Overall it > gives the wrong impression of what the logical grouping is. I think it > would be better to put the horizontal line between two emails and lose > the one between header and body. Heh, so I did have that line before but it was pushing down on the next message too much for scrolling purposes. However, this is a great suggestion and I will prepare the patch for it tonight. > 2. I agree with Tom that the new look of the message headers are much > better than the old ones, but it appears to me there's still too much > space between consecutive lines of the header -- about 80% of a full > line. Why not reduce that to look like regular single-spacing? It looks like there is some more wiggle room with this, so I will adjust it so it’s a bit tighter. > 3. Listing the attachments together with the headers, rather than at > the bottom of each email, seems generally more convenient, too. This is a great suggestion. If others feel this is worthwhile we can add that in too. I know that would change the existing workflow for some, so I want to make sure that’s ok. > 4. Another point is that we don't really need to display the email > addresses of people listed in From, To, CC fields; they look like just > clutter (plus we're probably feeding the spammers). How about we lose > them? So instead of > > Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>,Christophe Pettus <xof(at)thebuild(dot)com>,Craig Ringer<craig(at)2ndQuadrant(dot)com>,Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>,Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>,RobertHaas <robertmhaas(at)gmail(dot)com>,Anthony Iliopoulos <ailiop(at)altatus(dot)com>,TomLane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Catalin Iacob <iacobcatalin(at)gmail(dot)com>,PostgreSQLHackers <pgsql-hackers(at)postgresql(dot)org> > > we would have > Cc: Tomas Vondra, Christophe Pettus, Craig Ringer, Thomas Munro, Andrew Gierth, Robert Haas, Anthony Iliopoulos, TomLane, Catalin Iacob, PostgreSQL Hackers > > (if we really wanted to keep the email addresses, maybe they could be in > a tooltip on each name instead?) Or (hear me out) given what we know about email and anti-spam technology today, we could use anchor tags… I do like the name idea. However given a quick glance at the code, it looks like we’d have to do some nontrivial post-processing work based on how all of that is stored. Now, we already do some nontrivial post-processing work to handle the email obfuscation as seen above, so perhaps we can put this on the table. Anyway, to argue the other side of “leave it as is” part of the mail archives is to see who sent the email and from where. We could accomplish that with something like a tool tip (feeling eh about this; I find unless you make a tooltip obvious people don’t use it) or with the anchor/mailto work, which has the added benefit of being a URL and in most browsers acts as a tooltip. In the interim, I’ll work on prepping #1 and #2 so we can get those deployed sooner rather than later. Thanks, Jonathan