Modern UI/UX for RGOV interfaces
Closed this issue · 16 comments
One thing for me that has sort of acted as a blocker in implementing a new UI for the voting interface has been the design standards that should be followed, material UI? Bootstrap?? What color codes, font types, UI elements.
Also, another reason for creating this issue was as a result of the discussions from issue #201 and pull request #190.
So, I would really love input from everyone here so the UI team and development can move alot faster without having conflicting designs
I think there are two goals that aee almost at odds with each other.
On the one hand I think we need to have a clean interface that is something a non-programmer would use but at the same time we like to show the Rholang contracts that are being signed as a "Proof of Design' (Yes we are really performing on chain contracts)
So I wonder if we could have an interface where I login, do various things (show issues, castVote etc) and have on each page a Developer Button to toggle a Show Rholang window
In order to design each web page that would be displayed for each interaction we need to define a list of roles and interactions.
For example there is always a Vote Organizer and a set of Voters; so before we can define the script we use for the next demo we need to define the operations each role can perform as well as dependencies and additional inputs
Organizer can: Create an Issue/Ballot, Add Voters/Groups - What else?
Voters can: View Issue/Ballot, CastVote, DelegateVote, TallyVote - What else?
I think @jimscarver may be the best to expand that list as I believe he laid the foundation of the design.
Let's keep it to atomic functions it may be as simple as going through all the actions and pick a subset that should be used in the next voting demo and what capabilities we want to demonstrate
Please narrow the scope of this issue.
If it's about visual design, propose some visual elements.
If it's about dependencies, make a proposal to add one or more dependencies and explain how the dependency helps address project requirements.
#201 is about being explicit about taking on dependencies. Each new dependency is judged on it's own costs and benefits. I can evaluate a proposal to use material or a proposal to use bootstrap, if the proposal is clear about the benefits. This is easiest if the proposal is s PR that addresses some issue that we have agreed needs assessing.
The problems with #190 were
- Commits with diffs that didn't match their commit message
- Commits that went beyond the scope of the PR
- Not following existing standards from CONTRIBUTING.md
Oh.. Another aspect of #190 is that syntax highlighting enhancement #134 isn't clearly related to the goal of scalable governance. It's not on any agreed milestone. So review of a PR for it should be quite conservative. I would rather postpone the enhancement than sacrifice a clean git history, ocap discipline, etc.
We have embraced the developer interface since community involvement is necessary for the evolution of decentralized governance. https://rushkoff.com/books/program-or-be-programmed/
The syntax highlighting will significantly enhance the developer interface nut we do have other priorities. At the same time we want to encourage people to work where their passion is.
I do not like the split editing screen. Finding the result becomes unobvious. I love davids new styles and fixing editing would be worthwhile in my view.
Design issues may not be relevant if this is a "standards" thread but we do need to consent to our design directions. Nobody gets their way in a cooperation.
... I love davids new styles ...
pointer?
... I love davids new styles ...
pointer?
@w2vy when you say:
show the Rholang contracts that are being signed as a "Proof of Design' (Yes we are really performing on-chain contracts)
do you mean the developer interface or the voting interface?
@dckc @jimscarver the whole point of the issue is to get everyone's thought as to what set of tools ( dependencies, libraries) to use, if we have to create an issue for each separate library or dependency, don't you think that would rather slow down the process?
I don't see any way to anticipate all the library dependencies we will ever need. Each new dependency must be motivated by some feature, and a new issue for each feature is completely ordinary, no?
It's possible that one feature will motivate more than one dependency, of course.
@dckc so this means for any new library or dependency that we may add, we have to create a new issue? I am trying to gain clarity.
All development is in the context of some issue. Every line of code should be in service to some issue. So yes, since adding a dependency involves lines of code, it should be in service to some issue.
If interactjs were needed for syntax highlighting, then we wouldn't need #201 separate from #134 . But the stated motivation for interactjs is not to make syntax highlighting work, but to change the way textarea resizing works. That's a separate issue, to my mind.
Issues / PRs might have a wider scope, such as "modern web design for actions UI". That's sometimes more straightforward, sometimes less than more tightly scoped issues. It's more straightforward if everybody's on the same page based on previous discussion.
@dckc @jimscarver @w2vy
@David405 is asking (I think) about what we want as a (somewhat) standard web experience.
I think bootstrap is a convenient, easy way to proceed to a more inviting RGOV experience, and I think we should solicit @David405 continuing advice since @David405 has the knowledge and expertise RGOV lacks.
Let's let the work happen and see what results. I'm sure @David405 will keep us in the loop.
#My2c
@David405 Please comment on whether or not this issue blocks rv2021. https://github.com/rchain-community/rgov/milestone/4
@Bill-Kunj I don't see this as a blocker
The issues raised here are:
Not blocking to RGOV development
Not blocking to RGOV deployment
Let's bring the details in other issues?
Closing