- Published:May 3rd, 2013
- Comments:7 Comments
- Category:Documentation, Firebug, Planet Mozilla
One of the new features introduced in Firebug 1.12 alpha 5 is a filter for DOM event logs (issue 229).
Logging of DOM events has been available in Firebug for a long time and the filter should make it more useful and effective in daily usage.
The problem is that we are unsure whether UI/UX of the filter is implemented properly.
So, if you are using this handy feature please read further and let us know what you think (leave a comment below).
Previous Implementation
See the next screenshot, it shows a menu item that represents the Log DOM events feature.
- Log Events feature can be just switched on or off.
- There is no way to pick, which events should be logged for selected node. All events for the node are logged in the Console panel.
- So, there might be a lot of logs in the Console (especially those for
mousemove
events)
New Implementation
This screenshot shows the new implementation. There is a new submenu that allows to pick what events should be actually logged.
- You can still click the top level Log Events menu to log all events just like before.
- You can also open the submenu and pick only the category of events you are interested at.
- There is a tooltip listing all events in the selected category.
- The tooltip also shows an example of how to use the feature from Firebug's command line.
Questions
- But, is the submenu with event-categories actually needed? Isn't the submenu too long and hard to use?
- Wouldn't it be simpler to keep the feature as it was before and just not log
mousemove
events? Is anyone actually interested in loggingmousemove
events? - Or is there any other and better solution?
What do you think?
7 Comments
[...] are not entirely sure if the UI/UX is OK and so, please read this post to help [...]
keep it as the new version.
for people who are whining about the menu being too long, let them use the command line option as helpfully listed in the tooltips
I haven't had the chance of testing the alpha but I hope that you don't need to open the submenu 5 times if you want to select 5 event types.
To be honest, I'm not specially fond of submenus as a GUI to choose items. Perhaps there could a link/icon somewhere that opens a good old dialogue with some good old checkboxes (and possibly an all/none one on top). There could be a visual clue somewhere to know whether a filter is applied. (Sorry for so many "somewhere", I know the key are the details.)
Whatever, even the submenu is a very welcome redesign. You're doing a great work.
@Álvaro:
> I hope that you don't need to open the submenu 5
> times if you want to select 5 event types.
Of course the menu stays open while selecting the different event types.
> Perhaps there could a link/icon somewhere that
> opens a good old dialogue with some good old
> checkboxes
That would require more clicks than the solution we have now. We generally try to avoid dialogs in favor of inline UIs.
> There could be a visual clue somewhere to know
> whether a filter is applied.
See http://code.google.com/p/fbug/issues/detail?id=5801.
> You're doing a great work.
Thanks!
Sebastian
Having mousemove events not checked by default would be sweet.
@Skoua: I like idea, but not sure how to implement the UI/UX. The sub menu doesn't allow checking/unchecking just "mousemove" events.
See the screenshot, there is only "mouse" item (event family with all mouse related events).
So, how this would work?
Might be useful to have a tri-state box for Select All to allow instant set all, clear all or select some.
Any way the sub menu can be aligned a little higher?