Rearrange menus

Bug #380671 reported by antistress
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
phraymd
Confirmed
Undecided
dmoore

Bug Description

Can't go back after choosing Selection>Show all selected :
If i select a few pictures and click on the "Show all selected" entry in "Selection" menu, how can i display again all the pictures ?
Maybe phraymd lacks a "Show all" option

Revision history for this message
dmoore (damien-moore) wrote :

You just need to clear the filter with the "broom" button. I agree that it isn't obvious you need to do that.

Changed in phraymd:
assignee: nobody → spillz (damien-moore)
status: New → Confirmed
Revision history for this message
antistress (antistress) wrote :

indeed (for both comments)
(BTW i've discovered it was the same with the tags pane : clicking a tag make unused tags disappear, clicking the broom make all tags reappear)

"Show all selected" is the only entry in "Selection" menu to add a keyword in the text field which is strange.
Maybe adding a "Show all" entry in Selection menu and not adding a keyword in the text field for "Show all selected" entry would be more intuitive ?

Revision history for this message
antistress (antistress) wrote :

BTW i don't see why clicking a tag make unused tags disappear : maybe the selected tags could be highlighted while other tags are still visible ?

After some thoughts, maybe the GUI could be more clear with separate menus :

Edition
− Select all
− Select none
− Invert selection
___
− Copy selection
− Move selection
− Delete selection
___
− Add tags
− Delete tags
− Set descriptive infos

View
− Show all selected
− Show all
− Relevance
−− Date last modified
−− Orientation
−− Shutter spedd
−− etc.

What do you think ?

antistress (antistress)
description: updated
summary: - Can't go back after choosing Selection>Show all selected
+ Rearrange menus
Revision history for this message
dmoore (damien-moore) wrote :

I've been resisting using a menu bar so far because menu bar context can often be unintuitive (what does a particular menu option act on? the photo? the selection? the view? the collection?). I also dislike the redundancy of having both toolbars and menu bars.

I may switch back to the more traditional menu driven paradigm eventually (or allow user choice)

having a view menu would make sense -- however the view will always be tied to the search text field because phraymd uses the search mechanism to filter the view. As phraymd deveops, it may make sense to hide the text field by default and make it more of a power user feature, with a more intuitive gui available to new users. Did you see the post on the search features: http://groups.google.com/group/phraymd/web/phraymd-development-update-1

I'm less sure about having an edit menu. I guess it's consistent with the paradigm of other apps, but that menu often ends up a an unintuitive catch all (e.g. search, and search again in firefox)

"BTW i don't see why clicking a tag make unused tags disappear : "

this will change eventually. I'm still implementing tag pane features. currently I'm only tracking the "unused" tags associated with the current view.

"maybe the selected tags could be highlighted while other tags are still visible ?"

The tag counts are probably enough, but highlighting wouldn't be difficult. In the future I may also show the tag as e.g. "Friends (X/Y)" where X is the number of images with that tag in the view, Y is the number in the collection.

Revision history for this message
antistress (antistress) wrote :

1°) "I've been resisting using a menu bar so far because menu bar context can often be unintuitive (what does a particular menu option act on? the photo? the selection? the view? the collection?)."
I would say : same thing with toolbar
It depens on the functionality :
For instance functionalities in Edit menu should be actions and act on current selection
That's why you can duplicate these functionnalities in the contextual menu.
That seems clear to me.
And not because it's consistent with the paradigm of other apps, but because it makes sense.

be that as it may, current entries should be gathered depending their nature : actions or not

That is what i tried to propose in my former comment.

Note that if you decide to gather entries related to actions in a menu, you don't have to name it Edit. It can be Operations or Actions or whatever you want.
You can also have 2 different menus for actions if you want to gather 2 kind of actions.
But it doesn't seem a good idea to have actions and non−actions in the same menu like now in the Selection menu.

2°) Concerning the search text field, you don't have to hide it. Gmail has similar stuff and it works well : noobs only key words, advanced users make use of Search Syntax which looks fine

3°) Concerning the GUI for tagging
Have you tried jBrout ? With jBrout you first select images and then drag and drop a tag on the selection to tag all images selected.
Tags can then be removed from the contextual menu
see picture attached

Revision history for this message
antistress (antistress) wrote :

BTW, i don't think that phraymd should have several GUI (1) : It could mean that you implicitly renounce to find THE good GUI
i strongly believe that one project may have one GUI that could fit all
it requires efforts to make the good choices but it's up to the developper to make these choices, not the user

That's why the search text field is a good idea for instance, since it can be used by both noobs and advanced users

(1) "I may switch back to the more traditional menu driven paradigm eventually (or allow user choice)"
"it may make sense to hide the text field by default and make it more of a power user feature, with a more intuitive gui available to new users"

Revision history for this message
dmoore (damien-moore) wrote :

"i don't think that phraymd should have several GUI. It could mean that you implicitly renounce to find THE good GUI
i strongly believe that one project may have one GUI that could fit all"

Don't worry -- I have strong priors about what constitutes a good GUI and will continue to tweak until I get there. However, I'm prepared to give the user the option to deviate from my defaults if it makes sense.

"be that as it may, current entries should be gathered depending their nature : actions or not"

I thought that was what I was doing with the "selection menu": gathering together commands that modify or work with the selection.

One way to improve this would be to turn the selection menu into a selection pane, akin to the tag and map panes. That way I can more logically arrange the actions and also convey state information about the selection directly in the pane.

Thoughts?

Revision history for this message
dmoore (damien-moore) wrote :

"Have you tried jBrout ? With jBrout you first select images and then drag and drop a tag on the selection to tag all images selected. Tags can then be removed from the contextual menu"

I have briefly tried jBrout. Drag n drop isn't my favorite metaphor (especially on touch screen or track pad) so personally I'll always want an alternative way to set the tags. Having said that, the current trunk version allows you to drag tags to an image to add a tag to that image (I'll also eventually add drag n drop support for tagging the selection if the item is part of a selection). There's also a "tag mode" and "tag selected" options: when you depress the former, you will tag everything you click with the tags checked in the tree; the latter tags the selection with everything checked in the tree.

You can also drag tags to an image to set an image for that tag in the tag tree view

Revision history for this message
antistress (antistress) wrote :

(concerning the GUI for tagging, see Bug #395389)

Revision history for this message
antistress (antistress) wrote :

i think that report can now be closed

Revision history for this message
antistress (antistress) wrote :

Maybe this report could be markes as "Won't fix" ?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.