Should ether contracts have GUIs? I'm a UI designer and here's why I don't think so.

avsaavsa ✭✭Member Posts: 68 ✭✭
This discussion was inspired by comments from @Stephan_Tual? in two other recent posts so I though I'd put here because I really want to see what other people believe is the future of Etherum and the reference clients.

http://forum.ethereum.org/discussion/751/so-i-designed-a-concept-ui-for-the-alephzero-client
http://forum.ethereum.org/discussion/711/web-components-marketplace-for-ethereum-ui-markup

The question is either Smart contracts should, in the future, have UI information. I see mainly two ways this could evolve:

* Ether contracts start having more code related to UI and how to present the information to the final user. New GUI elements are created and can be reused. Ethereum evolves into a whole decentralized OS.

* Contracts have information on what commands they accept and what's the data format or options each command takes. Ether provides the apis, and data for the backend of any app, in any platform. Clients can use whatever native OS code they prefer, and use Ether as the cloud api, a decentralized always persistent network.

I truly believe the second one is by far a better approach. First, because it's simpler and isn't a boil the ocean kind of approach. You don't need to implement custom interface elements, reinvent the browser, recreate 30 years of GUI code from multiple platforms.

Also, it promotes a separation of code in the Data/Model/Controller layer and the View/Interface layers. This creates cleaner and easier to maintain code.

Finally, it allows UI to flourish and Ether to be future proof. A OS built for the desktop isn't necessarily good for tablets and smartphones, and a mobile OS might not be good for wearables, robots or microwaves. OS's and interface needs change and separating Ether as just the data api we allow it to flourish in any platform.

A good example is Twitter clients. When twitter started, it was an open platform that allowed anyone to build clients on top. This created an environment where UI design flourished as everyone tested different approaches, on multiple platforms. The best innovative UI of the time came from twitter third party clients.

So in my vision, the reference client should only have a very basic "contract navigator" that permits you to use and test any contracts, but allows you to launch it in an external client for a better experience. This contract could have a list of accepted commands and a basic UI to provide the correct data in each command (a api request builder) but not more. The way data is presented, and how the interface is displayed, should be left to developers. (see attached)

Does everyone thinks similarly or am I too off the mark?

Comments

  • avsaavsa ✭✭ Member Posts: 68 ✭✭
    The image was hastily made, sorry for the unaligned title.
  • mquandallemquandalle ✭✭ FranceMember Posts: 50 ✭✭
    I'm also concerned about a potential unfair competition. I'd like to create a "github for smart contracts" where users can write, run and fork contracts in a nice web UI. This seems to be also the goal of the ethereum core team, the difference is that they will receive the IPO money and I don't (based on our current knowledge of the IPO model). The solution would be either to let investors vote on ethereum projects to distribute IPO money either to ask the core team to focus on the protocol layer and let the community build applications on top of it.
  • avsaavsa ✭✭ Member Posts: 68 ✭✭
    Well I do agree and hope that the IPO money is locked into a global DAC that helps fund ethereum related projects in an open, global and democratic way, but... What's your opinion on GUI elements? ;-)
  • mode80mode80 ✭✭ Member Posts: 64 ✭✭
    I think you'll see a spectrum. People will certainly create native desktop apps that talk to Ethereum. But I would agree that the "official client" shouldn't try to bundle all these. I'd like to see it go as far as the "API browser UI" that your mockup suggests, but not further.

    Right now there is no standard way for a contract to publish details of expected inputs. In fact POC-4 takes us to a place where this is more necessary because inputs to a contract are no longer a simple list but a binary blob format that will differ for each contract. A standard way for a contract to expose "API metadata" would make general-purpose contract browsers like yours feasible, and I think that would cover the UI needs for 99% of the contracts.
  • mode80mode80 ✭✭ Member Posts: 64 ✭✭
    ... Contract writers just need to follow a standard (e.g. contract storage slot 100 will be " contract title", slot 101 will describe the first input it expects, slot 102 will designate it as a "text", "number", or "true/false" value, etc.) This would then guide a general purpose contract browser UI that would work for submitting data to any contract that follows the standard.

    Whoever builds the first contract browsing GUI with widespread use -- that person will essentially set the standard. It might be the core dev team, but I'm not sure they've thought this far ahead.
  • chris613chris613 ✭✭ Member Posts: 93 ✭✭
    It seems like standardized metadata passed as part of the initialization parameter would suffice for most of what's being discussed here - namely documenting the contract's API enough to lay out a generic form to interact with it. Complex contracts will be pretty much unusable in this manner, and will require a proper client, so we should include torrent magnets into the metadata.

    I definitely agree with @avsa? that trying to make the ethereum client itself the primary means of interacting with contracts is going a bit too far. I appreciate that HTML5 is supposed to allow you freedom to do "whatever you want", but I just don't see that actually panning out when you account for all the design assets and UI specialization logic required to be bundled with it.

    Insight into the thinking around this part would be appreciated.
  • StephanTualStephanTual mod London, EnglandMember, Moderator Posts: 1,282 mod
    Having decentralized GUIs available to contracts does not preclude having 3rd party interfaces communicating with said contracts through headless clients, to the contrary, it promotes a generalized API.
  • avsaavsa ✭✭ Member Posts: 68 ✭✭
    edited April 2014
    Well @Stephan_Tual maybe it's just about how much GUI information is on the code. There can be some basic UI suggestions that can be implemented in a rich but simple client (so that we won't need a whole new client for each contract), but it's easy to be excessive in it.
  • JasperJasper ✭✭✭ Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    I thought the interface stuff would essentially be on a separate channel than ethereum. Contracts may reference a suggested one. I am trying to figure out the idea of transaction firewalls, i think i might be able to make the gui work on the same principle
  • FreddyFenderFreddyFender Member Posts: 39
    @Jasper, it has to remain on a separate channel or you invite code/GUI misuse and too many unknown outcomes! As to the idea of a firewall for code blocks and transactions, what about a What is Acceptable/Best Practices (WiA/BP) approach? The GUI can recognize all snippets of code and interpret the meaning without first running the contract. Simple color assignment (green, blue, red, yellow) + BP explanations of each snippet prior to acceptance of running code/txs might be a solution. Dormant code/txs can be back-checked or refused without prejudice if we know what we are seeing. There are a possible 60+ basic trust contracts, code reuse may be fee free if the dev team decide so, and many newbies will take their cue from the hardcore knowledge gang. Running the code is not dangerous but accepting a contract without a correct interpreter is the crux of our issue with any and all GUIs. Code Clearinghouses, contract insurance, Best Practices are the direction we are headed now that POC is underway and everyone wants some vision of the GUI that @avsa is seeking.

    @avsa, could you mock up a simple contract parser based on @mode80 etherscripter blocks or something similar? Your GUI would grab the contract code, get the details a la some blockchain viewer for additional information and then ok known code vs. unknown code and give free hints/paid solutions for anyone needing to discover the intent of a contract. I see only upside if we agree on WiA/BP but I am willing to entertain other solutions that avoid a muddy protocol.
  • mode80mode80 ✭✭ Member Posts: 64 ✭✭
    I gather you guys are talking about the problem of a contract suggesting a GUI that lies about what it actually does. (e.g. presents itself as an escrow contract but actually steals all funds to the creator.)
    I think we'll eventually need an EVM decompiler that's useful for auditing a contract's actual behavior, combined with some kind of reputation system.
  • chris613chris613 ✭✭ Member Posts: 93 ✭✭
    I just happened upon this: https://github.com/ethereum/cpp-ethereum/wiki/Provisional-PoC-5-JS-bindings

    From what I can gather here (specifically the last paragraph), is the idea that you point the client at a URL which can be a local file or a traditional web server, that provides you the content including javascript that has access to your ethereum client. All you really need is strong UI elements in the ethereum client/browser to provide an ACCEPT/DECLINE for create(), transact(), key() and keys(), and you're good to go. DApps can be served like a traditional website with the power of ethereum for the parts that need it, or can be packaged and distributed over something like a DHT-tracked torrent to run entirely locally.

    The relevant take-away is that there seems to be very little hints yet of the ethereum client forcing any one particular UI onto DApps.
Sign In or Register to comment.