Show HN: Don't code your UI, draw it • Hacker News Board

Re: Show HN: Don't code your UI, draw it

#111

Post by qwerty456127 » Mon, Nov 19, 2018, 4:51 AM UTC

vthriller wrote: post #99

madeofpalk wrote: post #83

Earlier quoted context omitted.

> Yes. We had drag and drop UIs decades ago. We had _simple_ drag and drop UIs decades ago. Computers operated within a lot more limited constructs back then. UI windows didn't resize, or it was reasonable to expect that they're fixed. How did those drag and drop tools back then handle creating a UI for screens ranging from 400pt wide to 2560pt wide?

> How did those drag and drop tools back then handle creating a UI for screens ranging from 400pt wide to 2560pt wide? For simpler forms you'd just set anchoring properties of the widgets in question (akRight/akBottom in Borland's VCL or whatever its counterpart is called in WinForms or what was its predecessor). Nowadays it's even easier with things like, say, GTK's HBox/VBox. > Computers operated within a lot more…

> 400pt wide to 2560pt wide

There are 2 major strategies for responding to such a difference:

1. Vector scaling. It will make the difference irrelevant and the resulting UI will look approximately the same on whatever a resolution.

2. Capacity scaling. I.e. keep the same font letting more information to fit in the control without scrolling.

It may be a little bit hard to formalize but these two can be combined intelligently. It is also important to know which one the user prefers (e.g. I mostly prefer the second while many prefer the first).

Re: Show HN: Don't code your UI, draw it

#112

Post by karanchahal » Mon, Nov 19, 2018, 5:05 AM UTC

jongold wrote: post #104

zeroname wrote: post #53

Earlier quoted context omitted.

Don't get excited. The thing that this demo shows in minutes could've been typed up in text in seconds . It is not a productive way to do things. There's a reason that these systems never catched on, they are unnecessary. You may say, but "non-programmers" will use it! No, they won't. Designers will use real design tools to create (non-functional) visual designs. Programmers will bring those visual designs to functio…

Yo - I did the Airbnb project linked ^^^ which I believe was the first of this wave of deep learning-powered sketch->UI projects (though standing on the shoulders of decades of R&D projects) Our take was that we really do design on paper or whiteboard first & foremost, which is why our project emphasized the webcam + sharpie thing rather than drawing in-browser etc. Here's a related thing I wrote about the need for d…

Hey ! I'm a big fan. Obviously this project as it is constructed currently isn't much. But the idea that machines can learn the code behind what artists draw is especially intriguing. I also think we'll get there is due time, with the great work being done on GANS and better scene understanding algorithms coming out. I was inspired by your team's idea, even won a Hackathon with this idea ! Thanks for your contribution, I'm a big fan

Re: Show HN: Don't code your UI, draw it

#113

Post by karanchahal » Mon, Nov 19, 2018, 5:07 AM UTC

leowoo91 wrote: post #81

karanchahal wrote: post #61

Earlier quoted context omitted.

Hello, thank you for your interest ! I have fixed the repo structure and added instructions on how to build and run. Hopefully that is fine, if not please tell me about it and I shall update it as soon as possible.

Thank you for fixing, I think it's close. Now, flask says "index.html" is missing :-) also step 2 should have "pip3 install -r" instead of "python3 -r".

Ah yes, I'm at work now. I'll fix that as soon as I get back, though that will probably be after a few hours.

Re: Show HN: Don't code your UI, draw it

#114

Post by kartickv » Mon, Nov 19, 2018, 5:11 AM UTC

nnq wrote: post #49

jfolkins wrote: post #32

Earlier quoted context omitted.

It sounds like you don't. But many in my org come to me with an idea, and having them think through the logical pieces and build a functional wireframe would help under resourced people like me so much. Also, many people just think that business logic for sanitization and validation "just happens." The barrier to wireframing, for them, is too high so they don't. But in this idea, I could see someone submitting a wire…

> many people just think that business logic for sanitization and validation "just happens." The barrier to wireframing, for them, is too high so they don't Maybe the barrier is where it should be. Or maybe it should be even higher! People who can't understand the logic of an interface have no business creating or suggesting interfaces. An UI is meant to be used, not looked at like a pretty picture in a frame. It sho…

I take your point about usability as opposed to visual design, and that many slick-looking UIs actually lower productivity.

But:

In this example, unless not handling international phone numbers leads to failure of the project, that can be handled later, say once the project is approved and time estimation is being done. If I'm building a notes app, and someone is proposing a new sign up form to increase conversions, and it has a phone number field, handling international numbers is the last thing to worry about at this stage (unless international numbers are a significant problem with the old form leading to abandonment).

We shouldn't doom good ideas with irrelevant details, which are absolutely relevant later, but not now. Product development happens in phases of increasing fidelity, and issues need to be brought up at the appropriate time, not too early, not too late.

Re: Show HN: Don't code your UI, draw it

#115

Post by kartickv » Mon, Nov 19, 2018, 5:21 AM UTC

jfolkins wrote: post #32

taeric wrote: post #27

Earlier quoted context omitted.

Odds are high, mine would look worse. I'm not exactly an artist. Unless you mean just sketch using graph paper and translating coordinates. Not sure why I need a camera for that. :(

It sounds like you don't. But many in my org come to me with an idea, and having them think through the logical pieces and build a functional wireframe would help under resourced people like me so much. Also, many people just think that business logic for sanitization and validation "just happens." The barrier to wireframing, for them, is too high so they don't. But in this idea, I could see someone submitting a wire…

I agree with your main point about empower people.

It seems that people are coming to you to help estimate how long an idea takes to implement. If that's the case, I agree with everything you've said.

But if they're proposing an idea, say a new sign up form to increase conversions, phone number validation is an irrelevant detail to worry about at this point (unless that was a significant problem with the old sign up form).

Re: Show HN: Don't code your UI, draw it

#116

Post by int_19h » Mon, Nov 19, 2018, 6:48 AM UTC

vthriller wrote: post #99

madeofpalk wrote: post #83

Earlier quoted context omitted.

> Yes. We had drag and drop UIs decades ago. We had _simple_ drag and drop UIs decades ago. Computers operated within a lot more limited constructs back then. UI windows didn't resize, or it was reasonable to expect that they're fixed. How did those drag and drop tools back then handle creating a UI for screens ranging from 400pt wide to 2560pt wide?

> How did those drag and drop tools back then handle creating a UI for screens ranging from 400pt wide to 2560pt wide? For simpler forms you'd just set anchoring properties of the widgets in question (akRight/akBottom in Borland's VCL or whatever its counterpart is called in WinForms or what was its predecessor). Nowadays it's even easier with things like, say, GTK's HBox/VBox. > Computers operated within a lot more…

In WinForms, it's still called Anchor (it really did take a lot from VCL), but since enums are scoped in .NET, you have Anchor.Left, Anchor.Top etc.

WinForms also had Dock (Left, Right, Top, Bottom, or Fill) which basically forced the control against that edge of its parent, taking up full length and/or height accordingly in one dimension, and using the explicitly specified size in the other. With multiple controls with Dock, they'd gradually fill the available space in Z-index order, stacking up against each other; then whatever control had Dock=Fill, would fill the remaining space.

So yeah, resizable windows were common, and easy to deal with. The real problem is dynamically sized controls themselves, e.g due to DPI changes, or because the control contains dynamic content of unknown size. With those, anchors no longer work well, and you need some kind of box and grid layouts. Which are available - but it's kinda hard to edit them visually in a way that's more convenient than just writing the corresponding code or markup.

The closest I've seen to visually editing UI that can accommodate dynamically sized controls was actually in NetBeans, which had its own layout manager for Swing. That thing allowed you to anchor controls relative to other controls, not just to the parent container. Thus, as controls resized according to their context, other controls would get moved as needed:

https://netbeans.org/kb/docs/java/quickstart-gui.html

https://youtu.be/_ZW4ktG1DEE?t=129

Still, you needed to be very careful in the UI form editor, to make sure that controls are anchored against other controls in ways that make sense.

Fundamentally, I think the biggest problem with UI designers today is that they can't really be WYSIWYG, the way they used to be in the RAD era. The DPI of the user machine might be different, fonts might be different, on some platforms (Linux) themes can be different in ways that drastically affect dimensions etc.

Re: Show HN: Don't code your UI, draw it

#117

Post by int_19h » Mon, Nov 19, 2018, 6:52 AM UTC

ZenPsycho wrote: post #109

sien wrote: post #91

Earlier quoted context omitted.

The idea would be that WASM will facilitate a particular language with a good standard library would be used to create an easy to use GUI drawing and then coding setup. But yes, it wouldn't support every language that could compile to WASM and you're right that would be even harder than creating a good tool for Javascript.

Such "easy to use GUI drawing libraries" would still need to be written in javascript. If you want actual things to appear in the browser you still need to interact with the DOM, which is actually harder with WASM, not easier. And while it's technically possible to say, just compile QT to wasm and give it a CANVAS tag as a dumb drawing surface, you've just broken accessibility, and that's a deal breaker.

Then we need APIs that would allow GUI frameworks that render onto to support accessibility. Such APIs have existed on desktop platforms for decades now, and popular frameworks like Qt use them, even when they draw all the widgets themselves.

By the way, Qt-on-wasm-on-canvas is already a thing: http://blog.qt.io/blog/2018/05/22/qt-for-webassembly/

Re: Show HN: Don't code your UI, draw it

#118

Post by int_19h » Mon, Nov 19, 2018, 6:58 AM UTC

blattimwind wrote: post #46

Retric wrote: post #44

Earlier quoted context omitted.

This really depends on how the UI designer does layout. Nothing says you need to allow users to do absolute positioning vs rule based when someone drags stuff around. You can help this along with multiple common views at different resolutions, so users don’t try and force a pixel perfect version.

It's funny how web development still doesn't offer the ease and productivity of early 2000s RAD environments. Even this software is actually not simpler, on the contrary: It is far more complex, because you don't know how to create a given widget [assuming you already learned what widgets there are, because the software doesn't tell you]. You have to learn what the software recognizes and how you need to draw it in m…

Early 2000s RAD environments had a much simpler model to work with, that didn't accommodate things like changing the size of widget's contents well. If all you needed was a button of a fixed size, that would always stay in e.g. the bottom right corner of the window, they could do that. If you wanted a button that would automatically resize as its label grew longer, some of them could do that too (pretty much every framework could do it for labels, but many couldn't for other widgets).

But the moment you wanted something like: there's two buttons, one following the other in the bottom right corner of the window, with a certain fixed spacing between them, but otherwise dynamically sized to content, it all broke down. And this just happens to be one of the most simple scenarios, just a basic dialog box with "OK" and "Cancel"!

How did it work in practice? We just made widgets "wide enough" to fit anything that could conceivably be thrown at them. If later that assumption was proven wrong - e.g. because translators came up with a very long string for the label - then the developers would have to go back and redo the UI.

Re: Show HN: Don't code your UI, draw it

#119

Post by pjmlp » Mon, Nov 19, 2018, 7:11 AM UTC

int_19h wrote: post #116

vthriller wrote: post #99

Earlier quoted context omitted.

> How did those drag and drop tools back then handle creating a UI for screens ranging from 400pt wide to 2560pt wide? For simpler forms you'd just set anchoring properties of the widgets in question (akRight/akBottom in Borland's VCL or whatever its counterpart is called in WinForms or what was its predecessor). Nowadays it's even easier with things like, say, GTK's HBox/VBox. > Computers operated within a lot more…

In WinForms, it's still called Anchor (it really did take a lot from VCL), but since enums are scoped in .NET, you have Anchor.Left, Anchor.Top etc. WinForms also had Dock (Left, Right, Top, Bottom, or Fill) which basically forced the control against that edge of its parent, taking up full length and/or height accordingly in one dimension, and using the explicitly specified size in the other. With multiple controls w…

> Fundamentally, I think the biggest problem with UI designers today is that they can't really be WYSIWYG, the way they used to be in the RAD era. The DPI of the user machine might be different, fonts might be different, on some platforms (Linux) themes can be different in ways that drastically affect dimensions etc.

WPF and UWP can deal with it perfectly fine.

Re: Show HN: Don't code your UI, draw it

#120

Post by pjmlp » Mon, Nov 19, 2018, 7:16 AM UTC

ZenPsycho wrote: post #109

sien wrote: post #91

Earlier quoted context omitted.

The idea would be that WASM will facilitate a particular language with a good standard library would be used to create an easy to use GUI drawing and then coding setup. But yes, it wouldn't support every language that could compile to WASM and you're right that would be even harder than creating a good tool for Javascript.

Such "easy to use GUI drawing libraries" would still need to be written in javascript. If you want actual things to appear in the browser you still need to interact with the DOM, which is actually harder with WASM, not easier. And while it's technically possible to say, just compile QT to wasm and give it a CANVAS tag as a dumb drawing surface, you've just broken accessibility, and that's a deal breaker.

Native toolkits also support accessibility.

And while accessibility is a big issue, I must sadly acknowledge that I am yet to have a project require compliance and validate its implementation, as such it never gets done.