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

Already on GitHub? Sign in to your account

Refactor wallet listings and categories into individual web pages #1661

Closed
wbnns opened this Issue Jul 4, 2017 · 14 comments

Comments

Projects
None yet
4 participants
Contributor

wbnns commented Jul 4, 2017 edited

Bounty: 190,000 bits / ~$500 USD

Last month (June 2017) the wallets page was one of our most viewed pages, with over 800,000 page views.

Currently on the wallets page, information about each wallet only appears via a popup overlay when touched or clicked. As a result, this data isn't easily accessible to search engines, isn't linkable and also isn't shareable for anyone who wants to direct another user to information on Bitcoin.org about a particular wallet.

We can enhance this page by turning the popup overlays into individual wallet landing pages. This will in turn bring more traffic to Bitcoin.org because it will cause Bitcoin.org to show up on Google searches for keywords like "Copay bitcoin wallet" for example. It will also provide more utility to users because they will be able to link to and share these pages so that other users can more easily connect with wallet info.

Here's a basic example of what a landing page could look like (this would be at https://bitcoin.org/en/mobile/android/greenaddress):

image

Note that the categories should also be links. For example, https://bitcoin.org/en/mobile/android/ would show all of the mobile wallets for Android:

image

The main wallets page would direct users to these newly linkable categories and individual wallet pages, that would soon after start showing up on search engines.

@wbnns wbnns self-assigned this Jul 4, 2017

Contributor

harding commented Jul 4, 2017

Can we discuss whether this is a good idea before we put a bounty on an implementation?

Contributor

wbnns commented Jul 4, 2017 edited

@harding Heya! Regarding the bounty, no - if there isn't an implementation that gets merged there wouldn't be one. Happy to discuss categories and individual wallet listing pages as opposed to unlinkable/unindexable popup overlays, though, if you have any feedback.

Contributor

kuzzmi commented Jul 14, 2017

Is this still relevant? I'd love to work on that, so I've already started.

Contributor

wbnns commented Jul 14, 2017

@kuzzmi Hello, absolutely - it would be great to have your help on this.

Contributor

kuzzmi commented Jul 15, 2017

Question: how often the wallets list gets updated?

Contributor

wbnns commented Jul 15, 2017

@kuzzmi Not super often - maybe a few times a year.

Contributor

kuzzmi commented Jul 15, 2017 edited

image

image

Quick update on this. I'm progressing well, all OS/platforms/wallets have their own links now.
Wallets and platforms are managed as collections, so no need of dealing with copy-pasting.

However still some work left and I will have a bunch of question regarding translation of the pages as they don't quite fit in _templates folder, meaning that their translations must be refactored very thoroughly as well. Currently only English version is working.

Another question is the wallet links. Is it a strict requirement to have a link to a wallet like https://bitcoin.org/en/mobile/android/greenaddress/? Don't want to make shortcuts, but this either will result in a bit of a duplication, or more redirects. To be honest, it absolutely makes sense in terms of SEO. However it will be a bit easier to make the following:

  1. When user clicks on the wallet logo on the page of a specific platform, he/she will go to https://bitcoin.org/en/wallets/greenaddress/#android, what will display a "preselected" platform-specific download links.
  2. When user comes from Google, there will be a list of platforms for this wallet to choose from to show platform-specific "download" buttons.

What you think?

It won't be THAT harder to make what you've initially written, however the value won't be that bigger. I'm still looking for a better solution, so if I find anything to make these platform+wallet permutations easier to implement+maintain, I'll let you know.

Contributor

wbnns commented Jul 16, 2017 edited

@kuzzmi Ok, great. Thanks for the work so far! Standby and I'll go through your progress and follow-up with some feedback (including answers to your questions). 👍

We should make sure we preserve the existing translation tags, etc., so that our international visitors don't lose the ability to view information about wallets in their own native languages (we receive a large number of international visitors who do not speak English).

Contributor

kuzzmi commented Jul 17, 2017 edited

image

Alright, so, after a bunch of trials and errors, I managed to get translation working from the original files with no modification. However I'll need to modify the original _plugins/templates.rb to make sure those pages are generated for all languages. Or, as the second option, to make another plugin, which will do specifically this.

The current state is as on the screenshot. The idea is to make each button to show a specific OS distribution package when user clicks, allowing pages to be deep-linkable and still to have a page where all the packages are visible, so Google can scrape them and OS-specific pages correctly.

Examples of urls:

https://bitcoin.org/en/wallets/greenaddress/#!platform=mobile&os=android
https://bitcoin.org/en/wallets/bitcoincore/#!platform=desktop&os=mac

This is the easiest thing that can be done to get individual crawlable pages per wallet and platform. If this doesn't work, a plugin must be added to create all permutations of platforms and wallets.

What do you think on that?

P.S.

As a side effect of this refactor, I managed to get rid of mysterious SCSS selectors like .wallets>div>div>h2:first-child+div+div+div>div refactoring them to something like .wallet .wallet-platforms .wallet-os-container .wallet-os-overview .wallet-os-checks .wallet-os-check-title which is far more maintainable on the long run.

Also, as a further improvement, the whole stylesheet needs to be refactored to use real SCSS, otherwise looking for a specific style is like looking for a needle in a haystack. Templates and pages are also in a not very maintainable shape. If this is fine with the community I can take care of that after completing the current assignment.

Contributor

kuzzmi commented Jul 17, 2017

Ah, nevermind, there is only one way of doing this right, so I've started with a separate plugin which will make static pages per wallet per os. Sorry for flooding this issue :)

Contributor

kuzzmi commented Jul 18, 2017 edited

image

Voila! A new plugin did a job, including translations. I still need to work a bit with wallets' data files, but apart from that all good.

A few questions from my side:

  1. What is the purpose of functions to "Rotate wallets once a day"? And should this be preserved in a refactored version? Currently it takes platforms/wallets in an alphabetical order.
  2. What default platform and OS I should use when user opens "choose-your-wallet" page?
  3. What is the purpose of "level" property in a wallet data?
  4. Should I clean up the main.js file from the functions that are no longer used?
Contributor

crwatkins commented Jul 18, 2017

What is the purpose of functions to "Rotate wallets once a day"? And should this be preserved in a refactored version? Currently it takes platforms/wallets in an alphabetical order.

The original purpose was "fairness" to list wallets in a different order each day assuming that some listing positions may be more favorable than other listing positions. I believe that some version of this should be preserved in the refactored implementation.

Contributor

kuzzmi commented Jul 18, 2017

@crwatkins Thanks for the explanation, exactly what I thought. And "once a day" is for convenience of end-users as I understand?

Contributor

crwatkins commented Jul 18, 2017

And "once a day" is for convenience of end-users as I understand?

I believe so. It changes positions, but not so fast that it would confuse a user in a single session. Other implementations could achieve the same results.

@wbnns wbnns closed this in #1691 Jul 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment