I know, there are open source business models which work for some companies and that's true but generally in the sorts of technical problems for IT people. Compared to the IT industry as a whole those are edge cases. They seem more important to us embedded in the IT industry, but compared to the overall multi-trillion dollar global IT industry they're peanuts.
It was scary how close we got to some published prices.
Did you mean MacOS?
- Drag and drop the file into a terminal to insert the path
- Copy and paste the file into the terminal, which inserts the path
- Press Command+I to show a popover describing the path to the file
- Enable the "show path bar" option in the Finder's "view" menu, which will show a nice graphical representation of the path to the current location at the bottom of the window (which lets you copy the POSIX path to each item)
- For more advanced users, run the command `defaults write com.apple.finder _FXShowPosixPathInTitle -bool YES` to show the full path to the current folder in each Finder window title
- Drag and drop the file into a terminal to insert the path
- Copy and paste the file into the terminal, which inserts the path
- Press Alt + Enter to see details describing the path to the file
- Press Ctrl+L to see full path. Or just use better file manager like Nemo
Ah, and also if you alt-rightclick on an item, you can copy its path to the clipboard. Or you can open the ‘Edit’ menu with alt pressed and copy the path to the current folder. Apparently there's even a shortcut for this.
THANK YOU!
- use columns view
It's certainly fine if you work a lot locally with the Mac; but for me, the cost-effective thing has been to fumble around each time (since I only do this a few times a year) rather than memorize handling that I use so seldom.
Also, nothing to memorize about copy & paste or drag & drop. I would say you’re used to Linux GUIs not doing what you expect so the obvious solutions aren’t even considered.
Showing the Finder path bar is the more obvious option. Nautilus, the file browser on some Linux distros, supports this as well.
To a terminal. I thought Linux was the one where you needed to open a terminal to do basic things, yet from my experience it's usually MacOS that needs a terminal for such basic things as turning off mouse acceleration.
Seriously, Linux has a lot of UX issues, but hiding the full path of files is a problem that plagues literally every single OS file manager. It seems that at some point, all the major OS makers agreed that users are too stupid to understand a file hierarchy, and came up with tricks to hide it.
And this is why I find myself mostly in the text shell.
Were I to go graphical the minimum I want is a simple address bar that I can override the current path with a specified path at will.
Maybe a tree view like in Windows 95 Explorer just to pretty things up. Some of the modern comforts like thumbnail images would also be welcome.
I wish they would stop insulting their users who have taken the time to understand the underlying technicalities of a file system. All this should be user-configurable in a good file manager. SpaceFM and PcmanFM come closest to what I've specified.
That's not a difficult question. The only time it makes sense to expose the internals is if you build a specialist tool for people who like internals exposed.
This means that no, it shouldn't be "user configurable" either. You don't want a combinatorial explosion of states in your UI for a tiny set of users in the general purpose case, and you don't want to create a honking fat tool for specialists who'll only use the specialist path.
The computer industry is discovering what the mechanical tools industry has known for a while: You can build a general purpose tool that's simple & straightforward, or you can make a specialist tool.
Pretty much any specialist will be slightly unhappy with the specialist tool and modify it to their own requirements, but you can't build a specialist tool that makes even close to all specialists happy. The specialists will also continue to use the generalist tool if it gets the job done, but they'll complain every step of the way.
I find this annoying as well, but it only happens when you use quick access shortcuts. And then once you're in a sub folder it'll display the full path in the title bar provided you turn on "Display the full path in the title bar" in the Folder Options.
Navigating directly to c:\Users\MyUser\Downloads will also show the full path in the title bar.
It seems some of these shortcuts have "special" behaviours in explorer.
Terminal -> Finder:
open .
I made a Bash function:
function cdf {
DIR=$(osascript -e 'tell app "Finder" to POSIX path of (insertion location as alias)')
cd "$DIR"
}In macos I don't have to edit random .conf files in system/application directories just to make my wifi work correctly. The graphical UI is configurable enough that I rarely need to modify anything outside of my normal user directories.
Where as in ubuntu the forums/stack overflow usually say "go to this file at /sys/whatever and write in this". Hence the need for full file paths.
The first thing I do on any Mac is to drop into Terminal to run this:
defaults delete com.apple.systempreferences AttentionPrefBundleIDs
Quick example, because I'm trying to make my nas usable on a mac and it's given me a headache.
defaults write com.apple.finder _FXShowPosixPathInTitle -bool YESIt's quite a basic thing, most games include it in their settings yet it doesn't seem important enough to have a setting in the OS itself.
True of any hotkey.
> which is why requiring it for a common UI function is bad design.
it isn't required.
Blame GNOME 3. After a decade it's still lacking polish everywhere. The day Canonical decided to drop the ball on Unity was a sad day.
> why can't I easily make a shortcut in ubuntu? > how about the fact that you can't get full file paths shown in the default file manager,
Is it any worse than needing to find the setting to display file extension in windows?
I am on Cinnamon desktop as it's a bit old school and predictable (for people who have been around since windows 98). I right click a file and I have an option to create a link. And my default file manager shows the full file path in the address bar . So I don't think it's a Linux problem rather than a Gnome 3 problem. But I am sure plenty of people don't mind Gnome 3 (everyone else at my work used the standard Ubuntu desktop.
In open source the developer has the power, they get to decide what they work on and nobody can tell them otherwise. The best a user can do is post a begging letter in a bug tracker. It doesn't matter what the user thinks, even a majority of users, all they can do is ask.
In commercial software it's the user putting bread on the developer's table. The user feeds and clothes the developer's children, and/or pays for their supply of mountain dew. If the user wants something, bye and large they get it, or at least they have a pretty solid chance of it more often than not. A vote for a feature speaks a lot more convincingly when it's backed up by a wallet.
There's nothing wrong with open source or free and libre software. It's great, I love it, but a lot of it's proponents seem to think proprietary software is some sort of crime and genuinely don't understand why proprietary software dominates so completely in so many domains outside of IT infrastructure.
unless it's accepted upstream, you've got an ongoing maintenance problem on your hands. getting an idea in isn't always just about time/resources/money. if your idea doesn't fit their 'vision', it won't be accepted, regardless of how much you have funded your feature. do you now take on maintaining a fork? sometimes the answer might be 'yes', but I suspect in most cases it's going to be 'no'.
(I've given up either reporting bugs or, where at all possible, using their software, as it's abundantly clear my interests and theirs are not in the least aligned.)
The Google model dominates the proprietary world presently, and even long-term shrinkwrap / clickwrap vendors such as Microsoft are shifting in whole or part to advertising-supported software.
What I pay for Google software is indirect, but given a roughly $100 billion global spend on online advertising, allocated largely among the world's richest 1 billion people, that amounts to about $100/year for the privilege of tools which frustrate rather than delight me.
As I've described in "The Tyranny of the Minimum Viable User", odds are strong that mass-market software of any stripe, including proprietary whether paid, subscription, or advertising-supported, will fail to address power-user / elite-user interests:
https://old.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr...
At a certain scale (much smaller than Google's, probably already at about 100 customers) it's impossible to please _all_ users of your software, so you try to please the majority. And whatever you change, there will always be that 'one guy' whose workflow will break.
If they are critical bugs, they might or might not be addressed.
Developers know best, even when they don't, because they're the ones doing the actual work. But in the FOSS ecosystem you have: i) the freedom to do the changes yourself ii) the freedom to offer help with design, documentation, ideas iii) a public bug tracking and issues manager
Let me know when you can do this commercially.
On a tangent: it is indeed a crime to use commercial software when there are libre alternatives; every use moves the needle one tick deeper towards Eternal September
For me, a large part of the fun of being a developer is enabling others to do stuff they otherwise couldn't. As such we absolutely entertain feature requests and similar, and implement a lot of them.
When sales come back from a sales presentation laughing and telling of jaws hitting the floor, it's almost always due to features that started as a suggestion from one of our users.
Very often though the feature requests are trying to solve XY problems. Often there's a better route to achieving what the user wants, which almost always is some way of avoiding redundant work or other workflow simplifications.
Us devs often do know best when it comes to edge cases and limitations, and about other use-cases that this particular user haven't considered.
However most requests are born from something real, so we will usually inquire what the user is after, in an effort to determine the impact and alternate routes. I might even contact other customers who I know use that module or have a similar work flow and ask them what they think.
And based on that implement changes that make the program better not just for that user but for all our customers.
What do you mean by "proprietary" in this context? I believe that the availability of the software's source code to its users is unrelated to the fact of whether the actual development of such software is paid or not.
Moreover, free and open source software (free as in "freedom", not necessarily free as in "free beer"), makes it generally simpler for the regular users to provide input regarding the features they need changed. So, in a way, it also helps to achieve the goal you describe:
> The best way to ensure people pay close attention to those last areas of fit and finish...
This is true, and I've seen that happen too, one of the companies I worked with would sell source licenses to customers, and as I understand it this was very common in the mainframe business going way back. The software vendor retained rights to sell and distribute the software though, that's what I mean by proprietary.
I've seen these arguments for open source and libre software before many times, but there's a huge discontinuity between the theory and what actually happens in reality. In the real world there are tens of thousands of small and large software houses producing niche software for diverse use cases for businesses all over the world. Hundreds of niche engineering design, test and optimisation applications, B2B services, audio and video tools, chemical engineering tools, automation and industrial control systems, booking and billing systems, here are an almost infinite variety. Most of them are only known to people actually in these niche specialisms. In that world customers paying for customisations is stock in trade, it's entirely normal. In fact the company I'm at right now is paying the vendor for customisations to our incident and change management ticketing system.
In comparison open source, outside nerdy IT oriented tech projects, might as well not exist. It's minuscule. Barely even a footnote.
Don't get me wrong, a good interface needs to take user feedback into account. But trying to accommodate the union of all features needed by all users is a recipe for madness. Somewhere you need an engineer, PM, designer, CxO, or someone who can make judgement calls and decide which user needs are more important than others.
If only that were true. I've watched a completely non-IT person work with both vanilla Gnome 3 and Windows 10; they found the former far more intuitive and unobtrusive (not looking at the individual apps, just the basic desktop UI). Proprietary design-by-committee doesn't necessary make for better solutions: hence the numerous complaints recently from people (often with accessibility issues) trying to book vaccination slots on government websites.
I think a lot of the methodological knowledge built by usability people has probably been ignored in favour of a metric-driven approach these days. That approach is very good at identifying bottlenecks in existing workflows or deciding between two ideas, but ultimately lacks the empathy you describe. You can only really build that by engaging directly with users, and watching them suffer at the hands of your creations.
Do normal users know all this? Or do they just only use the 10% easy functionality of the phone and is happy with that? Maybe articles like "17 Things You Didn't Know Your iPhone's Home Button Could Do" is a sign usability has been sacrificed in order to have a clean&neat design.
Of course menus don't translate well to touch devices, and menu systems can quickly become unorganized junk drawers for functionality, but it feels like discoverability was never fully solved on touch devices.
And it also has the same problem you describe - you don't know how to find something unless you know what it's called. And even if you do find something, there's no breadcrumb trail to learn how to find it without using search. You have to look at what's on the current page and like some kind of reverse engineering sherlock, think about where a designer could possibly have put this page. It's insane.
When that phone stopped working I got a decent Android phone and it felt so much more comfortable.
Sure, discoverability is good to have, but it is not a failure that you need to be told about it as long as it only contains features useful to power users.
Requiring experts to undergo some training to make the most out of their devices is acceptable UI if the final interactions are optimized for their use; double so if it doesn't interfere with usage by untrained users.
I wonder if it's kinda a stockholm syndrome or if it caters to one's ego somehow. After discovering a feature, one feels smarter / more connected to the device, compared to if it was actually easier to use from the get go.
For example, he texts frequently but doesn't know how to check his email. Because I am the tech support child, he reaches out to me for iPhone help. However, since I am not an iPhone user, I always struggle and sometimes fail to solve his problem.
Perhaps this is a sign I have not dedicated enough time to learning this new OS in my family ecosystem, but I do feel it is the least-similar to the other OS's I have used. It's like if my dad was learning programming and asked if I'd help him with his Lisp program. No thanks.
Though maybe I am just a luddite and the universe is written in iOS.
Not just unfamiliar, difficult.
I will say that when it first came out the direct manipulation of the iPhone UI was a qualitatively different experience compared to any other touchscreen for a very long time. Back then most Android reviews included caveats like "stuttery", "janky", or "low resolution", and these had the cumulative effect of spoiling the illusion of direct manipulation.
Today the gap is much smaller and easier to ignore, and the iPhone has added lots of hidden affordances like swipes and double, triple, and force taps to cater to expert users at the expense of novices.
One danger is if the affordance is triggered accidentally. For example, my kids like pushing buttons and swiping when I wouldn't think to do those things and accidentally switch apps or enter into guided access modes without meaning to. In my case I occasionally trigger things like sticky keys unintentionally.
Another danger is if application developers start assuming that they can rely on users knowing hidden affordances and use swiping, double-tapping, force pressing, right-clicking, etc in the core application workflow. Not an Android iOS example, but last night one of my kids started playing Stardew Valley as their first non-tablet game. It has a steep learning curve since it relies on multiple different keyboard keys and on differentiating between right and left-click, whereas I wouldn't consider right-clicking to be a novice skill.
For complete novices, the first thing they do is click the mouse, and since there are only two buttons it doesn't take long to figure out that left-click is the primary button, and right-click brings up a menu with handy options (practically everything has a context menu in Windows). But with the Web, where context menus are rare, I wouldn't be surprised if it's not as well-known anymore.
I have theories -- maybe it's because most web apps do not bother with context menus (outside of text operations), maybe it's because more people have developed their mental model from touchscreen devices where context menus are less commonly used, maybe more people are on laptops with trackpads that do not make right-clicking as obvious, maybe because there's no visual affordance indicating which onscreen elements have a useful context menu and which have the standard webpage context menu so it's a guessing game. I don't honestly know. But I am confident that if you place key functionality in a context menu of a web-based app that most novice users will not discover it on their own. As per Jakob Nielsen: "...be warned: less skilled users rarely use these [context] menus." [1]
Once end-users learn how to use your app (and therefore are no longer novices) then they seem to have no trouble remembering and using context menus, so it's a great way to expose expert affordances.
In the case of my kids I can also say that the Stardew Valley user interface (such as keeping right-click and left-click actions straight) has been the most difficult part of the game so far. And it doesn't seem like it was particularly necessary distinction to make -- there seem to be few cases where both right- and left-click actions are equally appropriate.
[1] https://www.nngroup.com/articles/feature-richness-and-user-e...
While that's the only way to build empathy, you should be aware (and beware) that it is also a good way to build contempt (as counterproductive as that often is). Many of the "dark patterns" probably originated that way.
Concurrency is excellent as an idea for systems design but horrible for user interfaces. Nothing seems to provide a stable interface and some concurrent process considers it it's privilege to suddenly modify a list of things I'm choosing from .. resulting in the items shifting just a few milliseconds before I click or tap my choice, which results in the wrong choice. This shift happens not only in vertical lists, but also tab-bar style buttons.
To be precise concurrency isn't to blame for it, but it's more like laziness. The interface elements should be locked in place if the system detects that I'm about to select something. Whatever else is waiting to show up can wait, because I obviously didn't need to know about them a few milliseconds earlier.
Or a window from a different app pops up (the app took a while to start), steals the Enter key press, interprets Enter as "Yes do [something]", and then does it (but I didn't want that!).
Why can't OS windows be click & mouse disabled for 2 seconds, after they open
Many graphic design refugees are interested in learning about usability, user research, heuristics, Fitts' Law, GOMS/KLM, etc. But it takes time and energy. I've found that some small companies with no established UX team start out gravitating to shiny portfolio examples and end up putting visual design (VX) folks in charge of interaction design which sometimes goes poorly e.g. https://medium.com/intercom-inside/the-dribbblisation-of-des...
I do believe there are programmers for every category though.
[1] https://blog.gardeviance.org/2015/03/on-pioneers-settlers-to...
The thing is: both design and programming are more often than not messy when things get real, but every programmer wants to create clean and beautiful code and every designer wants to create aesthetical designs. Many intuitively perceive this "beauty" to be in tension with the complexity of the problem that needs solving. The goal of programming and design is however not to create beauty, but to solve problems and do so beautifully and clearly communicate these solutions, because it doesn't matter how beautiful your code/design is if nobody understands it. Beauty is the cherry on top that you get to achieve once the cake below is done, tastes well and puts a smile on the faces of all the party guests. If you are good you might already plan the cherry into the shape of the cake at the very beginning — but confusing the cherry for the cake IMO means you are either not there yet in terms of your profession or the thing is a toy project to try things out specifically — which is totally acceptable if everybody involved agrees and totally egoistic and shitty if they don't. Don't agree to serious projects you are not willing to commit to once the initial interest fades.
Really good designers are about integrating both usabilty and aesthetics in an iterative process, and do so in such a way the problem is solved, and solved beautifully, all while reducing the cognitive overhead needed by users.
And this cognitive overhead is really what should drive us. The work of programmers and designers is so beautiful/dangerous because it multiplies to a thousand people for a thousand hours. Our decision affect people on a daily basis. Removing a papercut might seem like nothing, but if it avoids irritating even ten other people who use that thing 10 times a day, isn't it the obvious thing to not half-ass on, not to toy around with?
Btw. Design that is only about aesthetics is something that I call "styling" maybe we need a similar word for programmers who toy around?
There's a research field called Semiotics of Human-Computer Interaction studying user interfaces from that angle. Developers usually have a technical background from maths or engineering, and often are not aware of the importance of linguistics in our field.
Both programming languages and GUIs are languages (artificial, sure, but linguistics also study those) which are used to write expressions that can be read by humans. Semiotics, the study of signs and their meaning, provide methods to analyze how users make sense of the software artifacts (products and tools) delivered to them.
One researcher called the user interface a designer's deputy, i.e. a messenger that conveys in its entirety a message that the programmers wants to communicate to the users. This deputy must stand on its own, since it's the only information available to the user.
Users then perform sense-making on the symbols in the interface, to infer the meanings of all elements [1]. Notice that the user can't see what each interface element actually does, since they don't have access to the code; they can only guess what it does from the available symbols. If the symbols lead the user to infer an incorrect meaning, communication breaks.
[1] https://blog.prototypr.io/how-semiotics-can-help-us-in-ux-on...
If you go straight from problem to coder, you shouldn't be surprised that you don't have a proper solution, because nobody really made a proper solution. That's like building a house without an architect. Hire an analyst.
This is what agile was created to solve. It was an acceptance of the reality and an attempt to live with that rather than trying to bend it to your will.
Agile does not exclude different roles, on the contrary.
There should actually be testing associated with every step:
Is X a real problem worth solving (severity or cost x frequency)?
Would Y be an appropriate solution (test a mockup, prototype, or stub UI)?
Does the Z implementation work (as in, not just does the problem get solved when Z is used, but does Z actually get used to solve the problem)?
Have you ever played that telephone game?
And if they are, it often ends with impossible to implement/maintain designs.
Do you think business analysis is about software architecture? Oh boy.
Given the tendency for software architectures to mirror org-charts, the two aren't as disparate as you think.
This is giving a false complacency to what outta be a tight intergration between design + developers with an oversight from the product owner. It is simply inexcusable. We're actively creating a culture of disregard/complacency/ignorance by not shedding light on this as a huge problem in UX/UI design.
I want more people to make noise about this.
The big takeaway is that humans shouldn’t be required to think like computers when they are interacting with one.
“Warning : Failed to load library” <ok>
Why did the library failed to load? Why are we being informed? Why does it say “Ok” when it is not ok?
As a lovely example. And on the regular you still have these problems. The daily wtf is full of current day examples.
In defence of the developers/programmers, many people are really bad at explaining what they want, not least because it's often not what they actually need.
If a designer is designing something that looks good but doesn't work well (i.e., solve the problem), they are bad at usability/UX. They should be getting user feedback on their design before it's implemented - that's what user-centred design is about.
There's often a gap when it comes to understanding requirements - between the end-user and the developer, between the designer and developer, etc. Requirements gathering is actually a specialised skill and one of the key duties of a business analyst.
However, with dynamic display-based interfaces, you can do just that. Much as I tend to loathe Apple's design, the way they handle iPad shutdowns is quite good: first, you press a button; then, the entire display changes to focus on this task. If you want to shutdown, you then have to perform an entirely different gesture to confirm. This layering of visual feedback and input types escapes the control panel paradigm and correctly takes advantage of the freedom that act lends to better communicate with the user.
Unfortunately, doing so often means eschewing standards and best practices to find a solution that should work better for users. That is extremely difficult to get right; it's not very surprising that designers would purposely decide to use a flawed but known model instead.
We need to get it out of our heads that designers only do things because they're visually satisfying. They are making purposeful and critical decisions to meet a design objective.
It's not my job as a coder to care about your problem past what has been described to me. It is your job, as product lead, to care about the problem and design a sufficient information architecture, subdomain map, and other documentation to model your problem.
This goes both ways. It is not your job to care about my problems past how it impacts the product. I don't expect you to know or care about how we design the software or how it is implemented; whether we use snake or camelCase, if we use openssl or pgp, if we choose mysql or postgresql.
I just think it's important to outline that much of your comment can be applied in the inverse, and saying that "It's less work to become a mediocre programmer than to intimately understand the problem", is the same as saying "It's less work to become a mediocre product analyst than it is to intimately understand how to code".
I agree with your last point, it's important for every department to have humility and empathy for the problems of their peers. But, it's not a problem to be figured out by designers and coders; it's instead an issue that extends further and requires effort from everyone involved, and at every level, to support.
In particular, it is frequently the case where a product lead says something like “we need a way to...” and leaves the implementation open to discussion to all.
This often leads to a programmer, who is more deeply concerned with how that function will operate on the data, coming up with a “how about a button that...” and/or just implementing the button as a suggestion.
And then the UX architect and product lead, knowing that they don’t want to piss off this coder for fear of future pushback on their ideas, just caves and says “fine”.
That’s the most common scenario I’ve seen at larger companies. That, and having woefully inexperienced UX and UI designers in the first place.
That’s how I identify what I understand and what I don’t.
There's this widespread belief now that software is only good if a user who never saw it before can become proficient in it in seconds to minutes. I think this is one of the most devastating, dangerous ideas in computing. The only way you can achieve a learning curve like this is by removing almost all functionality from software - make it so dumb that it really takes only a minute to figure it out entirely. Sadly, this is what we see in mobile and web applications these days.
What worries me here is that we've conditioned everyone to assume software is immediately and fully discoverable. Nobody is expected to read the manual these days, and so manuals are not provided, and since manuals are not provided, any feature that cannot be made apparent without explaining it in the manual goes away.
(Even with kitchen appliances, the situation isn't that bad. When a person sees a particular appliance for the first time, they do read the manual, or get someone to show them how to operate it. Maybe it comes with the fact that buying appliances is expensive and overall a hassle, whereas software is too easy to procure?)
--
[0] - I highlight that condition, because it's my belief that most software vendors don't care about delivering value to users. They care about making money off users, and there are many cheaper ways to do that than creating a truly useful and ergonomic product.
Right. We're prioritizing learnability over usability.
> We should be making the easy things easy, hard things possible, and forget about the whole intuitiveness thing.
Whoa there... Another way of thinking about 'intuitiveness' is in terms of affordances. We mustn't throw the baby out with the bathwater. While it is too much to ask that every function should be obvious upon first seeing the UI, it is not too much too ask that every function should at least be obvious in retrospect after trying to use it or having it demonstrated, and of course leveraging affordances and interaction patterns the user is likely familiar with from elsewhere should be given priority.
Yes, of course. Thanks for bringing this up. I apologize, I went a bit too far there - what I meant was just "intuitiveness" in the sense of expecting people to be immediately able to work well with something they see for the very first time, with no explicit learning or training.
I also don't mean to ignore familiarity with UIs in general - yes, unless you have a good reason, it's a good idea to copy design elements users are well familiar with (if they're not completely insane, or dark patterns). This matters particularly on mobile and desktop. On the Web, everyone is used to websites looking different from each other, but there are still higher-level patterns (like footer with company info, "contact" link somewhere on the site, site logo redirecting to home, etc.).
I totally agree about affordances, and mental handles in general. "Obvious in retrospect" is a great way of putting it - once you know a feature exists, or used it briefly, it should be easy to find it again. Once you familiarize yourself with a bunch of features, it should be obvious where to find them, because they should fit a consistent mental model. In a way, it's the job of the UI - to let the user learn the correct mental model of the application, and how it manipulates underlying resources.
For that to happen though, you as a software team need at least to a) have a consistent mental model yourself, and b) design both "backend" and UI around that model. I think this is one part where we fail frequently, but unintentionally - the developers and the designers don't spend enough time ensuring they have a shared mental model. When this happens, you have UI that may be consistent with itself, but feels off when used, and every now and then you see surprising behavior or incomprehensible error messages - that's the "backend" model leaking out.
I *try* to make my software initially intuitive and gradually discoverable. I think a gentle learning curve is better than a completely flat one.
I thought quite a bit recently about the problem that you are talking about (diminishing end user value in software). I think the source is that we have a lot of devs and designers whose only experience is designing for maximized conversion rate or maximized engagement. As opposed to professional software.
They have no habit of designing for value.
And *that’s the culture*. Go to any awwwards gallery - all of the websites or webapps mentioned there are essentially ads with minimal content.
Which isn’t too bad, since it leaves a market untapped through the collective arrogance of the incumbents...
Some days ago I wrote here in HN about the change my stock broker made on their default home broker. It immediately becomes obvious that the people responsible for that design have never performed anything nontrivial with stocks. They created a symmetrical, colorful platform. The symmetry is enforced, therefore you don't have the flexibility of setting up your quote-boxes any longer (perhaps because that would break the artist's concept). Just to mention one of many issues the new design brought.
The same applies to the Google Meet example in the article. Functionally, you'd never want those buttons presented that way. But placing them like that makes them look nice and symmetrical and Gestalt-related stuff, so that's the way to go and deal with it, dear users.
> Perhaps the hardest part is having the humility to admit, "I don't understand the problem sufficiently" and the empathy to care about the problem enough to learn it well
I agree, but don't see that happening, not in the short term at least. I had an argument with a designer some time ago about how much longer the project was going to take and how her ideas were actually substracting value from a user perspective. But she ended the discussion with a "this project has my signature, my reputation is in there". And that's what my criticism against current UX trends is all about. Artist's concept trumps user needs, project maintainability and everything. They are investing all the resources on graphic design matters and this is obstructing the whole field.
Some UX folks argue that designers like those "aren't true UX designers". I agree, but those "false" designers seems to be outnumbering the "true" ones. The latter may eventually have to found a new discipline.
Therefore, in this project you'll be helping a professor from some non-CS department write educational software. You have to balance accessibility with pedagogical accuracy, as guided by someone who doesn't secretly know that some specific algorithm is the magic key to solving the problem.
If the stakeholder has such a clear vision of their end result, they probably won't need you to help them implement it!
You're spot on re: humility and empathy. I see so much hubris in programmers/computer people thinking they/we can fully understand the world's problems, much less solve them.
For starters, what context have you even experienced this in? From your description it sounds like both you and the programmer (or designer, as the case may be) are just doing this as a side project. Of course there's not going to be the incentive to follow-up and do the hard work of finding actual product-market fit if it was supposed to just be a fun learning experience from the beginning. Did you ever communicate with them what your expectations are, what the end goal is, how much of a time commitment you expect, and was the other person on the same page and equally invested in it? Also, why are you expecting the programmer to both figure out the nuances of the product and implement it? What is even your role in this, what do you bring to the table?
It sounds to me like you did not communicate well or did not set expectations properly about this project, and now you're blaming the other person for doing a bad/lazy job.
I try to make myself interested in your problems. However, most of them seem really ''otherworldy'' to me or are in a domain I don't care about about. I became a programmer because I like the art of the trade, and I keep myself interested by writing interesting code.
But what I think you really mean is that people are often in a blame culture that strategically puts up responsibility defenses which distracts them from producing a good result and focuses them on red taping to cover their asses. It is quite possible in these organizational structures to produce absolute shit and tick all the boxes and get everything approved and make sure no one in the position of actually doing stuff gets blamed for anything.
Not saying that it's their personal fault that certain companies are that way, but it is possible to have some self respect and march back up to the manager and say hey this is shit and we should do a better design rather than waste time on this (ok, yes in a more articulate and respectful way) - if you think that risks your job then it's probably going to be more fruitful working somewhere else anyway. Disclaimer: yes I know real life has other restrictions that means not everyone can do this.
It is kind of a tautology to say it but this hints at it being a human organizational social issue behind the pathology if it keeps cropping up.
I agree that good design is hard and often involves substantial work beyond just making something on the sheet.
They're essentially aestheticians, not designers. Yep, I hate them too.
The fact that the code is available means someone can fork it and make their own changes and improvements.
Firstly, I've observed a phenomenon when I talk to a programmer about a problem I want to solve. They might get excited, learn a bit of the problem domain and then go off and build something that kind of solves part of my problem. But then I'm stuck in a endless cycle of explaining the rest of the problem, to someone who isn't really interested, then waiting for a new iteration and then evaluating how it doesn't completely the solve the problem until the programmer gets bored and goes off to find something new and exciting to do with computers. Programming the computerwas always the end for them. They don't actually care about the problem. I care about the problem. So for me computers are a tool to solve my problem. I might as well write the program myself because it's less work to become a mediocre programmer than to intimately understand the problem.
My theory is that something like this happens in interface design. There are designers who love to create beautiful designs, and we love that, but beauty is the end of it for them. They don't actually care about the problem that the program (website, app, whatever) is supposed to solve. If they were stuck in a job filling out forms all day they would quickly learn the lesson to put the reset button out of the way. If they were intimately familiar with the problem, the better design would be obvious. And so it is that people with no "design skills" can point out the obvious mistakes of the designers.
It's also true that good design is hard. Starting with a blank sheet and creating something, let alone something good, is daunting. Perhaps the hardest part is having the humility to admit, "I don't understand the problem sufficiently" and the empathy to care about the problem enough to learn it well.