[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    RFC: Kexi Database quick notes and suggestions
From:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2005-07-11 8:43:57
Message-ID: 42D2314D.4060805 () iidea ! pl
[Download RAW message or body]

Alan Horkan said the following, On 2005-07-10 00:32:

> Jaroslaw Staniek asked me on IRC to give Kexi a try and so I did but I
> cannot resist proving criticism (hopefully constructive) so here goes.
> I'm not as familiar with Database applications as I am with other software
> so I am not making any strong recommendations.  I will simply make
> superficial suggestions as part of a heuristic review rather than anything
> very deep or insightful.  I only hope the Kexi developers will consider
> and maybe even like to follow some of the suggestions.  As always I
> strongly recommend looking at what the competition are doing and copying
> it unless you are sure your way is better.  I'd rather be wrong in a way
> users already understand and have a better chance of working around than
> be wrong in a whole new way that causes even more problems.
> 
> Sub menus are bad, slower to navigate, and rarely worth having for less
> than three items.  Would be better to have "Sort Ascending" and "Sort
> Descending" directly in Data menu, especially since there are currently no
> other items in the Data menu.  (Kspread has a single menu item for Sort...
> so no useful comparison there to help make my point.)

Can be changed, although the submenu is similar to the one in data-driven apps 
like MSAccess, and could my hint here be that if you want to quick access to 
your commands, use toolbar (sorting actions are there by default)?

> File, Download Example Databases...
> I might put this under help (examples are like documentation) but I'm
> probably just reacting to how the long label gives a really wide and odd
> looking menu.  The quality of the examples you are providing might also
> influence how prominently you wish to display and promote this feature.

THe action has been inserted there after discussion, the goal is to make it 
visible. We have already quite bad history of entries in Help menu being 
invisible  to our users (eg.  an action for "did you know" dialog).

> Unless Kexi plans to eventually provide other kinds of Imports (like
> perhaps from spreadsheets or Comma Separated Values) I might recommend
> using the standard File, Import rather then "Tools, Migration, Import
> Database..."

The "file->Import" submenu is good for us; it will decrease a clutter quite 
soon when more options appear

> And even if that change is not appropriate I think Migration should
> probably be changed to "Migrate".  I'm not exactly sure what the rule is
> but the style seems to be to verbs rather than nouns as menu item labels.
> (Since writing this earlier I see Kexi 1.0 now has an Import submenu.)

ok, we can go to the verb

> For greater consistency with the rest of Koffice and that other Office
> suite I might relabel the Create menu to Insert, and then also move the
> "Edit, Insert Empty Row" in there (possibly also relabelling it to give
> "Insert, Table Row".

The problem is that we're not "Inserting" the top level objects on creation to 
a document (Kexi is not document-driven, whatever that means to you...) but 
creates them in a sort of repository. We're going to have also an action for 
actual _inserting_ a table view e.g. to a form. What would we do then? Two 
"insert table" actions?
Also, looking at word processors, "table inserting" actions are often somthing 
like displaying a new table within a document, with optionally importing some 
data for it. DB objects creation is something we preferred not to call 
"Insert"...
That said, I agree we will need "Insert" menu as well.

> I find Dynamic user interfaces massively confusing.  If there are menu
> items you can leave permanently displayed but greyed out when not
> available it may help alleviate some of the confusion caused by the user
> interface being rearranged all the time.  I'm not sure if this is
> practical given how Koffice and Kexi work but I thought it was important
> to mention it anyway.

It's catch-22 situation. Without dynamic menu and toolbar system (it's 
developed as an entire small framework :) ) we an quickly end up with menus 
with tens items. Look at menus of KDevelop and Kate (both are targeted most 
for knowledgable users). We wanted to avoid such clutter. Finally, I must add 
that Kexi uses plugin system, so there can be enstalled 
table/query/form/report/macro/script/webaccess plugin and more, each 
incorporating its set of actions to menu and toolbars.  What is interesting, 
we've defined a common set of actions (eg. sorting a->z, z->a), and still 
expanding it. KActions from the set are defined globally and are greyed as you 
expecting. Other actions, specific to a given plugin, such as "insert primary 
key" are undoubltely, not reusable nor shareable.

> The Format menu includes menus for "Align Widget Position" and "Adjust
> Widget Size".  On the #kexi IRC channel it was discussed how "widget" can
> be a slightly confusing term for users.  I suggested using this as an
> opportunity to make it more consistent with Karbon, Kivio, and to simply
> use the label "Align" and "Adjust" (you might also want to borrow similar
> keybindings.  Although it may be possible to choose an even better label
> than adjust (resize, fit, ...) so I'd encourage you to look at how other
> software does it.  Having a GUI designer built directly into Kexi seems
> very complicated and a lot of work to develop, so if there were a way to
> leverage existing work and import designs from other KDE/Qt programs it
> would be worth exploring.

IMHO "Widget" term is here to stay, because it's ok for translation, while 
object or frame is not acceptable here.
I plan to make some renaming and menu-rearrangement looking more at 
KPresenter/Kivio etc.

> Seperators would add greater clarity to items in the submenu of
> Window, Tile, ...
> If you average about one one seperator for every four or five menu items
> it is pretty hard to go wrong.

Again, it's KMDI's stuff. Personally I found the submenu really confusing and 
dont know anyone using most of these actions. Can be fixed by fixing KMDI, 
we'll see.

> Sorry but I'm out of time, otherwise I would keep trying to find more
> little bits and piecs that might easily be improved.

Thx a lot! Finally a good portion of hints.

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska / Kexi Team
  http://www.openoffice.com.pl  |  http://www.kexi-project.org
  KDElibs/Windows: http://wiki.kde.org/tiki-index.php?page=KDElibs+for+win32
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]