6 ms·

> We've simply gotten used to them: Dealing with the idiosyncracies of bash, vi, or the JavaScript type system This stuck out to me, there seems to be a trend

> We've simply gotten used to them: Dealing with the idiosyncracies of bash, vi, or the JavaScript type system This stuck out to me, there seems to be a trend in UX/UI where any move away from the "simplest path" is seen as a huge negative. Could it be the case that we use these tools (especially UI patterns like vi) because after the learning curve the give a huge amount of value? It seems like we are assuming that we should make a developer tool with the same level of "immediate familliarity" that we try to build into a website where customers will bounce easily, for an audience who is willing to spend time learning a tool if it provides value to them.

Gehinnn 7y ago
I think even complex products should have a linear progression from newcomers, curiously exploring the product for the first time, to experts, who want to do certain tasks as fast as possible. It's simply not possible to learn vi by just using vi. Also, the author emphasizes that just dumbening a product is not the solution.
- ailideex 7y ago
  > It's simply not possible to learn vi by just using vi. I did. I learnt vi when I was told go fix this file on that computer, you have ssh, x forwarding won't work because you have 3 hops (embedded devices that won't allow forwarding of any kind), there is only vi on the box. So I figured out how to use vi. It is not rocket science, there is not that much to learn, vi muscle memory takes time but also not even that long I think.
  - Gehinnn 7y ago
    Did you read about vi before? How do you know all the shortcuts?
    - ailideex 7y ago
      I googled it. I did not know vi before that, and now I use vim as my main editor for code.
      - krisoft 7y ago
        So you did not just "learn vi by just using vi". You have also used a browser, google, and tutorials found by google. There is nothing wrong with that. In fact congratulation on learning vi! But sadly your example does not illustrate that one can "learn vi by just using vi".
        2zcon 7y ago
        The intro screen tells you exactly how to open help and exit. Man gives you even clearer instructions.
        Narishma 7y ago
        If you just launch vim it tells you the basics of how to use it, and how to get more help. So it's definitely possible to learn it without external resources. Emacs is the same.
  - test1235 7y ago
    There's not much to learn if you're editing the odd file ... if you want to use vim as an effective development tool, there's loads to learn.
    - ailideex 7y ago
      I would think there is a lot less to learn with vi than with Visual Studio.
  - OskarS 7y ago
    I certainly learned vi from vi (or I guess vim to be specific). The start page says "type :help or press <F1>", which led me to the help pages (and maybe doing vimtutor, can't quite remember), and then I "learned vi(m)" just working at it, poking and prodding at the various corners (and the manual for is excellent). No Google, no stack overflow, no teacher. Later I started looking up other peoples configurations and stuff, as well as some advanced guides, but I was already basically proficient at that point. On the other hand: I don't see what's so bad about a product for professionals where you might need a teacher to help you learn. Photoshop is not a simple product to use if you've never interacted with it before and most users go through some tutorial or has a teacher or something. It doesn't mean that Photoshop has bad UX. This goes for lots of software made for professional use: try learning Autodesk Maya or Avid without external resources, I dare you.
- robenkleene 7y ago
  Any examples of software that accomplishs this well? A quick summary of my experience: - Most complex apps are not learnable linearly: Ableton Live, Final Cut Pro, Logic Pro X, Photoshop, After Effects, Blender, all practically require reading the manual. - A few apps are ok at it: Adobe Lightroom, and Sketch, although those apps also are probably less powerful than those in the first category, e.g., Photoshop can do the majority of what both of those apps can do, and more. I would actually put shells and text editors as some of the easiest complex apps to learn linearly, because you can do so much with them with just cut and pasting text from the internet. Try following along with a Blender tutorial video that's not for an absolute beginner, and you'll get stuck almost immediately, because you won't know the keyboard shortcuts to perform the actions in the video. This happens far less with programming tutorials involving text editors and terminals.
ailideex 7y ago
Maybe a bit unrelated, I got used to Windows 2000, then window XP, then Gnome 2, then Gnome 3 came. So I stuck with Gnome 2, then moved to XFCE, and now with RHEL 8 I had to use Gnome 3 because there were no other options. Gnome 3 is an absolute horror show. I don't know who made it, for who, and what the theory behind it is but I don't see how it would be easier to use for someone non technical, my parents both understood how to use Windows 2000. It is just weird. It is harder to multitask as efficiently as I did in XFCE and Gnome 2. Gnome 3 is not simpler - it is just more convoluted. And I feel this is a very similar situation with other tools. I edit code with vim, in a terminal. This is simple as dirt. I do it because it is simple as dirt. Visual Studio is incredibly complicated to me because to do the creating code part my job I need to understand the following: - How code is built. - How to build the code without using any graphical front end. - But now when you bring VS into the mix I need to also understand visual studio. It does not remove complexity, it adds it. Similar thing with debugging, I need to understand all the ins and outs of debugging but now bring VS into the mix and I need to understand it's stupid UI. I like simple, my mind is simple. I can learn things, if there are rules and patterns it makes it easier to learn, but the less things I have to learn the happier I am. I don't have an option to not learn some things, like how to do build automation, how to debug code, how computers work, etc. But I do have an option to not learn something entirely useless like VS. I think the lie being sold is that somehow you can be a programmer without actually knowing how to use a computer. And to know how to use a computer is not the same thing as knowing how to click on things in the UI with a mouse. To know how to use a computer you need to understand how to use it to do automation - and once you need to do this VS is just a nuisance. Just a rant I guess.
- thom 7y ago
  The only way I found of making Gnome bearable these days: https://extensions.gnome.org/extension/1160/dash-to-panel/ https://extensions.gnome.org/extension/1160/dash-to-panel/
  - ailideex 7y ago
    I also use it, but it is quite buggy and not quite enough. Luckily xfce is now available for RHEL8 via EPEL.
izietto 7y ago
My point of view is different: there has to be a really strong reason to move my eyes from the code, and in the editors there should be respect for that. For example, I don't want to move from Atom to VSCode because VSCode has those huge icons that take space and distract me, when all I want in the default editor UI is the project directory tree and the code. Everything else should be opt-in.
- frosted-flakes 7y ago
  For what it's worth, you can easily hide those icons and access everything through the menu or command bar.
  - izietto 7y ago
    Right but VSCode doesn't work well with that bar disabled: for example, now I hid the activity bar (that's how it's called it seems), I clicked on a .status file and VSCode said "There are extensions for this file". I clicked on that, and now I have an extensions bar at the directories tree bar place. This happens because this UI setting is not the default one, so you encounter such kind of confusing behaviors every time you move away from the default behavior.
    - frosted-flakes 7y ago
      Is that a problem? There's only one sidebar. I agree there could be more, but I don't think there's much to be gained by it. Just learn the keyboard shortcut to bring up the folder tree. Or customise the icons so that they stand out less. Heck, I keep the sidebar collapsed most of the time since it's so easy to toggle it on with the keyboard.
      - izietto 7y ago
        I'm talking about UI/UX, not about shortcuts. If you switch my important sidebar with a marginal one it's a problem to me, from the UI/UX point of view. If you really want to talk about shortcuts: I don't want to learn the shortcut for the directories tree, because I just never hide it. And I'm talking about my flow, which might be different from yours.
rolleiflex 7y ago
I'm a designer [0] and an engineer — you'll take my shell from my cold, dead hands. There are two issues here: a) Designers trying to simplify everything beyond usefulness is a good instinct gone haywire. Simplification helps, but without an understanding of accidental complexity versus essential complexity, one is bound to end up painted into a corner with no flexibility left in the app. Few designers understand this, and those who do got it the long way round — by working on products that have a lot of essential complexity, like AdWords, and by repeatedly fighting those battles b) An engineer's operating environment, OS, IDE, shell, terminal, is a reflection of the inside of his or her mind writ large. Like every Jedi has to build their own lightsaber, every engineer has to go through this pain of building out their weapon, because one's workflow is how one thinks, how you look at the problems at hand. No UI designer can help with that. [0] (Because it's relevant to the context: ex-Google, ex-Facebook as professional experience)
- meagain3 7y ago
  Are you a registered member your state's engineers' association? (i.e. do you have seal?), if not please do not call yourself an engineer
  - azhenley 7y ago
    There is a difference between being an engineer and holding a license (e.g., PE) from some organization.
    - meagain3 7y ago
      So just anybody can call themselves engineer?, don't you realize this is a disservice to the actual engineers?
      - ghaff 7y ago
        Yes. You may not like it. I may not even like it but everyone from people who drive trains to technicians in lots of areas use the title. Furthermore, tons of experienced working engineers outside of software don't have PEs. They're just not needed in a lot of contexts. Edit: I'm referring mostly to the US. Licensing bodies in some places (perhaps including some US states) may say that only licensed engineers can be called/are engineers although the degree to which such strictures are followed will almost certainly vary. (I was told this was the case in Texas but there's no shortage of people in Texas who call themselves engineers but aren't PEs.)
adamkl 7y ago
Rich Hickey has a pretty interesting take on this very topic where he compares programming languages to instruments, and how instruments aren’t for beginners. How it takes work to become good at playing an instrument, and how that isn’t a bad thing. > But look at this guitar player with blisters. A harpist has blisters, a base player with blisters. There's this barrier to overcome for every musician. Imagine if you downloaded something from GitHub and it gave you blisters. Right? The horrors! That whole talk is filled with some interesting takes on designing and building software (with the usual skew that paints Clojure in a good light, so take it with a grain of salt if necessary). [1] https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/DesignCompositionPerformance.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
- inetknght 7y ago
  > Imagine if you downloaded something from GitHub and it gave you blisters. Right? The horrors! I'll have to remember that next time someone mentions that C should be a dead language. (I actually think C is a fine language, but should be deftly handled)
- waste_monk 7y ago
  > Imagine if you downloaded something from GitHub and it gave you blisters You mean Haskell?
BjoernKW 7y ago
In "The Design of Everyday Things" Don Norman describes this distinction as knowledge encoded in the head versus knowledge encoded in the world. For professional tools knowledge encoded in the head supported by appropriately encoded knowledge in the world absolutely is a viable approach, provided there's appropriate feedback and conceptual mapping corresponds to the mental model a user has about how that tool works, i.e. actions and reactions should be consistent. With modal design patterns such as the ones used by vi, for example, this can become a problem.
pjc50 7y ago
For things like vi, I'm developing the "left handed mouse" analogy: Many mice are ambidextrous (e.g. the Apple puck). Most are weakly right-handed with a slightly assymetrical shape. Some are very strongly right-handed (e.g. vertical mice) and can't be used sensibly in the left hand. So left-handed mice also exist. Some people are naturally left-handed. We (as a civilisation) used to treat this as aberrant but have now recognised it, and that different tools suit different people. I believe that something similar exists in programming tooling in relation to how people think about programs. There are clearly some people who have a strong, unusual "handedness" and have developed tools to match (e.g. Colorforth). A few people discover these and find them amazingly usable. Most other people find them baffling. Consider the three propositions: a) Jimi Hendrix played guitar in the wrong way with the strings in the wrong positions b) Jimi's configuration was correct and everyone else was wrong, because he's producing the objectively best music c) Jimi was left handed, and had constructed an accomodation which worked for him but should not be expected to work for anyone else Far too many discussions of programming tools devolve into (a) versus (b), largely because people want there to be an objective ranking of who the best programmer is and what the best tools are, rather than allowing for diversity of (programmer x tool).
- dehrmann 7y ago
  > aberrant Pretty sinister, if you ask me.
beefield 7y ago
I think there should be a clear distinction between your tools and... let's call them "utilities" what comes to UI. It is perfectly okay to make electricity plug, water faucet, toaster and the power button on your computer not only so easy that an idiot can use them, but so easy that an idiot can't use them wrong. Not only because requiring mental energy to use these is irritating but also because it can be dangerous. Your tools, then again, chainsaw, microscope, text editor... have no reason whatsoever to have an UI that is intuitive without training[1]. Because without training you are anyway going to be either dangerous, useless or in best case just really unproductive. [1] of course, the UI needs to be efficient after training.
- ghaff 7y ago
  And, in the case of things like chainsaws, they shouldn't be needlessly dangerous if a user is not as well trained as they should be or if they're simply inattentive/tired/etc. (And in the case of software, you should generally not be able to cause massive damage/loss of work because you picked the wrong menu item.)
addicted44 7y ago
Listing vi in there shows that the OP, even if they may have good points in general, is limiting what good UX is to certain specific attributes, whereas developers want to optimize for additional attributes. And this isn't just me saying that because I like vim. It's because of the objective fact that nearly every developer tool that is created will include a vim mode. And if included as an extension it will often be one of the most popular extensions. What that objectively indicates is that there is a large contingent of developers who genuinely find the vim modal editing UX excellent, to the point they seek it in other tools as well (including browsers, mail clients, RSS readers, etc).
- werg 7y ago
  Yes, you are right I didn't put that very well. Modal editing really has a lot of benefits, even if I personally don't go for them (am more of an Emacs guy). What I would say is that vi really doesn't give you a lot of interactive context -- and it's hard to add it on.
werg 7y ago
Oh yes, that is certainly what we do. And there's nothing wrong about that. We are definitely in the business of building tools for professionals, i.e. a bit of a learning curve is not the issue. The "professional hazing process" isn't necessarily bad. What I would say is that there is some (maybe a lot of) potential value that vi cannot develop simply due to the very reduced form factor that it has. I believe this never really has come to the fore because most programming languages are designed in a fairly limited way. I.e. they don't really take into account that they are a User Interface. As positive examples I would point out the kind of interactive editing mode that you can find in dependently typed programming languages. I believe e.g. Idris has a pretty cool Emacs mode.
dehrmann 7y ago
Bash and JS are interesting cases because they're so ossified core problems are impossible to touch.

Gehinnn 7y ago

I think even complex products should have a linear progression from newcomers, curiously exploring the product for the first time, to experts, who want to do certain tasks as fast as possible. It's simply not possible to learn vi by just using vi. Also, the author emphasizes that just dumbening a product is not the solution.

ailideex 7y ago
> It's simply not possible to learn vi by just using vi. I did. I learnt vi when I was told go fix this file on that computer, you have ssh, x forwarding won't work because you have 3 hops (embedded devices that won't allow forwarding of any kind), there is only vi on the box. So I figured out how to use vi. It is not rocket science, there is not that much to learn, vi muscle memory takes time but also not even that long I think.
- Gehinnn 7y ago
  Did you read about vi before? How do you know all the shortcuts?
  - ailideex 7y ago
    I googled it. I did not know vi before that, and now I use vim as my main editor for code.
    - krisoft 7y ago
      So you did not just "learn vi by just using vi". You have also used a browser, google, and tutorials found by google. There is nothing wrong with that. In fact congratulation on learning vi! But sadly your example does not illustrate that one can "learn vi by just using vi".
      - 2zcon 7y ago
        The intro screen tells you exactly how to open help and exit. Man gives you even clearer instructions.
      - Narishma 7y ago
        If you just launch vim it tells you the basics of how to use it, and how to get more help. So it's definitely possible to learn it without external resources. Emacs is the same.
- test1235 7y ago
  There's not much to learn if you're editing the odd file ... if you want to use vim as an effective development tool, there's loads to learn.
  - ailideex 7y ago
    I would think there is a lot less to learn with vi than with Visual Studio.
- OskarS 7y ago
  I certainly learned vi from vi (or I guess vim to be specific). The start page says "type :help or press <F1>", which led me to the help pages (and maybe doing vimtutor, can't quite remember), and then I "learned vi(m)" just working at it, poking and prodding at the various corners (and the manual for is excellent). No Google, no stack overflow, no teacher. Later I started looking up other peoples configurations and stuff, as well as some advanced guides, but I was already basically proficient at that point. On the other hand: I don't see what's so bad about a product for professionals where you might need a teacher to help you learn. Photoshop is not a simple product to use if you've never interacted with it before and most users go through some tutorial or has a teacher or something. It doesn't mean that Photoshop has bad UX. This goes for lots of software made for professional use: try learning Autodesk Maya or Avid without external resources, I dare you.
robenkleene 7y ago
Any examples of software that accomplishs this well? A quick summary of my experience: - Most complex apps are not learnable linearly: Ableton Live, Final Cut Pro, Logic Pro X, Photoshop, After Effects, Blender, all practically require reading the manual. - A few apps are ok at it: Adobe Lightroom, and Sketch, although those apps also are probably less powerful than those in the first category, e.g., Photoshop can do the majority of what both of those apps can do, and more. I would actually put shells and text editors as some of the easiest complex apps to learn linearly, because you can do so much with them with just cut and pasting text from the internet. Try following along with a Blender tutorial video that's not for an absolute beginner, and you'll get stuck almost immediately, because you won't know the keyboard shortcuts to perform the actions in the video. This happens far less with programming tutorials involving text editors and terminals.

ailideex 7y ago

Maybe a bit unrelated, I got used to Windows 2000, then window XP, then Gnome 2, then Gnome 3 came. So I stuck with Gnome 2, then moved to XFCE, and now with RHEL 8 I had to use Gnome 3 because there were no other options. Gnome 3 is an absolute horror show. I don't know who made it, for who, and what the theory behind it is but I don't see how it would be easier to use for someone non technical, my parents both understood how to use Windows 2000. It is just weird. It is harder to multitask as efficiently as I did in XFCE and Gnome 2. Gnome 3 is not simpler - it is just more convoluted. And I feel this is a very similar situation with other tools. I edit code with vim, in a terminal. This is simple as dirt. I do it because it is simple as dirt. Visual Studio is incredibly complicated to me because to do the creating code part my job I need to understand the following: - How code is built. - How to build the code without using any graphical front end. - But now when you bring VS into the mix I need to also understand visual studio. It does not remove complexity, it adds it. Similar thing with debugging, I need to understand all the ins and outs of debugging but now bring VS into the mix and I need to understand it's stupid UI. I like simple, my mind is simple. I can learn things, if there are rules and patterns it makes it easier to learn, but the less things I have to learn the happier I am. I don't have an option to not learn some things, like how to do build automation, how to debug code, how computers work, etc. But I do have an option to not learn something entirely useless like VS. I think the lie being sold is that somehow you can be a programmer without actually knowing how to use a computer. And to know how to use a computer is not the same thing as knowing how to click on things in the UI with a mouse. To know how to use a computer you need to understand how to use it to do automation - and once you need to do this VS is just a nuisance. Just a rant I guess.

thom 7y ago
The only way I found of making Gnome bearable these days: https://extensions.gnome.org/extension/1160/dash-to-panel/ https://extensions.gnome.org/extension/1160/dash-to-panel/
- ailideex 7y ago
  I also use it, but it is quite buggy and not quite enough. Luckily xfce is now available for RHEL8 via EPEL.

izietto 7y ago

My point of view is different: there has to be a really strong reason to move my eyes from the code, and in the editors there should be respect for that. For example, I don't want to move from Atom to VSCode because VSCode has those huge icons that take space and distract me, when all I want in the default editor UI is the project directory tree and the code. Everything else should be opt-in.

frosted-flakes 7y ago
For what it's worth, you can easily hide those icons and access everything through the menu or command bar.
- izietto 7y ago
  Right but VSCode doesn't work well with that bar disabled: for example, now I hid the activity bar (that's how it's called it seems), I clicked on a .status file and VSCode said "There are extensions for this file". I clicked on that, and now I have an extensions bar at the directories tree bar place. This happens because this UI setting is not the default one, so you encounter such kind of confusing behaviors every time you move away from the default behavior.
  - frosted-flakes 7y ago
    Is that a problem? There's only one sidebar. I agree there could be more, but I don't think there's much to be gained by it. Just learn the keyboard shortcut to bring up the folder tree. Or customise the icons so that they stand out less. Heck, I keep the sidebar collapsed most of the time since it's so easy to toggle it on with the keyboard.
    - izietto 7y ago
      I'm talking about UI/UX, not about shortcuts. If you switch my important sidebar with a marginal one it's a problem to me, from the UI/UX point of view. If you really want to talk about shortcuts: I don't want to learn the shortcut for the directories tree, because I just never hide it. And I'm talking about my flow, which might be different from yours.

rolleiflex 7y ago

I'm a designer [0] and an engineer — you'll take my shell from my cold, dead hands. There are two issues here: a) Designers trying to simplify everything beyond usefulness is a good instinct gone haywire. Simplification helps, but without an understanding of accidental complexity versus essential complexity, one is bound to end up painted into a corner with no flexibility left in the app. Few designers understand this, and those who do got it the long way round — by working on products that have a lot of essential complexity, like AdWords, and by repeatedly fighting those battles b) An engineer's operating environment, OS, IDE, shell, terminal, is a reflection of the inside of his or her mind writ large. Like every Jedi has to build their own lightsaber, every engineer has to go through this pain of building out their weapon, because one's workflow is how one thinks, how you look at the problems at hand. No UI designer can help with that. [0] (Because it's relevant to the context: ex-Google, ex-Facebook as professional experience)

meagain3 7y ago
Are you a registered member your state's engineers' association? (i.e. do you have seal?), if not please do not call yourself an engineer
- azhenley 7y ago
  There is a difference between being an engineer and holding a license (e.g., PE) from some organization.
  - meagain3 7y ago
    So just anybody can call themselves engineer?, don't you realize this is a disservice to the actual engineers?
    - ghaff 7y ago
      Yes. You may not like it. I may not even like it but everyone from people who drive trains to technicians in lots of areas use the title. Furthermore, tons of experienced working engineers outside of software don't have PEs. They're just not needed in a lot of contexts. Edit: I'm referring mostly to the US. Licensing bodies in some places (perhaps including some US states) may say that only licensed engineers can be called/are engineers although the degree to which such strictures are followed will almost certainly vary. (I was told this was the case in Texas but there's no shortage of people in Texas who call themselves engineers but aren't PEs.)

adamkl 7y ago

Rich Hickey has a pretty interesting take on this very topic where he compares programming languages to instruments, and how instruments aren’t for beginners. How it takes work to become good at playing an instrument, and how that isn’t a bad thing. > But look at this guitar player with blisters. A harpist has blisters, a base player with blisters. There's this barrier to overcome for every musician. Imagine if you downloaded something from GitHub and it gave you blisters. Right? The horrors! That whole talk is filled with some interesting takes on designing and building software (with the usual skew that paints Clojure in a good light, so take it with a grain of salt if necessary). [1] https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/DesignCompositionPerformance.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

inetknght 7y ago
> Imagine if you downloaded something from GitHub and it gave you blisters. Right? The horrors! I'll have to remember that next time someone mentions that C should be a dead language. (I actually think C is a fine language, but should be deftly handled)
waste_monk 7y ago
> Imagine if you downloaded something from GitHub and it gave you blisters You mean Haskell?

BjoernKW 7y ago

In "The Design of Everyday Things" Don Norman describes this distinction as knowledge encoded in the head versus knowledge encoded in the world. For professional tools knowledge encoded in the head supported by appropriately encoded knowledge in the world absolutely is a viable approach, provided there's appropriate feedback and conceptual mapping corresponds to the mental model a user has about how that tool works, i.e. actions and reactions should be consistent. With modal design patterns such as the ones used by vi, for example, this can become a problem.

pjc50 7y ago

For things like vi, I'm developing the "left handed mouse" analogy: Many mice are ambidextrous (e.g. the Apple puck). Most are weakly right-handed with a slightly assymetrical shape. Some are very strongly right-handed (e.g. vertical mice) and can't be used sensibly in the left hand. So left-handed mice also exist. Some people are naturally left-handed. We (as a civilisation) used to treat this as aberrant but have now recognised it, and that different tools suit different people. I believe that something similar exists in programming tooling in relation to how people think about programs. There are clearly some people who have a strong, unusual "handedness" and have developed tools to match (e.g. Colorforth). A few people discover these and find them amazingly usable. Most other people find them baffling. Consider the three propositions: a) Jimi Hendrix played guitar in the wrong way with the strings in the wrong positions b) Jimi's configuration was correct and everyone else was wrong, because he's producing the objectively best music c) Jimi was left handed, and had constructed an accomodation which worked for him but should not be expected to work for anyone else Far too many discussions of programming tools devolve into (a) versus (b), largely because people want there to be an objective ranking of who the best programmer is and what the best tools are, rather than allowing for diversity of (programmer x tool).

dehrmann 7y ago
> aberrant Pretty sinister, if you ask me.

beefield 7y ago

I think there should be a clear distinction between your tools and... let's call them "utilities" what comes to UI. It is perfectly okay to make electricity plug, water faucet, toaster and the power button on your computer not only so easy that an idiot can use them, but so easy that an idiot can't use them wrong. Not only because requiring mental energy to use these is irritating but also because it can be dangerous. Your tools, then again, chainsaw, microscope, text editor... have no reason whatsoever to have an UI that is intuitive without training[1]. Because without training you are anyway going to be either dangerous, useless or in best case just really unproductive. [1] of course, the UI needs to be efficient after training.

ghaff 7y ago
And, in the case of things like chainsaws, they shouldn't be needlessly dangerous if a user is not as well trained as they should be or if they're simply inattentive/tired/etc. (And in the case of software, you should generally not be able to cause massive damage/loss of work because you picked the wrong menu item.)

addicted44 7y ago

Listing vi in there shows that the OP, even if they may have good points in general, is limiting what good UX is to certain specific attributes, whereas developers want to optimize for additional attributes. And this isn't just me saying that because I like vim. It's because of the objective fact that nearly every developer tool that is created will include a vim mode. And if included as an extension it will often be one of the most popular extensions. What that objectively indicates is that there is a large contingent of developers who genuinely find the vim modal editing UX excellent, to the point they seek it in other tools as well (including browsers, mail clients, RSS readers, etc).

werg 7y ago
Yes, you are right I didn't put that very well. Modal editing really has a lot of benefits, even if I personally don't go for them (am more of an Emacs guy). What I would say is that vi really doesn't give you a lot of interactive context -- and it's hard to add it on.

werg 7y ago

Oh yes, that is certainly what we do. And there's nothing wrong about that. We are definitely in the business of building tools for professionals, i.e. a bit of a learning curve is not the issue. The "professional hazing process" isn't necessarily bad. What I would say is that there is some (maybe a lot of) potential value that vi cannot develop simply due to the very reduced form factor that it has. I believe this never really has come to the fore because most programming languages are designed in a fairly limited way. I.e. they don't really take into account that they are a User Interface. As positive examples I would point out the kind of interactive editing mode that you can find in dependently typed programming languages. I believe e.g. Idris has a pretty cool Emacs mode.

dehrmann 7y ago

Bash and JS are interesting cases because they're so ossified core problems are impossible to touch.