Prototyping Eve's UI

[co...@kodowa.com]

Hey Everyone,

We’ve been heads down thinking of ways to make Eve easier to use based on all of your feedback and we’ve got some early ideas that we’d like to share. For this round, we started from the concept that the database explorer should be the primary interface for Eve and that writing programs is really a side effect of exploring the system. Here are some early videos of the direction we’ve been going:

First up we have the direct manipulation of records. The record here is a button, and we can see its attributes and values in its associated card.

Here's a more recent video of the events interface (click image for video):

We've also added a decision tree component, that allows you to define sequences and branching logic (click image for video)

Finally, we have some work hot off the presses, showing the bouncing ball demo being built in this interface (this is just a still, click the image for a full-size view):

We’re aiming to have this be a big highlight of the release we want to do by the end of October, but in the meantime we’ll be sharing sneak peeks every couple of days to get some feedback and keep everyone in the loop. So as we go, let us know what you think! And here’s to the next version of Eve! :)

[Zubair Quraishi]

I saw a twitter video a couple of weeks ago with Eve and a scrolling debug UI that looked pretty good, looks very differentt to these though

[co...@kodowa.com]

Zubair,

That interface was an editor Josh was prototyping for the text interface. The one shown here is indeed a new direction.

I think elements from that prototype editor will be useful in this new context as well.

Corey

[H. Ryan Jones]

The first demo is pretty interesting. A couple questions there:
- it looks like you put an action on the click, but then it's still showing up as a lightning bolt afterwards, shouldn't it show the action there?
- are there thoughts to using autocomplete? (esp for the button/size aspect)
- it seems strange that the count variable (record?) doesn't update from 0 in the table despite it changing the size and text

Excited to see where this goes :)

--
You received this message because you are subscribed to the Google Groups "Eve talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eve-talk+u...@googlegroups.com.
To post to this group, send email to eve-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eve-talk/1b77a5e3-bfab-4fb6-a153-a84b634e8835%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Felix George]

Looks awesome.  Can you see guys doing entire apps in this GUI?  Or, it is supplemental?  I'm assuming this view wouldn't be appropriate when writing server-side code only for headless Eve?.....

[Zubair Quraishi]

I think I'll have to wait until I see these UI demos you posted here in context of developing an applicaiton before I comment further, so if I see a todo app or something devleoped with them

[Chris Granger]

@Ryan the first image is the earliest of all of them and so is missing a lot: 

- Yep it'll indicate the behavior somehow, we're still working out the best small representation for that. 

- Definitely, you should need to type very little in general. To put that to the test, we're actually trying this on a phone as well as a desktop.

- It just wasn't implemented in that one, the later ones all do the right thing.

@Felix We think this approach works just as well for non-UI things as UI and we've been doing (and will continue to do) lots of mockups for things that aren't UI-y. The interface here makes everything a lot more concrete, but the semantics are largely the same as all the recent incarnations of Eve. Realistically, all this UI is is the database explorer with the ability to very directly describe what you would normally put in a block. Those property lists are the definitions of tags and their associated attributes/values, which represents several blocks worth of code all at once in a much easier to digest fashion. One thing that's important to make this fully general purpose that isn't shown in those screenshots is being able to throw together first-class sets, but that coupled with the attribute lists and decision trees lets you do everything you can do in the Eve syntax, but much more cleanly.

@Zubair Yeah, we expect this to be a very "show don't tell" kind of thing, so we'll keep posting new bits every couple of days so folks can see them. Once it gets a little less rough around the edges, we'll put it up so that people can play with it too. :)

Cheers,

Chris.

--
You received this message because you are subscribed to the Google Groups "Eve talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eve-talk+u...@googlegroups.com.
To post to this group, send email to eve-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eve-talk/d7f52140-cd1a-45e8-80b5-9eded5bff3fe%40googlegroups.com.

[Chris Granger]

Just as a follow-up, one of the big reasons we're doing this is because *we* weren't as productive in Eve as we'd thought we'd be. Before I started this prototype, I was working on writing an optimizing compiler to take Eve code and turn it into Javascript and LLVM IR using Eve itself. I initially did the compiler prototype in Rust, which was "ok" - Rust's lack of dynamism makes some compilery things pretty rough, but it wasn't awful - and then tried the same thing in Eve. For a large portion of what I did for the compiler, Eve was pretty magical. Things largely just worked, Eve got me to think about the problem in a slightly different way which ended up in a much better design, and it was trivial to visualize the state of the compiler thanks to the way blocks work. 

But there were some bad parts too. In something as complex as a compiler, despite having written the whole thing in a nice literate style, I had a hard time piecing together where everything came from and how it all fit together. Eve's compositionality means that I should be able to just throw things in as I want, but when those pieces all need to interact meaningfully and there's a lot of branching and such going on it's not that simple. There was no single organization of the code that would fit to make the compiler obvious and easy to work with. It read a bit like a book, but that didn't help me before the "book" was fully written. 

Josh was experiencing similar things as he was building out the database explorer that he showed in the snake example. We had this amazing set of semantics, but using Eve in the large just wasn't right yet. Blocks felt heavyweight and when certain things went wrong (especially around commits) it was very hard to figure out why. Lots of the feedback we've gotten on Eve so far can be boiled down to the way you work with Eve right now is confusing and opaque - this is why everyone's so excited about the database explorer - but there's something deeper there that folks like William Taysom have been hinting at.

If we think about the real goal of Eve, it has nothing to do with runtimes, or UIs or any of that. The real goal is to make going from an idea to something that works on a computer as fast and easy as possible. If I dream something up, whether it be a little phone app or a binary decoder, the amount of time it takes me to go from the idea to something that works should be close to the time it takes me to really figure out what I want. Time I spend beyond refining my idea is time wasted on "incidental complexity" - things I have to do as a result of the medium I am working in instead of the actual problem.

At its most basic, I have to do two things to make something. I have to explore what my idea really is and I have to encode it into something that's meaningful to the computer. Prototyping environments like pen and paper have very low encoding overhead and so make the first part much faster, but it's actually more than that - they don't just make it easier, they fundamentally enable you to explore in ways that would otherwise be impossible. Tools like Framer help people try and achieve something similar for animation prototypes and the like. In those cases, the job of the tool isn't to produce the end product, but to help you discover what the end product even is. Without being able to see it or experience it, you're basically just throwing darts in the dark.

Because of the cost of encoding in modern programming environments (even Eve up to this point), you're left staring at an incredible cliff just to try some simple thing out, much less make it "real." If we ignore what we've done for a moment, that's the problem that needs to actually be addressed. That's what makes programming awful.

With these larger programs, we realized Eve in all its awesomeness didn't currently help us as much as we expected it would. Some things are much nicer in Eve than they are in say Python, but some things are much harder too. The question is whether that's fundamental to our approach or just our implementation. After lots of deliberation, we think it's the latter - the model is sound, the ideas we think are pretty good ones, but because of how we interact with Eve, it isn't that much better than Python.

A while back I asked a question on Twitter - what if you could build a complete functional clone of FourSquare in a day? There are lots of angles you could take on that question, but the most relevant one here isn't about how the industry changes or what that means for software engineering, it's what that means for us as individuals. What could we do if the system you worked with didn't just make the cost of encoding very low, but helped you explore your idea as well? What would it mean if you really could build your entire idea in a day? The reason we started going down this UI is that we think it could be a viable path to that reality.

It's not going to be obvious until the UI gets further along, but its purpose is to make working with Eve not just more pleasant, but to drastically reduce the incidental complexity. Not sure if you folks remember, but in several of my talks over the years I used the example of an "incrementer button" to show how ridiculously complex programming is. It's the simplest "real" UI program we could come up with - a button that shows the number of times it's been clicked. When we asked career programmers to make that button it took several of the better engineers I know 20-30 minutes. With this incomplete, not very good prototype, I did it in 13 seconds. The goal is to make it so that that extends to pretty much anything you want to do - that you can go from the idea to the result in the time it takes you to figure out what you want.

[Zubair Quraishi]

Wow, I really loved this reply, and yes, I agree, the issue is about how to make it that Eve works "in the large" for bigger types of systems too. Just out of interest, do you think things like Wix Code could ever scale to large scale apps?

[Pascal Bergmann]

Thanks for the insight, Chris. It's all about productivity. I already got excited to see business app builders like Odoo Studio (https://youtu.be/xCvFZrrQq7k). It shows how something that had to be coded in XML and Python before becomes an order of magnitude easier and faster. Having something like that on a lower level... Wow! Eve will have a big impact!

Personally, I think the early prototypes of Eve (the GUI centric ones) felt more accessible than the current version. Taking a look at how accessible languages (e.g. Python) grew recently, I think that might be an important differentiating factor. The graphic interface shown above feels like a big step in the right direction.

Looking forward to October to try out the explorer :)

[julian...@gmail.com]

Hi.
I'm greatly relieved to see Eve heading in this direction.
Thanks

[William Taysom]

Hello Friends,

Better weigh in as @Chris has gone straight heart of it.

*we* weren't as productive in Eve as we'd thought we'd be.

Same feeling in my various forays amounts to a big, red, blinking flag.  

the model is sound, the ideas we think are pretty good ones, 

Eve has real foundation while still being far from a 1.0.  Let's take inventory.

For a large portion of what I did for the compiler, Eve was pretty magical.

Absolutely!  Data structure and flow choices?  Gone.  Matching and annotating graphs?  Trivial.  Nanopassing http://nanopass.org/ with Eve must be a real pleasure.

but because of how we interact with Eve, it isn't that much better than Python.

In both code transforms invisible state.  Eve improves the transformation in some respects, but the state still is invisible.

a lot of branching and such going on it's not that simple.

Things get branchy for me with Eve when I'm hankering for user defined functions.  Have I missed them along the way?  Maybe it's my Prolog speaking, but I want to say:

  search
    start <= stop
  bind
    start = range[start, stop]
  end


  search
    result = range[start, stop]
  bind
    result = range[start - 1, stop]
  end

I had a hard time piecing together where everything came from and how it all fit together. ... compositionality ... just throw things in

With Eve rules matching anything anywhere, it's easy to make a mess.  There's a legend that imperative programmers when confronted with the mess turned to object-oriented encapsulation trading chaotic freedom for bureaucratic bondage.  Instead of one machine with many moving parts, ship stationary parts between departments.  Is there an alternative to Kafka's choice?

Choose freedom.  Accept spaghetti tangles.  Touch the noodly appendage.  Gaze into the abyss.

Selfish http://www.selflanguage.org/ direct manipulation (what we see in @Corey's images) helps you get started – even all the way through some projects.  In the end complexity comes for you.

Form building with @Pascal's Odoo, charts with Tableau https://www.tableau.com/, even grandpa HyperCard http://hypercard.org/ can take you great places.  Even overcoming the tradeoff between ease and capability https://vimeo.com/66085662 in the end complexity comes for you.

Prototyping environments like pen and paper have very low encoding overhead and so make [exploring] much faster, but it's actually more than that - they don't just make it easier, they fundamentally enable you to explore in ways that would otherwise be impossible.

Including ways that will never work!  A pencil doesn't check whether your equations make sense.  Be you an the associate analyst, a capable consultant, a seasoned spec writer, an elder economist, in the end complexity comes for you.  Often in the from of a software developer.

Time I spend beyond refining my idea is time wasted on "incidental complexity" - things I have to do as a result of the medium I am working in instead of the actual problem.

How do you tell incidental from intrinsic complexity?

Did you find an answer on Stack Overflow?  Incidental.

Was boilerplate involved?  Incidental.

Is there more than one obvious way to do it?  Incidental.  Suggests there isn't a clear choice for how the idea is represented in the medium.

Did you step away from the computer to take a long shower?  Intrinsic.  Suggests that the mental model was missing an important detail.

Did you then pound the wall in frustration?  Incidental.  Suggests that the idea is fixed, but that the artifact is going to take tedious effort to adjust. 

Did you weep in despair?  Intrinsic.  Suggests that you don't know how to proceed.

With software development, the kinds of complexity bounce off each other so much that it's hard to tell which is which and ultimately it doesn't matter.  In the end complexity comes for you.

Reducing incidental complexity is not enough.  It can actually make the experience worse.  Where incidental complexity may pose an external puzzle, intrinsic complexity forces a person to face their inadequacy.  Meditative manual manipulation gives way to brain racking.

What could we do if the system you worked with didn't just make the cost of encoding very low, but helped you explore your idea as well?

Exploring ideas means confronting complexity and its cousin confusion.  Encoding has a cost, but the real cost comes from finding that the thing encoded isn't what you want.  What then?  How fast can you iterate?  Helps, but we can do better than gradient descent.  Step back, survey the terrain, then press forward.  That's what good visualization gives us.  Consider:

piecing together where everything came from and how it all fit together

The damn computer knows where everything came from because it had to piece it all together to run the program in the first place.  Just remember what happened and give the programmer an overview.  The more data the less detail you can show; but the more data, the more full the picture.  For example, instead of showing records change over time, focus on rules, showing records being passed from one to another.

Better leave it at that,

William

[Chris Granger]

@Zubair It kind of depends on how we define scale. One useful way of thinking about it is if we imagine all the things that only number in the single digits became thousands. So in the UI shown above, thousands of cards, with thousands of attributes, and thousands of behaviors. The question then is can the system support working with something like that? In Wix's case I'm not sure. I wasn't able to find much about it, but I suspect the answer is no - from what I can tell its a small set of domain specific actions (web-pagey things) with a fallback to blocks of Javascript. That's unlikely to scale better than just a regular old JS project would due to the impedance mismatch that having blocks of JS spread out everywhere causes. Likewise, it'd probably be crazy to try and do something like gmail in it. Wix's use case is very That being said, Wix doesn't necessarily have to scale to something like gmail - it has chosen a very narrow domain (mostly static websites) and within that domain it probably scales up to the largest things people tend to do. It does, however, suffer from the general purpose cliff problem most systems like that do. Wix is super easy until you get to the point where you need to write code, at which point, you're faced with an incredible barrier to entry - you have to become a programmer.

 @Pascal Odoo's marketing is... intense. Everything is the best most epic thing ever made haha. There's a lot of power in that approach and it's something we lost when Rapid Application Development tools fell out of fashion for whatever reason. There's no doubt that the GUI's were more accessible than the text syntax/model is, but none of them really worked to the extent they needed to. They also weren't very fun to use. This one is a much better direction than any of those were I think, in that not only is it much more general and efficient, but it's really neat to play around with so far.

@William Complexity does come for us all and it's something we've been very deliberate in thinking about as we move forward with this approach. As I mentioned to Zubair, it's interesting to imagine what happens when we apply the everything in the thousands test to this prototype. Thousands of cards is fine, they all live in the ether and can be summoned at will. Thousands of attributes is fine as long as there's a mechanism for grouping. Thousands of behaviors though? That seems pretty scary and not outside of the realm of possibility. Manual semantic grouping might help there, but we can do better. In general you tend to only care about the behaviors that affect specific things at any one point in time and as you said before, the computer knows exactly where everything comes from. There's no reason why we can't give you tools to take context into account, e.g. I only see the behaviors that affect my player's health. Ultimately there only two cures to complexity, make it less likely to crop up by providing abstractions that are only as powerful as necessary to accomplish your goal (any more powerful and you're inviting complexity) and giving you ways to slice the system up such that no single view through your pinhole is ever that complex. If you truly have thousands of behaviors that affect the health of the player, unfortunately there's not much that can be done - that is  the essential complexity of your domain and you have to stare into the abyss. I'm willing to argue that's fairly rare though. The problem is our tools tend to make seeing that and doing anything about it very difficult. This UI is designed to do the opposite, we want to make it apparent what affects what and when things start getting pretty complex. We also have some really interesting idea on how we can enable you to make sweeping changes to the whole system without fear and how you can reorganize and reuse things without being perfect from the start. As you said, there's no stopping complexity, but assuming you have all the information, there are ways to wrangle it. We *can* build tools that let us manage large systems efficiently, but it requires designing for that case up front. I'm very excited to see where we end up.

> Where incidental complexity may pose an external puzzle, intrinsic complexity forces a person to face their inadequacy.  Meditative manual manipulation gives way to brain racking.

That is a wonderful insight. It's the reason for fidget toys (our office is full of them) and why cleaning the house or going for a walk is a one of the best things you can do. Sometimes you just need to do something mindless and repetitive to allow the difficult things to ferment. I'm not sure that the incidental complexity in programming really helps much though, since it's complex enough that in many projects *it* becomes the vast majority of the complexity of the system. The question is can the environment give you enough things to fidget with and explore in order to arrive at your answer. In a traditional text environment you're not really given much. You can make changes, but the change cycle is usually pretty expensive, even if it's "only a few seconds." I think one of the best things we can do to help confront essential complexity is to never leave you at a loss. To always give you somewhere to go or something on the screen to fiddle with. There should never be a case where it feels like you are just stuck with nothing else to try. That's not to say we can provide a path where everything you do is directly accomplishing your goal, but we can provide you the freedom to explore side paths while you try to find the "right" one.

 

--

You received this message because you are subscribed to the Google Groups "Eve talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eve-talk+u...@googlegroups.com.
To post to this group, send email to eve-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eve-talk/f92af601-c21f-4b45-8802-84e58287fff7%40googlegroups.com.

[ruben.n...@gmail.com]

Speaking to the idea of managing a lot of behaviors I wonder if an editor interface that treats behaviors as connected blocks.
e.g. Code Bubbles, Quartz Composer, etc.
(I don't envision this editor being the only way to edit code.)

Some of the problems with that system is that because it is 'visual programming' it scares away some programmer. 
It is also tedious and error prone to connect blocks as the inputs and outputs tend to be small connection points.

One way this could be improved is that the arrows between behaviors can be dynamically generated as if I understand the optimizer that Chris wrote correctly it already does it this work: https://twitter.com/ibdknox/status/898245177243869184. They could also be highlighted to show how an action in a behavior effects other behaviors. 

Here is a quick mockup of this idea:

[William Taysom]

@Chris Thank you for your thoughts.  Could not agree more.

to help confront essential complexity ... we can provide you the freedom to explore side paths while you try to find the "right" one.

Plays to a human strength.  When we can imagine a path, we're remarkably good at picking a good one.  Consider how people are relatively better Go players than Chess players.  The constantly moving pieces of Chess make for a twisted state-space.  Since Go stones only move on capture, I person can prune and lookahead very effectively.

Thousands of behaviors though?

I suppose UIs have the convention of the beloved top-of-the screen menu where the actions go to hide in a submenu – or better yet – within a dotted "But Wait There's More..." item.  A quick look through Excel's menus shows about 50 ellipsis triplets.

see the behaviors that affect my player's health.

Like contextual menus or the right-side inspector column?

cures to complexity, make it less likely to crop up by providing abstractions that are only as powerful as necessary to accomplish your goal (any more powerful and you're inviting complexity)

Magic when it's tight.  Leaky on a good day.  And treatment worse than the condition far too often.  Abstraction requires indirection meaning you have at least two things where before you had one.  They might be simple untangled things; but it can quickly become more tangled than when you started.

and giving you ways to slice the system up such that no single view through your pinhole is ever that complex.

Pinholes yes – or fuzzy lenses.  When you can't see all the details, you may end up seeing what really matters.  Something about forests and trees?

Sometimes you just need to do something mindless and repetitive to allow the difficult things to ferment.

My mechanical engineer friends seem to spend endless hours rotating models.

Some of the problems with that system is that because it is 'visual programming' it scares away some programmer.

@ruben Scratch https://scratch.mit.edu/ reveals exactly how much overhead freeform syntax imposes.  When I first tried Scratch, I was shocked by how easy block structured programming with draggable blocks is!  Instant convert from skeptic to true believer.  "Everyone budding programmer should start with this," I thought.  And those were Scratch's early days.  Now with broadcast blocks, lists, variables, sprite cloning, and custom blocks, I feel the software has years of curriculum potential.  Wax on.  Wax off.

It is also tedious and error prone to connect blocks as the inputs and outputs tend to be small connection points.

Node-based programming seems to thrive best in domains where tedious point connection is already the norm.  Consider Archimatix https://www.youtube.com/watch?v=W7NhIE2Tx_I for example.  Besides keeping a sort of log of steps, node systems often show intermediate results.

[co...@kodowa.com]

We've got a brand new demo for you today. In this video, Josh demonstrates building the bouncing ball program (thanks Felix H.):

We'll be posing more soon!

Best,

Corey

[Pascal Bergmann]

Hi Corey,

interesting approach!

What about instances of objects? In your demo you create several balls, but the pane on the left only shows the master object. I guess in future versions you'd simply click on a ball to inspect it's state?

I really like the behavior-panel. Feels like a good explanation of why the instance does things, helping handling complexity.

Hm... I think I'll just watch that demo one more time :)

[Zubair Quraishi]

Very nice demo! I still don't know how all the developer UI panes fit together but it is starting to feel "right"! Is the Component - Entity model an inbuilt part of Eve 0.4?

[co...@kodowa.com]

We've got a new demonstration for you today (gif available at https://imgur.com/a/QphEU)

This demonstrates the prototype interfacing with hardware (a webcam) and an external library (OpenCV). I don't think we've demonstrated anything like this before.

Pascal,

> What about instances of objects?

This is something we're trying to address now: how do you talk about a single ball versus all the balls? Clicking on a single ball will bring up a a property grid for just that ball, but then we need to be explicit about whether the adjustments you make to that grid apply to all the balls or just the one. We'll try to show something like this in a future example.

Corey



On Monday, September 18, 2017 at 5:59:02 PM UTC-7, co...@kodowa.com wrote:

[William Taysom]

Clicking on a single ball will bring up a a property grid for just that ball, but then we need to be explicit about whether the adjustments you make to that grid apply to all the balls or just the one. We'll try to show something like this in a future example.

 

The OmniGraffle selection matrix comes to mind <https://support.omnigroup.com/doc-assets/OmniGraffle-Mac/OmniGraffle-Mac-v6.3.0.0/en/EPUB/art/og61_selectionmatrix_callouts.png>.  It's not the best thing ever, but it is suggestive – differentiating objects based on their properties.  What if one had a similar tool, but instead of manually flipping on and off properties to group by, the system could guess.  Suppose you select two balls.  Their shape and color is the same, their positions differ.  So the system could suggest, to the side, selecting all balls of similar shape and color.  (A digression into machine learning lurks nearby.)

[Pascal Bergmann]

Will there be an update about the UI in this months blog post? =)

[simonh...@hotmail.com]

It sounds like the problem here is that the assumption is that the tools for understanding the program need to be the same as those used for building the program. But what if you made the debugger provide different ways to query the program code, and the program state? If you can provide views that show how a bit of data propagates through the system, which rules get invoked and how the code changes, that should help things. And this UI you are prototyping seems to be moving in the right direction. While I think you need to settle on a single core language, and it sounds like you've pretty much nailed that, I can see the use of many views on top of that model, both in how the programs get created and also how they are understood. Declarative languages typically require very different approaches to debug them, I debug SQL in a very different way than some .net or java code, same with debugging jquery code. So I do think you are right that different tooling is the answer, but that should probably extend to debugging the program and understanding it's state. When i've thought about improving programming in the past, i've thought about adding tools that allow you to query, interactively, the program's state both over time and at points in time, and figure out the lineage of each variables value, and the statements that impacted it's state changes over time. The code as well as the data should be queryable. I feel that thinking along those lines can help you solve these problems.

Finally, whatever solution you come up, there is a certain unavoidable level of complexity in software systems that you will be unable to avoid, no matter how clean the language is, as you've talked about before. So realizing that, you need really good ways of navigating that necessary complexity, so providing different views on top of the  program that allows you to view the system from different levels of abstraction i think it critical to building more sophisticated systems, and I don't think literate programming can necessarily help you get there. How you do you reason about the code on a system level, the way you've reason about a complex enterprise system as a set of APIs interacting, or a GUI as the data flows between different windows? Understanding complex software involves being able to reason about it at different levels of abstraction, from the module level up to the system level, and you need ways to support that.

On Monday, September 18, 2017 at 7:59:02 PM UTC-5, co...@kodowa.com wrote:

[William Taysom]

Good points Simon. It is nice when tools for understanding play well with tools for authoring. Alas, tricky coordination between the two often limits how far people take tools for understanding.