7 comments in, and it's all ragging on this. Good job everyone
What’s the purpose of developing in the open if not to get feedback? A pat on the back and a attaboy doesn’t help anyone improve.
Show HN: Don't code your UI, draw it
31–40 of 148 posts
Re: Show HN: Don't code your UI, draw it
#32Earlier quoted context omitted.
What if you could sketch your UI with a stencil, paper, and pencil. Then take a picture of it and have it translated into native components?
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. :(
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 wireframe to me and my response being "well what happens when a phone number is international?" I'm educating stakeholders on the functional cost of producing their idea.
This would theoretically create a feedback loop for future ideas and initiatives as now, they've begun to be educated on the process. They have direct experience.
Anyway, anything to lower that barrier in order to partner with and teach my executives and their supporting staff would be a huge win. At least for me.
Re: Show HN: Don't code your UI, draw it
#33Re: Show HN: Don't code your UI, draw it
#34Codeless UI is so exciting! This reminds me of Ivan Sutherland's Sketchpad from the early 60s https://en.wikipedia.org/wiki/Sketchpad
Re: Show HN: Don't code your UI, draw it
#35Earlier quoted context omitted.
What if you could sketch your UI with a stencil, paper, and pencil. Then take a picture of it and have it translated into native components?
Now that is a super interesting idea. Create a flow scheme too so you can process transitions? flow:success f1:s1->f1:s2->f1:s3 flow:error f1:e1->f1:e2 edit: another thought is that this concept could encourage people in your org who struggle with wireframe technology to express their ideas. Generationally and across culture, smartphone use is now accepted. People also know how to draw on pencil and paper. Now all yo…
Re: Show HN: Don't code your UI, draw it
#36Rule based means I tell use instruction like "this button must be on top on that button horizontally centered", "this label must fit that text", "this image must be between this and that", etc... and let the layout engine deal with it. UIs are usually not paintings, window sizes vary, text length changes with localization, decorations change depending on the environment, etc... Approaching a UI like a canvas will certainly yield good results on the designer machine, but will look out of place everywhere else, if it is usable at all.
I think it is the basis or what they call "responsive web design".
Re: Show HN: Don't code your UI, draw it
#37Earlier quoted context omitted.
What’s the purpose of developing in the open if not to get feedback? A pat on the back and a attaboy doesn’t help anyone improve.
I feel people who are only willing to point out negatives (without any appreciation for good parts) should refrain from giving feedback. Frankly speaking, such feedback isn't very motivating.
We're in this obnoxious age of confusing useful criticism with any reaction one can come up with on the fly, no matter how superficial. Like it's their destiny to weigh in on something as rapidly as they can, and as if they're doing some critical service for the universe.
The comment above exemplifies this when they say "what, we're supposed to pat them on the head and say attaboy?" No, the problem is that you think you need to fire off some undigested response at all. If you have nothing meaningful to say, then just say nothing. It's okay.
Re: Show HN: Don't code your UI, draw it
#38Earlier quoted context omitted.
I feel people who are only willing to point out negatives (without any appreciation for good parts) should refrain from giving feedback. Frankly speaking, such feedback isn't very motivating.
Nor is it actionable. Exists solely for the "critic" to signal how unimpressed they are, as if seeing the defects in something is some challenging feat. We're in this obnoxious age of confusing useful criticism with any reaction one can come up with on the fly, no matter how superficial. Like it's their destiny to weigh in on something as rapidly as they can, and as if they're doing some critical service for the univ…
- add a requirements.txt to list dependencies
- create a .gitignore file.
Re: Show HN: Don't code your UI, draw it
#39Re: Show HN: Don't code your UI, draw it
#40Interesting idea, but I'm not sure I see any advantage over dragging movable/resizable components from a toolbar, but there are several obvious disadvantages.
What if you could sketch your UI with a stencil, paper, and pencil. Then take a picture of it and have it translated into native components?
This might make more sense for a designer, but they shouldn’t be so close to production anyways.