It's minimally viable, which means it does what people needs now without costing too much in resources. I'm not Joe (I wasn't even born at that time), but
> a text file (with an undefined character encoding)
Most team kinda have the same system to work from, so character encodings doesn't matter much (and people who deviates from the norm know how to handle such things).
> an undefined structure for the header of the file
That's pretty much YAGNI. By the time you get to this point, you could probably switch to a DBMS and import the old data.
> a rule that status must be 'open' or 'closed' in every human head
A lot of rules, even today, are encoded in human head. In the ticketing systems at $WORK, each team has a different set of fields with different semantics for the status field. And there's a global repo. You can easily enforce that new addition don't have any other value.
> a revision control system which dates changes
No need to wonder how to enforce proper date control. And less code
> an out of band way to request and obtain permission to change the owner, possibly a high-trust environment with no arguing "you agreed" "no I didn't"
The owner of the ticket? Why can't it be a new update to the file? It's version controlled. And the import to the global repo (which I think is the source of truth) can be monitored and constraints enforced.
> a programmer/scripter who can develop the management reports on-demand
It was 1986. If you have a computer on site, you also have a programmer available.
---
So you got a working solution without investing too much resources solving subproblems, some of which are not even important.
Even with bootstrap, design was a solved problem. What you bring with a UI designer is appeal (aka make thing pretty and enjoyable). If you want utilitarian, even the old x11 toolkit like Athena, Win 98 era widgets would do the part.
I wouldn’t, but you’re not much of a product designer if you can’t get your ideas across using simple tools like a sketch on a whiteboard (there was|is an app the let you take photos and link them using active areas).
So you can take bootstrap (or even raw html) and create something useful. Then you make it nice, not the other way around.
You would have to be a big outlier to feel the need to create a custom widget. Most widgets have been defined since decades.
I agree that design is about primitives. wireframes and IA should come across clearly at any fidelity.
But i don't think that's what tailwind and bootstrap are doing. But people very much use these tools to "solve design".
The layouts, widgets, and primitives in these tools are not primitives. I can't deny they get tons of people very far very fast. But my main disagreement is that all of this isn't design and it's not what designers do. You touched on what i agree with: UX flows, diagrams, stories, journeys, personas, etc, these all need to be designed and connected in reality using various primitives for the medium.
Then you slap a cohesive paint job on it, interaction elements, tone and terminology and yes, there is that element of design too.
UX designers I encountered have mostly been tasked on ensuring consistency across the various product (A lot of devs are very cavalier about spacing and font sizes). Sometimes they proposed new flows and layouts, especially when the product needs a coat of paint.
So tools like Figma is nice in that regards as it's simpler to iterate on (From simple to hardest: Sketch on whiteboard|paper, Wireframe tools like Balsimiq, Figma|Sketch, css code) because it's pure fiddling with various properties. Figma has direct feedback while the code may require a compilation phase.
hmm, actually, you got a point there. emacs could be the like that graphical terminal, except for now it is still stuck inside a traditional terminal itself. even the GUI version of it is mostly just looking like a terminal, not really taking advantage of the potential of graphical elements. we would need a real GUI and support for exchanging structured data with external commands. for now emacs is still kind of its own world.
> even the GUI version of it is mostly just looking like a terminal, not really taking advantage of the potential of graphical elements.
Emacs is text based (mostly), but customization happens through the the concept of Faces, not ansi escape codes. You can then embed properties in the text objects and have them react to click events. The only element missing is a 2D context that could be animated (if it's static, you can use SVG as Emacs can render it).
I'm a bit skeptical too, but I can understand his points. Most of what is rote is probably written somewhere and if you have a library of code and snippets (including the existing project), it's easy to copy and adapt it. And that activity is very inducing to flow state, so you don't mind the time spent.
Most established projects has quite good documentation. And if they don’t, that’s because they consider the code as the documentation and just provide with an overview. The source code is the main truth and there’s a trick to reading it quickly. But that’s acquired by playing around with a lot of projects
Facade are to be looked at, not to be used. Most things that are to be used in a practical manner has retained the same basic form: desks, chair, handle, cart, cup,…
Dunno, I have been in IKEA and saw 50 types of drawer handles, for example :)
(Same for car interior design, or things like even doors that some swivels on one axis, some split on multiple, some slide.)
I don't think that us humans really actually like/want standarts. We think we do, but there are 100+1+1 standart from which to choose. So Claude becoming "standart" iš just +1 standart to choose from. Unique is fun!
Also doubt. But most likely because of organizational inertia. After a while, you’re mostly focused on small problems and big features are rare. You solution is quasi done. But now each new change is harder because you don’t want to broke assumptions that have become hard requirements.
reply