Every Bitcoin software will display amounts of Bitcoin or Satoshi, but there are various details to consider around how the numbers are formatted. There have been discussions in Slack, and since it's a common "problem", maybe we should come up with recommendations to include in the guide.

Slack conversation
Figma summary

Reported by @moneyball

It seems we can add a social image that can pop a in people's timelines.

What we currently have

Template

Someone can design it, then it'll need to be uploaded to the GitHub here.

This issue creates the introductory page for the onboarding section and outlines the upcoming content that will be part of this section.

You can read the proposed section here

parent: Recovery
title: Recovering an on-chain wallet
permalink: /guide/recovery/on-chain

How does the wallet arrive at it's balance and what are the problems that the user may encounter during the process?

• Derivation Paths
• Choosing Address Type
• Selecting Account
• Defaults
• Gap Limit

Fees can get expensive at times and have a big influence on how long transactions take to confirm. There are various details to consider when designing a fee picker, let's come up with some good recommendations.

Slack thread
Figma

Create a simple best practice / backup storage options page for reference.
Somewhere we can point people to when creating new keys with a recovery phrase that needs to be backed up.

Consider:

• Redundancy (if, when and how to create several backups)
• Physical resistance (grades of resistance from paper --> metal)
• Resistance to usage on discovery (whoever finds the full recovery phrase can access funds)

Should cover:

• Basic paper backup
• Metal and other alternative materials
• Where to store
• Inheritance planning

Could also mention:

• Multiple hardware keys to the same wallet instead of backups
• An extra (13th or 25th) word that is memorized instead of written down
• Splitting the recovery phrase to store in different locations

Some labels that come off the top of my head

1. Fees
2. Addresses
3. Transactions (verifying you are sending money to the correct place)
4. Private key
5. ...

So now if you github issue/PR has is related to one of these topics, you should add the label to it so we can sort by these labels in the future. For a code based repo, this is what this ends up looking like if you are disciplined about this:

As you can see from the image, you sort by things like "bug" or "documentation" etc to find all relevant information for that topic.

The site nav currently has "Contribute" navigation item. The content for that page has not been really defined. However, we do have some good info in the readme of the Meta repo we could use, right here.

So I see three options:

1. Make that nav item link out to the Guide readme (meaning we won't have a nicely designed page, but people will have to read a Github page for that info)
2. Create new content for the "Contribute" page based on the Guide readme (so we will have a nice-looking page in the Guide repo, and the info in the Meta readme. There may be some content duplication)
3. Move the Meta readme content over to the Guide repo so we can have an nicely designed page there

I'm for option 2. It allows us to have a more approachable visitor-facing page, and then more functional Meta readme with additional info for experienced contributors.

There have been various discussions on Slack and in calls where we had to clarify terms. Let’s try to gather and clarify them, so we can present clear language to users that will allow them to more easily understand and use bitcoin.

We should define whether we want this to be a general glossary (of which there might be other good ones online already), or whether we target it towards readers of the bitcoin design guide and their particular use cases. For example, each term could have a more technical description for the reader, and a second version that can be presented to users that is more focused on usage than technical comprehension.

Here's a Google Doc to kick things off. Once it's in a decent shape, we can move the content to this repo (probably to glossary.md).

Already some great thinking here https://www.figma.com/file/mPoRMRTBOvi61M8psIp4XY/Coin-Control?node-id=0%3A1

Might be worth breaking the glossary.md file up into sub glossaries to prevent this page becoming too unruly.

Some examples of sub glossaries:

Lightning
Wallets
Nodes
BIPS

Based on this Slack thread, discussing how on some mobile phones (iPhone 8), the title of the home page is not in visible on page load (above the fold).

Alexa has explored solutions in a Figma file.

type: page
title: Units & Symbols
permalink: /guide/payments/units-and-symbols/
file: guide/payments/units-and-symbols.md

Looking for someone to research and write this foundations page relating to payments.
Below is a rough outline to get you going.

Units

Currently there are two units that are widely used in apps, bitcoin and satoshi (sats). Satoshi seems to be what is used mostly within apps that support lightning payments. Bitcoin with 8 decimals is the unit common to onchain payments. Making a 1 satoshi payment in a transaction onchain isn't going to be so economical.

On lightning network the base unit is millisatoshi/msats which is a subunit of satoshis (I've never seen this exposed in a UI though).

There are also other units which are less used colloquially, and it's an interesting the process of how these units come into use. Should they also be included in the guide (see Units)?

Symbols / Codes

• What symbols and codes exist?
• What are different symbols/codes which are popularly used?
• Are there cases where one should be used over another?
  • e.g. What is the impact by the limited support for the bitcoin unicode symbol (see #5) ?

Consider Amount Display

Once these foundations are written - you should have a good base to explore Amount Displays more deeply. @GBKS has captured some of the early conversations around amount display in the community slack in issue #3 and can actually be included as is for a first version.

REF

• The visual language of bitcoin
• https://en.bitcoin.it/wiki/Satoshi_(unit)
• https://en.bitcoin.it/wiki/Units
• https://en.wikipedia.org/wiki/Denomination_(currency)
• First time contributors read these Content Guidelines
• https://blog.lolli.com/stacking-sats/
• https://wiki.ion.radar.tech/tech/bitcoin/satoshi-unit-of-currency#history

Via a comment by @AlexaAker here.

This could be a good starting point for a page for user research resources and integrating findings into the guide. Please add any links you know to this Google Doc, or in a comment.

There have been several open discussions in Slack around which domain to use for the website, with various preferences but no conclusion. I'd like to review the options here again, make a suggestion, and ask for input.

Domains owned by community members (please comment if you have more):

• designingbitcoin.org
• designbitcoin.org
• bitcoindesign.net
• designforbitcoin.org
• bitcoin.design
• bitcoindesigners.org (used in the Square Crypto announcement and a current redirect to the Slack workspace)
• bitcoindesigners.com

Domain we can try to purchase (do you have more ideas?):

• bitcoindesign.org (anyone know who owns this?)
• bitcoindesign.com (costs $6,500)

My recommendation:

• Use bitcoin.design
• Redirect bitcoindesigners.org and bitcoindesigners.com to bitcoin.design

Either way we go, the domain we end up with will likely be owned by a community member. Probably not a huge risk factor, just something to be aware of and have a Plan B for. Maybe we pick a second domain that also links to the site, just in case our community devolves into chaos and we end up not being BFFs anymore.

What do you think we should do?

The site nav currently has a "Projects" option with a list FOSS bitcoin projects (Wasabi, bisq, etc). I believe the idea is to present projects the community likes or is involved in.

Is this something we want? The idea generally sounds good, but might not be so easy to implement since it could be tricky to identify requirements for projects to be included.

Best to automate this so our source images are high-res and crisp and we don't have to remember to manually compress images.

Plugin link

I'd love to get your feedback on this page. Please view this short video for details.

I have a PR for this page, but might be easier to iterate on copy in the doc linked below.

Google doc
Preview link

Please let me know what questions you might have. As far as feedback, everything is helpful, whether it's your overall response to the page, to editing copy, coming up with better illustrations, or anything else.

Does any one have a preference over a javascript framework to be added to the website at its current state to help with interactions?

jquery
umbrella
cash

Should we just keep using vanilla js?

The glossary page will get pretty long and tedious to use. Here's a suggested design where all terms are collapsed by default and can be expanded. There's also an inline search-bar to instantly filter the page content as the user types, to more quickly get to what they are looking for.

Here's the design in Figma.

V1, which is a placeholder site, is being discussed here. For V2, @AlexaAker has kicked us off with some good design concepts and explorations, so I thought I'd create a dedicated issue for V2 to gather and continue this work.

• Alexa's concepts
• Relevant Slack thread
• Pedro's general mood board for the guide

Since we are still figuring out both content and visual design for the site, I assume we'll go back and forth on a few different ideas and explorations. This should be a fun process. Please add any relevant links I missed.

parent: Foundations
title: Addresses
permalink: /guide/foundations/addresses

See the glossary for description - this page should deal with the visual aspect of the address display.

• Address Versions (the different address types)
• Address compatibility
• Readability
• Visual Validation
• Display

There are several advantages to hosting the site via Github pages:

• Integrated with the Github collaboration tools
• Automatically reflects the latest codebase without any complex deploy processes
• Easy to configure due to Jekyll integration
• Integration with third-party tools like Transifex for localization

There are some known basics we can already explore (templating, search function, localization), but we will have to wait for the content and design to progress further to really know what all of our requirements are. We can either keep this issue open, or focus it on the basics and create more issues for future improvements.

References:
Github pages marketing page
Screencasts by Christoph

So far we have discussed Jekyll, VuePress and Gatsby as options. They are all based on markdown content, to allow for easy editing without complex technical requirements. Let's gather the benefits and disadvantages of each one based on our goals and requirements and decide on a direction.

Slack conversation

Considerations:

• Easy to add and edit content by non-technical contributors (markdown based)
• Easy to set up a local environment (for both tech and content contributors)
• Support for custom components in markdown
• Stable framework with good ecosystem
• Github pages can automatically build and deploy when code is merged
• Low learning curve for technical contributors
• Support static pages and blogging (potentially needed in the future)
• What else...?

As of today, we're including the guide as a part of a website which will include other sections: projects, contribute, and more in the future.

Do we want to consider encompassing everything under a "website" repository? Or is it better to keep the guide separate?

I think for now, as we grow the content from nothing, it would make sense to have everything under one roof, and then separate if it becomes much much bigger and justifies multiple repos.

Go crazy!

Here is some inspiration - https://www.creativebloq.com/web-design/best-404-pages-812505

I think a page like this could help us with two things.

First, it looks like we will be using Figma for many designs due to the ease of sharing and collaboration. While Github has many pre-defined processes built-in, Figma and other design tools do not. So I think it would be helpful if we articulate these for us.

Second, there are a few design resources being worked on that we will make publicly available for anyone to use and contribute to. Currently we have many Figma links floating around with no way to find them again other than asking around or searching Slack/Figma history. We can also list important design resources on this page.

This page would likely be under "Resources".

Below is a mock-up with some quickly written copy. What do you think of this? Note that this is heavily slanted towards collaborating on Figma community files. So this might need to be a sub-page under a more general "Design collaboration" or "Open design" section that is tool-agnostic.

parent: Managing Funds
permalink: /guide/managing-funds/transaction-history

A transaction history is usually displayed as a table or a list with items in chronological order.

• What is special about the bitcoin transaction history?
• State the primary attributes that need to be shown
• Saving meta data
• Define the available actions that are possible taking into consideration the different transaction states

Related

• Hide Amounts / Privacy Mode
• Amount Scanning / Gap Limit (troubleshooting)
• Labels

Unfortunately Slack expires the public invite link once a month and it must be manually recreated. I will need to do this and then open a PR to update the website in a timely fashion. Perhaps we make an exception for this particular change so that I can merge straightaway without review/approval (or, reviews can come post-merge).

Thoughts?

There are also a large amount of typefaces missing the Bitcoin symbol on fonts.google.com as these are very widely used on the web.

• How many? Could be a good starting point to for analysis.

“How to include” is not the hard part, any pro type designer can do this easily. Motivation to include this glyph in the font vs many other currency symbols, other punctuation, other language accents, etc is the difference. If we are not sure it will be used it doesn't get a high priority, but a bounty would change that

From a discussions in #BitcoinDesign slack

• https://bitcoindesign.slack.com/archives/C015856BDME/p1593063808128000?thread_ts=1591373945.177200&cid=C015856BDME

Example

• rsms/inter#284

A common understanding of the audience is helpful for writers to adopt appropriate language and weight off what to include and exclude.

This Google doc started by @johnsBeharry and I is a starting point we can iterate and then turn into a PR.

The site nav currently has an "About" option with placeholder content.

Do we need that page or is the info on the home page enough? If we need it, what information would go on there?

Shared by @pedromvpg in the slack, the Gitflow ❤️ Design git workflow proposed by @diogorsergio would be a great recommendation we could offer to FOSS Bitcoin projects.

We could also include a detailed how-to on Gitflow Design in the guide resources section.

Details on the Gitflow Design git workflow can be found here

What do you all think?

title: Requesting Payments
permalink: /guide/requesting-payments

Introduce core payment request data structure.

• Label/Observer
• Memo
• Expiration
• Address/Invoice

Formats

• BIP21
• BOLT11
• BIP21 Encoded with BOLT11

Sharing

• QR Codes
• Copy/Paste
• Transporting Across Apps

Every (well, almost every) Bitcoin application at some point needs to connect to the Bitcoin network to retrieve data or publish transactions. This can happen in different ways, each one with advantages and disadvantages. I think it would be helpful to lay these out, so designers and developers can choose the one that is most appropriate for their product.

This stems from a Twitter/Slack conversation a few days ago that led me to create this image (Figma):

Per request during a presentation at rC3.

I'm very interesting in writing this chapter and already have a lot of ideas.

[Sorry, if this is not the place the ask this question. I'm still learning how to use Git Hub. 😂]

This issue creates the introductory page for the payments section and outlines the upcoming content that will be part of this section.

You can read the proposed section here

Reviews of pull requests are equally important contributions as their creation.

After #125 gets reviewed and merged, I'd like to create Review.md a page that will teach the basics of reviewing a pull request together with best practices.

Here's the current structure I have in mind:

• Reviewing a proposed change
  • Prerequisites
    • Identifying what to review
    • Reviewing a pull request (actual process explained)
      - Best practices
    • Testing a pull request
      • Testing via Netifly
      • Testing locally

The creation of this page also includes 2 videos:

• How to review a proposed change
• How to test a proposed change

Usually, in software development, code(content) review is a separate process from testing, but since we're a content-focused project, I wanted to do it on a single page.

If there are any ideas, questions, or things you'd like to have covered here, let me know.

I'd like to propose this design as the very first version of the website for the Bitcoin Design community (decision on the domain is discussed here). I first submitted this for feedback last Friday in Slack here and a variation of it on July 8. This page is built (on the Jekyll setup we discussed) and ready to go live if we want to (see it in action here).

The Figma file for the design is published on the Figma community, you are welcome to duplicate it, put your own spin on it and suggests improvements. If you want to comment on the design, check the Figma source file here.

This is meant as a minimal, temporary placeholder so we can get something live soon. My sense from Slack conversations (example) has been that many prefer to go live and iterate fast, compared to trying to build a more complete V1 that will take weeks/months to complete.

Let's do some discovery on the overall feel, brand, styling and other aspects of what we want the guide to look like in the end.

Pedro has started a mood board on Figma with references to comparable sites that we can discuss.

Whether it's for payment, wallet import/export or multi sig, it's ideal if applications are compatible so users can interact seamlessly with each other and use whatever software configuration they want. For designers then it is important to understand what those touchpoint are (not necessarily the technical details, but more so the user needs and flows). So I started taking notes in a Google Doc in the hope that this can become a section of the guide.

See the doc

For more easily copying links to specific sections of a page.

Per @pavlenex comment here.

This has been brought up a few times. It could cover topics like...

• Use cases
• Hardware wallet UI design considerations
• Interaction between hardware and software wallets
• Features
• Popular products and product categories

The "Hardware" overview page has a short section about hardware wallets. This new page would be a natural extension of that content, but could also be linked to from relevant content in other sections (like private key management and transactions).

Bridging Bitcoin

Hello everyone.

I'd like to contribute this header design for the Bitcoin Design website.

Thank you for your time.

File On Figma:

Contribute Your Own:

How To Guide ⤢

Template ⤢

Guide & template by @GBKS

Hi all,
I'd like to contribute this header design for the Bitcoin Design website.
thanks a lot!

file on figma:

3D Abstract | Bitcoin Design Community Website Banner

full-res png image:

Contribute Your Own:

How to Guide

Template

Several sections outline principles, with some overlap already visible. Let's extract those and move them to a dedicated page. This will allow us to have a common basic understanding of those ideas. Each page then can focus on explaining how the relevant principles apply to that particular content.

Some principles I've seen described (there's probably a lot more, I just picked out ones I could quickly find):

• Permissionlessness
• Trust
• Privacy (onboarding, private key management, privacy)
• Security
• No loss of funds (private key management)
• Interoperability (private key management)
• Progressive security (private key management)

Links:

• Private key management -> Principles
• Onboarding draft doc
• Payments PR preview

World map in the background https://bitcoin.design/guide/payments/ should have better contrast.
This is good first issue for anyone interested in helping out.

Any takers?