UI ideas

[Felix George]

I have seen the team report that CSS and HTML 5 is not the end game as far as UI is concerned.  I know it's still super early but what are the ideas moving forward?  Something along the lines of XAML/Silverlight (wishful thinking)?  Or a specific solution like the XML of android?  I was just curious about the general goal moving forward.  Are you planning to supply Eve with its own native UI paradigm or will it depend on html and css for the foreseeable future?

[Josh Cole]

Hey Felix,

We're definitely interested in providing something better than the status quo here. XAML is more in line with what we're thinking -- in a sense, XAML is like Eve-lite specifically for rendering UI. What we're missing right now is a strong component library and theme so you don't have to worry about manually managing divs unless you're trying to make something pixel-perfect. Even then, we think a visual editor will better serve you than a textual one for that. Flash is another inspiration for me. Before I really knew how to program, I hit the ground running making animations and games as a youth. I'd like to provide that same tangibility when you're looking to artistically compose something.

We're currently looking to flesh out a standard component library and have mocked up a couple passes at the visual editor, but we need to finish shoring up the runtime before we focus on that. In the interim, we'd love to have an open discussion with the community about what they're looking for when making UI.

What programs/frameworks/libraries do the job well?

What makes them good/bad? What could make them better?

What does your dream workflow (no matter how seemingly impossible) look like? What's halfway between that and what exists today?

[Felix George]

I find myself in need of a fleshed out component library that includes a Listview (virtualized to load only on-screen elements), Splitview (for left/right menu fly-ins with a hamburger icon) and pivots which would solve most page navigation use cases in that they would work in both desktop and mobile situations.   

When it comes to the larger question of what makes a UI framework work well?.....  Drawing from my experience with XAML, I can say that Expression Blend was a piece of software that made designing a UI very simple with loads of power underneath for the experienced developer.  XAML just works.  Separate the UI from the code but give the User Interface markup such power and ease of use, that you can choose how you want to make use of it.  It's simplicity was the hallmark.  And when it was time to do some animations, you could actually skip the code, if you needed to, and do some really incredible things with the XAML alone.  I really haven't seen anything like this outside of the Blend/XAML combination.  Specifically, you could:

-Embed animation into the markup itself (no code needed)

-String together multiple animations with Story Boards rather effortlessly

-Eliminate the need for CSS because the markup describes the elements on screen as well as their styles and setting up templates is trivial

-use Blend as a live visual editor, embedding datasets to see your results in real-time

A dream setup would be the ease of use in UI development offered by XAML/Blend with the all-around simplicity and broad use cases of the Eve language.   Drag and drop components, style them visually or with the markup itself.  Import assets and use them immediately, and have the visual editor work real-time with your Eve records. The dream setup has no JavaScript.  Just Eve and a UI layer that is as much like XAML as possible.  Copy the whole thing wholesale and I'd be a happy camper, but at the very least please at least investigate it.  It's one of those systems I cannot find a fault with.   

[William Taysom]

-Eliminate the need for CSS because the markup describes the elements on screen as well as their styles and setting up templates is trivial

Eve's primary strength is the ability select nearly any record and add to it.  With that flexibly and power, CSS compares unfavorably to say the least.

[swthornton]

With my experience with WPF c# & XAML I would add my vote for XAML, I always found that separating the UI with XAML from the code-behind (C#) was a wonderful way of keeping my mind focused on the job in hand, I found it the clearest method of development I'd ever used - abstractions like this are critical to allow a programmers mind to be free to invent.

Steve

On Saturday, 13 May 2017 20:01:29 UTC+1, Felix George wrote:

[Joe Cancilla]

Hi Josh,

I'd love to find out what you've mocked up (or just have in mind) for the visual editor.

My dream workflow would be a 'direct manipulation programming system' like Ravi Chugh's deuce (but with Eve on the language side instead of lisp). http://ravichugh.github.io/sketch-n-sketch/blog/05-deuce.html

Make sure to check out his strange-loop talk if you haven't already:

https://youtu.be/YuGVC8VqXz0

Do you think Eve would be amenable to this type of system?

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

Here is my dream list of features of a UI framework:

1. Two way mapping between the elements and the code while in 'developer mode'.

1a. I should be able to change the code and see the change instantly and I should be able to grab a buttons edge and pull it larger and see the coder update.

2. Better nouns and verbs.

(i.e. The CSS properties  Padding and Margin are not self-describing.)

3. One way to do things. We need to move away from the mess that is CSS with 4 different ways to make things that all break in subtle ways.
(i.e. How do you layout something in CSS? Tables! Floats! Flexbox! Grids!)
3a. Honestly with this #1 might be impossible or a herculean task.)

4. Composable
4a. I should be able to compose code into widgets that are pure so that I can further compose those widgets into bigger widgets without fear.

Ruben

[Josh Cole]

@Ruben,

> 1. Two way mapping between the elements and the code

A visual UI editor definitely needs to happen. It's just a much smoother experience than working with text to make UI. We've done a little work on this in the past, but I actually don't think we took it far enough.

> 2. Better nouns and verbs

> 3. One way to do things

I'd also like to provide something a little higher level and less confusing than CSS, even if it does so by compiling down to it. That way we can provide a much smaller set of relatively easy to understand properties. Ideally, you can work primarily at the component level anyway, so you're just adjusting the default styling as necessary rather than writing it all from scratch.

> 4. Composable

This is a particularly interesting point to bring up. The cascading nature of CSS is pretty unpleasant to work with at times. There's a constant tension between bloating your HTML with a class for every single element and wrestling with specificity to get the right properties to apply. If we can fix just that problem alone, I think we'd have made styling at scale a much more tractable task.

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

@Josh

> 1. Two way mapping between the elements and the code 

 

A visual UI editor definitely needs to happen. It's just a much smoother experience than working with text to make UI. We've done a little work on this in the past, but I actually don't think we took it far enough.

I can understand the 'slowness' on this front. A lot of developers have a disdain for UI editors for a few good reasons:

1. Doesn't tend to work well with source control in that the output does not tend to be easily 'diff-able' or human readable.
2. Doesn't scale. Because of #1, you tend to have soft locks on UI files. 'Hey don't touch that UI file I'm editing it'.

3. Programmers are more comfortable with text over visual editors due to programmings current landscape.

All of those fall away if we have 1 to 1 mapping between text and the visual editor. I think it would help convince folks that visual editors are a 'good idea'.

I'd also like to provide something a little higher level and less confusing than CSS, even if it does so by compiling down to it. That way we can provide a much smaller set of relatively easy to understand properties. Ideally, you can work primarily at the component level anyway, so you're just adjusting the default styling as necessary rather than writing it all from scratch.

...

This is a particularly interesting point to bring up. The cascading nature of CSS is pretty unpleasant to work with at times. There's a constant tension between bloating your HTML with a class for every single element and wrestling with specificity to get the right properties to apply. If we can fix just that problem alone, I think we'd have made styling at scale a much more tractable task. 

I noticed I did a typo in my original reply that changed the meaning:

3a. Honestly with this #1 might be impossible or a herculean task.)

Is supposed to be:

3a. Honestly without this #1 might be impossible or a herculean task.)

What I mean is without one and only one way to do things making a 1 to 1 mapping between text and visual editor would be incredibly hard.

I think one of the main problems with CSS is that it's too low-level realistically for most UIs. Often times you do not need the power that it provides. One major problem is that often times you really only need Parent -> Child relationships with laying out UI. When you provide defining arbitrary relationships things get confusing fast. For example in iOS when Apple released Auto Layout, which is a Conway Constraint Solver based layout engine, they started with arbitrary relationships but later introduced 'Stacks' which are really just a Flexbox abstraction built on top of it because setting up UI through constraints is a minefield. (In that one bad constraint can throw a whole UI out of whack.)

But that is one of the things I'm starting to realize. Engineers will complain when they don't have the power to shot themselves in the foot, because 10% the time they think they need that power. Not realizing that constraints will make 90% of their work much easier. (See Rails, Functional Programming, C++ as examples of this pattern.)


Ruben

[Pascal Bergmann]

Maybe the way Flutter handles GUI definition isn't that bad: https://flutter.io/widgets-intro