Feature Request #648

[usability] Discovery Bar

Added by Tim Place over 6 years ago. Updated about 4 years ago.

Status:ClosedStart date:2010-12-09
Priority:LowDue date:
Assignee:Tim Place% Done:

0%

Category:-Spent time:-
Target version:0.6-externals
Branch:

Description

Currently, when you change the value of the gain or mix knobs in an audio module, the value of that parameter as you change it is displayed in the top-part of the module where the module name would normally be displayed.

So what if...

when your mouse hovered over whatever various UI widgets are in your module, the @description text for the parameters/messages/etc was displayed in that area. I like this better than hints (see previous email) and I like it better than using the Clue window or another module because the text is still displayed reasonably close to where the mouse is. Some @description text is quite long, so we would probably truncate to the first sentence, which would be subject to Twitter-like limitations.

moduleHelper-mockup1.png (457 KB) Julien Rabin, 2010-12-09 11:35 am

moduleHelper-mockup2.png (465 KB) Julien Rabin, 2010-12-09 11:35 am


Related issues

Related to Modular - Feature Request #69: Hint and clue automatic setting Rejected 2009-05-27
Copied to Max - Feature Request #1479: [usability] Discovery Bar Rejected 2010-12-09

History

#1 Updated by Tim Place over 6 years ago

One thought is that we double the height of the top area of the module and make the "second line" the Discovery Bar.

#2 Updated by Julien Rabin over 6 years ago

Just a quick qnd dirty mockup of both options. cf. attached files.

#3 Updated by Trond Lossius over 6 years ago

IMHO adding space to each module for hints would be a screen-waster.

#4 Updated by Tim Place over 6 years ago

Some people also feel this way about the URL bar at the top of a web browser. Or the status bar at the bottom of a web browser. These are issues that different web browsers deal with in different ways, which we could survey.

For example, Safari lets you turn the status bar on/off while Chrome overlays it without having a designated status bar (when hovering over URLs).

I'm not convinced that it is a waste of space. It might be that we can use this space for additional functions beyond contextual assistance. Perhaps it could also be used as a standardized way for a module to display information or messages of some sort. Both Google Chrome and Firefox (with it's "Awesome Bar") have been finding ways to make the area at the top of a browser server multiple functions while still giving the appearance of simplicity.

There are obvious reasons that web browsers are not direct corollary to Jamoma modules. However, browsers do try to provide maximum information, maximum ease of use, and maximum screen real-estate optimization (with the exception of Microsoft) and have extensive development resources dedicated to these problems.

Jamoma has been designed by us, and we are experts. But most people that want to try Jamoma are not us.

Perhaps I'm conflating too many issues here, but if we had a larger bar at the top then we could potentially have more room to display metering and other info. There is currently enough room for stereo metering, but 8 channels of meters at the top of module doesn't really fit very well right now.

#5 Updated by Trond Lossius over 4 years ago

  • Status changed from New to Rejected

#6 Updated by Pascal Baltazar about 4 years ago

  • Project changed from Modular to Max
  • Status changed from Rejected to Assigned
  • Assignee set to Tim Place
  • Priority changed from High to Low
  • Target version set to 0.6-externals

wouldn't it be better to have this in Max's status bar ?
I have the impression we already discussed that...

#7 Updated by Trond Lossius about 4 years ago

  • Status changed from Assigned to Closed

The issues are being moved to GitHub issue tracker

Also available in: Atom PDF