bitcoindesign / guide Goto Github PK
View Code? Open in Web Editor NEWA free, open-source community resource for designers, developers and others working on non-custodial bitcoin products.
Home Page: https://bitcoin.design/guide/
License: Other
A free, open-source community resource for designers, developers and others working on non-custodial bitcoin products.
Home Page: https://bitcoin.design/guide/
License: Other
Go crazy!
Here is some inspiration - https://www.creativebloq.com/web-design/best-404-pages-812505
Via a comment by @AlexaAker here.
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.
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.
Reported by @moneyball
It seems we can add a social image that can pop a in people's timelines.
Someone can design it, then it'll need to be uploaded to the GitHub here.
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.
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.
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?
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):
Links:
Best to automate this so our source images are high-res and crisp and we don't have to remember to manually compress images.
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?
Hello everyone.
I'd like to contribute this header design for the Bitcoin Design website.
Thank you for your time.
Guide & template by @GBKS
Already some great thinking here https://www.figma.com/file/mPoRMRTBOvi61M8psIp4XY/Coin-Control?node-id=0%3A1
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.
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.
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?
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.
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.
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.
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.
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:
The creation of this page also includes 2 videos:
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.
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.
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.
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?
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):
Domain we can try to purchase (do you have more ideas?):
My recommendation:
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?
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
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.
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.
Considerations:
Some labels that come off the top of my head
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:
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 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 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
Example
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. 😂]
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.
Per request during a presentation at rC3.
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?
title: Requesting Payments
permalink: /guide/requesting-payments
Introduce core payment request data structure.
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
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):
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.
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)?
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.
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.
There are several advantages to hosting the site via Github pages:
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
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.
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:
Should cover:
Could also mention:
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
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.
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).
Hi all,
I'd like to contribute this header design for the Bitcoin Design website.
thanks a lot!
3D Abstract | Bitcoin Design Community Website Banner
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?
This has been brought up a few times. It could cover topics like...
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).
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.