The context menu

[a.l.e]

What is the role of the context menu in Scribus?

- Show the most relevant actions in the current context?
- Show all the available actions in the current context?
- Show all the possible actions? (Gimp is doing that)

Once this question is answered, how fast should the context menu be?

- Should it have only (mostly) one level for fast triggering?
- Should it have good tree structure? (like now)

Anybody wants to propose a cocept that could be discussed with the team?
(currently, it seems that anybody can wish something and it will be added...)
(the idea to discuss this came from the discussion on the hyperlinks... where somebody proposed to add them to the context menu...)

[CGood]

My immediate responses. I'd like context menus to show a very large proportion of all relevant actions.

I prefer a context menu like in 1.5.1 where there is a tree structure. I think the context menu design in 1.5.1 is better than 1.4.6 for example.

Adding hyperlink to a text via an item or tree branch of items in the context menu seems sensible.

I would add that I'd also like to see more actions accessible via keyboard shortcuts. I suspect that is a topic for a different thread but speed of access to actions is connected to this thread.

[utnik]

hi ale

good question!

i like to see all the available actions in the current context in the CM.
for this it needs a good tree structure.

for speed i prefere keyboard shortcuts. (the context menu is for actions i don't need as often as i would remember the shortcut – so ultimate speed is secondary, but more keyboard shortcuts are needed...)

utnik

[tim_occ]

Hi,

In a classic menu bar you have actions sorted by topics, like Edit, Item, Page, etc.
In a context menu you have actions sorted by item.

I like context menues that give me an idea what I can do with the object. But at these point it should be focus on often used things. A second level is ok to group some actions into one topic. What I don't like is an overloaded one-level-menu which is like a wall of text.

I use context menues for two reasons:
1. to see what I can do
2. as a cheat sheet for action shortcuts

[GarryP]

If we think about what the context menu is called then there is the argument that its contents should relate to the object that has been right-clicked. In other words, the context menu should - using this argument - only hold actions that are relevant within the "context" of that object. To say it a bit differently, the context menu should only show actions that can be applied to the object that is selected.

For instance, if you right-click on an image frame then - using the above argument - there should only be actions in the context menu that can be applied to an image frame. That's a pretty reasonable argument but there's a slight problem: What about actions that are relevant to the context but are currently either not available or not applicable?

To expand the above scenario, if you right-click on an image frame you get a list of actions that relate to that frame - all well and good so far - but you may also get some actions that are not actually applicable. For instance, there's currently an action for "Adjust Image to Frame". This action is always available, even if the action has just been applied and the image already fits the frame. Using the argument above, this action should not be available as there is no reason to fit the image to the frame again; it's a pointless action - at this moment - because it has no effect. (The same goes for "Level -> Raise" when the object is at the top of the stack. etc.)

So now we have the question of what to do with this action. Should it be greyed out - to show the user that it might become available in the future - or should it not appear in the menu until it can be applied?

There is an argument that the action should not appear because it can't be applied and having it there takes up valuable space forcing the user to mouse over it to get to other actions. There is also the counter-argument that the action should appear - but be greyed out - so that the user knows that it's a possible action but it's just not available at the moment.

The discussion about which argument is correct has gone on for decades and will probably never conclude satisfactorily to both sides but it leads me to the next point: You either clamp down on the available actions and only show those that can be applied at the moment in time the user right-clicks, or you show more actions than those which are applicable. If you show more, then how many more do you show? Who decides which are to be shown and how far do you go?

As has already been mentioned, some applications - like GIMP - offer the user all possible actions but some are greyed out and unavailable. This means that you have a very large context menu with a lot of potential actions which the user can browse through to see if they can find one they want to use. This can be very useful to casual users where they know they did something a while back that performed the action they wanted but they can't quite remember what it was called. On the other hand, it can mean that the user is shown a multitude of choices, some of which are not available and they don't know how to make them available, and that can be frustrating.

Personally, I think that the main menu should offer every possible action - with some greyed out if they are not currently available - and the context menu should only offer those actions that can be currently applied within the context of the object that has been right-clicked. (By way of example, Scribus already does this by not showing the "Adjust Image to Frame" action if an image frame has no image.) I think this is a reasonable compromise between the two arguments. People who want to see every possible action - even if they can't actually preform them at the time - can see them through the main menu and people who only want to see the actions they can currently perform can use the context menu.

To expand on that a little: There also should be no action available via the context menu that isn't also available via the main menu. To rephrase that, there should be no actions that are "hidden" in the contextual menu. There are some people who don't use the contextual menus. There could be many reasons for this: they are using a pointing device that only has one button; they have limited physical ability and cannot use more than one button; etc. These people should not be given a worse experience of using the software because they cannot access part of it.

Then there is then the argument between having a "long" context menu and having a hierarchical context menu. Again, the arguments about this have been going on for decades and there is no "correct" answer. Some people like to have everything available on the first level of the menu while others prefer a shorter menu with sub-levels. I have used some applications where a long single-level menu is good and I have used some applications where a multi-level menu is good. It really depends on the application.

I think Scribus 1.4.6 has a decent compromise between the two. For instance, I like to be able to get to "Adjust Image to Frame" straight from the root level of the menu rather than having to go through something like "Image -> Adjustments -> Adjust Image to Frame". Conversely, I prefer to use "Level -> Raise" rather than having the Raise, Lower, Raise to Top and Lower to Bottom actions all in the root level. And when you consider the "Send To Layer" actions that makes even more sense.

As for which actions should be in the context menu and where they should be in it, I don't think anyone is going to agree with anyone else on everything. For me, having "Info" as the first action isn't very useful. I hardly ever use that function and having to mouse over it every time makes the menu feel awkward. The same goes for the Undo function (I generally use CTRL+Z). I also use "Send to Layer" much more often than I use "Edit Image" or "Attributes". But that's just me, other people might use Scribus differently. I don't think there will be consensus on this.

In summary then, I think that:
* The main menu should show all possible actions - even if they're not currently available.
* The context menu should only show actions that are applicable to the object currently selected.
* The context menu should present a compromise between a single-level list and a hierarchical list.

I realise that this doesn't answer a lot of questions but I hope I've been able to explain some reasoning in a decent way that helps the discussion move forward.

[a.l.e]

A complement to my question: What are you using the context menu for?

I use it:

- in Firefox for starting the inspector on a specific item (otherwise it's F12)
- in Irc to leave channels (right click on a specific channel and leave it)
- In Firefox / Libreoffice / Email to pick a spelling correction
- In Gimp to crop and resize images
- In Scribus for sending items to specific layers (I miss the action in Inkscape)
- In Scribus for fitting a frame to the image (but not the image to the frame)

Those are tasks that are highly related with a visual element I see on screen.

Personally, I'd wish that Scribus would have only few action in the context menu, mostly without sub menus.
Highly context sensitive.
Fast to trigger.

And use other means for making the available actions discoverable.

[GarryP]

Thinking back a bit on my own use of the context menu:
* Firefox - "Bookmark" and various "Save" functions, sometimes "View Page Source";
* GIMP - only really use it in the Layers toolbox for things like "Add Layer Mask" and "Merge Down", can't remember the last time I used it over an image;
* Inkscape - very rare, can't remember using it (have just been in to see what it looks like);
* Notepad++ - "Select All" and "Copy" normally one straight after the other, and spell check.

If I had to choose a most-used sub-set of actions for the Scribus context menu it might be something like:

TEXT FRAME

* Get Text
* Edit Text
* Sample Text
---
* Send To Layer
* Convert To
---
* Edit Shape (open Node Editor)

IMAGE FRAME

* Get Image
* Adjust Image to Frame
* Adjust Frame to Image
* Update Image (not entirely necessary)
* Image Effects
* Preview Settings
---
* Send To Layer
* Convert To
---
* Edit Shape (open Node Editor)
* Text Flow Around (with options)

POLYGON (and most others)

* Send To Layer
* Convert To
---
* Edit Shape (open Node Editor)
* Text Flow Around (with options)

[CGood]

A quick reply:

I like GarryP's context menu concept.

I'd add the Levels (up down top bottom) to his lists.

In the more distant future I'd love to see the ability for the user to be able to add or remove items from context menus etc., but that feels like several steps down the road.

[utnik]

hi ale

i don't use the context menu as often as garry (i use more keyboard shartcuts instead...)

my general cm use is:

in inkscape

   
• move to layer
• select same (color, stroke...)
• set mask

in gimp

   
• layer masks
• other layer operations

in scribus

   
• send to scrapbook
• send to layer
• convert to (text frame, polygon...)
• update image
• preview settings
• contents → clear

in firefox

   
• view source code
• object inspector

in libreoffice

   
• image anchor (on page, on paragraph...)
• text flow around objects
• level of objects

utnik

[AdmFubar]

Just found this thread... but how about a customizable context menu? So i can put my most used options there?