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.
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! :)
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.
--
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.
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 :)
*we* weren't as productive in Eve as we'd thought we'd be.
the model is sound, the ideas we think are pretty good ones,
For a large portion of what I did for the compiler, Eve was pretty magical.
but because of how we interact with Eve, it isn't that much better than Python.
a lot of branching and such going on it's not that simple.
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
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.
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.
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?
piecing together where everything came from and how it all fit together
--
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.
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:
to help confront essential complexity ... we can provide you the freedom to explore side paths while you try to find the "right" one.
Thousands of behaviors though?
see the behaviors that affect my player's health.
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.
Sometimes you just need to do something mindless and repetitive to allow the difficult things to ferment.
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.
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 :)
We've got a new demonstration for you today (gif available at https://imgur.com/a/QphEU)
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.