3 ms·

User experience is highly relative. To me magit is peak UX, above many many tools.. but to some it's utter sh8t and they want vscode (even though they are the o

User experience is highly relative. To me magit is peak UX, above many many tools.. but to some it's utter sh8t and they want vscode (even though they are the one sweating and ranting everytime they get confused).

charcircuit 3y ago
I agree that magit has relatively good UX compared to the rest of Emacs, but it is held back by Emacs' abhorrent performance. Magit however is not bundled with Emacs so I can not attribute its UX quality to the base Emacs editor. I do think of you did an actual user study you would find that it should be using more GUI elements to expose operations instead of keybindings
- agumonkey 3y ago
  Except on windows I don't recall any performance issues that were not due to repo size. Magit is an extension of the old emacs outline mode, it inherits all the ergonomics culture around it (tab to fold, C-n/C-p for skipping, C-c C-c to validate..., k to kill). User studies don't apply here, it's too complex (due to the inheritance mentionned above). As I said, I have colleagues using other tools, they're slower and angrier, even with more buttons, which is somehow part of emacs culture.. don't create more widgets than necessary. And I'd argue it's irrelevant to good HCI for non mainstream duties.
  - charcircuit 3y ago
    I have had the editor grind to a halt when doing some combination of having a ton of changes, showing hunks, and trying to scroll. >User studies don't apply here, it's too complex User studies always apply. And doing basic everyday source control operations should not be complex.
    - agumonkey 3y ago
      You can't compare fairly since people will cluster around what they consider right. Even though, as I can witness daily, they suffer more, take more time than the 'obscure emacs thing'. So many git interfaces add more weight, lag, random iconography and terminology. But it taps into people love for shiny, it seems an exciting new tool with all bells and whistles when in fact, it disrupt your flow more, adds layers of confusion and costs more ultimately. Fair point about massive hunk set causing lag, it's plausible.
- Ferret7446 3y ago
  Magit performance has very little to do with Emacs. All operations are performed via git subprocesses.
  - charcircuit 3y ago
    My expectation as a user is that the editor should never freeze. It should render at my monitor's refresh rate. What I experienced sometimes with magit is the editor freezing rendering 0 frames for 10s of seconds. It does have to do with Emacs.

charcircuit 3y ago

I agree that magit has relatively good UX compared to the rest of Emacs, but it is held back by Emacs' abhorrent performance. Magit however is not bundled with Emacs so I can not attribute its UX quality to the base Emacs editor. I do think of you did an actual user study you would find that it should be using more GUI elements to expose operations instead of keybindings

agumonkey 3y ago
Except on windows I don't recall any performance issues that were not due to repo size. Magit is an extension of the old emacs outline mode, it inherits all the ergonomics culture around it (tab to fold, C-n/C-p for skipping, C-c C-c to validate..., k to kill). User studies don't apply here, it's too complex (due to the inheritance mentionned above). As I said, I have colleagues using other tools, they're slower and angrier, even with more buttons, which is somehow part of emacs culture.. don't create more widgets than necessary. And I'd argue it's irrelevant to good HCI for non mainstream duties.
- charcircuit 3y ago
  I have had the editor grind to a halt when doing some combination of having a ton of changes, showing hunks, and trying to scroll. >User studies don't apply here, it's too complex User studies always apply. And doing basic everyday source control operations should not be complex.
  - agumonkey 3y ago
    You can't compare fairly since people will cluster around what they consider right. Even though, as I can witness daily, they suffer more, take more time than the 'obscure emacs thing'. So many git interfaces add more weight, lag, random iconography and terminology. But it taps into people love for shiny, it seems an exciting new tool with all bells and whistles when in fact, it disrupt your flow more, adds layers of confusion and costs more ultimately. Fair point about massive hunk set causing lag, it's plausible.
Ferret7446 3y ago
Magit performance has very little to do with Emacs. All operations are performed via git subprocesses.
- charcircuit 3y ago
  My expectation as a user is that the editor should never freeze. It should render at my monitor's refresh rate. What I experienced sometimes with magit is the editor freezing rendering 0 frames for 10s of seconds. It does have to do with Emacs.