Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GUIs are built at least 2.5 times

patricia.no

Post reply on HN
Print view View original

61–70 of 155 posts

Re: GUIs are built at least 2.5 times

#61

Post by breckenedge »

amelius wrote: post #60
throwaway2037 wrote: post #17

This part is genius: > I have made GUIs many, many times and my best case scenario goes something like: > 1. A design has been made, everyone loves it. Detailed drawings have been made. > 2. The devs are told to Make It > 3. The devs Make It, exactly to spec > 4. Everyone looks at it and everyone hates it > 5. So many meetings. So much stress. This Is Terrible! What To Do? > 6. A new design is made. So much better! D…

The main thing that pisses off devs is changing requirements. Unless the devs get a free pass the rebuild everything from scratch.

Like software, requirements can never be perfect. Overly prescriptive requirements are a huge red flag to me that a PM/client/designer is doing an engineer’s work, or micromanaging.

Re: GUIs are built at least 2.5 times

#62

Post by breckenedge »

mrkeen wrote: post #59
lukaslalinsky wrote: post #18

This was very hard to read and I wasn't even sure what is the conclusion. One thing I didn't understand, how does one disagree with agile dev processes, which are mostly built on top of the fact that many things, especially UX, you can't know in advance, so you have to build something small, get feedback, then either scrap it or improve it. The process described here sounds exactly like someone spending weeks if not…

> so it's kind of obvious it needs to be fully re-done so many times. But it hasn't really caught on in the management layer. Sure, they use all the right Agile buzzwords, but they still put features A, B and C into the plan, and ask questions like "when will B be finished?" "Finished?". Nah - we're the stewards of 14 bugs-as-a-service. We won't so much "finish B" as much as we'll transition to becoming the stewards…

This precisely. They treat development (programming) as the slowest part of the process, but that has not been my experience since Figma came out. I’ve not seen agile done right since it arrived, we’re just doing waterfall with sprints.

Re: GUIs are built at least 2.5 times

#63

Post by masfoobar »

I have worked for a number of different software companies over the years. For most of them, there were no dedicated frontend or UX designers. It is mostly backend devs who had enough/decent skills at frontend, whether it be GUI apps or Web apps.

However, when you are doing something specific for customers (not staff) - the design is important to get right early. However, even at a number of places I have worked, the structure is still wrong.

For example I worked for a company which has one UX designer. I will give him his props. He was good at GUI design and a whizz at css! Sadly, when he had "finished" the design, it gets passed over to the developers to implement the functionality around it. If something was not going to work functionally or a customer has changed the design... it is the developer that has to fix it. The UX guy has moved on to another project and the cycle repeats. It was wrong structure.

I found good results when a UX guy works alongside a Developer. As the UX guys works on the designs, it allows the developer to start building the business logic around it. It is all part of the development process, afterall. Sure, the UX guy is likely to make changes even from the customer but the developer is always aware and can adjust. A lot of the module work is likely to be small amendments.

Once the UX is finished then so is (mostly) the Module alongside Unit Tests or similar. It is simply a developer taking the UX project and adding the needed calls to the modules. It keeps the middle layer small, easier for further changes to the UI or the Module. etc.

Re: GUIs are built at least 2.5 times

#64

Post by breckenedge »

barrell wrote: post #19
bonki wrote: post #2

I have only skimmed the text but regarding GUIs specifically the list in the end is spot on. With that being said, I firmly believe that all software (given that one is not already deeply familiar with the domain) is/can/should be written three times to end up with a good product: 1. Minimal prototype. You throw something together fast to see it can be done, taking shortcuts and leaving out features which you know yo…

Personally, I’ve never found this lean methodology to work for me. I have a bit of a mantra that I’ve found works really well for me: “Put everything on the screen”. Every feature every variant ever possible configuration and all future potential states. Don’t care about how it looks or how it feels just put it all there. Build out as much of it as possible, as fast as possible, knowing it will be thrown away. Then,…

Sounds like sculpture. Or “add lightness.” My brain works the same way.

Re: GUIs are built at least 2.5 times

#65

Post by paddy_m »

WillAdams wrote: post #51
mpweiher wrote: post #47

Earlier quoted context omitted.

It is also my experience that this is the way to go, and it also matches my theoretical view aka prejudices. It seems to me that one of the things making this approach difficult is that we lack (design) tools that support iteration between design and development. Modern tools make going from design to development easier, but it is still largely a one-way street. And one that's been made worse by recent trends towards…

For a long while now, what seems to me a reasonably simple project (re-creating the UI of a drawing program and making it straight-forward to re-create program state with annotations/highlighting) has been stalled because I can't find a design tool which works better than just placing the screen grabs in a vector drawing program and annotating by hand.... I'm about at the point where I'm going to just code everything…

What made display postscript so great? I have only seen it mentioned in frothy marketing terms, not an in depth discussion of its approach, why it worked well, and how that compares to other alternatives.

Re: GUIs are built at least 2.5 times

#66

Post by paddy_m »

bob1029 wrote: post #25

A tight iteration loop is the only solution I've seen for building high quality UI/UX. Embrace that it's going to be terrible the first few times and plan for this. We could save on cost per iteration by avoiding the layout and styling pass until the very end. These interfaces are about communicating information. Plain text and basic form submissions work just as well as anything else when you're still trying to desi…

The best functional specs for a UI have come from business people building their own in excel. At a minimum they will have some idea of layout and what information should be displayed on which screens.

This also lets them focus on the core information, not the styling. Building GUIs on the web, there are infinite ways to style every UI element and more attention goes to that then the actual interaction.

Re: GUIs are built at least 2.5 times

#67

Post by quantum_bit »

I think the author could be more concise and also confuses multiple things in the article. I'll provide just a couple of points:

- Patterns like "Pipes and Filters" and "Signals and Slots" are *not* related to the process of software development, they are about internal software architecture. It does not matter how much one iterates over GUI during development with client's feedback, software still takes some input, processes it, and returns some output. Also, calling "signals" "inputs" and slots "outputs" is weird: usually signals are processed by slot (this is the Qt framework terminology for events and event handlers for GUI), so it is more natural to think about signals as inputs and slots as something that produces outputs.

- From the same section:

> I don’t know if these patterns are in a book, or have a name, but if not, they are now in a blogpost Or yeah, it is good to write an article without trying to do literature search first.

The last part of the article that says that people need to feel things before they understand whether they like them or not, was good, but I guess, all nontrivial things are done iteratively.

Re: GUIs are built at least 2.5 times

#69

Post by mpweiher »

wongarsu wrote: post #23
throwaway2037 wrote: post #17

This part is genius: > I have made GUIs many, many times and my best case scenario goes something like: > 1. A design has been made, everyone loves it. Detailed drawings have been made. > 2. The devs are told to Make It > 3. The devs Make It, exactly to spec > 4. Everyone looks at it and everyone hates it > 5. So many meetings. So much stress. This Is Terrible! What To Do? > 6. A new design is made. So much better! D…

The issue is that step 2 is wrong. Step 1 is to make a design, step 2 is to test it. Make a paper prototype and have your customer simulate working with it. If you feel fancy make a pretty prototype in Figma. If you have a good designer and cooperative costumer you can even combine step 1 and 2 with a whiteboard prototype. Ask the customer what a common task is. Draw the interface the whiteboard and ask the consumer…

> The issue is that step 2 is wrong ... step 2 is to test it.

But of course the best and only real way to test it is to test the real thing...so build it. Back to step 2. :-/

Recurring theme in pre-press: get the texts, get everybody to proof-read the texts, get customer sign off, do on-screen proofs of the layout, everyone signs off, do print-proofs, do proof-printer proofs, do a press-run. Everybody signs off. Print run of 120000 copies. Typo in first sentence on first page, present all the way back.

My idea is to make building real things about as cheap as creating a click-dummy or paper prototype. How's the old saying? "The merely difficult we do immediately, the actually impossible might take a while" ;-)

Re: GUIs are built at least 2.5 times

#70

Post by WillAdams »

paddy_m wrote: post #65
WillAdams wrote: post #51

Earlier quoted context omitted.

For a long while now, what seems to me a reasonably simple project (re-creating the UI of a drawing program and making it straight-forward to re-create program state with annotations/highlighting) has been stalled because I can't find a design tool which works better than just placing the screen grabs in a vector drawing program and annotating by hand.... I'm about at the point where I'm going to just code everything…

What made display postscript so great? I have only seen it mentioned in frothy marketing terms, not an in depth discussion of its approach, why it worked well, and how that compares to other alternatives.

You have to understand or have experienced how fragile the early graphics programs were --- basically a .eps file would be a black box of PostScript code, and would have a pixel image preview used on-screen (a classic gag was to use a resource editor to change the pixel preview) --- whether or no it would actually print/image correctly was something one wasn't certain of until holding the actual output in hand, and even then, it only held for a specific PostScript rasterizer/job setting. Sure, it was okay 99.99% of the time, but that 0.01% could be disastrous.

Display PostScript meant that the system used for on-screen display was the same as for actual printed output --- I _never_ had a job on my NeXT Cube fail to print to match the on-screen version. Moreover, one could do cool DPS programming such as custom strokes and fills in Altsys Virtuoso.

These days, PDF and Quartz (née Display PDF) mostly address the reliability (and presumably it's gotten even better since I left the industry), but I miss the programmability. Hopefully, using METAPOST will let me get some of that back.

Post reply on HN