Menu-Structure

[Vadym Krevs]

On 17 February 2010 07:55, Nicolai Haehnle <nhaehnle at gmail.com> wrote:
> On Tue, Feb 16, 2010 at 11:47 PM, Milian Wolff <mail at milianw.de> wrote:
>>> I don't think that's required. Most of us use the app every day, so we're
>>> the best persons to give feedback about the usability.
>>
>> Here at the sprint we thought something along these lines as well. Kate hasn't
>> had good experience with usability testing because somebody proposed changes
>> that simply suck when you actually use the app (i.e. indentation/tab in
>> different tabs, colors all over the place, ...).
>>
>> We should - if at all - ask our users.
>
> I've been following KDevelop SVN for a while now. Here's my rough
> train of thought when the menu changed:
>
> 1. I want to open a project (that tends to be one of the few things I
> use the menu for at all, mostly I just use keyboard shortcuts, the
> sidebar and the awesome Code Browser).
> 2. Where the f*** is the Project menu?
> 3. After a couple of seconds: Oh, there it is!
> 4. Did I mess up the build?
> 5. Sees separators.
> 6. Hey, that structure makes a lot of sense! Very cool!
>
> So yeah, it totally breaks consistency, but since the primary object
> manipulated by KDevelop isn't a File, but rather a Project (at least
> from my perspective; seems the developer consensus was that the
> primary object is a Session, but that's a minor detail), it totally
> makes sense to have the corresponding menu earlier.
>
> So count me as a happy user.
>
> cu,
> Nicolai
>

I realize that there's very little chance of me convincing you (by
"you" I mean kdevelop developers) to change your minds on this subject
(after all, you made it very clear you don't care what your users
think ...), yet let me draw your attention at least to the following:

1. Very often you said that you use the keyboard most of the time, and
don't want to use the mouse. Then why care so much about the menu
structure? After all, it exists primarily for those users who don't
use the keyboard so much or who are trying to discover how to perform
a particular task. And making menu layout inconsistent with every
other IDE/editor makes that discovery frustrating. For example, have a
look at Qt Creator - same functionality as the one present in kdevelop
is presented in a standard way that any user would be able to work
with without any confusion.

2. Why is "Find in files" hidden under Navigation? Every other
IDE/editor places this menu next to Find/Replace.

3. The new Editor menu is, well, a waste of screen space for lack of
better words. You open it, and all you see is 3 other submenus. So you
have to click on each submenu while trying to locate the one you're
looking for. The whole point of having a menu is to give users instant
visual feedback into the list of available operations via a single
mouse click/keyboard accelerator.

4. The primary task of anyone using an IDE is write code in files and
manage those files. If you spend more time "managing" "projects" or
"sessions" than working on code in files, then arguably you're using
the wrong tool, or the tool is making what should be simple
excessively difficult. That is why placing emphasis on the Sessions or
Projects menus makes no sense - it is simply not the primary user
activity in an IDE or an editor.

5. Finally, regarding usability. Believe it or not, some companies
actually hire dedicated usability experts to design GUIs. The reason
for this is very simple. Developers, on average, are actually poor
usability experts, especially in regard to the code they write
themselves :-)  Some are much smarter then average users, some feel
emotional attachment to "their" apps, some don't care about users,
some simply never encounter the issues other users have to deal with
on a daily basis, and so on  ...  So when someone says he's the
ultimate usability expert on Kdevelop, it is, well, funny.

For example, take Quick Open.  It probably works well for a small
project like Kdevelop + Kdevplatform when you can remember the name of
each file/class in the project. Unfortunately, it simply does not
scale for any non-trivial size project. Have you tried opening a
15000-20000 file project in Kdevelop, waiting for the parse to finish,
then clicking on Quick open and accidentally scrolling the dropdown
via the scroll bar?

Another example, session management - why is a project reparsed from
scratch when it's added to a session? Why isn't the parse state of the
project associated and persisted along with the project, so session
management becomes instantaneous? I read this mailing list, read the
source, and I know the technical reasons for the current clunky
behavior, but can you honestly call that "usable"? And identifying
sessions by GUIDs when starting kdevelop from command line is usable?

Finally, why aren't project/session/environment settings storable in a
file along with the source code so they could be checked into a
version control system and easily shared amongst many developers?
Today everything gets dumped into multiple rc files under .kde ...

This is just a small list of what I could think of on the spot. If you
knew how many users Kdevelop had (dozens, hundreds, thousands?), if
you cared about feedback from your users (who probably contribute a
fair amount of time testing and reporting bugs), then kdevelop would
be a much much better IDE. You'd  probably even have more
contributors.  Alas, you don't :-(

Rant off.


Regards,
Vadym