Re: pgarchives new design review - Mailing list pgsql-www

Hi,

Before my additional comments, thank you for proposing this.

On 7/29/22 10:53 AM, Dave Page wrote:
> Hi
> 
> On Fri, 29 Jul 2022 at 14:55, Sahil Harpal <sahilharpal1234@gmail.com 
> <mailto:sahilharpal1234@gmail.com>> wrote:
> 
>     Hi Dave,
> 
>     On Fri, 29 Jul 2022 at 15:49, Dave Page <dpage@pgadmin.org
>     <mailto:dpage@pgadmin.org>> wrote:
> 
>         I have a few comments, based on a quick look:
>         - The site is unusable if Javascript is disabled in the browser.
>         PostgreSQL websites have a general requirement that JS should be
>         optional, not a requirement.
> 
> 
>     Oh! I was not actually aware of this. There are JS files that are
>     already in use and present in the media/js directory so I thought it
>     won't be a problem. Otherwise we need to use normal tables only. Do
>     you have any suggestions for this?
> 
> 
> We can (and do) use Javascript for a nicer experience for the majority 
> of users. However, we need it to still be usable if a user does not have 
> Javascript enabled.
> 
> The buttons on https://www.postgresql.org/download/ 
> <https://www.postgresql.org/download/> are a good example. If Javascript 
> is disabled, they act as regular links that will take you to a new page 
> with the same content that you would see inline if Javascript were 
> enabled. Of course, that's not the only way to handle the problem. One 
> way might be to leave regions expanded by default, and to collapse them 
> if JS is enabled (if you can do that before the full page renders, so it 
> doesn't look weird).
> 
> 
>         - There is different styling on different buttons. For example,
>         the numbered buttons for by-day paging look quite different from
>         the previous/next buttons, which have a thicker border and what
>         appears to be a different background colour.
> 
>         - The thread paging buttons have different styling again (and
>         are using a shade of blue which is outside of our normal palette
>         I believe).
> 
>         - The blue used for the on-hover row highlighting also seems
>         unnatural. Perhaps a light grey would work better here?
> 
>         - Perhaps the Previous/Next buttons should be at either end of
>         the "per-day" buttons, rather than on a separate row?
> 
> 
>       Alright, the above points can be resolved easily. I will make
>     changes accordingly.
> 
> 
> Thanks.
> 
> 
>         - The lists of messages are (intentionally) a lot more compact
>         in the current design. The new design looks nice, but would
>         require a *lot* more scrolling as each row is now at least two
>         lines of text. I wonder if there's a way to keep at least some
>         of the compact-ness, whilst still making it look nicer.
> 
> 
>     I think users would not require to scroll much. Like in the new
>     design we have an option to set max entries to be displayed. So we
>     can set max entries to lets say 10 and then just jump/switch to
>     different pages one by one.
>     But still I am open to any new layout that we can use to keep at
>     least some of the compact-ness.
> 
> 
> Maybe :-). That setting seems to be per-day though, and is not persisted 
> (and is at the bottom of each day, so you'd have to scroll to change it).

> 
> One pattern I often use is to visit a page and use the browsers search 
> function to find a message (if I know it was from the last couple of 
> days for example). The current design would break that, so I'm not in 
> favour of hiding rows anyway.


I don't think some of these changes are an improvement for the target 
users of the archives, which are predominately PostgreSQL 
hackers/developers. Specifically:

* Hiding messages in the day view (as Dave mentions). On a high-traffic 
list like -hackers, this makes it very difficult to scan or find a 
specific message. The current format, which was designed with the input 
of several power users (after I broke their workflow with the redesign), 
makes it easy to scan and/or use browser tools (ctrl-f) to find messages.

* Similarly, I'm a -1 for the search fields in all of the days.

* Quick Links: I'm on the fence if that should be floating around. 
Looking into those + what you see when you scroll through the archives, 
I don't know if a user is tempted to click on any of those.

I think if we were to invest in anything around "linking" in the message 
archives, it would be towards making it easier for folks to figure out 
how to subscribe to a mailing list.

Thanks,

Jonathan