Having Gitflow ❤️ Design as a recommendation by Bitcoin Design for FOSS Bitcoin projects

[Bosch-0]

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?

[GBKS]

I'd like to see more discussion and actual use of this flow to validate it, particularly in the bigger picture of a full-fledged design process from initial discussion to asset export and QA. A few thoughts:

• I don't understand the distinction between the ux and ui prefixes for branches. I am not sure what would go in each one, would be great to clarify.
• The idea of regularly exporting screen designs to a repo is great. Creates a nice history and also room for discussion
• Using Sketch and Photoshop as tools is still problematic since they are paid tools and Sketch is not available cross-platform. Figma is more flexible, but doesn't allow you to store files the way Sketch does. No perfect solution, but Figma still seems to come out as the better choice at the moment
• The future work section lists areas that really need to get resolved (asset export, managing component libraries & style guides)

Maybe we can test this in projects we are involved in and try to refine it. I also think we're going to have a section about open design in the guide that can tackle this.

[diogorsergio]

The gitflow design is a work in progress, but its definitely better than the alternative or having no process at all.

To address some of your points @GBKS:

• UX and UI distintiction came from following a typical product development process where, UX is usually done first (Research, Wireframes) and then moved on to visual design (UI), so the idea was to separate both streams of work. What we see for the most part in open-source development is that one person takes on both roles so in this case we can just name the branches UX/UI instead and bundle them together.

• The workflow doesn't recomend any design tools those are examples. What the workflow says is for participants to stick to open file formats (.SVG for vector files / .ORA for raster files) in their exports no matter what tool they use, so that any designer can start straight away without being stopped by files of paid software, this way participants can use what ever tool they want, with the common ground of open file formats. I love Figma, but Figma is proprietary. Is Figma gonna be around in 5/10 years time? Figma is free, what if the incentives change down the line?

I've been using the gitflow in the https://github.com/Ride-The-Lightning/RTL-Design repo and its been great, but there are also downsides of course. So I'm refining things as I go and trying to improve it. But for open-source projects who don't have any design workflow/guidelines this is a good way to start.

[moneyball]

Out of curiosity, if Figma (or any proprietary tool) were to offer
a) an export option for all data (including comments)
b) an open-source viewing tool

Would this address the valid concerns @diogorsergio raised?

[GBKS]

Picking up this topic again as I think that workflow recommendations would be helpful. Maybe we can come up with 2-3 different ones for different sizes and types of projects. A small team that just starts explorations for a new project has different needs than a 50 person dev + design team for a mature application. Workflows can ideally scale well and if we can have a few different recommendations that users can choose from then they don't have to reinvent the wheel. This could be a nice extension to the Open design page, as well as the suggested page about design collaboration.

Some topics to consider:

• Needs based on project maturity
  1. Quick explorations early on
  2. Maturing stage where structures and standards are established but many things are still in flux
  3. Mature design system that slowly evolves
• Tools
  • Fitness for open-source (open file formats, import/export, etc)
  • Accessibility (operating system support, collaboration features, price)
  • Versioning
  • Cross-tool integrations
  • Learning curve, resources and documentation
• Workflows
  • Design exploration
  • Sharing and discussing designs
  • Collaboration among designers
  • Collaboration between designers and developers
  • Developer interactions with design (tools, files, asset export)
  • Ensuring consistency between design and implementation
  • Documentation & archival
  • Individual activities (see sample list)

I'm sure there's a lot more, but I wanted to share some starting points here.

[Bosch-0]

Move this to a discussion maybe? @pavlenex

[GBKS]

Good idea. Will do.