Re: pgarchives new design review

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(at)gmail(dot)com
> <mailto:sahilharpal1234(at)gmail(dot)com>> wrote:
>
> Hi Dave,
>
> On Fri, 29 Jul 2022 at 15:49, Dave Page <dpage(at)pgadmin(dot)org
> <mailto:dpage(at)pgadmin(dot)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