Closed Bug 741371 Opened 12 years ago Closed 12 years ago

If a panel is associated with a widget it should open near the click position by default

Categories

(Add-on SDK Graveyard :: General, defect)

Product:
Add-on SDK Graveyard
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: whimboo, Assigned: zer0)

References

(
URL
)

Details

Attachments

(1 file)

Pull request 503
165 bytes, text/html
zer0
: feedback-
Details 
Right now a panel which is associated to a widget element gets always opened at the left side of the widget. If you have a wide widget this behavior is odd and the UI feels broken. So instead of using the hard-coded origin position of the widget lets evaluate the click event and take its coordinates into account. That way we would be able to open the panel is close as possible to the position the event has been triggered. 

This behavior should be done by default, so this request is not a dupe of bug 638142 or bug 669523.
The necessary x and y coordinates can be specified as given by:
https://developer.mozilla.org/en/XUL/panel#m-openPopup
URL: https://developer.mozilla.org/en/XUL/...
Waiting on Matteo to look at this
Assignee: nobody → zer0
The panel's arrow should be positioned in the middle of the widget, that is consistent with the UX design of Firefox. The panel itself is aligned at run time depends by the space available. However the algorithm used in the last scenario needs to be fixed, as discussed in the bug 669523 that whimboo mentioned.

I need to understand this bug a bit more clearly: Henrik, could you provide a snapshot of the issue?
Matteo, just install MemChaser and click on the red dot to let the panel show up. You will see what's wrong immediately.

https://addons.mozilla.org/firefox/addon/memchaser/
I see. I think there is something doesn't work as expected in any case, because the popup arrow doesn't seems centered.

However the feeling about be broken, is given by the fact that there is no UI feedback that you have clicked a whole entity (the widget) but the "red dot". To make a concrete example, if are in bugzilla with Firefox, you see the identity box with "mozilla.org" and the bugzilla favicon. It doesn't matter where you click, on the icon or the text, you will get the same popup and always centered. It doesn't feel broken because we have a UI feedback that makes the whole identity box "pressed".

I'm not sure if display the popup in point where the user clicked is correct, because it doesn't seems consistent with the rest of the Firefox popups of the same type. Also, it could bring to the user the wrong feeling that he actually clicked on one entity (red dot in your example) instead the whole widget.

Technically speaking, I don't see any problem to implement this feature. But I'm not so sure from user experience / ui point of view.

Also, notice that this kind of behavior will be likely removed with new UI for add-ons: http://people.mozilla.com/~shorlander/files/addons-in-toolbar-i01/addons-in-toolbar.html
But it also true that I'm still not sure when these changes will be ready and landed, so maybe is worthy working on it.

Stephen, what do you think about that?
Ping Stephen, Matteo - any progress on this?
So according to what Stephen said in email:

"There are two things about our current arrow panel design that should be consistent:  1) panel arrow should be anchored to the middle of the active element; 2) the panels should be weighted towards the middle of the browser depending on which side the anchor is on."

I believe this bug is a WONTFIX then, but it's better waiting for a comment from Stephen.

Notice that currently the panel is not behaving as Stephen said, so we should fix it in any case, but not in the way described by this bug.
A panel in my described case is more like a context menu for me, which reacts on the element I have clicked on. If this bug is going to be WONTFIX and no other option in the Addon SDK is available to have such a feature implemented, I will probably have to go back and implement memchaser just with bootstrap.js and don't rely on the SDK.

I'm sure you find the right way to fix this so it matches the expectation of most of the SDK users.
(In reply to Henrik Skupin (:whimboo) from comment #8)
> A panel in my described case is more like a context menu for me, which
> reacts on the element I have clicked on. If this bug is going to be WONTFIX
> and no other option in the Addon SDK is available to have such a feature
> implemented, I will probably have to go back and implement memchaser just
> with bootstrap.js and don't rely on the SDK.

We should do our best to avoid mozillians to keep using the SDK! 
It would be really bad to see such simple addon have to use bootstrap addon for such reason. And I totally agree with Henrik that this bug has to be fixed somehow, it isn't an acceptable user experience!

I think that it is totally acceptable to center the panel to the click position by default. Eventually only on large widget (40px or more). We are planning to avoid (forbid?) large widget in to navigation toolbar. So that this new behavior won't have much impact with this upcoming work. I just see this as a fix for the current widget system until we get better option.
It is even more important to fix that soon as the new widget in navigation bar doesn't seem to be ready soon.
(In reply to Alexandre Poirot (:ochameau) from comment #9)
> We should do our best to avoid mozillians to keep using the SDK! 

I obviously meant:
 We should do our best to *ensure* mozillians to keep using the SDK! 
:o
Attached file Pull request 503 — 
Here is a potential fix for that.
I center the panel to the click position only when widget is larger than 40px (we can change that to whatever maximum size we want to limit for widget in navigation bar).
The only problem I have with this patch is that arrow panels seems to be buggy :(
Sometimes the arrow is not correctly set.

Matteo, would such fix be harmfull for future ?
Attachment #644242 - Flags: feedback?(zer0)
(In reply to Henrik Skupin (:whimboo) from comment #8)

> A panel in my described case is more like a context menu for me, which
> reacts on the element I have clicked on.

I think the difference here is that you consider what the widget have inside as separate elements, where a widget is one element (especially from UX point of view, as far as I understood). So, for instance, you shouldn't have different behavior depends by in which area of the widget you're clicking, that also why widget as one "onClick" property. A widget is considered a single entity – like a "button". This is makes more sense also in prevision of the new UI.

> If this bug is going to be WONTFIX
> and no other option in the Addon SDK is available to have such a feature
> implemented, I will probably have to go back and implement memchaser just
> with bootstrap.js and don't rely on the SDK.

I have the impression it will be a WONTFIX, but I'd like to wait the comment from Stephen. Notice also that in the new Firefox UI, Add-on like Memchaser will be displayed differently. Add-on what have huge width cannot be displayed as is, so you will have an icon with some text on the Add-on bar, that open a toolbar with all the information.

See: http://people.mozilla.com/~shorlander/files/addons-in-toolbar-i01/addons-in-toolbar.html

>> I'm sure you find the right way to fix this so it matches the expectation of
> most of the SDK users.

It's not about technical fix there, it's more about UX guidelines. Personally, I'd like to see more people using the Add-on SDK and at the same time, provide a consistent and good UI and User Experience to the users as well.

I believe that this bug will be a WONTFIX because the points above, but let's see what UX (aka, Stephen :) ) has to say, maybe he has some new ideas or some better explanation.
I'm not sure it is really important to involve Stephen in this. It is quite clear that this request doesn't make sense for these mockups, as we won't allow large widget from what I remember.
Here I would like to see current widget behavior (which allow and suggest large widgets) fixed until we manage to implement these mockups, which, obviously won't be anytime soon.
(In reply to Alexandre Poirot (:ochameau) from comment #9)

> We should do our best to avoid mozillians to keep using the SDK! 

I saw you the correction, but it's still amazing read this sentence. ;)

> It would be really bad to see such simple addon have to use bootstrap addon
> for such reason. And I totally agree with Henrik that this bug has to be
> fixed somehow, it isn't an acceptable user experience!

I agree that currently this is a bad user experience, but I also agree with Stephen that the solution is not open the panel on the click position by default.
I believe that the problem is that we don't give to the user the feedback that the widget is one entity, like a button. If we would have a visual feedback like an outline (see the new UI) that will be already better.

> I think that it is totally acceptable to center the panel to the click
> position by default.

Basically the click will follow the mouse and will "move around" the widget. I honestly agree with Stephen that this is not a really good UI.
Sure, can be "acceptable" technically speaking, but we're not talking about that here.

> Eventually only on large widget (40px or more).

It could be a trade off. I really like to have the opinion from Stephen.

> We are
> planning to avoid (forbid?) large widget in to navigation toolbar.

Exactly, that another reason this probably is a WONTFIX: adding a behavior now that we're going to remove, will makes the users and developer confused. In the new UI, you could have a widget around 64px in the Add-on bar for instance, than developers could be "tempted" do don't use it as one entity, and expect the same behavior we will introduce with this bug.

> So that
> this new behavior won't have much impact with this upcoming work.

In my opinion, it will impact, especially on expectations.

> I just see
> this as a fix for the current widget system until we get better option.

I really prefer have the opinion about it from UX before. We're going to introduce a change in UI and a new behavior that will change the user experience.

> It is even more important to fix that soon as the new widget in navigation
> bar doesn't seem to be ready soon.

As I said before, fix the current user experience doesn't means necessary "open the panel near to the click position". This is not our call, but UX ones. If UX thinks is acceptable, then we can do that. Otherwise, or we waiting for the new Add-on bar, or we find a better solution in the meanwhile.

I really don't want introduce something that is not considered a good UI and it's against the UX guidelines that UX team are writing.
(In reply to Alexandre Poirot (:ochameau) from comment #13)

> I'm not sure it is really important to involve Stephen in this.

Stephen is already involved, we exchange mail about all Add-on UIs since a while, this bug is one of them. UX is not only involved in the new mockups, but in the User Experience that Add-on SDK gives.

> It is quite
> clear that this request doesn't make sense for these mockups, as we won't
> allow large widget from what I remember.

Exactly. That's also to take in account. We don't want to introduce a behavior that we're going to not support anymore. For instance, someone could be expect it on "large" new Add-on UI button (64px) as well, after we introduce it.

> Here I would like to see current widget behavior (which allow and suggest
> large widgets) fixed

Agreed, but I don't think we should fix in that way.
(In reply to Alexandre Poirot (:ochameau) from comment #11)

> Matteo, would such fix be harmfull for future ?

I think we shouldn't apply this fix for the reason I already explained – at least, we should wait for UX.
In addition, if I saw correctly, it also add a `clientX` property in a public `show` method, that I really don't like in public API, it means that panel could be easily displayed in any `x` coord.
It's always interesting see the eternal debate between developers and designers, and I honestly like to be in the be in the middle. :) I'm pretty sure that we will find a good solution for both!
(In reply to Alexandre Poirot (:ochameau) from comment #13)
> I'm not sure it is really important to involve Stephen in this. It is quite
> clear that this request doesn't make sense for these mockups, as we won't
> allow large widget from what I remember.
> Here I would like to see current widget behavior (which allow and suggest
> large widgets) fixed until we manage to implement these mockups, which,
> obviously won't be anytime soon.

+1, although I'd really, *really* love for the mockups to be implemented sooner rather than later.
(In reply to Jeff Griffiths from comment #18)

> > Here I would like to see current widget behavior (which allow and suggest
> > large widgets) fixed until we manage to implement these mockups, which,
> > obviously won't be anytime soon.

> +1, although I'd really, *really* love for the mockups to be implemented
> sooner rather than later.

I totally agree to fix the current behavior, but I'm not sure that the way proposed in this bug is the best ones. We're introducing something that, as far as I understood is not consistent with the UI of Firefox, and a behavior we're going to remove with the new mockups. It's usually not a good thing introduce something and then remove it a bit later – we give to the developers expectations.

I prefer, as I suggest, to fix the current bad user experience with a visual feedback (outline) that we will have in the new mockups – so we're not going to remove anything, but add a bit of the whole we'll have in the near future –, that is also consistent with the Firefox UI. Right now it's not clear that the widget is a single entity for the user, than clicking in a specific area and see the panel display somewhere else it's misleading and it's definitely a bad user experience. Display an outline, like we have in the mockups, we'll solve that issue in my opinion.

But again, I'd really love to have the feedback from UX about it. As I said, we're talking here about user interface and user experience, so to me it's more a UX call than ours.
(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #19)
> I totally agree to fix the current behavior, but I'm not sure that the way
> proposed in this bug is the best ones. We're introducing something that, as
> far as I understood is not consistent with the UI of Firefox, and a behavior
> we're going to remove with the new mockups. It's usually not a good thing
> introduce something and then remove it a bit later – we give to the
> developers expectations.

Well, visually users are not able to differentiate between real xul elements or an embedded HTML content. They will recognize HTML elements as real separated elements and would assume to react accordingly, e.g. Resident Memory and GC data in MemChaser. If an element gets right clicked a context menu will open right next to the click position on the element. Lets take a toolbar button for example. Right click the backward button. Would you expect a context menu which opens in the middle of the toolbar's width? And as far as I got panels should be used in the SDK and that those will behave the same.

> area and see the panel display somewhere else it's misleading and it's
> definitely a bad user experience. Display an outline, like we have in the
> mockups, we'll solve that issue in my opinion.

Do you have a link?
(In reply to Henrik Skupin (:whimboo) from comment #20)

> > I totally agree to fix the current behavior, but I'm not sure that the way
> > proposed in this bug is the best ones. We're introducing something that, as
> > far as I understood is not consistent with the UI of Firefox, and a behavior
> > we're going to remove with the new mockups. It's usually not a good thing
> > introduce something and then remove it a bit later – we give to the
> > developers expectations.

> Well, visually users are not able to differentiate between real xul elements
> or an embedded HTML content.

I didn't say that. It's true that it doesn't really matter if the widget is made by HTML or XUL. As soon as the widget is embedded in the Firefox UI, it's just part of the UI and should be consistent with the browser's UI interface behaviors.

> They will recognize HTML elements as real
> separated elements and would assume to react accordingly, e.g. Resident
> Memory and GC data in MemChaser.

I agree, that's because there is no visual feedback that indicates that the widget is one element, and the click is related to this one element, as the panel as well: we're not talking about different panels displayed depends where the user is clicking, right? In that case it will be a sort of "context menu": in that case, I agree that the panel should be displayed near to the "context" element clicked.

> If an element gets right clicked a context
> menu will open right next to the click position on the element.

True, because it's a context menu, but the context menu is made by right click and not left click, and the content depends strictly from the single element clicked. The widget's panel is not a context menu because it doesn't depend by the element where is clicked and it is displayed on left click not right click.

I'm not talking here about technical details, but UI Heuristics ("Consistency and standards" mainly).

> Lets take a
> toolbar button for example. Right click the backward button. Would you
> expect a context menu which opens in the middle of the toolbar's width? And
> as far as I got panels should be used in the SDK and that those will behave
> the same.

The panel is not a context menu. The panel you're using in SDK is the same that Firefox displays for Password Manager, or when you click on a certificate icon in a website, or when you click to the star button. If you need a context menu then the element should be displayed on the right click and depends by the element you clicked. The panel instead is anchored to an element and displays additional information or actions for that specific element. Therefore the behavior has to be consistent.

So now I'm not sure what is your uses case: you need multiple different panels opened depends where the user has clicked?

> > area and see the panel display somewhere else it's misleading and it's
> > definitely a bad user experience. Display an outline, like we have in the
> > mockups, we'll solve that issue in my opinion.
 
> Do you have a link?

I posted before: http://people.mozilla.com/~shorlander/files/addons-in-toolbar-i01/addons-in-toolbar.html

Here is the new mockups of the widget add-on bar: the widget that displayed a panel and are clicked have the "pressed" state, that defines the "entity" area of the widget.
(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #21)
> panel as well: we're not talking about different panels displayed depends
> where the user is clicking, right? In that case it will be a sort of
> "context menu": in that case, I agree that the panel should be displayed
> near to the "context" element clicked.

Right now it's a single panel. But in the future we want to update its content to only display related information depending on the element the user has clicked on.

> True, because it's a context menu, but the context menu is made by right
> click and not left click, and the content depends strictly from the single
> element clicked. The widget's panel is not a context menu because it doesn't
> depend by the element where is clicked and it is displayed on left click not
> right click.

So a side-question, are context menus usable now with the Addon SDK? Those were kinda broken when we have tested those a while back.

> I posted before:
> http://people.mozilla.com/~shorlander/files/addons-in-toolbar-i01/addons-in-
> toolbar.html
> 
> Here is the new mockups of the widget add-on bar: the widget that displayed
> a panel and are clicked have the "pressed" state, that defines the "entity"
> area of the widget.

Ah, missed that one. Thanks again. I like what has been proposed.
(In reply to Henrik Skupin (:whimboo) from comment #22)

> > panel as well: we're not talking about different panels displayed depends
> > where the user is clicking, right? In that case it will be a sort of
> > "context menu": in that case, I agree that the panel should be displayed
> > near to the "context" element clicked.

> Right now it's a single panel. But in the future we want to update its
> content to only display related information depending on the element the
> user has clicked on.

In that case, from UI point of view, it means you have an Add-on that exposes multiple widgets, each of them has a defined area and have it's own panel. Of course, if you still need a panel and not a context-menu. If you're using the panel when instead you need a custom context menu (right click, list of commands in a context-menu UI element), then it's a different (additional) scenario.

So in the first case I think what developers needs (and I guess was already proposed somewhere), it's an Add-on SDK object that aggregates Widget objects, a sort of `WidgetContainer` or a `ComposableWidget`: you can already have the same approach now, but the user will be able to remove the single Widget or put in the middle of the widgets other Add-on's widget, and that's probably something you don't want.

If instead you need a context menu, we have to introduce, or fix the current one, a context-menu for widgets, so when the user will do a right click on a widget it will display a list of items (like the current Firefox's context menu). This context menu will be displayed near the clicked point, and like panel each widget could have it's own "context-menu".

So, both approaches are complementary actually, and depends by your uses cases probably one it's more suitable in short term than the other.

Let's say that you want the context menu approach (right click, displayed near the click coords), then it's the second solution we should implement.
Instead, if you want to keep the panel (left click, anchored to a widget, custom HTML content), then probably the first solution it's better. Even if you have one single panel at the moment that have the same commands for each widgets, you can reuse the same panel instance.

More important, both solutions are compatible with the new UI mockups, so we're introducing new features that will be useful and reused later; without broke developers expectations.

At least, that's my idea. :)

> > True, because it's a context menu, but the context menu is made by right
> > click and not left click, and the content depends strictly from the single
> > element clicked. The widget's panel is not a context menu because it doesn't
> > depend by the element where is clicked and it is displayed on left click not
> > right click.

> So a side-question, are context menus usable now with the Addon SDK?

Not for widgets; and yes, `context-menu` is the oldest jetpack module we have that definitely needs huge fixes and improvements. We already have some fixes and some bugs opened, if you're interested you can track them here:

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=whiteboard%3A[jpcontextmenu]

> Those
> were kinda broken when we have tested those a while back.

yeah, unfortunately.:/


> > Here is the new mockups of the widget add-on bar: the widget that displayed
> > a panel and are clicked have the "pressed" state, that defines the "entity"
> > area of the widget.

> Ah, missed that one. Thanks again. I like what has been proposed.

No problem, good to hear you like it! It's a big change, and like any big change some people like it some others don't. :)
(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #23)
> In that case, from UI point of view, it means you have an Add-on that
> exposes multiple widgets, each of them has a defined area and have it's own
> panel. Of course, if you still need a panel and not a context-menu. If

It's slightly off-topic now and I not want to discuss this further on this bug, but let me state one more thing. While this could work it actually doesn't work because the different widgets are not grouped and sometimes randomly arranged in the add-on bar. We have had this problem when the logger was a separate widget. So if this problem has been fixed meanwhile I'm happy to do so.

> So in the first case I think what developers needs (and I guess was already
> proposed somewhere), it's an Add-on SDK object that aggregates Widget
> objects, a sort of `WidgetContainer` or a `ComposableWidget`: you can
> already have the same approach now, but the user will be able to remove the
> single Widget or put in the middle of the widgets other Add-on's widget, and
> that's probably something you don't want.

Well, that would be fine but Firefox thinks that it can auto-arrange those widgets. As stated above that's blocking us.

> If instead you need a context menu, we have to introduce, or fix the current
> one, a context-menu for widgets, so when the user will do a right click on a
> widget it will display a list of items (like the current Firefox's context
> menu). This context menu will be displayed near the clicked point, and like
> panel each widget could have it's own "context-menu".

That would be the favored option.

> > So a side-question, are context menus usable now with the Addon SDK?
> 
> Not for widgets; and yes, `context-menu` is the oldest jetpack module we
> have that definitely needs huge fixes and improvements. We already have some
> fixes and some bugs opened, if you're interested you can track them here:
> 
> https://bugzilla.mozilla.org/buglist.
> cgi?quicksearch=whiteboard%3A[jpcontextmenu]
> 
> > Those
> > were kinda broken when we have tested those a while back.
> 
> yeah, unfortunately.:/

Means those have less priority and there is not target set to get those fixed at the moment?
(In reply to Henrik Skupin (:whimboo) from comment #24)

> It's slightly off-topic now and I not want to discuss this further on this
> bug, but let me state one more thing. While this could work it actually
> doesn't work because the different widgets are not grouped and sometimes
> randomly arranged in the add-on bar. We have had this problem when the
> logger was a separate widget. So if this problem has been fixed meanwhile
> I'm happy to do so.

Not sure about that, honestly. I believe we need to add the widget in the same container (explicitly, with a `WidgetContainer` stuff, or implicity, automatically do that when multiple widget are created for the same add-on, however I'm not sure order will be maintained) to fix that.

> Well, that would be fine but Firefox thinks that it can auto-arrange those
> widgets. As stated above that's blocking us.

I'm not sure why that's happen, maybe someone else from the team has investigated more and know some additional details. Do you have a bug and/or a way to reproduce that issue? It happens in Add-on bar or when you move the widgets in other point of the UI?

> > If instead you need a context menu, we have to introduce, or fix the current
> > one, a context-menu for widgets, so when the user will do a right click on a
> > widget it will display a list of items (like the current Firefox's context
> > menu). This context menu will be displayed near the clicked point, and like
> > panel each widget could have it's own "context-menu".

> That would be the favored option.

So, to summarize so far we have those options to solve your use case:

1. Open the panel near the click position 
2. Makes context-menu working on Widget
3. Avoid auto-arrange of Widgets from Firefox 

The first one it's probably the easiest to implement, but has some downside (both on Public API and especially on UI), and UX seems don't approve it – however, I'd love have a feedback from Stephen – and that's why I suggested that probably this bug will be marked as WONTFIX.

My guess is that the 2 will be probably the ones that takes more time. Not sure about the 3, I need to do some investigation. If we fix the number 3, it will helps you to solve your uses case, and therefore don't needs to have the number 1 implemented?

We could trying to fix the number 3 as first one, and implement the context-menu for Widget as new API later on. I know we're talking about refactoring the context-menu module, so maybe this operation could be done at that time (as I said, it's currently the oldest module we have), but I'm not aware about the priority of it.

> > https://bugzilla.mozilla.org/buglist.
> > cgi?quicksearch=whiteboard%3A[jpcontextmenu]

> > > Those
> > > were kinda broken when we have tested those a while back.

> > yeah, unfortunately.:/

> Means those have less priority and there is not target set to get those
> fixed at the moment?

Uhm, not sure I understood. The context-menu bugs has P1 priority – some of them – and we're trying to collect and fix those issues exactly because we know the context-menu needs fixes and improvements.
But that is another topic, as I said, context-menu is not designed for widgets at the moment.
(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #25)
> (In reply to Henrik Skupin (:whimboo) from comment #24)
> > Well, that would be fine but Firefox thinks that it can auto-arrange those
> > widgets. As stated above that's blocking us.
> 
> I'm not sure why that's happen, maybe someone else from the team has
> investigated more and know some additional details. Do you have a bug and/or
> a way to reproduce that issue? It happens in Add-on bar or when you move the
> widgets in other point of the UI?

This should be fixed already (see bug 685929). If not please open a new bug on it since we certainly want to get that fixed!
Comment on attachment 644242 [details]
Pull request 503

This behavior is a no go for UX, and add inconsistency in Firefox UIs. Also, with the fix for the bug 685929 the OP has a better alternative. However, I think we should definitely extends the context-menu to widgets as well.
Attachment #644242 - Flags: feedback?(zer0) → feedback-
WONTFIXing due to UX feedback.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Clearing the triage flag so this doesn't show up in the various triage lists.
Whiteboard: [triage:followup]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: