clarify the toolbars

[GoogleCodeExporter]

This bug report is intended for community discussion on a core user
interface of specto: the notifier window and its toolbar(s).

=======the problem==============
- we want the interface to be as intuitive as possible
- we have two "levels" of interaction. The user can apply actions on "all
watches" or "only the watch that is currently selected"
- we used to show buttons in the info pane, but we changed that in our
development branches (wout & jeff). All that is left is one toolbar at the
top (see attached screenshot).
- all this causes confusion

You are invited to discuss how we could make this all work without a Ph.D.
Ideally abiding by the recommendations of the Human Interface Guidelines 
http://developer.gnome.org/projects/gup/hig/draft_hig_new/

=======initial discussion=======
jeff: hey, while doing my patch I just remembered why I did not use
"refresh all", that's because it breaks "stop" if you use a label

Wout: i saw that you changed the refresh all back to a stock icon? but i
think it becomes confusing with the "refresh" button in the right-click
menu from a notifier entry

jeff: I think I have a solution for the refresh button problem:
1) add a separate "stop" toolbar button (that is made sensitive/insensitive)
2) make the refresh toolbar button apply only to the selected watch
3) add refresh in Edit menu
4) in the view menu, rename Refresh to Refresh All

Wout: another button in the toolbar would become too much, and this stop
button can only be used when you use refresh all
jeff: true, unless we manage to REALLY make it stop; our current stop is hacky
Wout: i dont think it is possible, would be too dangerious to kill a thread

jeff: here is the essence of our problem: we are trying to fit two
paradigms ("all watches" and "only the selected watch") in one toolbar;
that is difficult

Wout: yes i understand the problem, that's why i added the right-click
menu. Maybe i could also add a refresh menu option in the edit menu

Original issue reported on code.google.com by nekoh...@gmail.com on 6 Jan 2008 at 9:38

Attachments:

• Capture-Notifications.png

[GoogleCodeExporter]

As far as i'm concerned, having on the same ribbon buttons that act on all
watches or only on the watch that is currently selected is not a matter for me 
: the
role of these buttons is perfectly clear if their label is perfectly clear (i.e.
"Clear All").

By the way, i'm not sure of the utility of having a STOP functionnality.

Original comment by thibaut....@gmail.com on 7 Jan 2008 at 1:25

[GoogleCodeExporter]

If you want a clearer ribbon, we can imagine to hide the "edition" button (that
functionnality would still be accessible through the contextual menu and the 
edition
menu)

Original comment by thibaut....@gmail.com on 7 Jan 2008 at 1:31

[GoogleCodeExporter]

in complement to what i said in comment 1 :

If having, on the same pane, buttons that act "on all watches" and buttons that 
act
"only on the watch that is currently selected" (i.e. respectively "Clear All" 
and
"Remove") is not a matter for me as long as the label of these buttons is 
perfectly
clear, 
you should avoid having, on the same pane, 2 buttons with the same 
functionnality
refering, one, to "all watches", and, the other, to "only the watch that is 
currently
selected" (i.e. having "clear all" and "clear this item" in the same pane. In 
these
case, you could show a "clear all" button on the pane and propose a "clear this 
item"
option in context menu to avoid confusion)

Original comment by thibaut....@gmail.com on 9 Jan 2008 at 1:45

[GoogleCodeExporter]

I fully agree with the comment above...so this means that the current layout is 
good
and we should keep it this way :)

thanks for your comments thibaut!

Original comment by woutclym...@gmail.com on 9 Jan 2008 at 6:19

[GoogleCodeExporter]

thank you

and what about hiding the "edition" button (see comment 2) ?

Original comment by thibaut....@gmail.com on 11 Jan 2008 at 1:01

[GoogleCodeExporter]

but then, contextual menus are known for not being immediately
intuitive/discoverable, no? You'd be surprised how much people I see 
"forgetting"
they can right-click...

Shamelessly quoting the HIG that suggests: "Popup menus are used primarily by
intermediate and advanced users. Even some users who have used graphical 
desktops for
many years do not know about popup menus until somebody shows them."

disclaimer: this is not a hard and universal rule, see
http://developer.gnome.org/projects/gup/hig/draft_hig_new/menus-types.html#menu-
type-popup)

But in the end, I think you are right. So, it would look like this?

Main toolbar: 
=============
Refresh all/Stop, Add, Clear all (actually... this is precisely identical to 
Specto
Trunk!)

Context (popup) menu
====================
Jump to, separator, Edit, Remove, Clear

Double click signal
===================
= jump to,
But should the double click apply to the entire watch row instead of just the 
icon? I
would say yes, because we almost *never* rename a watch, so the "rename the 
watch
directly from the list view" is not a feature, it creates confusion and a 
smaller
target to "Jump to" (Fitt's law, etc)

Original comment by nekoh...@gmail.com on 11 Jan 2008 at 1:26

[GoogleCodeExporter]

I think the current buttons should stay in the main toolbar (refresh all, add,
remove, edit and jump to) i am already used to them and i use them alot...i 
want to
keep the edit watch because maybe someday we will have a watch that you re-use a
lot....i am thinking of the reminder watch where you create one reminder watch 
and
every time your reminder was updated, you can set easily a new reminder without
creating a new watch)

for the context menu i also added a "start watch", "stop watch" and "refresh 
watch"
and i think they are very useful and should stay.

so my opinion is to keep the current interface..but to remove the "rename watch"
function when you double-click a notifier entry is a good idea!

if you can give me a good reason why we should remove the edit, remove and jump 
to
button from the toolbar i will adjust it, but for now it stays

Original comment by woutclym...@gmail.com on 11 Jan 2008 at 6:58

[GoogleCodeExporter]

i agree to say that remove and jump should stay in the pane since they are 
"basic"
functionnalities and that there is no risk of confusion with other buttons

whereas i'm not sure that that "edit" is a "basic" functionnality nor will be
frequently used

Original comment by thibaut....@gmail.com on 11 Jan 2008 at 10:16

[GoogleCodeExporter]

I found a case why we should keep the "edit" button in the toolbar:
In Issue 121 somebody wants to burn a cd when the download is finished.
So i think he wants to change the update command in an easy and fast way every 
time
he wants to use this function to burn a cd automatically.

So i think the edit watch should stay

Original comment by woutclym...@gmail.com on 21 Mar 2008 at 7:37

[GoogleCodeExporter]

I agree that the edit button is something quite central to specto and needs to 
be
easily accessible. I suggest keeping it.

FWIW, I use edit quite frequently. Also, consider the use case of someone who is
doing the initial "error margin" configuration of a web watch, or changing 
passwords,
etc.

Original comment by nekoh...@gmail.com on 21 Mar 2008 at 11:26

[GoogleCodeExporter]

Original comment by woutclym...@gmail.com on 22 Mar 2008 at 8:33

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by nekoh...@gmail.com on 4 Oct 2008 at 12:45

• Changed state: Verified