So I designed a concept UI for the AlephZero client

avsa

Since using the AlephZero client I began thinking about how the client could look down the line, and once I had that itch I had to scratch it.

http://cl.ly/image/1v2G102r0T3S/o

Of course this is a very rough sketch and shows only the contracts tab. I imagined it as a collection of all your active contracts, but added a few features that are not on the current code but seem no-brainer, specifically features in which a contract tells the client the kind of data it accepts (and what UI) and the current status of the client.

I'm also adding the ability of querying a third party of your choosing to audit and describe each contract, so you can trust it before.

Most features of the current AlephZero are visible on that screen. The "owned accounts" would be similar to the contracts page and the remaining status and blockchain could be tucked in the "network" screen.

I'm using Retro gravatars to identify contracts because they're much more instantly recognizable than hashes, and I believe they are much better than the traditional "kaleidoscope" gravatars. I didn't pick or choose any, but you can still read an image in all of those random patterns.

So what does the community think? Is that kind of contribution welcome? How can I help in a more productive way?

Thanks

giannidalerta

Pretty awesome so far. Great to see some of the ideas visualized. My initial critique is with the currency options, you may need to try some other options with that, maybe a drop down? Ether can be pegged against other currencies and or assets.

I can see how tricky the contracts will be to visualized into a GUI. Specially with the underlining info.

@texture? what are your thoughts...

cphi

This is exactly how I see AlephZero when I think about where Ethereum is going. A separate tab could be the app store that would make it dead simple participate is contracts that are rated by the community.

StephanTual

Very good! The only thing is that it seems to be a 'contract' browser with a default, dynamically generated UI for each (I supposed you assumed that the contract browser parsed each contract to derive its interface).

In fact, we will be providing GUI tools for dapps developer, meaning that contracts will have their own, decentralized GUI unique to each. Personally when I think of the reference clients, I imagine them very much like the itunes store, with (d)applications going full screen when started.

bobbyremone

@cphi and Stephan_Tual having just tried out the AlephZero client this itunes app store type of approach you both talk about is exactly what came to mind. Incredibly excited about the opportunity to flick through different complex contracts and not only participate in them but examine how they were put together.

Fun times ahead!

avsa

@Stephan_Tual? I like your approach but wouldn't that take the task too far, trying to create a decentralized OS? When I think of the main client I see a basic interface to interact and send commands to apps, but I always imagines the ethereum contract would always be just the model/controller but not the view.

So a single app could have multiple clients, using any kind of technology: HTML in browser, a mobile app, a watch.

I see ethereum as bigger than the cloud (the ether) where data is stored and commands are executed, but multiple clients can be built on top of it.

Instead of trying to be java app, a single ugly interface that Should be universal but may not work in a future system, I see it as the Twitter API, one single service, multiple clients.

The main client, in this scenario, would be merely a central place to access, control and view the multiple apps.

Maybe the right metaphor would be a file system, were you keep data and an open apps..

jw1

First, great job on the mock-up. This mock-up begs the question as to whether contracts should hold metadata to generate such contract thumbnail tiles to allow for a richer contract browsing experience. This metadata would be optional and placed at the top of the contract; it would be simple and maybe expressed through annotations with num of character limits in Serpent (e.g. @name(...), @description(...), @line1(...), etc.)