New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve appearance and readability #648

Closed
wants to merge 14 commits into
base: master
from

Conversation

Projects
None yet
@NunoAlexandre
Contributor

NunoAlexandre commented Dec 26, 2017

Motive

I work with haddock and hackage almost daily, both at work and at home, and the current theme is unfriendly. I find it very hard to read content with such a wide #content and spacing is not great either.

Furthermore, I'd say many Haskell developers would appreciate the presense of the latest Haskell's logo (purple) colors in these docs.

(Together with haskell/haddock#721)

Changes

  • use latest Haskell's logo colours
  • decrease #content width to improve readability
  • use, custom nicer font: Merriweather Sans
  • improve sizes and distances
  • responsiveness (the menu is now always fully visible and good looking)

Preview

EDIT 04-02-2018: See #648 (comment)

Before:

before-hackage

After:

hackage-after-big

Smartphone

Before - iPhone 7

hackage-before-iphone7

After - iPhone 7

hackage-after-iphone7

Tablet

Before - iPad horizontal

hackage-before-ipad-mini

After - iPad horizontal

hackage-after-ipad-mini-lay

Before - iPad vertical

hackage-before-ipad-mini-stand

After - iPad vertical

hackage-after-ipad-mini-stand

Edit: Responsiveness

I have made it responsive so that it looks nice and reads well on both small and large screens. See commit summary for more information.

Improve appearance and readability
These changes include:

    - use latest Haskell's logo colors
    - decrease #content width to improve readability
    - use nicer font
    - improve sizes and distances
@gbaz

This comment has been minimized.

Contributor

gbaz commented Dec 26, 2017

nice!

Make it responsive
Right now, hackage is not responsive, which makes UX terrible.
For example, when viewing the page from a small device, the header
links overlap and the user no longer sees them all. Also, it is
annoying that the #content takes the same space in a small screen
as in a big one, as it results in very small sentences.
@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Dec 27, 2017

Thank you, @gbaz.

I've now made it responsive. Can you have another look at the preview screenshots above?
Thanks!

@hvr

This comment has been minimized.

Member

hvr commented Dec 27, 2017

I'm a bit confused tbh :-) Why is it considered a good thing that the new stylesheet seems to waste space left/right on a mobile device? Wouldn't you rather want to exploit the little screen estate you have on a mobile device as much as possible? Similarly, on desktops; I have a rather crowded tiled WM, and I make my browser windows rather small; so I'd expect it to use the little window space as efficiently as possible to display the content.

@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Dec 27, 2017

Hi @hvr,

Why is it considered a good thing that the new stylesheet seems to waste space left/right on a mobile device

"Waste" is subjective, but you have a fair point here. Design and typography wise, the empty space (aka "negative space") is beneficial. Furthermore, I have already reduced the "wasted" space on mobile devices. Maybe you mean that you still find it too much? I am fine with reducing it.

Similarly, on desktops; I have a rather crowded tiled WM, and I make my browser windows rather small; so I'd expect it to use the little window space as efficiently as possible to display the content.

It's not so much about if it's on mobile or desktop, but about how much space is available. This is solved by the previous point.

I also use a WM (i3wm), and I'd rather not have content taking the 100% of the available space as that is a disaster in terms of content proximity, and it's hard to read let alone.

@hvr

This comment has been minimized.

Member

hvr commented Dec 27, 2017

@NunoAlexandre Fwiw, I've given it a quick test-drive; it's not as bad as I thought when I make my windows smaller; there's a size at which the negative space suddenly snaps to a smaller amount, so i guess that's good enough :-)

However, I have a high DPI display (somewhere around 120 DPI), and while I can read e.g. GitHub's fonts in its UI just fine (without needing to zoom in), I'm feeling eyestrain with the font style and lower contrast of your stylesheet. Is there something that can be done to improve readability?

Btw, just in case you haven't seen this yet, there's also coloured blocks like e.g. at http://hackage.haskell.org/package/bad-package-example-0/candidate ... which design-wise may pose a challenge :-)

@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Dec 28, 2017

@NunoAlexandre Fwiw, I've given it a quick test-drive; it's not as bad as I thought when I make my windows smaller; there's a size at which the negative space suddenly snaps to a smaller amount, so i guess that's good enough :-)

Thanks for giving it a spin and for the feedback 👍

However, I have a high DPI display (somewhere around 120 DPI), and while I can read e.g. GitHub's fonts in its UI just fine (without needing to zoom in), I'm feeling eyestrain with the font style and lower contrast of your stylesheet. Is there something that can be done to improve readability?

This is good information. Mine is a 227 ppi display and I didn't notice the things you mentioned. Could you perhaps attach a screenshot? We could, for example, darken the colour of the text a little and/or reconsider the font. I like this one quite a lot because it's both very elegant and discrete. I.e, it's not just Helvetica again, which would bring a special feeling to hackage, without being an intrusive font that drags the reader away from the content. But we could try Open Sans or Source Sans Pro, for example:

Current (Merriweather Sans)

hackage-after-big

Open Sans

open sans

Source Sans Pro

source sans pro

@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Dec 28, 2017

Btw, just in case you haven't seen this yet, there's also coloured blocks like e.g. at http://hackage.haskell.org/package/bad-package-example-0/candidate ... which design-wise may pose a challenge :-)

I'm not sure what you meant by "challenge" in this case. It looks alright to me:

screen shot 2017-12-28 at 12 38 25

What I don't like is to have the title in the header. It's a bad idea, imo, as its size is always different, which makes the header size unpredictable and ugly often enough. I'd rather move the title to the #content, and let it always be Hackage :: [Package] in the header.

What do you think?

@phadej

This comment has been minimized.

Contributor

phadej commented Jan 28, 2018

Can we have a screenshot of https://hackage.haskell.org/package/lens-4.16/docs/Control-Lens-Operators.html with new stylesheet. It feels that there is more vertical whitespace around/in code blocks, but I'm not sure how bad it is on pages having a lot of doctests and other code blocks?

@TikhonJelvis

This comment has been minimized.

TikhonJelvis commented Jan 28, 2018

Looks great. I think the extra whitespace is great—having shorter lines of text is much easier to read.

In the screenshots the purple text looks a bit low-contrast, but that might be because of how the images are resized. The full-size images look better. Might still be worth making the text a bit darker.

@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Jan 28, 2018

Can we have a screenshot of https://hackage.haskell.org/package/lens-4.16/docs/Control-Lens-Operators.html with new stylesheet. It feels that there is more vertical whitespace around/in code blocks, but I'm not sure how bad it is on pages having a lot of doctests and other code blocks? @phadej

There is an open PR on the haddock repository with the same changes proposed here. The page of your link will be affected by that PR, not this one. I will add the screenshot you ask for over there.

@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Jan 28, 2018

Might still be worth making the text a bit darker. @TikhonJelvis

Agreed. @hvr raised the same issue. I was using Merriweather Sans, which is a low-contrast font. I switched now to Open Sans, which improves that. I will post some more screenshots tomorrow.

Nit text color and size adjustments
- Make the body text darker and bigger
- Make links shades of purple instead of orange
- Adjust size of header links on smaller screens
@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Jan 29, 2018

I have made the text color darker and changed the link colors from shades of orange to shades of purple.

Here follow two samples:
hackage-home
monoid-extras

@gbaz

This comment has been minimized.

Contributor

gbaz commented Jan 29, 2018

We need to handle preferred/non-preferred/deprecated in whatever scheme is done, and update the documentation accordingly.

cf #373

and for the docs:

, paragraph << "Orange versions are normal versions. Green are those out of any preferred version ranges. Gray are deprecated."

Other than that, this is looking pretty good!

@cocreature

This comment has been minimized.

Contributor

cocreature commented Jan 29, 2018

We need to handle preferred/non-preferred/deprecated in whatever scheme is done, and update the documentation accordingly.

Let’s take this opportunity to switch to a color scheme that is intuitively understandable. Green should not signify “errors”.

@moodmosaic

This comment has been minimized.

moodmosaic commented Jan 30, 2018

The current stylesheet is more readable on mobile devices. I'm actually with @hvr here:

Why is it considered a good thing that the new stylesheet seems to waste space left/right on a mobile device? Wouldn't you rather want to exploit the little screen estate you have on a mobile device as much as possible?


I'd rather just apply the colors of the proposed stylesheet to the old one; and I'll leave the rest as-is.

@gbaz

This comment has been minimized.

Contributor

gbaz commented Jan 31, 2018

The mobile margins are tighter than the desktop margins, and seem sort of in-line with how other mobile-optimized sites tend to do it.

I like high information-density but I'm sympathetic towards moving more towards how "everyone else" does it with regards to mobile these days, which is emphasizing readability over density to a certain degree.

As a whole this is definitely an improvement, and I'd like to see the preferred/etc colors sorted out so we can move forward with a merge while we have good momentum here :-)

@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Jan 31, 2018

@moodmosaic

You might not have seen this part:

@NunoAlexandre Fwiw, I've given it a quick test-drive; it's not as bad as I thought when I make my windows smaller; there's a size at which the negative space suddenly snaps to a smaller amount, so i guess that's good enough :-)

In any case, that space can obviously be tweaked.

@media only screen and (min-width: 950px) {
#page-header {
text-align: left;
text-align: left;

This comment has been minimized.

@phadej

phadej Jan 31, 2018

Contributor

double?

}
#content {
width: 55vw;

This comment has been minimized.

@phadej

phadej Jan 31, 2018

Contributor

as this is narrow page, should that be closer to 100vw?

This comment has been minimized.

@NunoAlexandre

NunoAlexandre Feb 1, 2018

Contributor

Yes, close to, to keep a minimally acceptable margin.

}
#content {
width: 75vw;

This comment has been minimized.

@phadej

phadej Jan 31, 2018

Contributor

should we however have also max-width: 1200px or something like that? Some (accidentally) full screen pages on ridiculously large displays :)

This comment has been minimized.

@phadej

phadej Jan 31, 2018

Contributor

Also, imho we should have min-width which is at wide as narrow viewport close to the breakpoint. EDIT that will remove "snap" when resizing.

FWIW, Iphone7+ is 1920-by-1080-pixel resolution at 401 ppi, i.e. 960px virtual pixels in landscape, which is wide viewport (as the breakpoint is at 950px).

This comment has been minimized.

@NunoAlexandre

NunoAlexandre Feb 1, 2018

Contributor

I have added the max-width you suggested. Thanks!

I am not sure about the min-width though. Having a page that floats around as one scroll is annoying, and it doesn't really help reading it. Do you guys have analytics data about how many people use hackage using a small device?

@vagarenko

This comment has been minimized.

vagarenko commented Feb 1, 2018

@NunoAlexandre

changed the link colors from shades of orange to shades of purple

Personally, I don't like new colors. I think the current Hackage color scheme is perfect. It's high contrast and has ideal warm-cool color balance, unlike dull grey monochrome Stackage-like scheme you moving towards.

Compare

https://hackage.haskell.org/package/lens-4.16/docs/Control-Lens-Operators.html

https://www.stackage.org/haddock/lts-10.4/lens-4.15.4/Control-Lens-Operators.html

IMO, the Hackage version is a lot more readable and pleasant to work with.

NunoAlexandre added some commits Feb 1, 2018

Adjust responsive behaviour
- Have special sizes for small, medium and large screens.
- Now the space is further exploited in small screens.
- Set a max-width
Make package version color scheme intuitive
The current color scheme is untuitive. Also, add the class "versions" to
the element holding the list of versions of a given package, and add
the class "normal" to normal versions. This helps making the style more
specific and explicit, while being able to drop the "!important" flags.
@elben

This comment has been minimized.

elben commented Feb 1, 2018

@NunoAlexandre I appreciate the work you've set out to do here. Knowing the risks of "design feedback via committee", here are some of my observations:

  • I think we need to consider for two different needs and reading experiences. Some pages are intended for a thorough read (e.g. tutorials) where readability and flow is important. Others like Haddock pages are references where density is more important than readability.

  • So I don't think making things less-dense is a necessarily a good thing. I don't understand this design trend of massive negative space. It may be great for Medium articles, but not for every kind of material. I think it is the wrong approach to say "we need more negative space" (which may be valid), and apply it everywhere to this extent.

  • What's up with the low-contrast trend in web design? I can barely see the text. You can't imagine any published book having a such a low contrast ratio.

  • One thing I appreciate today about the Haddock pages is that I can see many functions at once on a single page. I can compare functions against each other, without having to massively scroll all over the page.

  • I think your line-height is a bit too much. Notice how awkward the breaks between lines and paragraphs are below. They are too-similarly spaced:

screen shot 2018-02-01 at 2 47 08 pm

@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Feb 1, 2018

Update


Adjust responsive behaviour
- Have special sizes for small, medium and large screens.
- Now the space is further exploited in small screens.
- Set a max-width

Screenshots - Iphone7s ![iphone7s](https://user-images.githubusercontent.com/7075260/35702681-0311aa6a-079a-11e8-96a7-b090ef78efc9.png)
  • iPad Pro
    ipadpro

  • Desktop
    desktop

  • Vertical (using i3wm)
    vertical



Make package version color scheme intuitive (see #648 (comment))
The current color scheme is untuitive. Also, add the class "versions" to
the element holding the list of versions of a given package, and add
the class "normal" to normal versions. This helps making the style more
specific and explicit, while being able to drop the "!important" flags.

Screenshot

colors

@gbaz

This comment has been minimized.

Contributor

gbaz commented Feb 1, 2018

This is really coming along! It seems the remaining issues around readability mainly involve haddocks rather than the core hackage pages. Perhaps it could be useful to pursue discussions regarding them on that PR? (haskell/haddock#721). I think just bumping contrast a bit on the purple headers could help a ton.

(btw do you have screenshots of the table-based results that come from the /browse page etc? It would be nice to see.)

@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Feb 1, 2018

Hi @elben, thank you for your words and for your constructive feedback.

I think we need to consider for two different needs and reading experiences. Some pages are intended for a thorough read (e.g. tutorials) where readability and flow is important. Others like Haddock pages are references where density is more important than readability.

I personally cannot recall a case where density was more important than readability, for I would not prefer to see more content at once and have a much harder time reading any of it. I might be wrong here, I am not dismissing your observation.

So I don't think making things less-dense is a necessarily a good thing. I don't understand this design trend of massive negative space. It may be great for Medium articles, but not for every kind of material. I think it is the wrong approach to say "we need more negative space" (which may be valid), and apply it everywhere to this extent.

Do you have an example of a material which is better read with a dense design than with a good negative space that you can show?

I am not with you on this one. I have minor studies in typography and (negative) space is fundamental, and a lot of the things you are not into or don't understand have been thoroughly studied and tested. You are obviously free to have your preference, but I am afraid your are not on the winning side of the discussion.

If your point is that I am using too much negative space now, I am open to improve it. But I'd rather have a first version deployed and see what the masses have to say and tweak accordingly, as now the majority seems to like it as I am proposing (which obviously doesn't mean it's right), and democracy rules.

What's up with the low-contrast trend on web design? I can barely see the text. You can't imagine any published book having a contrast ratio so light.

You can't really compare screens with books.
I agree there is an exageration of low-contrast overall on the web, but I don't see how that is the case here? I think an example of it is, actually, Stackage (which I prefer to look at than Hackage, FWIW), but - again - I can't see how that is a thing on this PR.

One thing I appreciate today about the Haddock pages is that I can see many functions at once on a single page. I can compare functions against each other, without having to massively scroll all over the page.

If what you want is to look at raw code, why not look at the source? It gives your all you need and extras. However, we can indeed think of some code-reading mode, but let's not go off-scope here.

I think your line-height is a bit too much. Notice how awkward the breaks between lines and paragraphs are below. They are too-similarly spaced:

I agree, thanks!

@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Feb 1, 2018

Hi @gbaz,

This is really coming along!
Cool, nice getting your feedback!

It seems the remaining issues around readability mainly involve haddocks rather than the core hackage pages. Perhaps it could be useful to pursue discussions regarding them on that PR? (haskell/haddock#721).

Correct. I have delayed working on haddock for 1) lack of time to work on both and 2) to avoid having to make the same changes in both places. Once we are done here I will move to there.

I think just bumping contrast a bit on the purple headers could help a ton.

Are you referring to the top header (menu) or to the headings (titles)?

(btw do you have screenshots of the table-based results that come from the /browse page etc? It would be nice to see.)

Sure, here it is:
table-hackage

@NunoAlexandre NunoAlexandre force-pushed the NunoAlexandre:master branch from adb0b04 to c078846 Feb 4, 2018

Address PR comments
- Improve the text line-length and distance between parapgraphs
- Darken heading colors and use the same color for page titles
- Add minimal space between tables rows and align th's better.

@NunoAlexandre NunoAlexandre force-pushed the NunoAlexandre:master branch from c078846 to 630e3ad Feb 4, 2018

@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Feb 4, 2018

Preview latest suggestions

Instead of posting screenshots, I have hosted the pages you guys have shown interest in seeing the latest suggestions here proposed.

You can find a list of links to them following the link below:
https://nunoalexandre.com/2018/02/04/redesigning-haskell-docs#preview

This allows anyone to preview and try it out! I will keep on updating it as we ago so it will always be updated.

@identicalsnowflake

This comment has been minimized.

identicalsnowflake commented Feb 5, 2018

You can fix the header spacing like this:

  • #page-header
    • Remove border-bottom
    • Set padding to 0.6em 0
  • #page-header ul.links
    • Set margin to 6px 2em 0 2em

This will put the same amount of space above and below the items in the header and align all the text to the same horizontal line.

@v0d1ch

This comment has been minimized.

v0d1ch commented Feb 5, 2018

Great work! The only thing that I think could be better is to use dropdown menu for small screens but I guess you are just changing the css, not adding any extra html elements.
Looks a lot nicer now IMO.

Fix page-header elements alignment
The page-header .caption and the menu links were not alignment.
This was caused by changing the font-weight and size of the caption.

@NunoAlexandre NunoAlexandre force-pushed the NunoAlexandre:master branch from 087db65 to ad4c463 Feb 5, 2018

Decrease space between code blocks
There was too much space between code blocks as pointed out by
reviewers.
@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Feb 5, 2018

@v0d1ch

Great work! The only thing that I think could be better is to use dropdown menu for small screens but I guess you are just changing the css, not adding any extra html elements.
Looks a lot nicer now IMO.

Thank you very much. That is a good suggestion, but I am trying to reduce html changes as much as possible in this PR. Maybe you can create an issue here about it? The scope for now is to have the menu looking acceptable and working in small devices, which is the case now.

@thumphries

This comment has been minimized.

thumphries commented Feb 5, 2018

Just wanted to chime in on the contrast. The purple text against grey or white background was quite hard for me to read, so I tested it for WCAG compliance and found it falls short of AAA readability by a couple of points: https://webaim.org/resources/contrastchecker/?fcolor=9C5791&bcolor=F6F6F6 https://webaim.org/resources/contrastchecker/?fcolor=9C5791&bcolor=FEFEFE

Darkening a few shades to achieve WCAG AAA readability might be worthwhile; it would certainly stop me from immediately installing custom CSS.

@v0d1ch

This comment has been minimized.

v0d1ch commented Feb 5, 2018

@NunoAlexandre

Maybe you can create an issue here about it?

will do

@scott-fleischman

This comment has been minimized.

scott-fleischman commented Feb 8, 2018

I like the direction this style is going.

One minor point: there's too much initial vertical space when expanding individual instances.

NunoAlexandre added some commits Feb 8, 2018

Address PR comments
- Fix issue with font size on landscape mode
- Make table of contents stick to the left
on wide screens
- Change color of table of contents
Improve information density
- Reduce font size
- Improve space between and within code blocks
- Improve alignments
- Improve spacing within sub-blocks
@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Feb 17, 2018

Update

I have addressed the many comments about information density by reducing the font-size a little and improving some spacing between elements.

@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Feb 17, 2018

Just wanted to chime in on the contrast. The purple text against grey or white background was quite hard for me to read, so I tested it for WCAG compliance and found it falls short of AAA readability by a couple of points:

I don't empathize with this but if you suggest alternative colors I am open to adjusting. I am not of the opinion that every single element or piece of information needs to have the highest level of contrast possible. Sometimes you just need them to be easily spotted, for example. I ran a few tests using color and contrast schemes used in some docs by Google and the whole thing fails altogether, while those are one of the most readable docs around.

@thumphries

This comment has been minimized.

thumphries commented Feb 17, 2018

if you suggest alternative colors I am open to adjusting

Moving those sliders until the contrast ratio hits 7 (AAA readability) produces #6F3E69 and #794470, both of which no longer hurt my eyes to read.

I am not of the opinion that every single element or piece of information needs to have the highest level of contrast possible.

Your opinion here shouldn't matter. Accessibility should not be optional for a widely used technical reference. Other sites may not comply, but we could do so at no cost.

@TikhonJelvis

This comment has been minimized.

TikhonJelvis commented Feb 17, 2018

Your opinion here shouldn't matter.

This is a brusque way of putting it, but the core idea is sound. WCAG gives us a set of simple, objective rules for making our system useful and comfortable for as many people as possible. With contrast in particular, the standards exist to keep text readable even for people who do not distinguish colors well.

Since we aren't experts in accessibility, the guidelines help us do a good job without needing to second-guess other organizations or to generalize from our own limited experiences.

...that every single element or piece of information needs to have the highest level of contrast possible.

To be clear, the contrast guidelines do not expect everything to have the same level of contrast. There are different levels for different text sizes, and even the AAA standards for text below 18 pt allows a wide range of contrasts. It just provides a minimum contrast level chosen to work for people with 20/80 visual acuity:

A user with 20/40 would thus require a contrast ratio of 3 * 1.5 = 4.5 to 1. Following analogous empirical findings and the same logic, the user with 20/80 visual acuity would require contrast of about 7:1.

(From WCAG.)

This still gives you enough flexibility as a designer to use contrast as part of the design—for bringing attention to specific elements, for example—while maintaining a minimum level that works well for a wide range of people.

@NunoAlexandre

This comment has been minimized.

Contributor

NunoAlexandre commented Feb 18, 2018

I have increased the contrast of the links. IMO, now it all looks almost black. I.e, the contrast between different things is low., while it was clear before How do you go about that, @thumphries and @TikhonJelvis? I do not want to put aesthetics before accessibility, but this seems a mix of both.

@fredefox

This comment has been minimized.

fredefox commented Feb 19, 2018

I agree that the contrast between the text and the background should be large enough to make the text legible - but the same should go for the contrast between normal text and link text. Links are virtually indistinguishable at the moment. Perhaps saturating the color and increasing the brightness could satisfy both requirements.

@gbaz

This comment has been minimized.

Contributor

gbaz commented Mar 16, 2018

I've got a branch here: https://github.com/haskell/hackage-server/tree/gb/stylesheet-mar18

It has a few more small changes on top, to resolve the remaining issues. It tightens some spacing around headers a bit more (and distributes it around paragraphs again, instead of putting it all at the top). Additionally, it fixes the header styles for the old (non-template) pages. It makes the links more contrasty again, and makes unvisited brighter and more saturated than visited, as is general practice. It lets the width of the browse tables grow as the page is increased. And finally, it fixes a bug where long package-descriptions could force the menu offscreen.

I feel this is mergable.

The drawback is that, if we merge now, then the haddocks will still take some time to catch-up, and in the meantime the styles will be nonuniform between haddocks and main hackage.

On the other hand, this has been underway for a few months, and it would be good to merge before momentum is lost. We can always continue to tweak styles later, so I see little downside.

Thoughts?

@TikhonJelvis

This comment has been minimized.

TikhonJelvis commented Mar 17, 2018

Merging this now is definitely a good idea, even if it leads to some temporary inconsistency in style. I don't see anything fundamentally blocking this change and changes end up dying after sitting too long as PRs all too often...

@gbaz

This comment has been minimized.

Contributor

gbaz commented Mar 18, 2018

Ok, good to see the sentiment. Closing this in favor of #693, which has all this plus further changes, as described above.

@gbaz gbaz closed this Mar 18, 2018

hvr added a commit that referenced this pull request Mar 18, 2018

Move title (synopsis+description) out of the navigation header
This was suggested in
#648 (comment) :

Paraphrasing from the comment: Having the title in the header is a bad
idea as its size is always different, which makes the header size
unpredictable and ugly often enough. Thus we move the title to the
content area (which also makes the title feel more associated with the
content), and let the navigation header always show the
`Hackage :: [Package]` caption across all of Hackage.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment