In technical context leaving unknowns with unknown boundaries behind is an approach that makes it hard to assess next actions in error cases, but even more importantly it makes the future system design work rooted on uncertainty.
To me that is blocker to my thinking. I really need to understand the impact of leaving something behind before continuing. I’d likely do everything in my power to remove that unknown from current state for the sake of sanity.
I am interested if someone has written a document/post/article that approaches ”web needs simplification” in current context in holistic manner. E.g. Considering energy consumption, development costs, tooling complexity, state of web standards, private and public industry domain needs etc.
I personally see different problems in many of the areas, but I’d like to know if someone has already organised these topics.
”Start late” in relation to paying attention to details, testing UI and other quality aspects that are not visible in the beginning. In simple terms: budget some time to handle unknowns. Or at least some of them.
When it comes to the amount of upfront design needed…
…yes, everyone agree ”complete vision no stone unturned” is the optimal. That is easy ask.
In real life that is not possible, unless you are working with incredibly small scope OR without any schedule. I.e. not possible. Business with money involved? Just no.
Agree on level of experience. Experience usually helps a lot.
Unable to design and develop system with certain level of uncertainty and adaptability is the real tragedy.
I believe everyone should be interested on the possible routes ahead. Assuming one or two persons are able to foresee some unknowns is intellectually lazy. Expecting them to brainstorm it out to the detail infront of some whiteboard is just not how real life works.
- actually test the UI (different devices, browsers, viewports, scenarios)
- reserve APPROPRIATE time to test UI
- reserve APPRORIATE time to fix the issues
- have designer in tight loop
- have systematic approach to track issues
- test with users
- aim to apply fixes asap so that the fixes gets tested as well
Biggest single factor causing issues is to start late. The time will run out if the styling setup is not robust, it depends on some questionable conventions or libraries, or is simply hacked together.
It is not that complicated, but it is most certainly difficult to do magic tricks late in the development.
React itself is not a root cause. I believe the fundamental cause is a mix of skill issues, lack of knowledge, quality ambitions and time management.
You are not. As a dev I understand the temptation of Tailwind, but I don’t see the benefits really worth it in all cases where I see it’s used. Writing plain CSS just makes so much more sense in the long run.
Based on some experience (designer and developer), here’s some thoughts I currently have about them:
- high-level idea is usually understood, although mixed with design tooling
- practical usage rarely straightforward
- most of the activities are surface level and trivial
- required effort to maintain and develop often underestimated
- maturity level rarely reaches the potential
- ”component” is not an easy concept, especially in multi-product setting
- too often design driven, when implementation driven would make more sense
- generates meetings on many meta-dimensions
- not necessarily rewarding exercise for the maintainer due to various organisational and political challenges
- does not actually help on design-to-development e2e flow as much as advertised
- even with all the work put in, does not guarantee good product
To me that is blocker to my thinking. I really need to understand the impact of leaving something behind before continuing. I’d likely do everything in my power to remove that unknown from current state for the sake of sanity.