On 19-05-15 01:08, Avdi Grimm wrote:
Then the web started to take off,

throwing UI design back two decades ;),

and UX designers started rethinking
the whole paradigm. They started keeping things in the same window, but
adding back/forward buttons, and navigation histories, and sidebars, and
address bars, and tabs, and other affordances to make it easier to
switch between "things" without necessarily adding more windows.

We found that what works well for browsing and reading text not necessarily works for code. I regularly have 80 tabs open in 10 windows of more or less interesting stuff to read. Having a lot of edited buffers open at the same time is a problem, if only because "save all" might run into dependency issues. The current design stimulates working
in short cycles, and keeping code well-organized. I'd like not to lose
that aspect of the UI. And I also like a navigation history.

These days, most IDEs and editors have followed suit. I can't think of a
single editor in common use among the programmers I know which
encourages multiple windows.

Which seems like a mistake, as displays keep growing in size and the
IDEs and editors in common use have no way to use the space a 4K display offers.

Whether it's Vim, Emacs, Sublime, IntelliJ,
while you *can* open lots of windows if you really want to, they all
focus on making it easy to manage lots of buffers in a single window
rather than encouraging lots of windows.

That actually sounds like a really bad idea when you have a large display. I want to see all relevant code at the same time. Switching is slow.

Personally, I'm a fan of this trend. I'm much happier typing a few
characters to auto-complete the buffer I want to return to in Emacs,
than I am hunting around in an OS window list for it.

I would welcome an auto-complete based navigation to one of my open windows.

This is all a long-winded way of saying: just because this is currently
a problem, doesn't mean it's the *right* problem. It would be
interesting to see what a "fewer windows" approach to Smalltalk
development might look like.

A simple first step is Hopscotch. https://youtu.be/d6tj6KQtD1s
On a small-screen device like an iPad I like the approach taken by
Cel: http://cel.inf.usi.ch/
And have you seen Gaucho?
http://www.inf.usi.ch/faculty/lanza/Downloads/Oliv2013a.pdf
Stephan


Reply via email to