Just throwing an idea here based on vmarkelov's comment on reddit.

No thought on how to implement this yet. Still a lot to discuss

The Rising sort action would sort the repositories by how many stars they have gotten over the previous week/month.

For this to happen, the data needs to be collected. This will be done by vimcolorschemes-worker.

Once it has been done and enough data has been collected, the "rising" sort action can be implemented on the app.

Assuming the issues below have been resolved:

• vimcolorschemes/worker#23
• vimcolorschemes/worker#24
• vimcolorschemes/worker#25

Definition of done
User can click on a sort button that brings him to the /updated/asc/ or /updated/desc (or something like that) urls.

Google should not present page/2 in its results.

To implement

?

To confirm

• <meta name="robots" content="noindex, nofollow" /> should be present on non first pages.

Not do do

• next and prev tags should be used in the pagination component links or in header.

Original title and idea: Use more inclusive language on sort buttons

"Least popular" feels rough.

Could create toggle buttons for asc and desc instead of having both a sort asc and a sort desc button.

Will also leave space for potential filter buttons.

Description

There is no easy of determining with absolute certainty if a color scheme is mainly dark, light, or has both options by parsing the readme.

The words "light" and "dark" could be searched for, but I am not sure the results would be incredibly accurate.

I guess it needs to be tried out.

UPDATE: Since we now fetch and parse the vim files of a repository to verify that it's a color scheme, we can verify with precision if light, dark, or both backgrounds are available.

UPDATE 2: With v2.0 available, it is now possible to look in the vimColorSchemes field of a repository to search for dark or light repositories.

useNavigation has its complexities, and it would benefit from living in its own package.

Would be easier to make it evolve, build tests for it, etc.

Description

I've noticed in iPadOS that when a sub-image is focused on a repository page, the page doesn't scroll so that the focused element is in the viewport.

If there's anything the app can do to enforce the scrolling, it should be done.

The landing page will be a point of entry for the various instances of the app. (vim, vscode, iterm2, ...)

• It should have the same navigation as the app.
  • Maybe the useNavigation hook should have its own package and live independently?
• It should have the same look and feel as the app
  • Take note of the variables used in the app styling, and use them

Describe the bug
According to w3c, element <div /> is not allowed as child of element <a />. In the Card component, The RepositoryTitle component inside the <Link /> tag uses <div /> as a wrapper.

The website is currently using an svg as a favicon and it is not squared.

A favicon could easily be generated from the current image instead.

• 1 main image
• 6 secondary images for a mosaic/carousel

Description

The repositories that don't have any image should have a minimal placeholder image for now.

Describe the solution you'd like

• Pressing / focuses on the search input
• At build time, the whole search index is upload to an elasticsearch instance
• The previous elasticsearch index is removed
• The frontend search is made through a node.js proxy APl piping requests to the elasticsearch instance

Definition of done

• Be as descriptive as possible

Expected behavior
The site title should have vimcolorschemes at the end.

Screenshots

• S3less setup for dev ✔️
• More verbose on confusing stuff ✔️
• Limit env variable ✔️
• More readable handling of rate limit ✔️

Currently, the page meta description is always the same on all pages.

I think it would make sense to use the repository's description as the page meta description for all repositories pages.

Definition of done

• Be hosted on a service like AWS Lambda
• Run everyday

Since the project was open-sourced, and more people might contribute, I think it would benefit from having automatic linting

When the tab key is used while an image is zoomed in, the focused image changes, and the image is never zoomed out.

Definition of done

• Be as descriptive as possible

Definition of done

• Provide a short description of the project and its motive
• Provide documentation to help repository displaying their stuff on the app

Card images don't need a min-height that big on mobile.

Note: beware of cards with no images

Some repositories have their first image a logo that doesn't display code, so I need a way to choose myself their featured image.

Some others are collections of already existing colorschemes. These I would need to filter out.

I'm open to ideas, but I need a way to do these changes myself in the data.

Describe the bug
While on the home page (/), following the footer logo link with the keyboard will scroll the page to the top, but will not reset the current tab index.

The next key presses will start from the bottom while the user is seeing the top of the page.

To Reproduce

1. Go to vimcolorschemes.com
2. Press j or arrow down until the footer logo link is focused.
3. Press enter
4. Notice the page scrolled to the top.
5. Press j and notice nothing happened.
6. Press k and notice the focus was still on the footer logo link.

Expected behavior
Following the footer logo link will reset the current tab index to the top.

Screenshots

Additional context
Tested on macOS on Google Chrome.

When using the keyboard to navigate, the mouse just laying over the screen often triggers an unnecessary hover effect on links.

It should be implemented only if it's possible and not too hacky.

A possible direction would be to use the document.body.style.pointerEvents property to disable styles for a small amount of time when a key is pressed. Reactivate them after x time.

Describe the bug
Most sorted pages do not reflect the chosen sort.

To Reproduce
https://vimcolorschemes.com/updated/desc/ does not show repositories in the right order.

Description

• Short project presentation
• Deployments states
• Links to the wiki for contribution guide

I think the repository page could have more info while staying minimal.

Info such as stargazers count, last commit date, create date, etc. could appear there.

Netlify is good for now, as the app stays in the free tier.
If builds are daily and are > 10 minutes long, we'll need a pro account.

Anything really, as long as I can make the CI good enough.

Requirements:

• .dev builds from staging branch
• .com builds from master branch
• App builds from ./app and the command is gatsby build
• gatsby-cli needs to be installed on the machine

https://vimcolorschemes/2 is not a clear way of defining paginated pages.

/page/2 is much clearer.

For non-default sorted pages, /updated/desc/page/2 should be used.

Definition of done
User can click on a sort button that brings him to the /created/asc/ or /created/desc (or something like that) urls.

Going to the repository's GitHub page is an important action. The link should be more visible.

Is your feature request related to a problem? Please describe.
Pretty much only the title and images are present on the repository page.

Describe the solution you'd like
The repository page could benefit from a nice header with the info that the card already has.

Definition of done
User can click on a filter button that brings him to the /dark (or something like that) url.

Definition of done
It needs to include more all words related to vim color schemes. (Examples of missing terms: theme, colorschemes)

Make sure no repositories are left out. (Example of left out repo: Spacecamp)

Observations:

• Making a change in development mode triggers the build (and the thumbnail generating) from Gatsby and it fixes it.
• Happens more with a lot of images

Description

The position and spacing are not quite right on mobile.
The current page indicator should be positioned in the center.

When only next page link is present

When both previous and next page links are present

Description

• Instructions on how to run the project locally
  • with script
  • without script

Describe the bug
When using a certain ratio of window (ex: macOS 16:10), a card that is focused gets its link text in the middle of the screen, resulting in the image being cut off by the top of the window.

Expected behavior
The middle of the card should be focused, resulting in as much of the card being displayed on the window.

Screenshots

More info

I set the link's position to absolute top to confirm my suspicious:

The element in the center of the screen when the card is focused is indeed the a element, which is around the repository title for accessibility reasons.

How to fix

Just throwing ideas here, more research is needed.

• Hidden link at position absolute center of the card.
• scroll back like 100 pixels when focusing on a card.
• use ::before pseudo-element with a negative margin-top

A quick test shows that the 3rd option works well.

.card__title > a:before {
  display: block; 
  content: " "; 
  margin-top: -80px;
  height: 80px; 
  visibility: hidden; 
  pointer-events: none;
}

Maybe the height of the card could be calculated in order to focus on the center of the card.

Is your feature request related to a problem? Please describe.
Since no such info is available, one is forced to visit the GitHub page and parse it.

Describe the solution you'd like
The most common ways to install a color scheme could be listed below the main image.
They would be focusable and "yankable" by pressing y.

Ex.:

Plug 'github/url.vim'
colorscheme name

Plugin 'github/url.vim'
colorscheme name

Since some of them have multiple color scheme names, we can list those as well.

Definition of done
User can click on a sort button that brings him to the /stars/asc/ or /stars/desc (or something like that) urls.