14 ms·
Overall, the development world does not intuitively understand the difficulty of creating good interfaces (for people that aren’t developers.) In dev work, the
by DrewADesign 1y ago
Overall, the development world does not intuitively understand the difficulty of creating good interfaces (for people that aren’t developers.) In dev work, the complexity is obvious, and that makes it easy for outsiders to understand— they look at the code we’re writing and say “wow you can read that?!” I think that can give developers a mistaken impression that other peoples work is far less complex than it is. With interface design, everybody knows what a button does and what a text field is for, and developers know more than most about the tools used to create interfaces, so the language seems simple. The problems you need to solve with that language are complex and while failure is obvious, success is much more nebulous and user-specific. So much of what good interfaces convey to users is implied rather than expressed, and that’s a tricky task.
- finghin 1y agoIt’s also about keeping things simple, hierarchical, and very predictable. These do not go hand in hand with the feature creep of collaborative FOSS projects, as others point out here.
- hombre_fatal 1y agoGood point. A good interface usually demands a unified end-to-end vision, and that usually comes from one person who has sat down to mull it over and make a bunch of good executive decisions. And then you need to implement that, which is never an easy task, and maintain the eternal vigilance to both adhere to the vision but also fit future changes into that vision (or vice versa). All of that is already hard to do when you're trying to build something. Only harder in a highly collaborative voluntary project where it's difficult or maybe even impossible to take that sort of ownership.
- ozgrakkurt 1y agoIMO they just don’t care enough. They want people to use it but it is not the end of world if it stays niche
- csin 1y ago[flagged]
- Imustaskforhelp 1y ago> It's statistically very likely a hot chick does not know calculus. It would be honestly interesting if someone actually did a study regarding it. I do agree with this statement but it isn't as if everybody doesn't have other opportunity costs, people might have video games as hobbies or just normal hobbies in general as well which could be considered opportunity costs The question to me which sounds more interesting which I feel like I maybe reading in the lines but does the society shower attention to beauty which can make them feel less susceptible to lets say calculus which might feel a lot more boring respectively? Generally speaking, I was seeing this the other day but female involvement overall in the whole stem department has reduced in %'s iirc. Another factor could be the weirdness or expectation. Like just as you think this, this is assumed by many people about hot chicks lets say, so if a hot chick is actually into calculus and she tells it, people would say things like oh wow I didn't know that or really?? which could feel weirdness or this expectation of them to not be this way and be conventional and not have interests it seems. I have seen people get shocked in online communities if a girl is even learning programming or doing things like hyprland (maybe myself included as it was indeed rare) Naturally I would love if more girls could be into this as I feel like talking to girls about my hobbies when she isn't that interested or not having common hobbies hurts me when I talk to them, they can appreciate it but I feel like I can tell them anything, I am not that deep of a coder right now as much as I am a linux tinkerer, building linux iso's from scratch, shell scripting and building some web services etc. , I like to tinker with software, naturally the word used in unix/foss communities for this is called hacking which should be the perfect way to describe what I mean except they think I am talking about cybersecurity and want me to "hack something", Sorry about this rant but I have stopped saying this hacking just because of how correlated it is to cybersecurity to the normal public. I just say that I love tinkering with software nowadays. Side note, but is there a better word for what I am saying other than hacking?
- csin 1y ago
- zahlman 1y ago> I think that can give developers a mistaken impression that other peoples work is far less complex than it is. Not at all. Talented human artists still impress me as doing the same level of deep "wizardry" that programmers are stereotyped with.
- cenamus 1y agoTrust me, there are enough people here that believe that. Other engineering disciplines are simpler because you can only have complexity in three dimensions. While in software complexitiy would be everywhere. Crazy to believe that
- analog31 1y agoThere are many more than three "dimensions" if I may use the term loosely, in software or hardware engineering. Cost, safety, interaction between subsystems (developed by different engineering disciplines), tolerances, supply chain, manufacturing, reliability, the laws of physics, possibly chemistry and environmental interactions, regulatory, investor forgiveness, etc. Traditional engineering also doesn't have the option of throwing arbitrary levels of complexity at a problem, which means working within tight constraints. I'm not an engineer myself, but a scientist working for a company that makes measurement equipment. It wouldn't be fair for me to say that any engineering discipline is more challenging, since I'm in none of them. I've observed engineering projects for roughly 3 decades.
- swader999 1y agoThe top three are typically quality, budget and time. Usually a compromise is needed on one of these. You could replace quality with features in SW dev.
- nradov 1y agoScope is more of a dimension than quality. In theory it might be possible to accept lower quality in order to cut the budget or accelerate the time but in practice that doesn't seem to work. Any significant reduction in quality usually causes the project to grind to a halt after the prototype stage. You just can't build any new features when everything is broken.
- dhosek 1y agoIn the 90s I did a tech writing gig documenting some custom software a company had built for them by one of the big consultancy agencies. It was a bit of a nightmare as the functionality was arranged in a way that reflected the underlying architecture of the program rather than the users’ workflows. Although I suppose if they’d written the software well, I wouldn’t have had as many billable hours writing documentation.
- sublinear 1y ago> reflected the underlying architecture of the program rather than the users’ workflows Is this an inherently bad thing if the software architecture is closely aligned with the problem it solves? Maybe it's the architecture that was bad. Of course there are implementation details the user shouldn't care about and it's only sane to hide those. I'm curious how/why a user workflow would not be obviously composed of architectural features to even a casual user. Is it that the user interface was too granular or something else? I find that just naming things according to the behavior a layperson would expect can make all the difference. I say all this because it's equally confusing when the developer hides way too much. Those developers seem to lack experience outside their own domain and overcomplicate what could have just been named better.
- StrauXX 1y agoIf you ever spens time with the low level SAP GUIs, then yes, you will find out why that's definetly a bad thing. Software should reflect users processes. The code below is just an implementation detail and should never impact the design of the interfaces.
- DrewADesign 1y agoDevelopers often don’t think it’s a bad thing because that’s how we think about software. Regular users think about applications as tools to solve a problem. Being confronted by implementation details is no problem for people with the base knowledge to understand why things are like that, but without that knowledge, it’s just a confusing mess.
- LtWorf 1y ago> Overall, the development world does not intuitively understand the difficulty of creating good interfaces Nor can the design world, for that matter. They think that making slightly darker gray text on gray background using a tiny font and leaving loads of empty space is peak design. Meanwhile my father cannot use most websites because of this.
- hn_acc1 1y agoAs I age, this x1000. Even simple slack app on my windows laptop - clicking in the overview scroll bar is NOT "move down a page". It seems to be "the longer you click, the further it moves" or something equally disgusting. Usually, I dock my laptop and use an external mouse with wheel, and it's easy to do what I want. With a touchpad? Forget it.. I'm clicking 20x to get it to move to the top - IF I can hit the 5-pixel-wide scrollbar. There's no easy way to increase scrollbar size anymore either.. It's like dark patterns are the ONLY pattern these days.. WTF did we go wrong?
- BobbyTables2 1y agoIndeed. Win95 was peak UI design. I don’t understand modern trends.
- fragmede 1y agoWith a touchpad? Use two fingers to scroll (also works horizontally). Who's managing to hit a tiny scrollbar that disappears with a touchpad‽
- mjevans 1y agoThey just aren't as good at detecting real physical contact as a nice physical mouse is at responding to movement and pressure.
- fragmede 1y agoI mean, maybe but the question wasn't what is the superior general pointing device (trackball ftw if you ask me) though, but how to scroll using a trackpad without tearing your hair out.
- makeitdouble 1y ago> creating good interfaces (for people that aren’t developers.) This is the part where people get excited about AI. I personally think they're dead wrong on the process, but strongly empathize with that end goal. Giving people the power to make the interfaces they need is the most enduring solution to this issue. We had attempts like HyperCard or Delphi, or Access forms. We still get Excel forms, Google forms etc. Having tools to incrementaly try stuff without having to ask the IT department is IMHO the best way forward, and we could look at those as prototypes for more robust applications to create from there. Now, if we could find a way to aggregate these ad hoc apps in an OSS way...
- marcus_holmes 1y agoI have nightmare stories to tell of Access Forms from my time dealing with them in the 90's. The usual situation is that the business department hires someone with a modicum of talent or interest in tech, who then uses Access to build an application that automates or helps with some aspect of the department's work. They then leave (in a couple of cases these people were just interns) and the IT department is then called in to fix everything when it inevitably goes wrong. We're faced with a bunch of beginner spaghetti code [0], utterly terrible schema, no documentation, no spec, no structure, and tasked with fixing it urgently. This monster is now business-critical because in the three months it's been running the rest of the department has forgotten how to do the process the old way, and that process is time-critical. Spinning up a proper project to replace this application isn't feasible in the short term, because there are processes around creating software in the organisation, for very good reasons learned painfully from old mistakes, and there just isn't time to go through that. We have to fix what we can and get it working immediately. And, of course, these fixes cause havoc with the project planning of all our other projects because they're unpredictable, urgent, and high priority. This delays all the other projects and helps to give IT a reputation as taking too long and not delivering on our promised schedules. So yeah, what appears to be the best solution from a non-IT perspective is a long, long way from the best solution from an IT perspective. [0] and other messes; in one case the code refused to work unless a field in the application had the author's name in it, for no other reason than vanity, and they'd obfuscated the code that checked for that. Took me a couple of hours to work out wtf they'd done and pull it all out.
- hilong2 1y agoOne thing I still struggle with is writing interfaces for complex use cases in an intuitive and simple manner that minimizes required movements and context switching. Are there any good resources for developing good UX for necessarily complex use cases?
- tastyfreeze 1y agoI am writing scheduling software for an uncommon use case. The best method I have found is to use the interface and fix the parts that annoy me. After decades of games and internet I think we all know what good interfaces feel like. Smooth and seamless to get a particular job done. If it doesn't feel good to use it is going to cause problems with users. Thats said. I see the software they use on the sales side. People will learn complexity if they have to.
- DrewADesign 1y agoHonestly, it’s a really deep topic — for a while I majored in interface/interaction design in school— and getting good at it is like getting good at writing. It’s not like amateurs can’t write solid stories, but they probably don’t really understand the decisions they’re making and the factors involved, and success usually involves accidentally being influenced by the right combination of things at the right time. The toughest hurdle to overcome as a developer is not thinking about the gui as a thin client for the application, because to the user, the gui is the application. Developers intuitively keep state in their head and know what to look for in a complex field of information, and often get frustrated when not everything is visible all at once. Regular users are quite different— think about what problems people use your software to solve, think about the process they’d use to solve them, and break it down into a few primary phases or steps, and then consider everything they’d want to know or be able to do in each of those steps. Then, figure out how you’re going to give focus to those things… this could be as drastic as each step having its own screen, or as subtle as putting the cursor in a different field. Visually grouping things, by itself, is a whole thing. Important things to consider that are conceptually simple but difficult to really master are informational hierarchy and how to convey that through visual hierarchy, gestalt, implied lines, type hierarchy, thematic grouping (all buttons that initiate a certain type of action, for example, might have rounded corners.) You want to communicate the state of whatever process, what’s required to move forward and how the user can make that happen, and avoid unintentionally communicating things that are unhelpful. For example, putting a bunch of buttons on the same vertical axis might look nice, but it could imply a relationship that doesn’t exist. That sort of thing. A book that helps get you into the designing mindset even if it isn’t directly related to interface design is Don Norman’s The Design of Everyday Things. People criticize it like it’s an academic tome — don’t take it so seriously. It shows a way of critically thinking about things from the users perspective, and that’s the most important part of design.
- max51 1y ago>Overall, the development world does not intuitively understand the difficulty of creating good interfaces I think it's because they are not using the product they are designing. A lot of problems you typically see in modern UIs would have been fixed before release if the people writing it were forced to use it daily for their job. For example, dropdown menus with 95 elements and no search/filter function that are too small and only allow you to see 3 lines at a time.
- DrewADesign 1y agoThere’s a real difference in usage style between developers and most other users. Having the background knowledge to understand what’s going on behind the curtain makes it easy to deal with things like interactive visual complexity, tons of data and moving parts at the same timetime, implementation warts, etc.