Live data from Hacker News

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

github.com

31–40 of 148 posts

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

#31
post #10

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.

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.

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

#32
post #27

Earlier 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. :(

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 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

#33
this is pretty cool! one thing on the image drawing one is that there are "industry-wide" common practices when using a placeholder/drawing one to represent an image as a square/rectangle crossed from each angle (if I explain myself correctly). this dates back to the print design days, but would be a shape that's a lot easier to draw than the pseudo picture that's common in OS UI's. Yotako, which has been linked somewhere in the thread by tyingq (which reminds me of the Palm Pilot days) uses a similar approach as well. It makes it easier to draw and faster too

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

#35

Earlier 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…

Yeah, a flow scheme would be killer. You could easily come up with many different prototypes and get quick feedback on what works or doesn't work.

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

#36
Maybe I am not a UI designer but I much prefer rule based approaches than drawing.

Rule 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

#37

Earlier 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.

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 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

#38

Earlier 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…

The feedback was actionable

- add a requirements.txt to list dependencies

- create a .gitignore file.

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

#40

Interesting 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?

If I was using a lot of parameterization and abstraction, this approach would be very annoying. I mean, it’s great if I just have to do one UI, not so great if I have to do many of them in slightly different ways.

This might make more sense for a designer, but they shouldn’t be so close to production anyways.

Post reply on HN