The main challenge in UI design is balancing between:
- Allowing the user to perform desired operations in as few steps as possible
- Without cluttering the screen with all kinds of irrelevant controls
These constraints can be at odds:
Every time you hide some feature away in a menu, you are adding steps the user has to perform to achieve what they want
On the other hand, presenting every single feature on the screen all the time just clutters the UI and makes the user feel confused
It's no good to let the user decide what goes on the UI either: you've now just burdened the user with the job of creating a UI for your application.
Other constraints:
- Make sure all features are "disocverable" by just casually playing around the UI.
This rules out the idea of "hiding" things until the user triggers some kind of magic incantation.
Command pallets and shortcuts are great ways for enabling power users to perform operations quickly, but the product must have other ways for exposing features that is predictable and boring. Menus are a great way to do this. A user casually playing around with buttons and menus will eventually discover features, and they will also eventually learn the shortcuts for them.
> The main challenge in UI design is balancing between:
- Allowing the user to perform desired operations in as few steps as possible
- Without cluttering the screen with all kinds of irrelevant controls
Interestingly, I just watched a video by David Khourshid (founder of stately.ai; xstate/state chart/state machine fame) on how LLMs can interface with state charts of your application logic to find the shortest path to accomplishing a goal.
It doesn't seem like too far of a stretch, if your application is designed to support this use case, that an LLM can convert intent to shortest path for a user. I'm very excited about the possibilities here personally.
The great thing about menus and similar “universal” components is that the user only needs to learn one (or a very few) ways for how to discover things. One problem with modern UIs is that each app looks different and/or is laid out differently, and that there are a multitude of different-looking navigation elements and popup-menu buttons and/or sliding gestures. And of course that it’s often not clear what is just a label or graphic indication vs. a clickable button.
Desktop app complexity had grown over a decade so that Microsoft Word, which started with a simple single-row toolbar, now was taking over 30% of a typical PC screen with a sea of icons and controls. Meanwhile the growth in PC sales meant there was an influx of non-corporate users who were not being trained to use the apps.
That’s how we got Clippy (essentially similar to the text input box proposed here), “progressive”menus that hide advanced actions and features the user hasn’t been accessing, as well as the explosion of task-oriented panels in Windows XP.
The execution of these ideas left a lot to be desired. (The Office 2006 Ribbon UI was actually a meaningful step forward because it contextualized and prioritized the UI rather than hiding stuff. Microsoft has solid data showing that Ribbon improved the user experience.)
Maybe language model AI can give this kind of UI a new lease of life.
> The Office 2006 Ribbon UI was actually a meaningful step forward because it contextualized and prioritized the UI rather than hiding stuff. Microsoft has solid data showing that Ribbon improved the user experience.
It’s great for learning. But the different panels and varied icons, make it annoying to scan and find things…
compared to the traditional nested toolbar with consistent sized icons and labels
> Microsoft has solid data showing that Ribbon improved the user experience
do they also have data filtered to show powerusers? just because metrics go up doesn't really mean it got better. I'm pretty sure google also has metrics "showing" that it got better at finding stuff, which I really can't agree with. my ms-office literacy was much higher pre ribbon, and it never cought up
> That’s how we got Clippy (essentially similar to the text input box proposed here), “progressive” menus that hide advanced actions and features the user hasn’t been accessing, as well as the explosion of task-oriented panels in Windows XP.
You're implying those were bad decisions, but could you also explain what exactly was bad about them?
I think Clippy legitimately was a bad idea: It was a clumsy attempt at anthropomorphising the computer, and it also came over cartoonish and game-y: Effectively, used UI patterns from a video game in a context where users wanted to get serious work done. (Interestingly, it also foreshadowed a lot of later trends in tech: Clippy was asynchronous, interrupting the user with notifications even if the user never did anything; and it foreshadowed the ability of programs to actually analyze content and not just be dumb typewriters with the infamous "it looks like you are writing a letter" message. I guess Tech learned it's lesson from the backlash, namely that it needs to be more covert and subtle about those abilities...)
However, the idea to show possible actions in the context where they are useful always seemed like the most straightforward thing to me. Maybe i'm biased as a programmer, but it seems natural to structure an UI in an "object oriented" manner, where the user is presented with certain types of "entities" and can manipulate them using certain actions: E.g., if you have a file, you can copy, delete or move it; you can also launch a program to edit it. You can do the same with a folder, but you can additionally navigate into the folder, etc.
The same pattern in a lot of programs designed for creating media: The entities would be text selections in word processors, shapes and layers in image processors, 3D objects in 3D designers, etc.
That was the basic idea behind the task panels in WinXP I believe. So what was bad about them?
UI is no longer user-driven as in giving the user the best possible experience. It is business model driven, I.e. utilizing dark patterns ("Yes" | "Ask again later" dialogs), data/telemetry collection for advertising, showing "pro" features pretending to be available just to tell they require upgrading when trying to use etc.
I really like the site owner's "digital garden" metaphor. One of the problems with social media is they've constrained personal websites to a standard format, and this has molded creativity around what a personal website should look like.
For example, if people were somehow forced to make their own sites, they would find that the content they have to share is not quite blog, not quite portfolio, not quite photo gallery, etc.. sort of like geocities of the 90's. It's actually a hard problem.
In general, I really enjoy personal websites because they show different people's attempts at solving this problem, and the digital "garden concept" is a cool metaphor.
I identify as a strong proponent of function over form, but I have to say, that is one pretty website. The web used to be littered with design-heavy sites, although few worked as well as this does. Either way, I wish there were more of them these days.
VS code (developer interface) has this feature where you activate a text input with a hotkey. It is used to trigger specific actions. You can type text and it will give you the actions that match the text. You also see a list of the actions you triggered that way previously.
This is great because I don't have to remember how to trigger a specific action and I can also discover new actions just by searching.
Ultimately it doesn't change the UI, but it sounds quite similar to what the author describes. There is some potential there with a search bar that is more about intent than text matching.
This brings back memories from my old days of VS programming (.NET C# or C++) with IntelliSense when I used to bless every object instance with Ctrl+Space.
In the early 2000s Microsoft did a lot of research in to "Inductive User Interfaces". [1] The closest approximation still around would be Wizard interfaces.
Creating those UIs was so rewarding, as you really had to focus on the goals of the user and figure out the branching that could get the right user to the action or activity that they needed to perform.
My first "startup" was a tool for life insurance agents to recommend products to their prospective customers. IUIs were perfect for scenarios like that. You could abstract away a lot of complexity.
I don't think you need AI for this, VSCode and lots of other applications already have a "functionality search bar" built right into the program. (Often euphemized as a command palette).
I myself don't use them much but I can see where they are useful to the "new users" the article speaks of, to discover and unlock features as the user gets more comfortable with the program.
I've long since taken to preferentially using the search bar instead of bothering to learn the location of buttons e.g. in the Office ribbon menus. It's a true blessing.
I might just be me but as I get older I'm finding it harder and harder to navigate UIs even though I've been an early adopter of technology throughout my life. I wonder if it is a sign of cognitive decline or just the consequence of having to remember an increasing amount of perpetually changing UIs.
I don't have that much trouble with modern UIs, but that's because of accumulated generalized experience with UIs and programming, plus modern UIs are simpler by virtue of most new software being perpetual MVPs / toys. However, I've also noticed I have much less patience for "UI innovation".
When I was younger, I was under less pressure and could blow some time having fun with new software. These days, I have very little free time, and usually have a specific job or task to do for the new software - the UI is effectively standing between me and my goal, so the more I have to learn about it, the more irritated I get.
It's always irritation and never hopelessness, because I have 100% confidence I can figure the UI out given enough time - I just hate having to spend that time.
Note: that's not the same as "simple UIs == better UIs". Complex and powerful UIs with good manuals are the best for me. After all, if I used some software once, there's a very good chance I'll need to use it again, and again, and then some, probably in one or few sessions. Whatever time and frustration simple UIs and toy software save on first use, come back tenfold when I realize the UI is so dumb it doesn't have any way to batch repetitive operations.
Slightly differing UIs are not interesting enough for your brain to activate problem solving and learning. But they are different enough for you to get slightly confused in minor ways.
I think that’s why some people streamline their UIs as much as possible: vim/emacs/terminal everything, same bindings everywhere etc. all optimized for muscle memory and comfort.
Part of Englebart's great demo was about how they'd designed different kinds of interfaces for adults and children. Adults would have sequences of (chorded keyboard) commands that they could learn to do work rapidly. Children would have UI like is ubiquitous today - it could be explored and would be discoverable.
I never knew what research that was based on, but it sounds like you'd prefer the grown-up experience that most companies just don't make. The closest we see are hotkeys for things like Office or our IDEs, but those can lack consistency from one version to the next and certainly from one piece of software to the next.
Nice article. An alternate is completely unrelated to AI/GPT and rather, the basic use of a command bar/palette. Provides a lot of new ways to approach UX.
Yeah, I definitely think the biggest productivity gains I've had in my entire life were the command bar in VSCode and the integrated start menu search in Windows 7. Keep the UI simple, but searchable, even better if I never have to take my hands off the keyboard to find and execute a command.
On a somewhat related note, does anyone else find scrolling on the page really laggy? Not unusable but definitely noticable. I'm on desktop Firefox.
I've always found it weird that a "function search" hasn't become more mainstream.
It's easy to implement without AI. Just make a big list of your functions, describe them verbosely, and give them a link - now let the user search for what they want to do and send them there.
I remember Rhino3d having this 10 years ago and it was amazing while all kinds of daws, editing programs, desks etc. would be a jungle to navigate or just have a "docs" or "help pdfs" - such a waste of time to look through.
In general this kind of navigation has been overlooked for decades.
Current UI designs have business constraints that just can't allow for much change. The user is not the customer, the user can't be bothered to invest time to learn as there are multiple apps competing for their attention, if the user is familiar with some UI design you can't give him a completely different design regardless of how much better it is and so on.
In spaces where the business considerations are different (aviation, medical devices, mature open source projects, etc) the UI is pretty good for the target users.
A sidebar to this includes abusing "easy" to equate to "requiring less energy" to operate. An increase in stress equates to more energy used. To wit, being forced to find differences in ui functionality across mobile and web for the same app. Or clicking on a control that just jumped location because of a slow page render. Or maybe just gratuitous (debatable value) in ui changes between windows versions.
OG get off my lawn stuff: When I first started writing code back in 1989, I worked on a tui desktop app that was extremely refined to facilitate data entry from a piece of paper. Sort of a microscope split your vision between paper and instrument. Everything about the tui was custom and optimized via tons of user feedback. By far that app still represents an example of the least energy required to get something valuable done on a desktop. Yes, specific use case to a large degree, but the tui framework we built suggested ease of use for tuis in general.
Redoing the app in windows killed the experience to a noticeable degree. The point is, suggest that generalized ui tool constraints will force the user to expend more energy, in some way at some point. Obvious point, but there is no perfect ui solution, especially in today's world. Only trade-offs.
I like where they're going, but I think the model is too simple. There's no "a user". Software is a response to populations of users.
An MVP is always focused on a very specific audience, the early adopters for it. It can be minimal because it's for a group of highly motivated people eager to solve a specific problem. They tend to be both experts (in the specific problem space) and explorers (in their willingness to try things out).
By the time a product has spent a few years growing, it is often addressing the needs of a much broader set of users, which presents a much bigger UI challenge. But it's not just a UI challenge. Take film/video editing, for example. The original film editors were all using physical gear to splice actual film together. [1] The initial target for computer-based video editors was those same expert film editors. One of those editors who made the switch pointed out that people knew they didn't know how to use his complicated set of physical tools, but assumed that since it was on a computer, they too could edit film. [2]
That wasn't the case, though. If you want to go from addressing the population of "expert film editor" to "person who wants to be come an expert film editor" it's a radically different problem. A very valid solution to that is keeping the interface as is and saying "go take a class".
Then you also have populations like "person who doesn't want to become an expert editor but wants to share a tolerable video of Bobby's first birthday". That's an argument not for a modal interface, but for a tool built for that audience and no other. Maybe it's a cut-down version of the expert one. But just as likely as it's something that does not work with a pro editor's mental model at all, but with that of the existing user.
I'm working on this a lot right now, I have long tinkered on my personal productivity and data interface and I'm trying to make it accessible to others. It basically puts an end to context switching and deletes that cost from 80%+ of my workflows. It's a "no" first interface so it really removes clutter and cognitive overhead.
I think with NLP and with AI guides we really need to change our unifying OS interface away from "adhoc work tools catagorized by icons" and go to interfaces categorized by intent or users data structure (that maps to their problem/intent/world as it grows and develops), so much lexical work has been done, so many concepts propogated via guis, that I think composable lexical interfaces should return with visual and nlp aids.
The ideas are interesting, the illustrations are highly distracting.
> If the software is at a certain level of complexity, new users will only learn parts of it or not use it at all.
Being talked about complexity next to a cockpit of a plane that mandates pre-training, with an exam leading to the acquisition of a license, followed by a mandatory minimum number of flight hours per month to keep the right to fly alone isn't the best illustration I have of "new users will only learn parts of it"
And it goes on for every bullet point, there will be a plane cockpit next to it...
But yes, I totally agree that more thought needs to be given to the learning curve and discoverability of features of other non life critical, non regulated software.
I feel like you could strip down a UI, stick a language model on a help menu and you'd be most of the way there with this already.
I have a minor hesitation here. The user inputs an endpoint, and the program is then supposed to connect a user with the tool to complete it. Solutions often have different ways of being reached with tradeoffs associated with each method.
Also, I wouldn't underestimate the ways in which, for some types of workers, the affordances of tools are part of the creative process. There's a way in which a product will be less thought through when the journey from conception to completion is cut short.
Amusingly, for a long time, emacs has effectively been this, but with a fuzzy search tool. Very common to just bring up the command minibar and start typing words looking for relevant things.
Going back, many old machines were like this. They all had some form of "apropos" command that we seem to have completely forgotten about as things got bigger. Indeed, the idea of man pages and the like seemed to get skipped out on with dos, such that windows also didn't really have it ingrained heavily. The docs were almost certainly there, but they were often specific in formatting to each program? (Or is my memory just off?)
Really good article! I like how it framed simplicity and complexity of apps, and how users want to stay in a certain zone.
I know the example was trite but future UIs will just allow the user to type or speak what they're trying to do. For example coloring in the circle/triangle will literally require you to say just that.
Whenever I see how people are cropping, masking, and adjusting an image, it already feels so outdated with what AI feels like it will be able to do based on text/voice input.
[+] [-] hsn915|2 years ago|reply
- Allowing the user to perform desired operations in as few steps as possible
- Without cluttering the screen with all kinds of irrelevant controls
These constraints can be at odds:
Every time you hide some feature away in a menu, you are adding steps the user has to perform to achieve what they want
On the other hand, presenting every single feature on the screen all the time just clutters the UI and makes the user feel confused
It's no good to let the user decide what goes on the UI either: you've now just burdened the user with the job of creating a UI for your application.
Other constraints:
- Make sure all features are "disocverable" by just casually playing around the UI.
This rules out the idea of "hiding" things until the user triggers some kind of magic incantation.
Command pallets and shortcuts are great ways for enabling power users to perform operations quickly, but the product must have other ways for exposing features that is predictable and boring. Menus are a great way to do this. A user casually playing around with buttons and menus will eventually discover features, and they will also eventually learn the shortcuts for them.
[+] [-] blueberrychpstx|2 years ago|reply
- Without cluttering the screen with all kinds of irrelevant controls
Interestingly, I just watched a video by David Khourshid (founder of stately.ai; xstate/state chart/state machine fame) on how LLMs can interface with state charts of your application logic to find the shortest path to accomplishing a goal.
It doesn't seem like too far of a stretch, if your application is designed to support this use case, that an LLM can convert intent to shortest path for a user. I'm very excited about the possibilities here personally.
https://www.youtube.com/watch?v=qoNDyOClTtI
[+] [-] layer8|2 years ago|reply
[+] [-] pavlov|2 years ago|reply
Desktop app complexity had grown over a decade so that Microsoft Word, which started with a simple single-row toolbar, now was taking over 30% of a typical PC screen with a sea of icons and controls. Meanwhile the growth in PC sales meant there was an influx of non-corporate users who were not being trained to use the apps.
That’s how we got Clippy (essentially similar to the text input box proposed here), “progressive”menus that hide advanced actions and features the user hasn’t been accessing, as well as the explosion of task-oriented panels in Windows XP.
The execution of these ideas left a lot to be desired. (The Office 2006 Ribbon UI was actually a meaningful step forward because it contextualized and prioritized the UI rather than hiding stuff. Microsoft has solid data showing that Ribbon improved the user experience.)
Maybe language model AI can give this kind of UI a new lease of life.
[+] [-] gitgud|2 years ago|reply
It’s great for learning. But the different panels and varied icons, make it annoying to scan and find things…
compared to the traditional nested toolbar with consistent sized icons and labels
[+] [-] taskforcegemini|2 years ago|reply
do they also have data filtered to show powerusers? just because metrics go up doesn't really mean it got better. I'm pretty sure google also has metrics "showing" that it got better at finding stuff, which I really can't agree with. my ms-office literacy was much higher pre ribbon, and it never cought up
[+] [-] JohnFen|2 years ago|reply
I deeply hate the ribbon because it's so good at hiding stuff. And moving stuff around.
[+] [-] xg15|2 years ago|reply
You're implying those were bad decisions, but could you also explain what exactly was bad about them?
I think Clippy legitimately was a bad idea: It was a clumsy attempt at anthropomorphising the computer, and it also came over cartoonish and game-y: Effectively, used UI patterns from a video game in a context where users wanted to get serious work done. (Interestingly, it also foreshadowed a lot of later trends in tech: Clippy was asynchronous, interrupting the user with notifications even if the user never did anything; and it foreshadowed the ability of programs to actually analyze content and not just be dumb typewriters with the infamous "it looks like you are writing a letter" message. I guess Tech learned it's lesson from the backlash, namely that it needs to be more covert and subtle about those abilities...)
However, the idea to show possible actions in the context where they are useful always seemed like the most straightforward thing to me. Maybe i'm biased as a programmer, but it seems natural to structure an UI in an "object oriented" manner, where the user is presented with certain types of "entities" and can manipulate them using certain actions: E.g., if you have a file, you can copy, delete or move it; you can also launch a program to edit it. You can do the same with a folder, but you can additionally navigate into the folder, etc.
The same pattern in a lot of programs designed for creating media: The entities would be text selections in word processors, shapes and layers in image processors, 3D objects in 3D designers, etc.
That was the basic idea behind the task panels in WinXP I believe. So what was bad about them?
[+] [-] littlecranky67|2 years ago|reply
[+] [-] blueberrychpstx|2 years ago|reply
Us HN nerds could easily build alternatives we just don't. Or the ones that we do are so niche we never find them.
Interesting how there always seems to exist this dialectic
[+] [-] asimpletune|2 years ago|reply
For example, if people were somehow forced to make their own sites, they would find that the content they have to share is not quite blog, not quite portfolio, not quite photo gallery, etc.. sort of like geocities of the 90's. It's actually a hard problem.
In general, I really enjoy personal websites because they show different people's attempts at solving this problem, and the digital "garden concept" is a cool metaphor.
[+] [-] bityard|2 years ago|reply
[+] [-] d0m3|2 years ago|reply
[+] [-] easton|2 years ago|reply
[+] [-] amne|2 years ago|reply
[+] [-] carlosjobim|2 years ago|reply
[+] [-] jmacd|2 years ago|reply
Creating those UIs was so rewarding, as you really had to focus on the goals of the user and figure out the branching that could get the right user to the action or activity that they needed to perform.
My first "startup" was a tool for life insurance agents to recommend products to their prospective customers. IUIs were perfect for scenarios like that. You could abstract away a lot of complexity.
They were also great for accessibility.
1: https://learn.microsoft.com/en-us/windows/win32/appuistart/i...
[+] [-] bityard|2 years ago|reply
I myself don't use them much but I can see where they are useful to the "new users" the article speaks of, to discover and unlock features as the user gets more comfortable with the program.
[+] [-] Arrath|2 years ago|reply
[+] [-] CTDOCodebases|2 years ago|reply
[+] [-] ducktective|2 years ago|reply
Just read up on recent UI "improvements" on Firefox, GNOME, Android status-bar etc.
I blame it on job positions that need to churn out "change" for the sake of relevancy. You can't just solve UI, right?
[+] [-] TeMPOraL|2 years ago|reply
I don't have that much trouble with modern UIs, but that's because of accumulated generalized experience with UIs and programming, plus modern UIs are simpler by virtue of most new software being perpetual MVPs / toys. However, I've also noticed I have much less patience for "UI innovation".
When I was younger, I was under less pressure and could blow some time having fun with new software. These days, I have very little free time, and usually have a specific job or task to do for the new software - the UI is effectively standing between me and my goal, so the more I have to learn about it, the more irritated I get.
It's always irritation and never hopelessness, because I have 100% confidence I can figure the UI out given enough time - I just hate having to spend that time.
Note: that's not the same as "simple UIs == better UIs". Complex and powerful UIs with good manuals are the best for me. After all, if I used some software once, there's a very good chance I'll need to use it again, and again, and then some, probably in one or few sessions. Whatever time and frustration simple UIs and toy software save on first use, come back tenfold when I realize the UI is so dumb it doesn't have any way to batch repetitive operations.
[+] [-] dgb23|2 years ago|reply
Slightly differing UIs are not interesting enough for your brain to activate problem solving and learning. But they are different enough for you to get slightly confused in minor ways.
I think that’s why some people streamline their UIs as much as possible: vim/emacs/terminal everything, same bindings everywhere etc. all optimized for muscle memory and comfort.
[+] [-] drewcoo|2 years ago|reply
I never knew what research that was based on, but it sounds like you'd prefer the grown-up experience that most companies just don't make. The closest we see are hotkeys for things like Office or our IDEs, but those can lack consistency from one version to the next and certainly from one piece of software to the next.
[+] [-] bradwoodsio|2 years ago|reply
[+] [-] phosphorco|2 years ago|reply
[+] [-] worble|2 years ago|reply
On a somewhat related note, does anyone else find scrolling on the page really laggy? Not unusable but definitely noticable. I'm on desktop Firefox.
[+] [-] simulo|2 years ago|reply
The idea to use text more actively in user interfaces is not new, there were/are these ideas, for example:
- Gentner/Nielsen: The Anti-Mac Interface, 1996 ( https://www.nngroup.com/articles/anti-mac-interface/ )
- Raskin’s ideas as in "The Human Interface", 2000 and the Canon Cat, 1987: ( https://www.reproof.app/blog/on-designing-a-more-humane-comp... )
- Wirth’s Oberon Operating System: https://en.wikipedia.org/wiki/Oberon_(operating_system)#User...
[+] [-] kossTKR|2 years ago|reply
It's easy to implement without AI. Just make a big list of your functions, describe them verbosely, and give them a link - now let the user search for what they want to do and send them there.
I remember Rhino3d having this 10 years ago and it was amazing while all kinds of daws, editing programs, desks etc. would be a jungle to navigate or just have a "docs" or "help pdfs" - such a waste of time to look through.
In general this kind of navigation has been overlooked for decades.
[+] [-] carlosjobim|2 years ago|reply
[+] [-] trabant00|2 years ago|reply
In spaces where the business considerations are different (aviation, medical devices, mature open source projects, etc) the UI is pretty good for the target users.
[+] [-] jksmith|2 years ago|reply
OG get off my lawn stuff: When I first started writing code back in 1989, I worked on a tui desktop app that was extremely refined to facilitate data entry from a piece of paper. Sort of a microscope split your vision between paper and instrument. Everything about the tui was custom and optimized via tons of user feedback. By far that app still represents an example of the least energy required to get something valuable done on a desktop. Yes, specific use case to a large degree, but the tui framework we built suggested ease of use for tuis in general.
Redoing the app in windows killed the experience to a noticeable degree. The point is, suggest that generalized ui tool constraints will force the user to expend more energy, in some way at some point. Obvious point, but there is no perfect ui solution, especially in today's world. Only trade-offs.
[+] [-] wpietri|2 years ago|reply
An MVP is always focused on a very specific audience, the early adopters for it. It can be minimal because it's for a group of highly motivated people eager to solve a specific problem. They tend to be both experts (in the specific problem space) and explorers (in their willingness to try things out).
By the time a product has spent a few years growing, it is often addressing the needs of a much broader set of users, which presents a much bigger UI challenge. But it's not just a UI challenge. Take film/video editing, for example. The original film editors were all using physical gear to splice actual film together. [1] The initial target for computer-based video editors was those same expert film editors. One of those editors who made the switch pointed out that people knew they didn't know how to use his complicated set of physical tools, but assumed that since it was on a computer, they too could edit film. [2]
That wasn't the case, though. If you want to go from addressing the population of "expert film editor" to "person who wants to be come an expert film editor" it's a radically different problem. A very valid solution to that is keeping the interface as is and saying "go take a class".
Then you also have populations like "person who doesn't want to become an expert editor but wants to share a tolerable video of Bobby's first birthday". That's an argument not for a modal interface, but for a tool built for that audience and no other. Maybe it's a cut-down version of the expert one. But just as likely as it's something that does not work with a pro editor's mental model at all, but with that of the existing user.
[1] See, e.g., https://www.youtube.com/watch?v=0V8k6qMpv7E and https://en.wikipedia.org/wiki/Steenbeck
[2] first video here, https://www.adapttvhistory.org.uk/post-production/post-produ...
[+] [-] fellowniusmonk|2 years ago|reply
I think with NLP and with AI guides we really need to change our unifying OS interface away from "adhoc work tools catagorized by icons" and go to interfaces categorized by intent or users data structure (that maps to their problem/intent/world as it grows and develops), so much lexical work has been done, so many concepts propogated via guis, that I think composable lexical interfaces should return with visual and nlp aids.
[+] [-] bhy|2 years ago|reply
[+] [-] keyle|2 years ago|reply
[+] [-] Narishma|2 years ago|reply
[+] [-] bradwoodsio|2 years ago|reply
[+] [-] makeitdouble|2 years ago|reply
> If the software is at a certain level of complexity, new users will only learn parts of it or not use it at all.
Being talked about complexity next to a cockpit of a plane that mandates pre-training, with an exam leading to the acquisition of a license, followed by a mandatory minimum number of flight hours per month to keep the right to fly alone isn't the best illustration I have of "new users will only learn parts of it"
And it goes on for every bullet point, there will be a plane cockpit next to it...
But yes, I totally agree that more thought needs to be given to the learning curve and discoverability of features of other non life critical, non regulated software.
[+] [-] thelogicguy|2 years ago|reply
I have a minor hesitation here. The user inputs an endpoint, and the program is then supposed to connect a user with the tool to complete it. Solutions often have different ways of being reached with tradeoffs associated with each method.
Also, I wouldn't underestimate the ways in which, for some types of workers, the affordances of tools are part of the creative process. There's a way in which a product will be less thought through when the journey from conception to completion is cut short.
[+] [-] taeric|2 years ago|reply
Going back, many old machines were like this. They all had some form of "apropos" command that we seem to have completely forgotten about as things got bigger. Indeed, the idea of man pages and the like seemed to get skipped out on with dos, such that windows also didn't really have it ingrained heavily. The docs were almost certainly there, but they were often specific in formatting to each program? (Or is my memory just off?)
[+] [-] yoshyosh|2 years ago|reply
I know the example was trite but future UIs will just allow the user to type or speak what they're trying to do. For example coloring in the circle/triangle will literally require you to say just that.
Whenever I see how people are cropping, masking, and adjusting an image, it already feels so outdated with what AI feels like it will be able to do based on text/voice input.
[+] [-] wrftaylor|2 years ago|reply