Re: Dia's user interface

i went on for ages about keybindings but never got around to submitting
all the necessary patches.  I know that you can easily set these yourself
but that is no reason not to have sensible defaults (as i have said
previously on this list and was mentioned in the article).

I agree.  Most people don't know about the assignable shortcuts, so we
should have sensible shortcuts whereever we can.  Most of the Ctrl keys are
assigned, but I think the single-letter shortcuts should be assigned to
things like the standard tools.

I think it would be worth reorgansing slightly some of the keybindings and
as much as possible bring them in line with the HIG (Human Interface
Guidelines) for Gnome2.

I also think that Ctrl+key should be used as much as possible, rather than
single key shortcuts.  Reasons: Consistancy, harder to accidentaly do
something wrong, and how do you handle conflicts with Text Input.

Which reminds me.  Text input in Dia does not allow you to do many of the
things i am accustomed to doing with a text box such as Ctrl + A to select
all.  I was also suprised that the default text layout was centred, rather
than left alinged (although i can understand why this was done).
In one of my diagrams i wanted to add quite a long description, what i
really wanted was a standard* Text Area, left aligned text with a fixed
width but a scalable height.
(* standard as in it would work the same as a text area on a web  page)

Ctrl+A, is currently used for Fit to Page (i may have gotten the name
wrong i dont have it in front of me) and in my previous mail i suggested
that it be changed to Ctrl+F (F for  Fit ...)
That would allow Ctrl+A to be used for Select All, and Ctrl+I for Invert

Here's a UI question:  If multiple objects are selected, should properties
changes apply to them all?  Currently that only happens when the objects
are grouped.

Personally, yes it should.  Several time is grouped objects, applied the
setting to the group then ungrouped them.

A couple improvements for the color picking I've been pondering:
Have easy access to the most frequently used colors in the diagram (not
  sure how -- menu on color widget?  Menu somewhere else?)
Have (even) more selection types, like select by same color, same line
  style etc.

I have to give this more thought and find an example i really like.  As
the article says you should not just bolt on more Preferences.  If you do
it well so that it "Just Works" then you probably will not need so many

MDI is great if you have a decent window manager, but frankly win32 does
not and it would be vastly more convenient if i could pin the tools
windows always on top, or that i could have the main window maximised
with enough room left for the tools window (i could do this manually but
anyone who tells me that is missing the point).  This kind of improvement
might be more appropriate to gtk for windows rather than dia, but i have
not talked to anyone further upstream.  Essentially organising the
various windows is a pain for some one who (even when using linux) is
still very used to SDI.

Somebody (I forget who) mentioned the desire for a tabbed environment,
basically being able to have a single 'document' (file) consist of several
diagrams, shown as tabs.  But that's not your point.

I dont get Tabbed interfaces, i much prefer a good windowmanager and a
well organised Taskbar.
(i have not used Gnome 2 yet, but i really hope it can be set to
group/hide tasks by least recently used rather than just by application).

I believe we can give placement hints that the decent window managers may
ignore, but which may make it easier for SDI people to have a decent
layout.  Point to work on.

Currently i maximise the workspace then resize it enough so that i can put
the toolbox on the left and then i resize maximise the height of the

It was ages before i realised i had to use the center button to access
certain features.  Not many laptops come with a 3 button mouse, using a
trackpad can be far less precise than a mouse so i appriecate when a
program is well designed and accesable (but mostly i wait until i have a
desktop computer i can work at).  Sometimes redundancy is bad but i think
it should be possible to do almost anything just using the keyboard
(although this is slightly less practical with a drawing application than
say a word processor).

Ugh.  Good point.  A first step may be to have the object menu be
duplicated in the right-hand menu.  But we should definitely have a
keyboard shortcut for the menus -- seems even when the diagram menu bar is
on, the indicated shortcuts don't work.  And the diagram menu should
probably be on by default, for accessibility?

Are the start-up tips (as in Gimp and Gnucash) useful?  They may reduce the
amount of simple questions (like right-button click).  If well organized,
they can come instead of (or with) the splash screen.

I used to find these mildly annoying and would read through the first few
and then turn them off, but on reflection I do think they are generally a
good idea and clever way to get people to read at least a little bit of
the documentation.

Labelled toolbar buttons.  When you are just getting started having to
use tooltips is slow and cumbersome.  Also bigger buttons are easier to
hit.  Although i realise this may not be appropriate for Dia, it is
something programs like abiword should make more use of.  (Abiword can
actually do this if you edit a config file and it has the UI for it but
no one actually wired the UI to functionality.  It is an old bug and one
of my pet peeves but i digress).

Is this for the toolbox icons (ie pointer, magnify etc) or are you thinking


of load/save/print-toolbars?

i dont know about these toolbars, my version of dia may not be
recent enough.

I found the default selection behaviour very odd.  If i select an obect i
do not expect both the current and previous objects to be selected
(unless i have held down shift or ctrl or something).  This may be what
other have become used to but it is inconsistant with my general usage of
other programs, such as selecting files in Nautilus or on the desktop.

That's not what's supposed to happen, and I can't reproduce it.  Shift does
indeed make multiple selections.  Can you explain in more detail?

I dont use Dia very often, sorry my mistake.
This is either an old behaviour that has been fixed or i have changed some
preferences so that is no longer happens.

Font sizes are not set using the standard sizes such as 10 point, 12
point, 24 point etc.  It is like forcing an American to use metric.  I
can figure it out but i know roughly what size 12 point is when it is
printed and i dont have the same referenece to reality when the units are

I am not an American.  I did not even realise what the scale being used
was metric.  I was merely commenting on the fact that i did not have any
frame of reference to what the scale meant.

Yes, that's probably the biggest UI problem, the fact that the units are
hardwired to centimeters.  There's half-assed code in there that does
unit-based input, but it needs to be tested and used.

Exam time approaches so i cannot offer my help.  In fact i should be
studying right now.

Hope that helps.  I am one of those Usability critics mentioned in the
article who does not submit much code (yet).  I would be happy to give
this more thought and analyse more what things slowed me down when using
dia or did not work as expected.  I hope i can help to make dia even

That would be wonderful.  Every time I use Dia seriously (as opposed to
hacking on it) I find things I'd like to improve, but I never write them

I should have probably filed most of these in Gnomes Bugzilla but some of
these things require more detail and it is hard to know if a project is
receptive to criticism (and even harder to be constructive when you

PPS I strongly suggest comparing and reusing the best ideas from similar
programs like Kivio, Visio, Rational Rose, Sodipodi, Corel Draw etc.

Good point.

Glad to be of use.

Alan Horkan
"Born Critic"

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]