There are many things we can do to have an Amber Smalltalk IDE that makes the difference in terms of developing experience and productivity. The best ones take a lot of effort that is currently unfunded. Maybe we should start a Kickstart campaign and change that. But in the meantime why not do smaller steps in the right direction? We could do small incremental improvements with what we already have.
So for now, let’s take a look at the current IDEs: Helios and Legacy IDE.
Why I don’t like Helios?
First of all, is totally okay to like Helios and I personally liked that Nicolas tried to innovate on the Smalltalk IDE design. I’ve talked with him many times about it and I’ve helped to implement it with some contributions in the inspector and workspace. Innovation on the Smalltalk IDE it’s not something trivial because the traditional designs are extremely well validated and pass the test of time.
Still, there is room to innovate the Smalltalk IDE and truth is that even I have already some drafts on what a rockstar Smalltalk IDE would be. I’m validating its design with some inner-circle veteran developers before any disclosing or deciding to do anything beyond some UX/UI drafts.
The thing is I’ve tried hard with Helios and it really didn’t work for me. You could say that is a matter of preference on developing taste for stateful User Interfaces, like “are you a vi person or a non-vi person?”
But is not.
With time I’ve got some muscular training on getting the right key combinations and end up doing things apparently fast. It wasn’t. The deal-breaker for me was a pragmatic test on plain old productivity.
Helios takes too much time to pop-up and open and hides some actions behind a wall of sequenced keystrokes while the classic IDE provides an instant embedded open and is more “mouse friendly.”
In the end, Economics decided for me. Yes, Helios could connect to a remote environment but (a) that does not happen today and (b) might never do because the development of that feature, sadly, is not moving forward. The day to day result is that Helios made me overall less productive and slower than using the good old Legacy IDE.
Hence the divorce.
So after moving away from it I’ve started to see new things and try to figure out new possibilities and I’ve come to the personal conclusion that for the goal of having a more productive and overall better User Experience developing with Amber, it would take significantly less effort to make the Legacy IDE way better than Helios way better.
I am the only one perceiving this?
How do you use Amber to code? Here is a poll I’m running to understand this question better.
I hope this doesn’t sound rhetorical because this is a genuine question I have. I can easily just fork and do the incremental adjustments I want to see done on the classic IDE or, I can bother myself in trying to amplify those benefits for the whole community. And I don’t know what to do yet.
What do you think? Should I try to promote this Legacy IDE improvements and fixes in the official Amber repo or just fork? Please help this spread and leave a comment with your preference so our community can find it and know.
Here is the issue I’ve tentatively opened: https://github.com/amber-smalltalk/amber-attic/issues/3
Stating these problems as a start:
- Typography issues
- Poor contrast issues
- Focus issues
- Lack of search keyboard shortcut
- Tab close area too small
- SUnit button alignment
- Horizontal arrow keys should change the pane in focus (on Browser and SUnit)
- Vertical arrow keys should change the selected list item when focus is in a list pane
- Save button disabled on pristine
- Class browse shortcut
- Icons on the class list
- Icons on the package list
- Drag and drop to categorise methods
- Marking changed packages
- Visual feedback on successful commit finished
- Visual feedback on failed commit (handle exception and display proper message)
- Select and change theme easily and persist the preference on localStorage
- Change theme to be dark by default
No comments:
Post a Comment