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

List:       kwrite-devel
Subject:    Re: Fwd: Heuristic Analysis for KWrite and Kate Menus
From:       Anders Lund <anders () alweb ! dk>
Date:       2002-03-26 17:12:11
[Download RAW message or body]

On Monday 25 March 2002 21:12, Christoph Cullmann wrote:
> Hi,
> nice mail about usability of kate/kwrite and possible problems, open for
> disccusion ;)

> My name is Irwin Kwan and I'm writing to you from the KDE Usability Group.
>
> I have noticed some differences between Kate and KWrite especially dealing
> with the Menu Settings.  I have written up a draft document with proposed
> usability changes for the two applications to make them more consistent.

This is indeed a very nice analysis. Thank you very much for giving attention 
to Kate/Kwrite!

I have a few comments, and I will add them here, with aprts of the documents 
from Irwin above each comment.

> TOOLBARS:
> ~~~~~~~~~

> KWrite has two extra buttons to increase the font size after the 'find'
> button.

I think they are there to facilitate the browser extension. Imho they should 
be removed from kwrite and only be displayed in the browser extension - or 
maybe not at all?

> *General KDE Note: the Find icon looks much too similar to a 'zoom'
> button.  Potentially misleading; perhaps forward suggestion to KDE-Look
> to consider alternatives

Agreed;)

> Kate has five extra buttons, all dealing with Window-splitting or
>  file-browsing.
> 
> Back (back arrow): View previous document
> Forward (forward arrow): View next document
> Split Vertically (window with vertical line): Opens the same file in the
>  same window, vertically
> Split Horizontally (window with horizontal line): Opens the same file in
>  the same window, horizontally
> Close Current Panel (single panel): Closes the current window panel.
> 
> *Criticism: The Close Current tooltip is 'Close Current' , which might
>  be confused with 'Close' (for close file).  A better tooltip might be
>  'Close Current View'.

Yes, or even "Frame", as a "View" represents a single document, whereas the 
frame may contain instances of several documents.

> *Criticism: The Close Current icon is a single white square.  I
>  recommend that it be changed to a white square with a red slash or
>  similar to let the user know that it is a 'Cancel' action.

The icons for the splitting handling are from Konqueror, and was of cause 
chosen because they look familliar. The function in Kate is a bit different 
though, as a frame may contain more than one document.

(snip)

> General Observations:
> ~~~~~~~~~~~~~~~~~~~~~
>
>
> KATE:
> -In Kate, you cannot drag the file-list sidebar smaller if your file
>  names are too long.

You cand make the file selector smaller than the tool buttons demand. I am 
working on that, but it means a whole new toolbar-like widget, as KToolBar 
cannot be used in a widget with reasobable functionality.

The file selector btw does have a issue with the loaction combo: the listbox 
is resized to the width of the combo, hiding most of long paths. As this is 
done by KComboBox, it is not easy to avoid, I am trying...

> -Your View settings are not saved on shutdown.

Well, that is a configuration issue. You can check the "Restore View 
Configuration" option, which will do that. When closed by the session manager 
this should work, but i can't test it as i have a bug with splitting views 
(we are working on it, but it is not trivial...)

(snip)
---------

> MENU ORDER
> ~~
> 
> I recommend the following order for menus in Kate.
> 
> 	File Edit View Bookmarks Tools Document Settings Help
> 
> I recommend the following order for menus in KWrite.
> 
> 	File Edit Bookmarks Tools Document Settings Help
> 
> -Why?
> 	This keeps the first five items in the identical order, and the last
>  two in
>  identical order.
> 	'View' is Kate specific and is added in the middle.
> 	'Document' added to KWrite for overall consistency.
> 
I can agree to the principles. Here is what I think: Generally, I look for the 
menus I use the most at the left of the menu bar - after considering 
conventions (file, edit ---- help). And there is a cross-desktop for the 
Document menu to be to the left I think. How ever, I would like to see 
"Tools" next to "Edit" in Kate/Kwrite, as most of the commands there are 
moved to make the edit menu smaller, and avoid bad logic.

However, on my system (running HEAD, with slightly changed menus) I do have 
the suggested menu order, including the "Tools" menu, allthough not all 
commands that you recommend moved there have been (yet).

I thought theese changes had made it to KDE 3 - if not I apologize.

> * Up For Discussion: The top-level menu order (should we put Document before 
> or after settings, etc.).

Before. It is more often used, and relates to the documents rather than the 
application.

> * Up For Discussion: Where to put some options such as Panel-splitting and  
> File lists: perhaps in a new Menu named 'Window'?

I have had a similar thought. There is some confiusion as to how this works 
atm, actually. If for example both the file list and file selector are open, 
and you activate the Settings->show (the one active) it will close down.
This is becase of the dock system, and needs work. I believe we should have 
commands to "show" and - whenever a docked window is in a tabbed stack at 
least - focus each docked tool window. There is currently no way of focusing 
the tool windows using the keyboard, so that is really a missing feature.

> * Up For Discussion: The naming of some of the menu items: Document -
> Window?  View -> Window?

I think we sould use the words "Document", "View" and "Frame", which i guess 
is most familliar to users. A document is the contents of a file, which have 
one or more Views, each positioned inside a Frame.

(snip)

> *Find in Files... should not appear in KWrite.
> (Question: What is 'Editing Command'?)

Read the manual:)

> Changes in Both:
> -Editing Command should have an ellipsis (...) because it brings up a
>  separate
>  dialog.

Agreed.

> Changes from Kate:
> -Removal of a number of items to make the menu smaller.  (Most of them
>  will be
>  relocated to the Tools menu).
> -Some reordering.  (Go To Line... for example was moved closer to the
>  top.)

As I stated above, I have partly done that;)

---
(snip)

> Up for Discussion:
> "Toggle Bookmark" is an awkward term and perhaps should be renamed to
> Add Bookmark'.  If you want to delete a bookmark, perhaps add an 'Edit
>  Bookmarks' style dialog.
> Call it 'Add Bookmark' if you don't have a bookmark there.  If you do,
>  grey it out.
> Add another item called 'Delete Bookmark'.  If your cursor is on a line
>  with no bookmark, then grey it out.  If your cursor is on a line WITH a
>  bookmark, activate this item.

NO!! PLEASE!!
Splitting this would greatly confuse, and make usability worse -  would have 
to remember two commands rather than one, and it would eat a precious 
shortcut. Imo the them "Bookmark" is wrong - this is traditionally known as a 
"mark". This is very confusing inside konqueror, which allready has a 
"Bookmarks" menu, and soemone even at a point changed the kwrite 
browserextension menu  to add the it's "Bookmarks" menu in the menubar, next 
to konquerors own (my original place when I made the marks feature available 
to the browser extension was to in edit->marks - neither very good, but 
better imho).

"Toggle Mark" is exactly what is beeing done, and thus the correct term. You 
can see it if you use the icon border, click on a line to toggle the mark. 
Deniying me the opiton to remove a mark with the keyboard without launching a 
dialog would probably make me dump kate.

The only alternative I can think of, is changing the text of the action to 
reflect the current line when the menu is launched, so that it would say "Set 
Mark" if the line had no mark, and "Remove Mark" if it did. But commands with 
changing labels are tricky, and should be used with care.

> DOCUMENT MENU
> ~~
>
> Document Menu: To manipulate document settings for one specific
>  document.
>
> Document
> 	Back*
> 	Forward*
> 	--
> 	KDE Scripts >
> 		Convert file text to lowercase
> 		Test Shell Script
> 	Highlight Mode >
> 		Normal
> 		Sources >
> 		Markup >
> 		Scripts >
> 	End of Line >
> 		Unix
> 		Windows/Dos
> 		Macintosh
> 	--
> 	Show Icon Border
> 	Show Line Numbers
> 	--
> 	(Document List)*
>
> *Not in KWrite
>
> Changes from KWrite:
> -I moved a lot of the options such as 'End of Line' and 'Highlight Mode'
>  to this
>  menu because they make more sense to apply to a 'document' rather than
>  as a
>  setting.  Settings implies global whereas these options apply only to
>  the
>  current document.

I agree to this.

> -I moved 'Show Icon Border' and 'Show Line Numbers' because they apply
>  only to a
>  specific document and not to the global settings.

Well, they apply to the View, not the Document. Currently, if you split a 
frame the settings aren't even copied. See below. 

> *Comment: 'Show Icon Border' and 'Show Line Numbers' cannot be set to be
>  displayed on default when you open a new file.  These options should be
>  added
>  to the "Configure <applicaiton>" dialogs to state "Display Line
>  Numbers".

That is on my TODO. I add options for line numbers to be on by default, and 
for icon border to be on, off or auto, where auto would display the border 
when there is one or more marks in the Document.

>  Using the 'Document' menu they can toggle the Numbers on and off for
>  one
>  document.

Well, that does not happen just because you move the command to another menu;)
To achieve that, the property should be moved to Document, rather than View 
where it resides now - anything else would be ugly. Alternatively it could be 
an option to have settings even, that is if a new view is added for a 
document, the state of line/icon borders are copied. But I personally agree, 
I would like to move that setting to document.

> Changes from Kate:
> -Moved the 'Show Icon Border' and 'Show Line Numbers' from View to
>  Document.
>  The settings do not apply to the View, but instead to the Document.
>  (Try
>  opening a couple files, then setting one to 'Show Line Numbers'.  Click
>  on the
>  other document.  Then click back to the original document.)

??? If I do that, things works as expected: the View for which I displayed 
line numbers shows them, others not.

>
>  ~~
>  VIEW MENU
>  ~~
>
> View Menu: Change viewing options (This does not appear in KWrite).
>  Operations
>  apply to the Kate window.
>
> View
> 	Split Horizontal
> 	Split Vertical
> 	--
> 	Show File List
> 	Show File Selector
> 	Show Terminal Emulator
> 	--
> 	Close Current
> 	Go >
> 		Next View
> 		Previous View
>
> Changes from Kate:
> -I moved 'Show Terminal Emulator' from 'Settings' to 'View' because the
>  Terminal
>  opens in a new View.  Showing the Terminal Emulator is not a setting.
> (Fascinating facts: The command for this in Konqueror is called 'Open
>  Terminal
>  and appears under the Tools menu.  Another command called 'Show
>  Terminal
>  Emulator' is under the 'Window' menu.)

Well, the term "View" in Kate reffers to a visual representation of a 
document. What you suggest is a microsoftish interpretion of the "view" menu, 
which is one mistake that KDE didn't (at least on a global level) duplicate: 
In KDE those settings are usually in the Settings menu.

> Up for discussion:
> -Where to put 'Show File List' and 'Show File Selector': Under
>  'Settings' or
>  'View'?  They are within a view-style window, but are not the same as
>  an
>  Editing View.  I put them under 'View' because I believe it is more
>  natural for
>  people to look here than under 'Settings'.  However,

See above. In KDE they belongs under "settings". The dockable interface is 
problematic here though, as focusing and opening/closing a docked window is 
not (nessecarily) the same.  

> Up for discussion:
> -Rename 'View' to 'Window' to be more consistent with Konqueror.
> 	My personal take?  I like 'View' a lot better, and I think makes more
>  sense
>  than 'Window' does.
Absolutely. Again, "View" refers to a representation of a document.

> -Maybe move the Documents List under 'View'.
> 	'Documents' applies to one document.  Why put them under the
>  'Documents'
>  section then?
> 	But the Documents list isn't a View-style operation.

IMO the document menu of Kate is exactly what it should be. There is some 
confusing with the file menu. When I originally added the "open with" option 
for example, I wanted to put it under "Document" as it is an action 
corresponding to the "current document". The same could be said for other 
commands. It was moved because of the convention, which tends to win over 
logics quite often - at least for something as traditional as the file menu;) 


> ~~
> SETTINGS MENU
> ~~
>
> Settings Menu: Settings for the global application, such as displays and
>  behaviour.
>
> Kate Menu:
> Settings
> 	Show Toolbar
> 	Show Statusbar
> 	Show Path
> 	--
> 	Configure Shortcuts...
> 	Configure Toolbars...
> 	Configure Kate...
>
> Changes:
> -Removed 'Show Terminal Emulator', "Show File List", "Show File
>  Selector" for
>  reasons discussed under 'View'.
> -Added 'Show Statusbar'. (This should be on by default).  This is an
>  option in
>  KWrite that is not in Kate.
> -Added 'Show Path'.  This is an option in KWrite that is not in Kate.

This option was removed from the kate settings menu on request. It is in the 
kwrite menu, because kwrite does not have a settings dialog of it's own, 
since kwrite just a wrapper around katepart, ont a real application of its 
own. The reason for removing it was that it is a rarely used option, most 
people will set it once and never again, so having it in a menu is considered 
overkill and polution of the menu system. 

(snip)

Well, that was my comments. Again, thanks for the input. I hope we can make 
the best of this discussion, apart from making kate and kwrite more 
consistent, it raises some important discussions for kate, which is a complex 
application, and deserves carefull design of the command interface.

-anders


_______________________________________________
kwrite-devel mailing list
kwrite-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]