Maybe the next revision of this article about GUIs should include some images
GUIs are built at least 2.5 times
71–80 of 155 posts
Re: GUIs are built at least 2.5 times
#72Earlier quoted context omitted.
"Plan to throw one away. You will anyhow."- Fred Brooks, _Mythical Man Month_ A software engineering book written decades before I was born- my college assigned us the 25th Anniversary Edition- and yet I re-read it every few years and find some new way to apply its lessons to my current problems.
"If you plan to throw away one, you will throw away two" -- Craig Zerouni, via Programming Pearls: Bumper Sticker Computer Science https://moss.cs.iit.edu/cs100/Bentley_BumperSticker.pdf
Maybe you will, but maybe not. Hence the title - 2.5 attempts sounds about right.
Re: GUIs are built at least 2.5 times
#73Earlier quoted context omitted.
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 e…
Thanks, I'm starting to understand. So Display Postscript was useful because it let you know that what you put on the screen as a programmer would be what's printed?
And it allowed for cool graphics effects like custom strokes and fills.
So that primarily matters for stuff you want to print. It wouldn't matter as much for assembling a UI.
How does windows handle this stuff?
Re: GUIs are built at least 2.5 times
#74Earlier quoted context omitted.
Any engineering surely works as an analogy - be it mechanical, electrical, chemical or anything else.
I feel like building a house and programming are the only kinds of engineering where the customer can change the project halfway through and not get laughed out the room
erh, the option with the house, sounds rather expensive?
my day-to-day work regards professional building cost estimation software, and I would claim people try to do a lot of work to avoid having to do that.
I'm not saying they don't sometimes end up doing it anyway, but in my perspective, the larger the scale, the more this is aggressively avoided as much as possible.
Similarly, I encounter a lot of comparisons where "we" software people are told to be either more or less like the building people.
What I do see though, is that building people perpetually tend to miss out on a lot of data optimisations / pipelines in the building project flow. They keep talking about wanting to do this, but in practice end up entering a lot of data from scratch multiple times. One of the culprits I see, is that the people who should have shaped the data for this, have no economic motive to do so - "why should we do that, it will only be a problem for X other people at a later stage we are not involved in".
Re: GUIs are built at least 2.5 times
#75This 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…
[deleted]
Re: GUIs are built at least 2.5 times
#76Earlier quoted context omitted.
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 e…
Thanks, I'm starting to understand. So Display Postscript was useful because it let you know that what you put on the screen as a programmer would be what's printed? And it allowed for cool graphics effects like custom strokes and fills. So that primarily matters for stuff you want to print. It wouldn't matter as much for assembling a UI. How does windows handle this stuff?
As a graphic designer/compositor/typesetter.
Windows uses (used?) WMF and pixels for on-screen display which would then either be used for printout via some conversion process, or a parallel construction would be maintained for output and the need to keep that in synch would often result in slight differences in output --- maybe there were other approaches.
One of the neat things in Display PostScript was one could use Interface Builder to add a print button to any window to get the underlying PS code.
Re: GUIs are built at least 2.5 times
#77Earlier quoted context omitted.
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.
Nobody said requirements need to be perfect or never leave room for free interpretation.
Re: GUIs are built at least 2.5 times
#78That "feels right" thing is "the quality without a name" from "The timeless way of building" by Christopher Alexander: it is "fitness for the purpose" or, perhaps, "being true to its own nature". It is both very real and very elusive.
Russian carpenters had a saying to the effect of "to do the job without tricks and let the measure and beauty to guide you". The primary skill here is not to do a thing, but to listen to what the thing itself is telling. (See also "The stone flower" by P. Bazhov).
Re: GUIs are built at least 2.5 times
#79A 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.
> Building GUIs on the web, there are infinite ways to style every UI element and more attention goes to that then the actual interaction.
AKA bike-shedding, or "Law of triviality", just to put a name on this pretty common occurrence.
Re: GUIs are built at least 2.5 times
#80This 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…
UX is hard. What usually happens is that you have: - developers who are bad at UX writing the software and improvising with all the use cases that were not adequately specified in the design document - end users who are bad at UX giving their input, but can tell when something feels right for their use case - managers/spec writers who are bad at UX and are trying to translate the wishes of end users to the developers…
I've found that most teams are hesitant to show backend code, API calls, etc. during demos.
Screw that! Show your product owner and stakeholders the complexity of the backend _in conjunction_ to the ease of the front end.
The underlying note is "here is what you'll do manually and without support if you don't want the UX as it is now."