RTL (Ride The Lightning) is a full function, device agnostic, web user interface to help manage lightning node operations. RTL is available on LND, C-Lightning and Eclair implementations.
Visit the development repository ShahanaFarooqui/RTL for more information. Follow @RTL_App on Twitter for important announcements.
This is the Github repository for the design work stream of RTL. It exists as a way to mitigate issues commonly found in design workflows of open-source software projects where the work created never comes into git. Which means such work is not being tracked and doesn't have an auditable history. Files also might not be stored in a common place accessible to everyone, so its always a hit and miss on how to gain access to them, and sometimes due to these being created with proprietary software they can sit behind a closed gateway and as contributors come and go from the project their access can be lost.
By using git we make things easier and open for anyone wanting to collaborate and hopefully streamlining the work process by connecting the development and design repositories together. For this to work a success we need to adopt a design workflow that focus on open-source ideals, so that no one is restricted by proprietary software and gatekeepers. We introduce such workflow bellow which we have been testing, It's called Gitflow Design and It's based on the popular A successful Git branching model (Gitflow) by Vincent Driessen, but adapted to a design workflow.
Gitflow design as mentioned above is a git workflow for designers and design work. It's meant to be open, platform agnostic and help minimise dependencies on proprietary software and help to increase collaboration.
By using git, we get to take advantage of a lot of useful features available such as controlled access, review process, feedback system, version control files, preview changes in context with side-by-side diffs, detailed history of changes and more, something developers had for years, but that designers never really took advantage of.
master / design
Instead of a single master branch, this workflow uses two main branches to record the history. The master branch stores all the signed off releases from the design branch, and the design branch servers as an integration branch for all the features. It's in the design branch where supporting branches are fully reviewed before being merged onto it.
ux/feature / ui/feature
New features being designed should have their own branches. There are two types of feature branches, one for the user experience work with the prefix ux/ and the second for interface design work with the prefix ui/, and if all went to plan one follows the other.
As an example we might have an upcoming feature named helpsystem, for this to start, a ux feature branch should be created and named ux/helpsystem. This is where the user experience work will be done. When the ux is finalised and ready for review, the designer will create a pull-request to start the final review process to merge it to the design branch. If the reviewers are happy with the work that was done and it has been signed off, the pull request is accepted and the branch merged onto design and then deleted.
At this point the ux/helpsystem is ready to progress into ui design. It starts with a new feature branch created and named ui/helpsystem. It now follows the same steps as before and when the ui work is finalised, the branch should be pushed and a pull-request created to initiate the review process so it can be signed off and merged onto the design.
Following that we now have both the ux/helpsystem and ui/helpsystem branches merged in design, so now, the next step is for a reviewer to merge design onto the master so the feature is pushed.
You can read the step by step guide on how to follow this workflow further down the page.
Couple of ideas for future improvements with the goal of having everything within github and publicly accessible.
If you have any ideas on how to solve any of these, please get in touch! 👍
🎉First things first, thanks for showing interest in contributing to RTL 🎉
This workflow is still a work in progress and we are still changing it, so if you have any suggestions on how to improve it, please get in touch!
We want to keep the workflow open to anyone who wants to contribute, so it tries to focus on using open file formats that can be easily accessible to others and are not dependant on proprietary software.
Free open source software you can use:
The workflow can be followed with the Github Desktop App, but also via the terminal. There's a guide for both, so follow the one you're most comfortable with.
This is an example of the folder structure being used to keep things organised and manageable for all of us.
.
├── documentation # Supporting documents
│ └── research # Research material
├── images # Assorted images
└── lnd # Lightning implementations
└── dashboard # Feature files
├── ux # User experience work
│ ├── exports # Exported artboards
│ └── source # Source files
│ ├── sketch # Editable file being used
│ └── svg # Open format alternative
└── ui # User interface work
├── exports # Exported assets
└── source # Source files
├── psd # Editable file being used
└── xcf # Open format alternative
When using proprietary software, please make sure you always keep copies of the editable file in open file formats. For example if you use Sketch, keep the .sketch file in the source, but also export all your artboards into separate .svg files.
More and more companies are opening their file formats and as they do this sometimes we can take advantage of that and version control their files. When this is the case, we will include a guide on how to do it.
Sketch 43, Introduced a new open file format where .sketch documents are now stored as .ZIP archives containing .JSON files and what that allows us is to use git to keep track of changes made to the files. The .sketch file in itself isn't ready out of the box to be versioned in git, so there is a bit of a manual process in order to make it work. but you can read more about it here sketchflow.md.
This step by step guide will walk you through the basics of Gitflow Design.
It will cover, cloning the RTL-Design repo, creating a new feature branch, pushing your changes to github and creating a pull request to get your work reviewed. All this is shown through both the desktop application and via terminal.
If you're not familiar with the terminal or command line applications, the Github Desktop application is the perfect solution. It works perfectly out of the box and makes interacting with git a lot easier.
Launch the Github Desktop app and click to Clone a repository from the Internet