KDevelop: General direction and UI - don't worry

[Alexander Dymo]

Hey, 
recent news about Qt Creator waked me up from silence a bit so I decided to 
write something. But I'm not going to write anything about QtCreator right 
now. Let's first start with KDevelop, it's direction in general and its UI.

There're a lot of discussions here and there about KDevelop and its problems 
right now. Problems with both project direction and UI usability. I only want 
to say that we shouldn't worry too much.


When you're building a product, you need to:
1) solve the user's problem
2) .... there's no 2nd task actually :)

Two years ago we decided that the problem we're solving is called "C++ 
application development" and we're building the right C++ IDE. 
So far everybody was agree with that and I don't buy when people say we don't 
have direction and vision.


UI? In many comments to recent articles and blog posts people say KDevelop 
(both v3 and v4) has usability problems.

Let's see which problems are frequently named and what real-world impact those 
problems have:

1) too many menus (12 in v4), crowded popup menus, etc.
Xcode has exactly 12 menus. Eclipse has 9-11 here. Visual Studio - 11.
Popup menu in Eclipse barely fits my screen.
So what? Who cares? 90% of people just use Eclipse, VS and Xcode.

2) vertical text in toolviews
So what?
IntelliJ has that as well and it's still rated as one of the best IDE's.

3) too many widgets on screen
Look at Visual Studio - a lot of complex (and rather small btw) widgets. 
Who cares?

4) small space for editors
Ever tried to work with Eclipse? Ever tried its UI designers?
So what? 

5) no "bling" - nothing fades, appears, has black colored shapes, etc.
Who cares? Do emacs and vim have any of that "bling"?


My conclusion after such analysis? Forget about those "usability" questions. 
Want to make some gui effects? toolview previews? want to remove more menu 
items? Fine, but that won't make KDevelop any more usable than it is now. Not 
by a millimeter. At least not now.


Let's remember the goal. Let's remember what the product we're developing 
needs to do. The product needs to _solve_ users's problem.
KDevelop4 is not there. Not now. 

I'd personally expect the finished KDevelop4 to
1) start fast
2) open any kde/cmake project from the directory on my disk without much 
question
3) load that project as fast as possible
4) compile it and compile parts of it
5) set a breakpoint, launch debugger and stop on it
6) give me code completion
7) rename class/method without much effort from my side
8) check in and out my project from any modern VCS
etc. 
etc.


How does that correlate with, for example, "Bookmarks" menu being visible in 
the menu bar? There's no correlation.
How does that correlate with vertical text on toolview buttons? There's no 
correlation.
How does that correlate with GUI effects? There's no correlation.
etc.
etc.


Usability problems don't happen because of vertical text and extra menus. The 
usability problem is when the user can't create/open KDE project without 
answering 4 stupid questions. The usability problem is when there's no way to 
get documentation for class under cursor. The usability problem is when you 
have to interrupt your workflow to compile your project. The usability problem 
is when navigation history is totally innavigatable. Those are the real 
problems and they are numerous. But none of those have anything to do with 
extra menu or widget on the screen.


I hope I made my point clear enough. We have far more complex problems to 
solve than removing widgets, buttons and menus. The user should be able to get 
their work done with KDevelop. That's the major criterion of usability we 
should think about right now. Anything else is for the future.