Subscribe to RSS Feed

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 logging mousemove events?
  • Or is there any other and better solution?



What do you think?


Rss Commenti

7 Comments

  1. [...] are not entirely sure if the UI/UX is OK and so, please read this post to help [...]

    #1 Getfirebug Blog » Blog Archive » Firebug 1.12 alpha 5
  2. 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

    #2 pd
  3. 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.

    #3 Álvaro G. Vicario
  4. @Á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

    #4 Sebastian Z.
  5. Having mousemove events not checked by default would be sweet.

    #5 Skoua
  6. @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?

    #6 Honza
  7. 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?

    #7 Ann

Sorry, the comment form is closed at this time.