Revamp website with new UI #40

Closed
opened 2026-02-17 11:36:49 -06:00 by GiteaMirror · 38 comments
Owner

Originally created by @damianopetrungaro on GitHub (Aug 20, 2018).

Originally assigned to: @zeke, @jameswomack, @nexdrew, @stevemao, @hutson on GitHub.

What do you think about revamping the UI of the website with a new theme (and\or new tool for generating the static website)?

We can make it as cool as keep a changelog so that more people will read it because it looks good

Originally created by @damianopetrungaro on GitHub (Aug 20, 2018). Originally assigned to: @zeke, @jameswomack, @nexdrew, @stevemao, @hutson on GitHub. What do you think about revamping the UI of the website with a new theme (and\or new tool for generating the static website)? We can make it as cool as [keep a changelog](http://keepachangelog.com/en/1.0.0/) so that more people will read it because it looks good
Author
Owner

@damianopetrungaro commented on GitHub (Aug 20, 2018):

Looking for sth like this: https://themes.gohugo.io/theme/hugo-icon/

@damianopetrungaro commented on GitHub (Aug 20, 2018): Looking for sth like this: https://themes.gohugo.io/theme/hugo-icon/
Author
Owner

@hutson commented on GitHub (Aug 20, 2018):

I have no particular preference for a theme, though I am fine with y'all going with a new theme.

My only request is that the following be taken into consideration:

  • The theme should be web accessible.
  • The tool needed to generate a website from a them should be low friction.
  • The theme should emphasize the content of the standard (and not detract from it with flashy graphics or other, unrelated content)
@hutson commented on GitHub (Aug 20, 2018): I have no particular preference for a theme, though I am fine with y'all going with a new theme. My only request is that the following be taken into consideration: - The theme should be [web accessible](https://www.w3.org/WAI/fundamentals/accessibility-intro/). - The tool needed to generate a website from a them should be low friction. - The theme should emphasize the content of the standard (and not detract from it with flashy graphics or other, unrelated content)
Author
Owner

@damianopetrungaro commented on GitHub (Aug 20, 2018):

Yeah sure, I was thinking to use hugo because it has more themes (and it's also faster to compile and reload changes, but this is not a big deal for this project).

Feel free to suggest any theme for any tool you like and of course match what @hbetts recommend.

@damianopetrungaro commented on GitHub (Aug 20, 2018): Yeah sure, I was thinking to use `hugo` because it has more themes (and it's also faster to compile and reload changes, but this is not a big deal for this project). Feel free to suggest any theme for any tool you like and of course match what @hbetts recommend.
Author
Owner

@damianopetrungaro commented on GitHub (Aug 20, 2018):

example

Generated using a file like this

Powered by Hugo and hugo-theme-sarah
Of course, I still need to change some colors, links add images etc. etc. but this one looks better IMHO.

Let me know about it ;)

@damianopetrungaro commented on GitHub (Aug 20, 2018): ![example](https://user-images.githubusercontent.com/8950503/44368808-65a2f300-a4d4-11e8-82ed-cc6ded140bf8.gif) Generated using a file [like this](https://gist.github.com/damianopetrungaro/902091136592514750be4f6003f67bbf) Powered by Hugo and [hugo-theme-sarah](https://github.com/avelino/hugo-theme-sarah) Of course, I still need to change some colors, links add images etc. etc. but this one looks better IMHO. Let me know about it ;)
Author
Owner

@hutson commented on GitHub (Aug 21, 2018):

It looks fine to me.

@hutson commented on GitHub (Aug 21, 2018): It looks fine to me.
Author
Owner

@damianopetrungaro commented on GitHub (Aug 21, 2018):

Please, @conventional-commits/committee give me a feedback so I will put some effort if all of you are fine with it ;)

@damianopetrungaro commented on GitHub (Aug 21, 2018): Please, @conventional-commits/committee give me a feedback so I will put some effort if all of you are fine with it ;)
Author
Owner

@damianopetrungaro commented on GitHub (Aug 21, 2018):

I got some free time at home and i designed those two things.

If we are going to implement a custom design we need someonw who will write HTML and CSS ( i never wrote it so i need external help)

Feedbacks appriciated:

screen shot 2018-08-21 at 11 31 17 pm screen shot 2018-08-21 at 11 32 00 pm
@damianopetrungaro commented on GitHub (Aug 21, 2018): I got some free time at home and i designed those two things. If we are going to implement a custom design we need someonw who will write HTML and CSS ( i never wrote it so i need external help) Feedbacks appriciated: <img width="882" alt="screen shot 2018-08-21 at 11 31 17 pm" src="https://user-images.githubusercontent.com/8950503/44430408-e0364600-a59a-11e8-8198-af994b9a2f0b.png"> <img width="881" alt="screen shot 2018-08-21 at 11 32 00 pm" src="https://user-images.githubusercontent.com/8950503/44430409-e0364600-a59a-11e8-9a26-222acde0c92f.png">
Author
Owner

@hutson commented on GitHub (Aug 21, 2018):

If we are going to implement a custom design we need someonw who will write HTML and CSS

For that reason I would prefer if we limited how much customization we do. Unless we can find two or more people that are able and willing to dedicate the time to being our HTML/CSS contributors.

As for the designs in your latest commit, I think they look great. My only suggestion would be to increase the font size so that the text is easier to read.

@hutson commented on GitHub (Aug 21, 2018): > If we are going to implement a custom design we need someonw who will write HTML and CSS For that reason I would prefer if we limited how _much_ customization we do. Unless we can find two or more people that are able and willing to dedicate the time to being our HTML/CSS contributors. As for the designs in your latest commit, I think they look great. My only suggestion would be to increase the font size so that the text is easier to read.
Author
Owner

@damianopetrungaro commented on GitHub (Aug 21, 2018):

Already done ;)

As for the designs in your latest commit, I think they look great. My only suggestion would be to increase the font size so that the text is easier to read.

This will be one very simple page so the effort won't be huge.
If someone is free to spend some time coding it would be great!

For that reason I would prefer if we limited how much customization we do. Unless we can find two or more people that are able and willing to dedicate the time to being our HTML/CSS contributors.

@damianopetrungaro commented on GitHub (Aug 21, 2018): Already done ;) > As for the designs in your latest commit, I think they look great. My only suggestion would be to increase the font size so that the text is easier to read. This will be one very simple page so the effort won't be huge. If someone is free to spend some time coding it would be great! > For that reason I would prefer if we limited how much customization we do. Unless we can find two or more people that are able and willing to dedicate the time to being our HTML/CSS contributors.
Author
Owner

@damianopetrungaro commented on GitHub (Aug 21, 2018):

Found someone who has some free time next week!

@lorenzodianni is the best js developer I have ever known and he uses the conventional commits for months!

He'd be happy to take care of the HTML/CSS page.
And it would be great also having your feedback about the design and the project itself!

@damianopetrungaro commented on GitHub (Aug 21, 2018): Found someone who has some free time next week! @lorenzodianni is the best js developer I have ever known and he uses the conventional commits for months! He'd be happy to take care of the HTML/CSS page. And it would be great also having your feedback about the design and the project itself!
Author
Owner

@zeke commented on GitHub (Aug 21, 2018):

Wow really cool to see this design work, @damianopetrungaro 🎨

new tool for generating the static website)?

I haven't used hugo, though I know it's popular and active. I wouldn't be opposed to this if you want to take the initiative, @damianopetrungaro 👍

That said, when pondering how I personally would revamp the existing site, I imagined using Node.js (rather than Ruby or Go) and a set of of "small sharp modules" like:

The above tools could be used to generate a static site and/or a dynamic server-rendered site.

@zeke commented on GitHub (Aug 21, 2018): Wow really cool to see this design work, @damianopetrungaro 🎨 > new tool for generating the static website)? I haven't used [hugo](https://gohugo.io/), though I know it's popular and active. I wouldn't be opposed to this if you want to take the initiative, @damianopetrungaro 👍 That said, when pondering how I personally would revamp the existing site, I imagined using Node.js (rather than Ruby or Go) and a set of of "[small sharp modules](https://gist.github.com/adamwiggins/5687294#small-sharp-tools)" like: - https://ghub.io/hubdown to convert markdown into GitHub-style HTML - https://ghub.io/github-markdown-css to style that HTML - https://ghub.io/nanohtml to wrap pages in a layout. The above tools could be used to generate a static site and/or a dynamic server-rendered site.
Author
Owner

@damianopetrungaro commented on GitHub (Aug 21, 2018):

I chose Hugo for the great doc and the super active support.

That said, when pondering how I personally would revamp the existing site, I imagined using Node.js (rather than Ruby or Go) and a set of of "small sharp modules" like:

https://ghub.io/hubdown to convert markdown into GitHub-style HTML
https://ghub.io/github-markdown-css to style that HTML
https://ghub.io/nanohtml to wrap pages in a layout.
The above tools could be used to generate a static site and/or a dynamic server-rendered site.

@damianopetrungaro commented on GitHub (Aug 21, 2018): I chose Hugo for the great doc and the super active support. > That said, when pondering how I personally would revamp the existing site, I imagined using Node.js (rather than Ruby or Go) and a set of of "small sharp modules" like: https://ghub.io/hubdown to convert markdown into GitHub-style HTML https://ghub.io/github-markdown-css to style that HTML https://ghub.io/nanohtml to wrap pages in a layout. The above tools could be used to generate a static site and/or a dynamic server-rendered site.
Author
Owner

@bcoe commented on GitHub (Aug 22, 2018):

@zeke @damianopetrungaro I like the direction we're going in, but I don't love that I need to click a button to start reading the spec, it seems like the page you land on is a bit barren.

Maybe the tldr; description of the specification could be above the fold, and then we dig into it deeper as you scroll down the page.

With this new design, the actual specification itself will still be in markdown?

@bcoe commented on GitHub (Aug 22, 2018): @zeke @damianopetrungaro I like the direction we're going in, but I don't love that I need to click a button to start reading the spec, it seems like the page you land on is a bit barren. Maybe the tldr; description of the specification could be above the fold, and then we dig into it deeper as you scroll down the page. With this new design, the actual specification itself will still be in markdown?
Author
Owner

@damianopetrungaro commented on GitHub (Aug 22, 2018):

@bcoe the idea is to scroll and read the spec, what I posted is just the first section the users will see.

Maybe the tldr; description of the specification could be above the fold, and then we dig into it deeper as you scroll down the page.

It depends if we wanna change it, I already linked an example of how the doc could be changed so.
But if we don't want to move from markdown, we won't.
The new design will just be a UI improvement.

With this new design, the actual specification itself will still be in markdown?

@damianopetrungaro commented on GitHub (Aug 22, 2018): @bcoe the idea is to scroll and read the spec, what I posted is just the first section the users will see. >Maybe the tldr; description of the specification could be above the fold, and then we dig into it deeper as you scroll down the page. It depends if we wanna change it, I already linked an example of how the doc could be changed so. But if we don't want to move from markdown, we won't. The new design will just be a UI improvement. > With this new design, the actual specification itself will still be in markdown?
Author
Owner

@zeke commented on GitHub (Aug 22, 2018):

the actual specification itself will still be in markdown?

Yes please! The layout and design should be kept separate from the spec, for ease of editing, portability, and translatability.

@zeke commented on GitHub (Aug 22, 2018): > the actual specification itself will still be in markdown? Yes please! The layout and design should be kept separate from the spec, for ease of editing, portability, and translatability.
Author
Owner

@damianopetrungaro commented on GitHub (Aug 22, 2018):

Yup, this is what exactly I am working on 😄

@damianopetrungaro commented on GitHub (Aug 22, 2018): Yup, this is what exactly I am working on 😄
Author
Owner

@damianopetrungaro commented on GitHub (Aug 22, 2018):

@zeke I've done a small test on how it may look like.

https://github.com/damianopetrungaro/_hugotest
https://github.com/damianopetrungaro/_hugotest/blob/master/content/beta0.0.3/index.md

Quick explanation:

{{< welcome >}}
will load the first section (the one with the nice UI linked ⬆️ )

{{% white-partial %}}...{{% white-partial %}}
will inject the markdown defined in the two shortcodes in some HTML defined in the theme (see here)

We may also avoid using the white-partial and color-partial using some CSS.
But I am not a FE developer, so in the doubt, I've put it there, I am quite sure @lorenzodianni will help us to remove those two elements too 😄

@damianopetrungaro commented on GitHub (Aug 22, 2018): @zeke I've done a small test on how it may look like. https://github.com/damianopetrungaro/_hugotest https://github.com/damianopetrungaro/_hugotest/blob/master/content/beta0.0.3/index.md Quick explanation: `{{< welcome >}}` will load the first section (the one with the nice UI linked ⬆️ ) `{{% white-partial %}}...{{% white-partial %}}` will inject the markdown defined in the two shortcodes in some HTML defined in the theme ([see here](https://github.com/damianopetrungaro/_hugotest/tree/master/themes/conventional-commits/layouts/shortcodes)) We may also avoid using the `white-partial` and `color-partial` using some CSS. But I am not a FE developer, so in the doubt, I've put it there, I am quite sure @lorenzodianni will help us to remove those two elements too 😄
Author
Owner

@damianopetrungaro commented on GitHub (Aug 26, 2018):

Conventional Commits.pdf

There are missing only the images/icons/sth to put in the middle of the page.
This is a good version of the UI.

Differences between link size will be fixed on code side.
Please send all of your opinions and which color you do prefer!

@damianopetrungaro commented on GitHub (Aug 26, 2018): [Conventional Commits.pdf](https://github.com/conventional-commits/conventionalcommits.org/files/2321134/Conventional.Commits.pdf) There are missing only the images/icons/sth to put in the middle of the page. This is a good version of the UI. Differences between link size will be fixed on code side. Please send all of your opinions and which color you do prefer!
Author
Owner

@damianopetrungaro commented on GitHub (Aug 26, 2018):

btw, we may also use the simple logo I put on the PDF as main one, is super simple and imho represent the pureness of a clean conventional commit

@damianopetrungaro commented on GitHub (Aug 26, 2018): btw, we may also use the simple logo I put on the PDF as main one, is super simple and imho represent the pureness of a clean conventional commit
Author
Owner

@hutson commented on GitHub (Aug 26, 2018):

Purely my two cents based on my aesthetics preferences:

  1. The second color palette looks to washed out.
  2. The commit message structure in the Summary section, and the examples in the Examples section need the be more distinguished (They kind of blend in with the surrounding text).
  3. The second Specification section needs to be called FAQ or Frequency Asked Questiones.
  4. Why are there two Read the Spec buttons at the top?
@hutson commented on GitHub (Aug 26, 2018): Purely my _two cents_ based on my aesthetics preferences: 1. The second color palette looks to washed out. 2. The commit message structure in the _Summary_ section, and the examples in the _Examples_ section need the be more distinguished (They kind of blend in with the surrounding text). 3. The second _Specification_ section needs to be called _FAQ_ or _Frequency Asked Questiones_. 4. Why are there two _Read the Spec_ buttons at the top?
Author
Owner

@damianopetrungaro commented on GitHub (Aug 26, 2018):

  1. If you don't like it we won't use that one :)
  2. I was thinking to use a code block there
  3. Yep, my bad
  4. One is the default one, the other one the mouse over :)
@damianopetrungaro commented on GitHub (Aug 26, 2018): 1. If you don't like it we won't use that one :) 2. I was thinking to use a code block there 3. Yep, my bad 4. One is the default one, the other one the mouse over :)
Author
Owner

@damianopetrungaro commented on GitHub (Aug 27, 2018):

If no one has nothing to add on this I'll ask to @lorenzodianni to start working on CSS and HTML

@damianopetrungaro commented on GitHub (Aug 27, 2018): If no one has nothing to add on this I'll ask to @lorenzodianni to start working on CSS and HTML
Author
Owner

@bcoe commented on GitHub (Aug 27, 2018):

@damianopetrungaro I'm really happy with how this is looking.

@bcoe commented on GitHub (Aug 27, 2018): @damianopetrungaro I'm really happy with how this is looking.
Author
Owner

@lorenzodianni commented on GitHub (Aug 27, 2018):

Hi to everyone!
@damianopetrungaro send me all info about the new style, i'll work on it asap! 🕺

@lorenzodianni commented on GitHub (Aug 27, 2018): Hi to everyone! @damianopetrungaro send me all info about the new style, i'll work on it asap! 🕺
Author
Owner

@damianopetrungaro commented on GitHub (Aug 27, 2018):

Sure 💪

@damianopetrungaro commented on GitHub (Aug 27, 2018): Sure 💪
Author
Owner

@damianopetrungaro commented on GitHub (Sep 4, 2018):

Thanks to the great effort and the great work that @lorenzodianni put into it, we are proud to announce the first demo of the UI revamp!

https://conventional-commits-test.netlify.com/en/v1.0.0-beta.2/

@hbetts @zeke @bcoe
There are still a couple of things to optimize (like the redirects and the anchor link to the specs), but this will be super close to the final version!
Any feedback is welcome!

Code here https://github.com/damianopetrungaro/_hugotest

@damianopetrungaro commented on GitHub (Sep 4, 2018): Thanks to the great effort and the great work that @lorenzodianni put into it, we are proud to announce the first demo of the UI revamp! https://conventional-commits-test.netlify.com/en/v1.0.0-beta.2/ @hbetts @zeke @bcoe There are still a couple of things to optimize (like the redirects and the anchor link to the specs), but this will be super close to the final version! Any feedback is welcome! Code here https://github.com/damianopetrungaro/_hugotest
Author
Owner

@damianopetrungaro commented on GitHub (Sep 4, 2018):

FYI:
We'll have for free (0 configurations and 0$) CD on Pull Request thanks to netlify

I asked them if we may also have a free pro account so that it will not belong only to me but to all the admins 😄

I'll keep you updated 😄

@damianopetrungaro commented on GitHub (Sep 4, 2018): FYI: We'll have for free (0 configurations and 0$) CD on Pull Request thanks to [netlify](http://netlify.com/) I asked them if we may also have a free pro account so that it will not belong only to me but to all the admins 😄 I'll keep you updated 😄
Author
Owner

@hutson commented on GitHub (Sep 4, 2018):

Three things I came across:

First, the drop-down for Versions is really difficult for me to use. Hovering over a version for more than a second causes the menu to vanish. (Using latest Firefox)

Second, the title looks cutoff for the specification:

screenshot_20180904_091235

^ That's what I see at the very bottom of my screen when I first load the page.

Instead of just saying GitHub, I feel like changing it to Contribute may help encourage our community to take a more active role in the development of this specification.

@hutson commented on GitHub (Sep 4, 2018): Three things I came across: First, the drop-down for _Versions_ is really difficult for me to use. Hovering over a version for more than a second causes the menu to vanish. (Using latest Firefox) Second, the title looks cutoff for the specification: ![screenshot_20180904_091235](https://user-images.githubusercontent.com/6701030/45036761-faecce00-b022-11e8-903f-d710b611cccd.png) ^ That's what I see at the very bottom of my screen when I first load the page. Instead of just saying _GitHub_, I feel like changing it to _Contribute_ may help encourage our community to take a more active role in the development of this specification.
Author
Owner

@hutson commented on GitHub (Sep 4, 2018):

It should be said, though, that I really do like the website. Contrast feels pretty good. It's easy to scroll through and find content. Branding is really starting to take shape.

👍

@hutson commented on GitHub (Sep 4, 2018): It should be said, though, that I really do like the website. Contrast feels pretty good. It's easy to scroll through and find content. Branding is really starting to take shape. :+1:
Author
Owner

@damianopetrungaro commented on GitHub (Sep 4, 2018):

Sure!

Instead of just saying GitHub, I feel like changing it to Contribute may help encourage our community to take a more active role in the development of this specification.

@lorenzodianni let's fix that https://github.com/conventional-commits/conventionalcommits.org/issues/81#issuecomment-418383793

@damianopetrungaro commented on GitHub (Sep 4, 2018): Sure! > Instead of just saying GitHub, I feel like changing it to Contribute may help encourage our community to take a more active role in the development of this specification. @lorenzodianni let's fix that https://github.com/conventional-commits/conventionalcommits.org/issues/81#issuecomment-418383793
Author
Owner

@damianopetrungaro commented on GitHub (Sep 4, 2018):

@hbetts i am not a frontend dev, but doesn't the content shown at the very bottom of the screen when the page is loaded depends on the screen size?

@damianopetrungaro commented on GitHub (Sep 4, 2018): @hbetts i am not a frontend dev, but doesn't the content shown at the very bottom of the screen when the page is loaded depends on the screen size?
Author
Owner

@bcoe commented on GitHub (Sep 4, 2018):

@damianopetrungaro this is looking really good 👍 a couple minor nits:

  • the drop down menu for versions feels a little disjoint from what it's dropping down from, I think an arrow pointing towards the link it's dropping down from could help with this, like this:

      <img width="233" alt="screen shot 2018-09-04 at 2 18 36 pm" src="https://user-images.githubusercontent.com/194609/45058416-824f3700-b04d-11e8-8141-93ebfc6b3f6c.png">
    
  • clicking the "Read the Specs" link didn't do anything.

  • we need to word smith a better introduction sentence, off the top of my head:

    write conventional commit messages, doing so allows you to: convey meaning to your users, automate semantic versioning, generate beautiful human-readable CHANNGELOGs.

☝️ this is pretty clunky, but I think a paragraph that calls out some of the reasons why I'd benefit from writing conventional commit messages would be good.

@bcoe commented on GitHub (Sep 4, 2018): @damianopetrungaro this is looking really good 👍 a couple minor nits: * the drop down menu for versions feels a little disjoint from what it's dropping down from, I think an arrow pointing towards the link it's dropping down from could help with this, like this: <img width="233" alt="screen shot 2018-09-04 at 2 18 36 pm" src="https://user-images.githubusercontent.com/194609/45058416-824f3700-b04d-11e8-8141-93ebfc6b3f6c.png"> * clicking the "Read the Specs" link didn't do anything. * we need to word smith a better introduction sentence, off the top of my head: > write conventional commit messages, doing so allows you to: convey meaning to your users, automate semantic versioning, generate beautiful human-readable CHANNGELOGs. ☝️ this is pretty clunky, but I think a paragraph that calls out some of the reasons why I'd benefit from writing conventional commit messages would be good.
Author
Owner

@damianopetrungaro commented on GitHub (Sep 5, 2018):

@bcoe

Do you think adding an arrow would be better?
We can try to add it and see how it looks.

the drop down menu for versions feels a little disjoint from what it's dropping down from, I think an arrow pointing towards the link it's dropping down from could help with this, like this:

About the second point is sth that will be fixed when migrating properly, this is just a test, and as I said it's sth we need to add.

clicking the "Read the Specs" link didn't do anything.

about this:

we need to word smith a better introduction sentence, off the top of my head:

For me it's fine, but it needs to be short, there's already a summary section we don't need t to create it also there 😄

@damianopetrungaro commented on GitHub (Sep 5, 2018): @bcoe Do you think adding an arrow would be better? We can try to add it and see how it looks. > the drop down menu for versions feels a little disjoint from what it's dropping down from, I think an arrow pointing towards the link it's dropping down from could help with this, like this: About the second point is sth that will be fixed when migrating properly, this is just a test, and as I said it's sth we need to add. > clicking the "Read the Specs" link didn't do anything. about this: > we need to word smith a better introduction sentence, off the top of my head: For me it's fine, but it needs to be short, there's already a summary section we don't need t to create it also there 😄
Author
Owner

@damianopetrungaro commented on GitHub (Sep 5, 2018):

I am also super proud to announce that netlify gave us a special pro plan for free!

We'll be able to add more than collaborators to our team, and enjoy a free CD for each new PR and branch!

I'd like to add them in the README when the new UI we'll go live!

@conventional-commits/committee Please send me your email in the private team and I'll add you on the netlify platform!

@damianopetrungaro commented on GitHub (Sep 5, 2018): **I am also super proud to announce that [netlify](https://netlify.com) gave us a special pro plan for free!** We'll be able to add more than collaborators to our team, and enjoy a free CD for each new PR and branch! I'd like to add them in the README when the new UI we'll go live! @conventional-commits/committee Please send me your email in the private team and I'll add you on the netlify platform!
Author
Owner

@lorenzodianni commented on GitHub (Sep 5, 2018):

@bcoe what do you think about this arrow?
schermata 2018-09-05 alle 22 28 25


@hbetts about specification title:
the gradient section has always 100% viewport height and the article section has a negative translationY (so the article moves up).
Do you think it's better to move it higher or to move it under the gradient section? (we will see the article only after scroll)

@lorenzodianni commented on GitHub (Sep 5, 2018): @bcoe what do you think about this arrow? <img width="138" alt="schermata 2018-09-05 alle 22 28 25" src="https://user-images.githubusercontent.com/7217805/45119315-66d25200-b15b-11e8-8639-929076bdf2d4.png"> ___ @hbetts about specification title: the gradient section has always 100% viewport height and the article section has a negative translationY (so the article moves up). Do you think it's better to move it higher or to move it under the gradient section? (we will see the article only after scroll)
Author
Owner

@damianopetrungaro commented on GitHub (Sep 5, 2018):

@lorenzodianni IMHO see the article only after scrolling is the best solution (maybe it looks better too)

@damianopetrungaro commented on GitHub (Sep 5, 2018): @lorenzodianni IMHO see the article only after scrolling is the best solution (maybe it looks better too)
Author
Owner

@hutson commented on GitHub (Sep 5, 2018):

negative translationY (so the article moves up).

Thank you for the explanation! 👍

Do you think it's better to move it higher or to move it under the gradient section?

That's a really tough one.

I moved the content up using -95px and it feels like it's crowding the content on the splash page. Also, it seems a little redundant (The title of the splash page, and the title of the article both say Conventional Commits).

Moving the content down looks nicer, but it's not apparent that you can scroll down to read additional content.

Any thoughts on that later point?

@hutson commented on GitHub (Sep 5, 2018): > negative translationY (so the article moves up). Thank you for the explanation! 👍 > Do you think it's better to move it higher or to move it under the gradient section? That's a really tough one. I moved the content up using -95px and it feels like it's crowding the content on the splash page. Also, it seems a little redundant (The title of the splash page, and the title of the article both say _Conventional Commits_). Moving the content down looks nicer, but it's not apparent that you can scroll down to read additional content. Any thoughts on that later point?
Author
Owner

@damianopetrungaro commented on GitHub (Sep 11, 2018):

All the changes have been applied.
See that I have no more feedbacks I'll open a PR today, and pair with @bcoe to transfer the domain to Netlify.

fyi: offical version

@damianopetrungaro commented on GitHub (Sep 11, 2018): All the changes have been applied. See that I have no more feedbacks I'll open a PR today, and pair with @bcoe to transfer the domain to Netlify. fyi: [offical version](https://conventional-commits-test.netlify.com/en/v1.0.0-beta.2/)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#40