|BitShares UI Team|
|Duration||2018/02/15 - 2018/06/15 (6 months)|
|Accounting & Reporting||workers.bitshares.foundation/2018-02-bitsharesui|
The BitShares GUI has a great deal of functionality, so much that it can be overwhelming for new users to grasp. Some users expect it to simply hold their funds securely and allow for transfers while others require the full power of the exchange, voting, asset creation etc.
The goal of this worker proposal is to build upon the progress of the past years improvements to the UI.
Being a budget worker, the price tag is an upper bound for the costs that this worker proposal can have at most. Funds are used on a cost-basis and are accounted for hourly. After termination of the worker proposal, unused funds are given back to the BitShares DAC.
Issues located at BitShares/BitShares-ui will be gathered into Milestones with a two week release schedule. Anyone in the community will be able to claim, work and submit a PR for that issue. If the PR is accepted, the user will be paid according to the terms on the README.md under the Development Process heading.
There are many opinions across the BitShares community about what is most important. These opinions vary due to the broad range of individual capabilities. Some users want to see new features developed as soon as possible while others would like to see a refined user interface with reliable, less ambiguous controls and helpful documentation. It’s our goal as a team to listen to everyone and make decisions based upon what we hear from the community.
At the core, we plan to start with bugs. Bugs cause unexpected behavior and unexpected behavior is particularly vexing with a financial application.
In the past 6 months, the UI team has improved the usability of the BitShares wallet in desktop mode, but the performance on the mobile view has suffered. We have allocated additional funds with this worker to invest in responsive design. It will be a priority to invest in work that makes useability on small screens enjoyable.
Tables, dropdowns, form fields, modals, fonts, icons, colors. We plan to seek community comment via github issues and mock ups to propose consistent ways to view all of the current information available in the BitShares wallet.
In some cases, this simply means we will alter a table to fit into an accepted style. We may propose to merge two separate views into one if it’s discovered that they contain related information.
Along the way, the goal is to create a flow that most people will find intuitive. The additional funding for this proposal will add weight to the UX/UI design work that needs to happen up front. This new budget proposal earmarks $8,000 per month to the UX process alone.
We have a goal to ensure that most features in the BitShares wallet are intuitive with additional guides and information available for those who need additional assistance.
Currently, updates to the BitShares-ui are handled by a small team of users who are claiming issues and being paid bounties on these issues. The only exceptions to this are Bill Butler and Sigve Kvalsvik who are both paid a flat rate to manage issues and code review respectively. Furthermore, the BitShares Blockchain Foundation seeks a management fee (<10%) for dealing with the on-chain worker proposal and offer transparent accounting.
|BitShares Blockchain Foundation||3,000|
Will perform code review for all contributors and merge PR’s into staging and handle releases on a bi-monthly schedule. This includes:
As the project manager for BitShares/BitShares-ui, I will review all issues created (15 hours per week). I will mediate discussions on github around new features. Milestones will be created for each 2 week Sprint. Sprints will be populated with enough issues to occupy 90 hours of development work and 60 hour of UI/UX for the 2 week sprint. Understand that these hours are quality hours, not planning hours. As many in this field are aware, developers are always working on problems in their minds. In most cases I’ve found that a 15 hour task will require anywhere from 25 - 30 hours of a developer’s time. Each issue will be tagged as feature / task / bug / duplicate / rejected.