Magic Lantern Forum

Developing Magic Lantern => General Development => Topic started by: stevefal on January 29, 2013, 01:37:55 AM

Title: ML UI rationalization
Post by: stevefal on January 29, 2013, 01:37:55 AM
I think ML UI could be more straightforward, so here are some ideas what it could be like:

(http://i.imgur.com/e6wAdJb.gif)


Audionut edit: seems imgur might be having some issues, here's another link to the gif from OP.
(https://i.postimg.cc/ZRXyKdts/e6wAdJb.gif)
Title: Re: ML UI rationalization
Post by: vertigopix on January 29, 2013, 10:43:09 AM
Nothing to say, it's perfect !
Title: Re: ML UI rationalization
Post by: weldroid on January 29, 2013, 01:35:25 PM
I like this a lot!
Title: Re: ML UI rationalization
Post by: avalonique on January 29, 2013, 01:45:58 PM
LOVE IT!
Title: Re: ML UI rationalization
Post by: RenatoPhoto on January 29, 2013, 02:19:47 PM
Thumbs up!
Title: Re: ML UI rationalization
Post by: SDX on January 29, 2013, 02:26:29 PM
You are not the first one with the attempt to fix it. All it needs is developer who actually can do the changes.

Check out this thread (more the visual part): http://www.magiclantern.fm/forum/index.php?topic=1185.0
And this one (initially we discussed an implementation of themes, but it quickly ended up with a discussion about the usability problems and ideas to fix those): http://www.magiclantern.fm/forum/index.php?topic=1918

You are absolutely right, MLs UI has many problems and needs to be fixed. ML simply doesn't look and feel like it is made for 'non-hackers'. There are many voices here on the forum that say, that the next mayor release should have a new UI - but it is allot of work. And all the devs are already working hard on new ports (which we have many of at the moment).
Title: Re: ML UI rationalization
Post by: HD Cam Team on January 29, 2013, 02:39:50 PM
Very briefly since I'm from a cell phone:

This is a VERY important and helpful proposal to make ML easier and more intuitive to use, but please remember that the 5D Mark 2 does Not have a "Q" button.

Regards
Title: Re: ML UI rationalization
Post by: stevefal on January 29, 2013, 04:15:17 PM
Right, Q not always there..
Title: Re: ML UI rationalization
Post by: stevefal on January 29, 2013, 04:46:47 PM
Quote from: SDX on January 29, 2013, 02:26:29 PM
..it quickly ended up with a discussion about the usability problems and ideas to fix those.

All it needs is developer who actually can do the changes.
Yep, I figure it's worth a shot.
Title: Re: ML UI rationalization
Post by: stevefal on January 29, 2013, 11:11:30 PM
Some details














FocusedExample                    SET                   Q                      LR                    MENU          Main dial          D-pad V            D-pad H
tabs              (any) menu gets focus - change tab - move verticalmove verticalchange tab
menu              (any) <item action><item action><item action>tabs focusmove verticalmove verticalchange tab
picklistOverlay/Global Drawpick+exit<item action><item action>exitmove verticalmove vertical -
submenuDisplay/Advanced...<item action><item action><item action>exitmove verticalmove vertical -
documentHelp/About MLexit* - - exitscroll verticalscroll vertical -

Kinds of menu items:















Type              Example                       SET                      Q                       LR                   
choiceOverlay/Global Drawshow picklisttoggle defaultstep value
compositeOverlay/Zebrasshow submenutoggle defaulttoggle default*
nestingDisplay/Advanced...show submenu - -
numericDisplay/LV display gain - toggle defaultstep value
actionDebug/Screenshotperform action - -
informationHelp/About MLshow document - -
Title: Re: ML UI rationalization
Post by: a1ex on January 30, 2013, 12:35:55 AM
Most ideas are very good. I've already implemented the bottom bar visual change and started to change the backend to get better separation of content from presentation (e.g. to use different fonts/colors for name and value, or for dropping of colon; now these are hardcoded and a menu entry is displayed as a single string).

However, there are a few things to keep in mind:

- Button layouts differ across cameras, but there is a common subset. We tried to make a list here: https://docs.google.com/spreadsheet/ccc?key=0AgQ2MOkAZTFHdFFIcFp1d0R5TzVPTVJXOEVyUndteGc#gid=1
- All cameras have SET, MENU, PLAY, DISP/INFO and ERASE.
- Most cameras have Q, but some don't; they use some other button. It's placed either on left on right side, so it feels weird for ON/OFF toggling. Canon uses it for opening setting menus, so current usage is consistent.
- Top scrollwheel is usable on most cameras, except for 500D.
- Only some cameras have a back scrollwheel (main dial).
- Wheels are not usable at all while recording. As weird as it sounds, some users are navigating the ML menu while recording (not me). There are some other rare situations when scrollwheels don't work (exceptions, not rules).
- DISP/INFO should display help. I think this is obvious.
- ERASE should open ML menu. Alternative: swap MENU/ERASE (open Canon menu with ERASE).  Users tend to spend a lot more time in ML menu than in Canon menu.
- Navigating with only the right hand is desirable (where possible). This is why Q opens and closes submenus, and not MENU, for example.
- Having to go focus the top bar in order to scroll through tabs doesn't make sense to me. It's OK for the picture style dialog, where you select one picture style, and then tweak settings. But here it would just slow down the navigation IMO.

So, there are some usability reasons for the current key scheme:

- A very common usage pattern in ML: quickly turn on and off the things that you use. Go to submenu for advanced settings (stuff that you don't change very often).
- Scrolling with the two wheels is very fast (and consistent with Canon menu).
- Canon menu requires 3 key presses to toggle a boolean. ML requires one.
- Most items with many choices are placed in submenus, where you can use the top scrollwheel to select them quickly. The rear scrollwheel always navigates up/down.
- To change something quickly, press Q then use scrollwheel. This is the reason for the edit mode (if there's no submenu, Q + wheel is still consistent with the other things that have submenu).
- When scrollwheels don't work, arrows can serve as backup (LEFT/RIGHT keys will always do the same thing as top wheel, for example).

Some more previous work to review:
https://groups.google.com/group/ml-devel/browse_thread/thread/d1e273de2490f5e5?pli=1
https://groups.google.com/group/ml-devel/browse_thread/thread/be747d2621e7bbaf/b6107c847e1eeaac

Quote
When you know ML (and anyone
will in a short time), it's quickest to reach settings with both
wheels and then cycling through the values with SET, you don't have to
take your thumb off the back dial and don't need to use the horrible
joystick buttons. If there are many values, you can use PLAY to cycle
the other way around. The submenus are very nice, esp. on related
settings like the bitrate menu, but shouldn't replace the good ol'
ways(tm) :-)

Quote
Reserve Set to only turn features on/off from the main menus.
Reserve Q button for opening/closing submenus (is there any scope for nested submenus?, maybe Play should be used to exit submenus in this case).
All options for a feature moved into the sub menu, where they are adjusted with L/R cursor (or enabled/disabled with Set).
Trash should exit all ML menus with a single click.

Overall, I like the graphical tweaks and the idea of incremental changes, but I don't think it's a good idea to break the old habits. Also we should not rely on scrollwheels - they are nice for making things faster, but there should be a backup method (plain arrow keys).

P.S. you can already try the menu without icons, and with ON/OFF labels grayed out, and with movie features grayed out in photo mode etc, with this patch (http://a1ex.magiclantern.fm/bleeding-edge/newmenu.patch). It's very rough, this change requires major rewriting of the menu backend.
Title: Re: ML UI rationalization
Post by: stevefal on January 30, 2013, 02:47:16 AM
Thanks. I think having Q is dependable going forward, and ML can use it any way it wants. The idea with focus on tabs is that it solves other things. Joystick could also change tabs all the time. It could be like this:
















Type                SET                   Q                      (depends)             LR                   
choiceshow pickliststep valuetoggle defaultchange tab
compositeshow submenutoggle default*toggle defaultchange tab
nestingshow submenu - - change tab
numeric - step valuetoggle defaultchange tab
actionperform action - - change tab
informationshow document - - change tab

QuoteI don't think it's a good idea to break the old habits.
I think breaking old habits is ok if the new habits improve things.
Title: Re: ML UI rationalization
Post by: stevefal on January 30, 2013, 03:03:06 AM
How it is now:


















Type                     Example                           SET                     Q                        LR                   
choice (var A)Overlay/Global Drawstep value - change tab
choice (var B)Display/LV brightnessedit modeedit modechange tab
compositeOverlay/Zebrastoggle defaultshow submenuchange tab
nestingDisplay/Advanced...show submenushow submenuchange tab
numericDisplay/LV display gainedit modeedit modechange tab
actionDebug/Screenshotperform actionedit modechange tab
informationHelp/About MLshow documentedit modechange tab
Title: Re: ML UI rationalization
Post by: HD Cam Team on January 30, 2013, 09:52:23 AM
(Again briefly from a cellphone, sorry if| missed something):

. IMO the more similar behavior (as much as possible) between Canon menu and ML menu, the much better for intuitive experience, especially helpful for new or not master ML users

. It's necessary to give alternative to Q button and rear wheel (etc.) that Some Cameras don't have (like I said 5D2 doesn't have Q button)

. Something like "My Favorites" tab /menu (like Canon's) would be extremely useful (if possible and yet not implemented). I know this would require work. Just an idea To have all the featunes you use most in one single Tab.

Regards
Title: Re: ML UI rationalization
Post by: ORyan on January 30, 2013, 11:30:43 AM
QuoteI don't think it's a good idea to break the old habits.

I would have to disagree with this as well. Like Steve said it's not a great idea to do this needlessly or gratuitously, but any change for the better will eventually be accepted and will only serve the betterment of the tool.

Case and point: Blender (the cg app)
The interface is notoriously horrid. It breaks all conventions and native interaction models. Which in itself is a big UI/UX no-no.   This causes the learning curve to be very steep and hard on new users. It also causes old users to be vehemently anti anything new even if it makes things easier int he long run. It's almost become a point of pride in the Blender community that you survived the learning curve. Even if that means that in Blender an action may take 3-5 steps when in another program it may take one. Blender is an immensely powerful tool, and it's free. However, it goes largely unused and overlooked because it's interface is so foreign and hard to use. It's a shame really. The bigger shame is that the developers have taken on this idea that they can't change things now. That it's too late and would upset too many users. That breaking old habits, even if it means many more would adopt the software and support it, is not a good idea.

Facebook is a great example of what to do. They redesign and come up with what they consider a better experience (and in many cases it is more immersive and addicting, which serves them more than you) and people flip out and cause a huge stink... and a week later no one even remembers.

Change is hard, but if it's for the better people will support it.

Now finding the development bandwidth to implement those changes... that's a different story.
Title: Re: ML UI rationalization
Post by: scrax on January 30, 2013, 04:10:42 PM
Agree that SET button have too many use, me too don't understand in full why some item use set to scroll values and other go in edit mode to change them, probably number of value?

Info menu can be considered an action like screenshoot IMHO

I'll suggest that SET should not go in edit mode, also we have a consistent Q alternative for camera without it. PLAY for going into edit mode.
This an idea











Type                     Example                           SET                     PLAY                        LR                    DISP/INFO         MENU         
var A, var B & numericOverlay/Global Draw etcstep valueedit modechange tabcontextual helpHide thing mode
compositeOverlay/Zebrastoggle defaultshow submenuchange tabcontextual helpHide thing mode
nestingDisplay/Advanced...show submenushow submenuchange tabcontextual helpHide thing mode
actionDebug/Screenshotperform actionedit modechange tabcontextual helpHide thing mode
Title: Re: ML UI rationalization
Post by: a1ex on January 30, 2013, 04:14:14 PM
Instead of edit mode, you can just show a pickbox for items that have more than two choices. That can be seen as a mini submenu.

The discoverability issue is already addressed by placing button hints in the selection bar.
Title: Re: ML UI rationalization
Post by: stevefal on January 30, 2013, 04:46:59 PM
QuoteInstead of edit mode, you can just show a pickbox for items that have more than two choices.
I agree. I think it should show for two choices too, because I don't know there are only two, and I think opening is what people expect from Canon. Also you can have help text for each.
Title: Re: ML UI rationalization
Post by: a1ex on January 30, 2013, 05:00:54 PM
I don't expect SET to open things, I expect SET to do the most commonly used action.

Think at zebras. In normal usage, you just want to turn them on or off. The most obvious choice for this is SET.

When you configure the parameters, you don't do this all the time. Once you are happy with those settings, you can forget about them.

So, why not optimize for the most commonly used scenario?
Title: Re: ML UI rationalization
Post by: stevefal on January 30, 2013, 06:05:31 PM
QuoteSo, why not optimize for the most commonly used scenario?
I think it's best to optimize for both.
Title: Re: ML UI rationalization
Post by: stevefal on January 30, 2013, 11:52:12 PM
Quote from: HD Cam Team on January 30, 2013, 09:52:23 AM
It's necessary to give alternative to Q button and rear wheel (etc.) that Some Cameras don't have (like I said 5D2 doesn't have Q button)
Right: http://wiki.magiclantern.fm/userguide#the_q_button
Title: Re: ML UI rationalization
Post by: stevefal on January 31, 2013, 12:22:14 AM
Quote from: scrax on January 30, 2013, 04:10:42 PM
Info menu can be considered an action like screenshoot IMHO
True but you have to exit it too.

Title: Re: ML UI rationalization
Post by: stevefal on February 01, 2013, 07:44:17 AM
Better demos:
(http://i.imgur.com/WsU4YYE.gif)5DMKIII
(http://i.imgur.com/vipYsOJ.gif)600D
Title: Re: ML UI rationalization
Post by: a1ex on February 01, 2013, 08:53:05 AM
Nice design for pickbox, I like it. Should it also be used for numeric toggles? (e.g. audio gain, ISO)

Please show a mockup of navigating zebras (or focus peaking, or histogram). I'm still convinced that, for this kind of items, the submenu is not the canonical path (under normal usage you just turn them on and off). This is more of a right-click (context) menu.

Usability: prompting the user with so many tuning parameters when he just wants to turn it on/off is not a good idea IMO.
Title: Re: ML UI rationalization
Post by: g3gg0 on February 01, 2013, 09:42:10 AM
one hint from my side:
please, please do not take canon user interface as reference.
there are so many different keys a user has to press.

for entering submenu a, you have to press SET, for the next you have to press INFO..
the next submenu is opened with M.Fn. some values are changed with wheel, for the next you need cursors.
it is so inconsistent, so i would not take it as reference :)
Title: Re: ML UI rationalization
Post by: scrax on February 01, 2013, 01:25:48 PM
Like the submenu a lot, but not all can be made half screen width, most of them needs 700px

About Global draw, I think that on off is good, but for other thing like MLU for example for me is worst to go in a submenu, change which type of MLU and then back to the main menu to enable it.
Having the three option as ON states plus a OFF state for me would be better in that case.
So I can toggle quickly without open submenu from MLU for selftimer to MLU handheld.
Same thing I did for Custom modes, you have 6 state 0 is off other are Cmode options, so user can choose the one he want right from the main menu without the need to go in the submenu.

The icon for the button was not bad, maybe instead of square bracket a rounded square is nicer.

I was thinking about having LR arrow always for changing values and edit mode only for changing tabs, which problems could give that? We don't have enough buttons?

For what I can see item with just an option in submenu could be made like a list of thing selectable from main menu like it is for global draw instead of an on/off only in main menu and the options in submenu, they could be in submenu too.

Play button like it's used now seems a bit useless, since Q or SET do the same things and we lost the button for less value, not?

Is possible (even by self compiling) to disable the warning for hidden menu?

Maybe we could add an option to don't show the hidden warning and one to don't show the two line text so to give more space for menu items to advanced users.

Also I didn't understand well, from what I remember from the mailing list, why we don't use canon font in the code for the menu? It seems more readable and bigger too (that will help readability and with scrollable menu isn't a problem).

So far I have max 7-8 items for menu shown and a couple totally hidden (help and debug), Pref has only one item shown and Display a few, all other things are setting that I set once and then hide like Overlay thing, to change the state I use LV display presets.

With a working setup like this having font like canon size will be perfect for my use
Title: Re: ML UI rationalization
Post by: SDX on February 01, 2013, 01:50:54 PM
Quote from: scrax on February 01, 2013, 01:25:48 PM
[..] having the three option as ON states plus a OFF state for me would be better in that case.
I fully support that one.
In general I really like the stuff people come up with there. But I still have a little question regarding these dropdown menus or what you would call them (as presented in post #22): When I choose eg. the MLU mode, how do I change the parameters related to this (delays and such). Would that be another menu (as it is right now)? If so, I don't think having two menus would be a good solution, since the ON-mode1/ON-mode2/ON-mode3/OFF parameter already is the first entry in the submenu and therefore selected by default. Or did I get something wrong?

EDIT: scrax just edited and added kinda lot of stuff to his post which basically covers my stuff.
Title: Re: ML UI rationalization
Post by: scrax on February 01, 2013, 02:07:54 PM
Quote from: SDX on February 01, 2013, 01:50:54 PM
I fully support that one.
In general I really like the stuff people come up with there. But I still have a little question regarding these dropdown menus or what you would call them (as presented in post #22): When I choose eg. the MLU mode, how do I change the parameters related to this (delays and such). Would that be another menu (as it is right now)? If so, I don't think having two menus would be a good solution, since the ON-mode1/ON-mode2/ON-mode3/OFF parameter already is the first entry in the submenu and therefore selected by default. Or did I get something wrong?
I think that we should have the submenu/sublist like it is now. But from the main menu when we select MLU we should be able to change it not only to ON/OFF but also to the first three item in the submenu.
We will still be able to enter the submenu and use it like now, but from Shoot menu we should have the option that toggle from OFF/(Always) ON/SelfTimer/Handheld. Other things in MLU submenu are probably set once and then forget so you will have not a lot of necessity to open the submenu if you could change the MLU mode from main Shoot menu.
Title: Re: ML UI rationalization
Post by: scrax on February 01, 2013, 02:18:31 PM
Quote from: scrax on February 01, 2013, 01:25:48 PM
Like the submenu a lot, but not all can be made half screen width, most of them needs 700px
Didn't get at first that it was not a submenu new layout, opss, sorry.

Now that I got how it works I don't like it anymore, because I hate when canon want me to press SET to confirm a choice like windows, are you sure? no thanks.
I'm so happy to have learn a way to override standard dialog with Q dialogs that don't need set to confirm selections, so please remove the set confirmation from the mockup... can't see it :D

I think that it will be good enough if Q press (or whatever) show/hide it and SET toggle items on it even when not shown so like it's now.
Title: Re: ML UI rationalization
Post by: scrax on February 01, 2013, 02:21:00 PM
Quote from: a1ex on February 01, 2013, 08:53:05 AM
Nice design for pickbox, I like it. Should it also be used for numeric toggles? (e.g. audio gain, ISO)

The numeric toggle could be something like on android/iphone where numbers move up down and selector stay fixed, just an idea/question
Title: Re: ML UI rationalization
Post by: Greg on February 01, 2013, 02:35:32 PM
Quote from: scrax on February 01, 2013, 01:25:48 PM
Like the submenu a lot, but not all can be made half screen width, most of them needs 700px

Yes, we need a width of 700px
Title: Re: ML UI rationalization
Post by: a1ex on February 01, 2013, 02:35:45 PM
Heh... while you were talking here, I went ahead and implemented the pickbox (and also the MLU suggestion). It's on the repo, give it a try (maybe post some screenshots too).
Title: Re: ML UI rationalization
Post by: scrax on February 01, 2013, 02:40:44 PM
Quote from: a1ex on February 01, 2013, 02:35:45 PM
Heh... while you were talking here, I went ahead and implemented the pickbox (and also the MLU suggestion). It's on the repo, give it a try (maybe post some screenshots too).
Updating repo now, did 5 min ago and there was still nothing new ;D
BTW, solved problem with dialog icon double buffering, but need help with adding icon to ico.c can I post them to let you add them?
Title: Re: ML UI rationalization
Post by: scrax on February 01, 2013, 02:42:18 PM
wait....

before updating source will check if you implemented also the SET confirmation  ;D ;D

EDIT: tried, and some items show ON/OFF only, some nothing some more thing, some have also q submenu so they are two now, don't know if is habit or what but before to me seems more quick to change values.
Title: Re: ML UI rationalization
Post by: 1% on February 01, 2013, 04:35:40 PM
have a screenhot?

/scared to try it

will we have to redo all menus?
Title: Re: ML UI rationalization
Post by: a1ex on February 01, 2013, 05:03:59 PM
If we want to remove the colon or use proportional fonts, we will have to rewrite all display functions (split name and value in two separate strings, and let menu.c do all the drawing where possible). There's a sketch of this in my first patch from this thread.

For now, it works on the existing menu structures. The pickbox is fully passive (just a display thing) and it looks at the choices array. Comment out the pickbox call, and you are in the old edit mode.
Title: Re: ML UI rationalization
Post by: stevefal on February 01, 2013, 05:54:12 PM
Quote from: a1ex on February 01, 2013, 08:53:05 AM
.. pickbox... Should it also be used for numeric toggles? (e.g. audio gain, ISO)
A spinner would be better.

QuoteI'm still convinced that, for this kind of items, the submenu is not the canonical path..
I think that's old habits. A better new habit would be SET opens openable things and Q toggles toggleable things.

Quoteprompting the user with so many tuning parameters when he just wants to turn it on/off is not a good idea IMO.
I agree. Q can do that. It would work for GD too, which doesn't have it now.
Title: Re: ML UI rationalization
Post by: 1% on February 01, 2013, 06:03:34 PM
set opens the pick box, q opens the pick box but play actuates the value on some menus. can set/play work the old way and q just open pick box or submenu? hitting q again should hide the pick box or sub menu.

right now it doesn't feel consistent to me.

Definitely do NOT make q just toggle stuff on/off
Title: Re: ML UI rationalization
Post by: stevefal on February 01, 2013, 06:06:04 PM
Quote from: g3gg0 on February 01, 2013, 09:42:10 AM
... please do not take canon user interface as reference. there are so many different keys a user has to press...
It think Canon's best ideas should be a reference.
Title: Re: ML UI rationalization
Post by: 1% on February 01, 2013, 06:11:08 PM
Honest truth: I don't care if newbies get confused. i care about fewest click to activate the function so i can use it to take whatever image i have to in the time it is available.

scenes don't come back when i have to click 2 or 3 times to access something. if you miss it its gone vs a new user having to read a little bit to understand what they're doing.
Title: Re: ML UI rationalization
Post by: stevefal on February 01, 2013, 06:14:47 PM
Exactly - fewest clicks.
Title: Re: ML UI rationalization
Post by: 1% on February 01, 2013, 06:21:35 PM
something like bitrate with many numerical choices. no way to use the scroll wheel on pickbox and for cameras that have only 1 wheel it even worse.
Title: Re: ML UI rationalization
Post by: stevefal on February 01, 2013, 06:22:30 PM
Quote from: scrax on February 01, 2013, 02:07:54 PM
we should be able to change it not only to ON/OFF but also to the first three item in the submenu.
We will still be able to enter the submenu and use it like now, but from Shoot menu we should have the option that toggle from OFF/(Always) ON/SelfTimer/Handheld.
I think those submenus could use ON/OFF item, like Global Draw as the master switch for Overlay.
Title: Re: ML UI rationalization
Post by: stevefal on February 01, 2013, 06:29:12 PM
I think scroll wheel can work for pickbox.
Title: Re: ML UI rationalization
Post by: a1ex on February 01, 2013, 10:11:02 PM
What about:

- SET/PLAY: increment/decrement (like in the good old days)
- Q: show submenu / pickbox / edit mode (whichever of those makes sense for current item)

You can try this key scheme right now on the repo.
Title: Re: ML UI rationalization
Post by: stevefal on February 01, 2013, 11:57:51 PM
More ideas:
(http://i.imgur.com/vGKOA6A.gif)
Title: Re: ML UI rationalization
Post by: 1% on February 02, 2013, 12:31:18 AM
Ok, just pulled commits... trying.


QuoteThis is analogous to Global Draw, which serves as the "master switch" for everything on the Overlay menu.

not quite, this makes sense for global draw but not for everything. global draw isn't meant so much as a master switch but to tell whether to draw all graphics or not. including shutter/aperture, etc
Title: Re: ML UI rationalization
Post by: stevefal on February 02, 2013, 12:36:52 AM
Got it.. so there are others beyond Overlay
Title: Re: ML UI rationalization
Post by: 1% on February 02, 2013, 12:50:23 AM
yea, shutter, aperture etc.

new commits are good. sometimes it glitches when graying out items. might be from dma copy, i will see. not everything needs autoiso off.
Title: Re: ML UI rationalization
Post by: stevefal on February 02, 2013, 12:52:18 AM
600D:
(http://i.imgur.com/wJZ9q0T.gif)
Title: Re: ML UI rationalization
Post by: 1% on February 02, 2013, 12:56:06 AM
other cams have arrow keys + wheel. I think both the wheel and keys have to work it, they do right now. i like the graying of things not working in whatever mode. just have to make sure the reasons are right so we don't really disable a feature that will actually work.
Title: Re: ML UI rationalization
Post by: stevefal on February 02, 2013, 07:52:31 AM
Quote from: 1% on February 02, 2013, 12:56:06 AM
other cams have arrow keys + wheel. I think both the wheel and keys have to work...
Missed that. Fixed, thx.
Title: Re: ML UI rationalization
Post by: a1ex on February 02, 2013, 09:35:17 AM
Quote from: 1% on February 02, 2013, 12:50:23 AM
sometimes it glitches when graying out items. might be from dma copy

Using uncacheable BMP VRAM (see bmp_vram()) will fix that (but it will draw slower, so probably negates the dma copy advantage). Worth running some benchmarks.

Quotenot everything needs autoiso off.
I've counted 3 things, and I'm sure I've missed some.

I'm thinking to add a callback to check dependencies, instead the MNI_WARNING icon hack.

Quotei like the graying of things not working in whatever mode. just have to make sure the reasons are right so we don't really disable a feature that will actually work.

Sure, that's why I've introduced 2 levels of warnings: first will gray out the feature (meaning it won't work at all), and the second will just display some advice (e.g. intervalometer works best in photo mode... but if you want to enable it in movie mode, it will still work; but for bulb ramping, you really need to go to photo mode => intervalometer is not grayed out, but ramping is).
Title: Re: ML UI rationalization
Post by: wolf on February 02, 2013, 12:29:55 PM
@stevefal I like the design of your submenu. It looks cleaner and doesn't change size depending on the entries.
In my opinion fast and easy editing of features should have priority.
Title: Re: ML UI rationalization
Post by: a1ex on February 02, 2013, 02:41:48 PM
If we go for full-screen submenu, it may not be obvious that submenu items are using a different keybinding (left-right: toggle values).

More stuff on the repo: icons removed, ON/OFF labels dimmed, colon erased (really dirty implementation, but it's just enough to try the concept without breaking the entire codebase).

In menu.c, define CONFIG_MENU_ICONS and undefine CONFIG_MENU_DIM_HACKS to go back to the old style (icons, colons and no dimming).

To me, it starts to look more and more like an old DOS program :D
Title: Re: ML UI rationalization
Post by: SDX on February 02, 2013, 03:44:38 PM
I just tested the latest stuff by Alex and noticed something about the now missing icons:


This only applies to the Icons of course. Otherwise I love the stuff discussed here!
Title: Re: ML UI rationalization
Post by: SDX on February 02, 2013, 03:57:52 PM
Okay, a bit more constructive.
Together with A1ex we tested a few ways to solve this. You see three screenshots, whereas the first one is the discussed one, without icons and grayed entries. The second one, my favourite with only grayed entries. The last one is pretty much the original.

(http://i.imgur.com/30I648P.png)
Title: Re: ML UI rationalization
Post by: nanomad on February 02, 2013, 04:13:55 PM
I rely a lot on visual feedback and the second one looks the best to me
Title: Re: ML UI rationalization
Post by: stevefal on February 02, 2013, 04:19:32 PM
I think main and submenus should look and work the same, as much as possible.
Title: Re: ML UI rationalization
Post by: screamer on February 02, 2013, 04:48:35 PM
the second one is my favorite
Title: Re: ML UI rationalization
Post by: stevefal on February 02, 2013, 05:11:42 PM
I think folks will get used to more emptiness. I like it.
Title: Re: ML UI rationalization
Post by: stevefal on February 02, 2013, 05:46:56 PM
What do people really get out of the icons?
Title: Re: ML UI rationalization
Post by: stevefal on February 02, 2013, 05:48:04 PM
Quote from: screamer on February 02, 2013, 04:48:35 PM
the second one is my favorite
interested in why..
Title: Re: ML UI rationalization
Post by: 1% on February 02, 2013, 05:54:22 PM
Well its not compiling yet, probably cause a1ex isn't done.

getting rid of the reverse toggles might drop binary size some but now i have to rewrite the 600D build and its bitrate.c and hope the pulls don't eat a bunch of functions.
Title: Re: ML UI rationalization
Post by: a1ex on February 02, 2013, 06:02:29 PM
It's quite easy to rewrite the reverse toggle: if (delta < 0) call the reverse func. I did that in audio.c.

What error are you getting? Here it compiles fine on all cameras from nightly repo, with the default feature set.

Title: Re: ML UI rationalization
Post by: 1% on February 02, 2013, 06:24:34 PM
I have to upgrade gcc, found it in an earlier commit.

*I'll go by what you did on how to fix it but still a pita... oh well its for the best. kinda itching to know how much if any size got saved.
Title: Re: ML UI rationalization
Post by: nanomad on February 02, 2013, 06:26:22 PM
Looks like it's time to upgrade the default settings to GCC 4.7 at least. I'll get cracking on a version check
Title: Re: ML UI rationalization
Post by: nanomad on February 02, 2013, 06:36:39 PM
Quote from: stevefal on February 02, 2013, 05:46:56 PM
Everyone relies on visual feedback! Can you please describe, in priority order, any specific elements of information that you rely on from the icons?

The most important (to me) is the ON/OFF/DISABLED status. But also the "volume icon" (not the correct name, but I hope you get the idea) to quickly tell how far a value is from the starting one
Title: Re: ML UI rationalization
Post by: screamer on February 02, 2013, 07:12:57 PM
Agree with nanomad, the left icons for me are useful because you have an immediate feedback about the generic status of a function (green or red dot ecc). And really the space that icons use is not so much
Title: Re: ML UI rationalization
Post by: 1% on February 02, 2013, 07:19:59 PM
well 600D audio is broken now. the values jump aroun. ie internal mic is gray. 12db is last and gray on analog gain.

6d crashes from beep.c task on memor.c... maybe from shoot_malloc small or dma copy... i dunno but both worked yesterday. playback also crashes from the same thing and sometimes the menu.

its not from dma, I took it out and still dies;

ASSERT: 0
at ./Memory/Memory.c:568, task write_q_task
lv:0 mode:7


bug is confirmed to be from smallaloc... took it out and still get an error, shit

compiled a smaller binary an so far no crash... wtf, was only like 450k
Title: Re: ML UI rationalization
Post by: a1ex on February 02, 2013, 08:00:56 PM
Graying is not exact, ignore it for now. Whenever a value is zero, the menu code thinks it's off and grays it. Disable CONFIG_MENU_DIM_HACKS and should be OK.

The change for analog gain looks alright, should toggle exactly the same as before:

static void analog_gain_toggle( void * priv, int delta )
{
-    menu_numeric_toggle(priv, 1, 0, 7);
-    audio_ic_set_analog_gain();
-}
-static void analog_gain_toggle_reverse( void * priv, int delta )
-{

-    menu_numeric_toggle(priv, -1, 0, 7);
+    menu_numeric_toggle(priv, delta, 0, 7);
     audio_ic_set_analog_gain();
}


Can you show a screenshot with what's wrong?
Title: Re: ML UI rationalization
Post by: stevefal on February 02, 2013, 08:08:47 PM
Quotehe most important (to me) is the ON/OFF/DISABLED status
I'll give the left side icons a go..
Title: Re: ML UI rationalization
Post by: 1% on February 02, 2013, 08:14:39 PM
that is supposed to be -12 db

(http://i.imgur.com/jqRHEQd.png) (http://imgur.com/jqRHEQd)

also screen shot now says 0s
Title: Re: ML UI rationalization
Post by: a1ex on February 02, 2013, 08:18:57 PM
The menus are not aligned, the ":" should stay on the same column for all items. This is what's causing the bug.

The ":" is now erased the hard way, and its position is hardcoded. To implement it cleanly, I need to rewrite all the display functions.

Disable CONFIG_MENU_DIM_HACKS and should be OK.
Title: Re: ML UI rationalization
Post by: 1% on February 02, 2013, 08:31:03 PM
ok, works without the dim hacks.

still says off db tho.
Title: Re: ML UI rationalization
Post by: stevefal on February 02, 2013, 08:39:27 PM
I think edit mode should be clearer to see
Title: Re: ML UI rationalization
Post by: stevefal on February 03, 2013, 04:49:40 AM
.. maybe like this
(http://i.imgur.com/32N7GB7.gif)
5DMKIII
(http://i.imgur.com/WDP6WEv.gif)
600D
Title: Re: ML UI rationalization
Post by: Greg on February 03, 2013, 08:21:09 PM
An interesting idea from the submenu.
Title: Re: ML UI rationalization
Post by: a1ex on February 04, 2013, 12:11:06 PM
The backend now has much better separation of content from presentation, so the new design should be straightforward to implement.

Selection bar tweaks were implemented, and it looks quite nice now.

Now, think about the so-called canonical path for enabling zebras:
- Now: scroll to Zebras, press SET.
- New approach: scroll to Zebras, SET, SET, MENU.

For enabling zebras, focus peaking and histogram:
- Now: scroll to zebras, SET, scroll down, SET, scroll down, SET.
- New approach: scroll to zebras, SET, SET, MENU, scroll down, SET, SET, MENU, scroll down, SET, SET, MENU. Whew!

Seriously, why is this an improvement?

Yes, you can press Q, but this is not the obvious choice for on/off. When acting quickly, the first impulse is to press SET. The submenus were designed for things that you don't access very often (i.e. set and forget things).

Also, on most cameras, you need to use both hands for new keybindings. The one-handed navigation advantage of the current approach was pretty much ignored so far.
Title: Re: ML UI rationalization
Post by: screamer on February 04, 2013, 12:28:37 PM
Agree with Alex about all. I love the improvements in usability in the graphical design, but agree about set & q (more usable with the old behaviour) and also agree about the onehanded approach (more fast and useful).
Title: Re: ML UI rationalization
Post by: wolf on February 04, 2013, 01:49:00 PM
First, thanks to the dev department that put so much effort into the gui.  :)
I like this new look very much.
(http://i.imgur.com/gOd5YM2.png?1)

I have to admit, that I like the submenu style more the way stevefal suggested it. I'm not afraid of getting lost in the submenu when there is no window and think there is too much information which is not needed displayed.  If you exit the submenu you are in the main menu again after pressing trashcan. I mean it's not possible to enter the ML menu inside a submenu.
(http://i.imgur.com/0EL33x3.png?1) (http://i.imgur.com/cKtmfwz.png?1)

BTW. It's great that it's possible to hide items in the submenu.
Title: Re: ML UI rationalization
Post by: stevefal on February 04, 2013, 04:23:10 PM
I still think flipping SET and Q would be better. It solves a lot of other problems.
Title: Re: ML UI rationalization
Post by: 1% on February 04, 2013, 04:29:45 PM
QuoteThere is utterly no discernible indication that it should be expected to do that. People are confusing being fastest with being obvious.

current is good, menu is on the other side for me too and 6D has a limited number of buttons that can be assigned, I suspect I'm not the only one with this problem. the icons are consistent and easier to implement. Just have to re do my bitrate menus for 600D builds an a few odds and ends like advanced bracketing, mem browser, property browser , etc.

QuoteCanon users will not expect SET to toggle things.

how so? its the way to toggle things from the canon menu. q is only on the quick screens (and you press set too to select). dead otherwise.
Title: Re: ML UI rationalization
Post by: nanomad on February 04, 2013, 04:40:05 PM
Using the menu key for menu navigation is a big No-no for me too. That's the only thing canon engineers never realized (one handed operation). Now  it's so close to the eye sensor the screen simply turns off when using the right hand to access the menu ... :/
It's probably the only thing they did right on the 1100D...

Actually, I'll probably code a swap menu/play feature on the 650D ... it's too annoying


About menu operations, I suggest we do an A/B test (old navigation vs new navigation, two user sets comprised of new and old ML users). Who's with me?
Title: Re: ML UI rationalization
Post by: SDX on February 04, 2013, 05:27:58 PM
Good idea, but I don't think that we should do "old vs new". Since we all know, that the old one is rubbish, we should rather do a "new1 vs new2".
Also, I absolutely agree on, that the thing with the menu button isn't such a great idea. Usually, I would assume that I can leave the submenu with the same button as I entered it with. And having to use two hand is annoying as well.
Title: Re: ML UI rationalization
Post by: stevefal on February 04, 2013, 05:44:22 PM
This wouldn't work with 3 levels
Title: Re: ML UI rationalization
Post by: 1% on February 04, 2013, 07:17:25 PM
we don't have a 3rd level.
Title: Re: ML UI rationalization
Post by: screamer on February 04, 2013, 07:28:53 PM
So, no 3rd level, no need to use the "menu" button (really not the best in fast operations).
And about the set and the q, it's not only a habit matter, the canon menu (as 1% observed) use set for toggling things and q only for quick menu. Anyway i suggest to implement something similar to the menu -> erase swap in the properties, that one used to swap between canon menu and ML activation. We can use someting similar in the preferences for Q and SET buttons, so who wants to use set for toggle can do it, and who prefer q can do it too
Title: Re: ML UI rationalization
Post by: a1ex on February 04, 2013, 07:34:38 PM
Right, no 3rd level. Rationale: see the links I've posted at the beginning of the thread.

My Menu is working :D

(http://a1ex.magiclantern.fm/bleeding-edge/mymenu.png)
Title: R: ML UI rationalization
Post by: nanomad on February 04, 2013, 07:45:04 PM
Now we need a "Set menu as default" and we are set (to open the preferred menu or the last one used)
Title: Re: ML UI rationalization
Post by: 1% on February 04, 2013, 08:16:03 PM
It was easier hiding menus the old way.
Title: Re: ML UI rationalization
Post by: a1ex on February 04, 2013, 08:21:58 PM
Right, that's why so many people were hiding things by mistake :D

(and customizing menu is more like "set and forget", no?)
Title: Re: ML UI rationalization
Post by: 0xAF on February 04, 2013, 08:25:51 PM
Quote from: a1ex on February 04, 2013, 08:21:58 PM
Right, that's why so many people were hiding things by mistake :D

(and customizing menu is more like "set and forget", no?)

count me in, when i first took ML in my hands (i think it were when Alex handed it to me), i clicked here and there ...
then later when i was @home, i was wondering where the heck is that thing that i saw before ...
took me some minutes to find out that i can hide/show stuff from the menu...

i think it should be harder to do that, not as easy as it was with me ;)
Title: Re: ML UI rationalization
Post by: screamer on February 04, 2013, 08:38:06 PM
Had problems with hiding menus only the first time i used it, but really was a "half useful" thing. Probably i prefer the idea of "my menu" instead. Agree with Alex, it's more "set and forget" and i like a lot the idea
Title: Re: ML UI rationalization
Post by: stevefal on February 04, 2013, 09:40:13 PM
Improved..
(http://i.imgur.com/NrB1Cb9.gif)


Title: Re: ML UI rationalization
Post by: stevefal on February 04, 2013, 10:13:54 PM
I think 3rd levels should be possible.
Title: Re: ML UI rationalization
Post by: wolf on February 05, 2013, 12:25:02 AM
I think that the "one handed operation" is the best way to work with ML.

What if the trashcan button only exits the current menu to the level above and from the top level it exits?
So from a submenu it's needed to press the trashcan button two times or press half shutter to exit.
When I shoot, I mostly use half shutter to exit ML because it's the most simple way for me.
Title: Re: ML UI rationalization
Post by: 1% on February 05, 2013, 12:47:25 AM
the hiding is useful for the help tab.

Title: Re: ML UI rationalization
Post by: stevefal on February 05, 2013, 01:40:37 AM
EOS-M version
(http://i.imgur.com/xxaPuBV.gif)
Title: Re: ML UI rationalization
Post by: Jolly Roger on February 05, 2013, 01:51:54 AM
Quote from: wolf on February 05, 2013, 12:25:02 AM
What if the trashcan button only exits the current menu to the level above and from the top level it exits?

I second that, I've had exactly the same tought.
Title: Re: ML UI rationalization
Post by: stevefal on February 05, 2013, 02:23:02 AM
I think that makes sense
Title: Re: ML UI rationalization
Post by: 1% on February 05, 2013, 03:18:41 AM
Heh, full screen submenu looks good but some things should have small submenu. now you could actually have a 3rd level, like a small submenu within the fS one, lol

I notice when I select a setting over LV I can't move down to the next one anymore.
Title: Re: ML UI rationalization
Post by: sutobe on February 05, 2013, 09:32:06 AM
There's two things I noticed with today's Nightly build:

1. Outside Liveview in Overlay menu.
Histogram is green but maybe should be orange since it's also only working in LV

(http://i49.tinypic.com/108g5kl.jpg)


2. There's no info which of 4 possible Overlay Layouts is selected, making it difficult to configure them (usually shown right next to the "Global Draw" option)

(http://i47.tinypic.com/es7x4y.jpg)



I like the idea of secondary menues being fullscreen (this is also is a good workaround for the splitting Audio menu symbol lol).

Any chance the picture can be moved downwards when Inverted Screen is activated?  Because when it is und and you set the screen on "even lower" the screen actually is moving upwards.
Title: Re: ML UI rationalization
Post by: a1ex on February 05, 2013, 09:49:40 AM
Histogram does work outside LV, just take a picture ;)
Title: Re: ML UI rationalization
Post by: sutobe on February 05, 2013, 10:04:29 AM
Yes well I was refering to the ML overlay but it's not a big deal aynways ;-)


But this might be, just noticed when you're trying to correct values per ML (exposure, ISO etc) the screen doesn't turn transparent anymore, both video and photo mode

(http://i50.tinypic.com/2zs4fvc.jpg)

Title: Re: ML UI rationalization
Post by: stevefal on February 05, 2013, 02:59:48 PM
I agree testing with other people is a good idea.
Title: Re: ML UI rationalization
Post by: SDX on February 05, 2013, 04:11:34 PM
Just compiled from the main repo and tested the menu. It took 30 seconds to get used to it, even though it is different. Good. Definitively a candidate for a comparative test (IMHO).
Title: Re: ML UI rationalization
Post by: 1% on February 05, 2013, 04:47:39 PM
its easier on the eyes an icons seem more straight forward to use. just sad adv hdr is crashing. hex browser I fixed but don't know how to override the current digit.
Title: Re: ML UI rationalization
Post by: basovandrey on February 05, 2013, 05:53:55 PM
"Google translation"

Hello. 
Hopefully on the logic of developers and propose to completely abandon button "Q"
1. It is very easy to press the buttons that are next.
2. no need to think what button to press Q or SET.
3. All becomes clear and simple.
4. Button Q bad button an uncomfortable.
(http://rghost.ru/43571410/image.png)
Title: Re: ML UI rationalization
Post by: stevefal on February 05, 2013, 06:42:34 PM
I like the idea of making things simpler. This might go too far.
Title: Re: ML UI rationalization
Post by: g3gg0 on February 05, 2013, 07:18:33 PM
well it sounds like the discussion "mac" vs "pc"

mac: one mouse button is enough
pc: we have a left click for normal functions and a right click for advanced/options

i prefer the PC style. one SET button for enable/disable/select and a Q button to open the submenu.
Title: Re: ML UI rationalization
Post by: stevefal on February 05, 2013, 09:20:17 PM
I think there's more to it though..
Title: Re: ML UI rationalization
Post by: 1% on February 06, 2013, 09:31:32 AM
Bad enough power switch on 6D is on wrong side. When I drive I can shoot with 600D 1 handed and switch ml settings. To have to use menu to cancel close is a death sentence for operation.
Title: Re: ML UI rationalization
Post by: Marsu42 on February 06, 2013, 10:27:53 AM
Hi all,

Disclaimer: I admit I didn't follow the recent ui threads, but often compile the ml trunk to get the latest features. So it might be seem a bit like nagging if I only post if I dislike something, but imho either the GNOME ("You don't need/want that feature") is the way for ml nor the Windows8/GNOME ("People get confused by windows, you want full screen") submenu commit https://bitbucket.org/hudson/magic-lantern/commits/31c81a3d8fead31693417ee826299e852f213f12 ... I repeat what I wrote elsewhere because I was told this is the correct place.

First off there probably is a different usage style between amateurs/newbies and professionals, just look at the camera bodies Rebel vs. 5d3/1dx with more buttons - less complexity eases the way into using a dslr and ml, but quickly limits you when it slows you down achieving your goal. Since I have been using ml for quite some time, I'm in the latter group, and I'd wish ml would gain more appeal to pro and advanced photogs now that the code is more stable.

So here it goes: Imho the full screen submenus are a major slowdown for navigating ml - I have to re-think "where am I?" every back & forward because all of the screen changes. I see the rationale to gain space for more verbose settings & descriptions, but imho it's too large a regression. Ml recently has gained great features that could be used for pro shooting like exposure lock, but here a fast and non confusing navigation is everything - either with many unrolled menus like on the 6d, or with submenus like on the 5d3 but with a navigation bar that tells you exactly where you are.

My issue is not with debugging/"set once and forget" stuff but with the usual shooting settings because you need to be able to change the latter quickly in the field, having two Canon/ml menus is already an (acceptable) complication, but I'd avoid anything that complicates flipping through and setting things like bracketing, exposure lock and so on. I'm looking forward to the ml "My Menu" for the same reason...

Btw: As for the rest of the newer ui appeal in the current trunk: Well done, the colors and greyed out option make navigating much easier (until using a submenu that is...).
Title: Re: ML UI rationalization
Post by: wolf on February 06, 2013, 11:56:38 AM
Quotethe way for ml nor the Windows8/GNOME ("People get confused by windows, you want full screen")
using arch and mate-desktop and did not get confuse by full screen submenu. I just prefer simplicity, but I can deal with small submenus as well.   :)

QuoteSo here it goes: Imho the full screen submenus are a major slowdown for navigating ml - I have to re-think "where am I?"

So my proposal is to keep the fullscreen submenu, if this is technically possibly, in the script menu. The advantage of more parameters is obvious and for scripts with no parameters it appears less confusing or clearer to me.

Title: Re: ML UI rationalization
Post by: a1ex on February 06, 2013, 01:06:02 PM
Well... after considering all the previous proposals and arguments, I'd settle for:

- Windowed submenus (with up to 11 items, just like full-screen ones).
- Only one level of submenus (see my links from ml-devel for rationale).
- SET for most used action: ON/OFF, pickbox for 3+ choices, edit mode for ISO & friends, run action. Fallback to submenu only if there's nothing else to do.
- Q (or equivalent): toggle submenu (advanced settings menu, think of it as right-click). Maybe fallback to pickbox or edit mode.
- Zoom In: edit in LiveView. Maybe the LiveView button can do the same (should be more obvious).
- MENU goes back (close submenu, cancel edit mode). Fully optional, just for consistency with Canon menu.
- LEFT/RIGHT always does the same thing as top scrollwheel (navigate or edit).
- UP/DOWN always does the same thing as rear scrollwheel (navigate or edit). Scrollwheels are just accelerators.

This behavior is implemented in current trunk (4f4cf19c3177 (https://bitbucket.org/hudson/magic-lantern/commits/4f4cf19c3177)).

Any objections?

If you want to do A/B testing and try SET for submenus, Q for ON/OFF and so on, feel free to do so, but implement the test code yourself. I'll just optimize the current keybinding scheme and layout, which I think it works best for power users.
Title: Re: ML UI rationalization
Post by: screamer on February 06, 2013, 01:09:39 PM
Great Alex, i love the way you set a point here. agree completely with your keybindings, as i've though from the beginning of this discussion, i prefer the q and set roles you gave. So for me is perfect ;)
Title: Re: ML UI rationalization
Post by: scrax on February 06, 2013, 01:42:49 PM
@Marsu42 I don't see the problem with full screen submenu, there is a bigger title with more words telling you where you are and an icon to show you that it's a submenu. And to get there you have to be in the main menu item before so how can you "lost" yourself?
Instead we get a lot of space were cropmarks, focus patterns and other thing can be bigger, more and more clear.

We are not discussing about a computer GUI, this is not Mac, Win, Linux or Dos it's ML and it's for a camera with not a fixed number of buttons, a small display, full screen on 720px is not so big.
We don't have the needs like on desktop to move around windows to see under them, we are more like a smatphone were any pixel is precious to show info since the space is limited. And maybe I don't remember correct but even Symbian never had windows, why do we need them?

Also full screen submenu are more clean, don't have problems with the icons and they just work good.

IMHO full screen submenu are a winning change and should be adopted in main tree, but if other devs are not agree, it's ok for me to keep them smaller.
Title: Re: ML UI rationalization
Post by: wolf on February 06, 2013, 01:49:35 PM
I guess only a few people had the opportunity to take a look at the different styles and flavors of ML-bleeding-edge. That's my only concern with this settlement.
Building open source software is mostly a kind of meritocratic way in terms of decisions making and I'm fine with that.
I think fullscreen submenus are better.
Title: Re: ML UI rationalization
Post by: a1ex on February 06, 2013, 02:09:11 PM
The windowed submenu can be made as big as the full-screen one, so the extra space argument is very weak.

When there are 2 or 3 items in the submenu, the full-screen one looks kinda empty (like those Canon menus with only 2 items).
Title: Re: ML UI rationalization
Post by: scrax on February 06, 2013, 02:24:35 PM
Quote from: a1ex on February 06, 2013, 02:09:11 PM
The windowed submenu can be made as big as the full-screen one, so the extra space argument is very weak.
Ok, just tried ;)
Quote
When there are 2 or 3 items in the submenu, the full-screen one looks kinda empty (like those Canon menus with only 2 items).
Also this is not an argument for submenu full screen, you are right about the empty submenus, so let's forget those full screen submenu and think about the actual submenu. With the 1px border they look a bit like an old website to me, @stevefeval have you any idea for making them more inline with the new desing? Maybe just removing the border and making the upper angles curved?

BTW: I'm still thinking we need bigger font with less item on screen, we can't "read" 11 item together (max we can do is 3 or 4) so having less item bigger could be better in theory also for accessibility, no?
Title: Re: ML UI rationalization
Post by: a1ex on February 06, 2013, 02:36:22 PM
If we can find a better look for the submenu, that's perfect. Maybe some subtle shadow effect.

I've tried Canon Gothic font for main menu (replace bmp_printf's in entry_print with bfnt_printf and increment y by 40 instead of font_large.height (32)). Looks kinda ugly IMO.

(http://a1ex.magiclantern.fm/bleeding-edge/largefont.png)

So I'd keep the current font and avoid scrollbars.
Title: Re: ML UI rationalization
Post by: scrax on February 06, 2013, 02:48:29 PM
Quote from: a1ex on February 06, 2013, 02:36:22 PM
If we can find a better look for the submenu, that's perfect. Maybe some subtle shadow effect.

I've tried Canon Gothic font for main menu (replace bmp_printf's in entry_print with bfnt_printf and increment y by 40 instead of font_large.height (32)). Looks kinda ugly IMO.

Will try it right now, from the screenshoot I like it more than what we have now, but there was some nice font suggestion in the older topic (http://www.magiclantern.fm/forum/index.php?topic=1185.msg6667#msg6667) that could be valid (personally I like that Segoe UI, don't know win users feelings about it). Also PT Sans Narrow (https://www.google.com/webfonts/specimen/PT+Sans+Narrow) is nice.


EDIT: After few test I've spaced them more to 46 for y and fixed audio and focus item number to 7 and 6 default is 8 also added all change under ifdef CONFIG_CGOTHIC_MENU, I like it so far and to me it looks more readable, but scrolling item quick keeping arrow pressed is showing some problem to updatee the selection making all item blue for a little...
Title: Re: ML UI rationalization
Post by: 1% on February 06, 2013, 05:08:21 PM
Tried commits this morning. Don't like that set forces menu to be selected and make bg transparent instead of just toggling forward... but I think this was the only fix for 550d?
Title: Re: ML UI rationalization
Post by: a1ex on February 06, 2013, 05:18:10 PM
It was like this since 2.3 (until the beginning of this thread). When there are many choices (not just on/off), I find it easier to use left/right for changing the values.
Title: Re: ML UI rationalization
Post by: stevefal on February 06, 2013, 07:01:41 PM
Maybe the SET/Q part could still be clearer.
Title: Re: ML UI rationalization
Post by: Marsu42 on February 06, 2013, 07:33:55 PM
Quote from: scrax on February 06, 2013, 01:42:49 PM
@Marsu42 I don't see the problem with full screen submenu, there is a bigger title with more words telling you where you are and an icon to show you that it's a submenu. And to get there you have to be in the main menu item before so how can you "lost" yourself?
Instead we get a lot of space were cropmarks, focus patterns and other thing can be bigger, more and more clear.

Ok, I'll try once again for peace and understanding's sake :-) ... as I wrote above, I do acknowledge the benefit of more space. But to reiterate the drawback: If the submenu is laid over the opaque main menu, I still have the same visual cues at the top, it's just some added information (the submenu). With full screen submenus, the whole screen is replaced and I have to gather new information (the title bar) to see where I am, and this costs time and causes some confusion because I cannot see that I'm say in the movie main menu (Alex' latest build fixes that problem).

I'm 99% sure that the result of a usability test "change these 10 settings in the shortest amount of time" would be that full screen submenus are slowest.

Quote from: scrax on February 06, 2013, 01:42:49 PM
Also full screen submenu are more clean, don't have problems with the icons and they just work good.

I see your rationale, that's why I mentioned GNOME. Not that a full screen (aka Win8) couldn't make sense on a small screen device - it's about either "function follows form/design" (GNOME) or "form/design follows function" (Bauhaus). Personally and from my experiences while shooting in the field, I don't want the "cleanest"/most stylish look, but the most usable - which is in my case the fastest.

Quote from: a1ex on February 06, 2013, 01:06:02 PM
This behavior is implemented in current trunk (4f4cf19c3177 (https://bitbucket.org/hudson/magic-lantern/commits/4f4cf19c3177)). Any objections?

No objections from me, actually looks really good & usable and I feel at home again, thanks :-)
Title: Re: ML UI rationalization
Post by: stevefal on February 06, 2013, 10:33:56 PM
Quote from: a1ex on February 06, 2013, 05:18:10 PM
...I find it easier to use left/right for changing the values.
Me too, plus... Canon
Title: Re: ML UI rationalization
Post by: stevefal on February 07, 2013, 12:48:46 AM
Quote from: Marsu42 on February 06, 2013, 07:33:55 PM
I'm 99% sure that the result of a usability test "change these 10 settings in the shortest amount of time" would be that full screen submenus are slowest.

I don't think so. I think it would be fine.
Title: Re: ML UI rationalization
Post by: stevefal on February 07, 2013, 01:13:37 AM
Proportional fonts would be nice. Tell me if I can help.
Title: Re: ML UI rationalization
Post by: g3gg0 on February 07, 2013, 01:34:15 AM
now as alex made the menu a lot more structured/cleaner.
cant we make two appearance types?  beginner/poweruser

the one will open submenus/options with set and follows some of stevefal proposed usability guidelines
and the other is more like the current style as we know it.
Title: Re: ML UI rationalization
Post by: stevefal on February 07, 2013, 02:33:15 AM
I think one could work for both.
Title: Re: ML UI rationalization
Post by: scrax on February 07, 2013, 02:52:46 AM
Quote from: Marsu42 on February 06, 2013, 07:33:55 PM
With full screen submenus, the whole screen is replaced and I have to gather new information (the title bar) to see where I am, and this costs time and causes some confusion because I cannot see that I'm say in the movie main menu (Alex' latest build fixes that problem).
To me this sound weak like the more space argument I used ;D but now I understood your example about GNOME, and, as you already noted probably, I've already proposed some design suggestion for the submenu not fullscreen.
I'm for the max functionality with if possible a good design, since for me graphics is something important.

BTW: I've read just now the reply from stevefeval and I'm agree with him and in the end it's a matter of taste. I like what those changes are gonna bring to ML UI, full screen submenu or not.

Quote from: stevefal on February 07, 2013, 01:13:37 AM
I would like to do the legwork to bring a nice proportional font into the project. I have the workflow to generate bitmap fonts if necessary, in FON, FNT, SFP, SFL and BDF formats.

Is this feasible?

I don't understand in full how ML use font but here there are more technical info about it: http://magiclantern.wikia.com/wiki/Fonts
Title: Re: ML UI rationalization
Post by: scrax on February 07, 2013, 07:44:48 AM
This is my build from the pull request with also the gothic font and an ML icon added to the menu:
https://bitbucket.org/600Dplus/magic-lantern-fixes/downloads/ML2.3NEXT_20130207_GothicMenuFont_600D-Cmode_CustomDialog.zip
try it if, I found it better to read also from more far.

Just a question, now SET opens pickbox, Q also open pickbox, PLAY decrease value without picbox, what button for increase value without pickbox?

since that is a 3 click vs 1 regression with that new layout, no?
Title: Re: ML UI rationalization
Post by: stevefal on February 07, 2013, 04:26:46 PM
new MENU and LR icons
(http://i.imgur.com/e3WAJ1F.gif)
Title: Re: ML UI rationalization
Post by: wolf on February 07, 2013, 06:17:00 PM
Is it intended that the other items are faded out or is it just because of the development version?

(http://i.imgur.com/tlKkhVq.png?1)
Title: Re: ML UI rationalization
Post by: Marsu42 on February 07, 2013, 11:59:02 PM
Quote from: g3gg0 on February 07, 2013, 01:34:15 AM
cant we make two appearance types?  beginner/poweruser
the one will open submenus/options with set and follows some of stevefal proposed usability guidelines
and the other is more like the current style as we know it.

I didn't look at the current menu code, and some more seasoned dev could tell how much code complexity would rise - and size, since it'd probably be a runtime switch and not a compiler one. But I'd advise more time trying to find a compromise or a decision, it's not like the current ui is broken, so no need to rush?

Concerning the latest proposal: I really took the time and compared it step by step with the (very nice) current trunk ui. Please forgive me for not reading the entire thread since multiple proposals seem to have been tried and withdrawn, and I don't want to backtrack that - so please correct me if I've got some intention wrong.

Again sorry I'm very late to this, I really do applaud any effort to make ml more accessible and open it to more user groups - though imho the people ml should aquire next are pro shooters.

* Q button for enabling/disabling and SET for menu: Yes, the old behavior is not consistent with the global draw item. however, the action I do most is enabling/disabling and the SET button is much easier/faster to reach than Q, so I'd opt either for the other way around (some change to the global draw switching to match the rest) or just for a way in the ui to make the current behavior most clear.

* full screen submenu: I commented on this above, and you won't be surprised that a new "back to menu" icon doesn't make such a large difference for me :-o ... I'd definitely vote for the current trunk menus and I'm confident ml users are smart enough to figure that left/right changes the value w/o an additional <> icon.

* menu key for back: I take this is meant to enable 3rd level submenus? First off, I switched menu with trash, so the "<menu" icon is confusion for this case. And is there really a pressing need for nested submenus? Afaik it's a usability fact that unrolled menus are faster to recognize, at least in web pages. My real issue with the q/menu proposal is that it eliminates the right hand only control, which is one of the few reasons I like my 60d over the Nikon d7000 and the 6d over the 5d3 :-o ... I seldom switch Canon settings (set to trash on my 60d) since these are accessible though the camera's button controls, but I often use the ml menu (set on menu).

Did I overlook any other vital changes you are proposing to implement over the current trunk ui?

Btw: If you could compress the gif as non-progressive it'd be easier to step though it, the tool I found (Animated GIF Frame Extractor) only shows the delta images ... or is there any better tool to manually step through the gif?
Title: Re: ML UI rationalization
Post by: scrax on February 08, 2013, 12:08:02 AM
I'm agree with marsu, why not use the Trash button instead of MENU? If we need to go quickly out of ML from a 2nd or 3rd level we have always halfshutter and that's normal in all other dialogs.
Title: Re: ML UI rationalization
Post by: wolf on February 08, 2013, 12:43:49 AM
I think it is strange to open a submenu window with SET and with another pressing of  SET being able change the first value.
So I suggest a [BACK] to the menu entry on top. Pressing SET two times brings you  back again being sure that you didn't accidentally change a value.
Beside that I really think that there are too many different icons which let ML appear more difficult to handle with than it actually is.

Title: Re: ML UI rationalization
Post by: stevefal on February 08, 2013, 08:34:56 PM
That's my problem with how things work. I think it could be better.
Title: Re: ML UI rationalization
Post by: sutobe on February 08, 2013, 08:46:24 PM
I like how the UI appears in the actual NB.

Today I tried the My Menu function (which I didn't know it was there lol) and this is definitely a nice addition.

But, and this is just my opinion, I don't really like it's always jumping back to My Menu, either if the camera was turned off or if you leave ML.

Sometimes this is a little bit annoying.

Except for this great work so far
Title: Re: ML UI rationalization
Post by: stevefal on February 08, 2013, 10:27:24 PM
Heh, I can't let go. I think people are stuck in their old ways and should try my new idea.
Title: Re: ML UI rationalization
Post by: scrax on February 09, 2013, 06:23:05 AM
Since the biggest problem in implementing the new rational UI proposed by stevefal is the quick on/off toggle of items I think that maybe that rational UI is hard to implement because ML lacks a way to quickly enable functions. Something that should be independent from main menu. A sort of function list to only enable them. Maybe that list could be MyMenu, but we need to have a way to show it instead of ML menu, a shotrcut like DISP+Trash in LV/movie or DISPLAY_off+Trash in photo mode (if not possible to get disp press-unpress in this mode) maybe.

That solve the MyMenu always opening problem and also could be the only non rational but pratical part of ML UI, disabled in main menu by default so only user who know and prefer that can have it.

If all that don't make sense, what about implementing the Q/SET rational UI and let user chose what they want from a menu option and then make a pool also, maybe? Is it too complicated?
Title: Re: ML UI rationalization
Post by: 1% on February 09, 2013, 07:36:04 AM
The one handed operation is a pretty valuable feature. Sometimes features are left on from using the camera like fps override, hdr, etc. Some features only in the submenu like digic gain but valuable for video on the fly. Lefty's are screwed by the design of the entire camera.


QuoteOn 60D, SET, Q and MENU

600D/6d menu on the left.

QuoteThe benefits of sound, professional design outweigh the cost of one's thumb moving 2 centimeters N times a day. By the way, how many is N? If you say 5, I will say "then no biggie". If you say 500, I will say "then you will surely become good at it."

Fuck that line of thinking, I use the camera to take pictures. I guess this is what I can thank for the flood of gimpy devices I keep having to deal with. Did anyone actually try to use it for what its for? More than 5 mins?

you are right that some things are more habit than anything but those habits arise in "professionally" designed things too.

Title: Re: ML UI rationalization
Post by: a1ex on February 09, 2013, 08:20:45 AM
Quote from: scrax on February 09, 2013, 06:23:05 AM
what about implementing the Q/SET rational UI and let user chose what they want from a menu option and then make a pool also, maybe? Is it too complicated?

Anyone is free to implement it. Good luck modifying all the 80 submenus ;)
Title: Re: ML UI rationalization
Post by: Marsu42 on February 09, 2013, 11:08:59 AM
Quote from: stevefal on February 08, 2013, 10:27:24 PM
Heh, I can't let go.

I see, and understand your frustration if a concept that has been put up with a lot of love and work doesn't receive instant approval.

However for the sake of matter of fact discussion you might want to put things a little in perspective here - we're all ml enthusiasts and interested in improving it. That's why I'm not a fan of "habituated pattern shared by ML users" or "habit-skewed thought experiments" arguments: if you simply deny the willingness or ability of others to come up with valid assessment in the first place and dismiss them as "platitudes", that's immunization against critique and doesn't allow for any exchange in good faith at all. I would really like to ask you please cut back a little here?

As for "My core proposal has not been tried": Well, implement it and give us a pull request or find a dev that is enthusiastic enough for it to do it, otherwise the discussion has to be centered on your (very nice!) mockups

Quote from: stevefal on February 08, 2013, 10:27:24 PM
I caution people about what "expert" or "pro" product implies regarding usability. Well designed professional products should be harder only for the power and control they provide. Unfortunately the refrain, "this is for experts" is used to excuse unnecessarily cryptic design.

Either you misunderstood or wanted to misunderstand: Where exactly did anyone say that a cryptic ui is fine because we're experts? I'm really having a hard time to comment at this at all, but again the difference is that for "pro" shooting speed is imperative even at the cost of a required higher familiarity with the ui - that's why pro camera bodies have buttons all over the place and a Rebel has a touchscreen, another example would be the single-function button layout of "entry" 60d/6d vs. the multi-button layout of "pro" 5d2/5d3.

These two needs cannot be met 100% at the same time, though there are ways to do something like qick access to features otherwise hidden deep in menus.

Quote from: stevefal on February 08, 2013, 10:27:24 PM
On the other hand, new users must give the current UI a chance because they have no choice. They/we are certainly confused.

Just out of interest: Who's "we"? Afaik the current ui is only in the latest trunk and there hasn't been a chance for a wider beta testers group to return their experiences, or am I mistaken since I didn't folllow everything here?

Quote from: stevefal on February 08, 2013, 10:27:24 PM
You're focused on 2nd order problems. By taking such a strong position on full-screen (sub)menus, it trades away core benefits of a UI platform that must then be explained away as "we don't need that". I'm confident ml users are smart enough to use full-screen submenus.

You're confusing cause and effect - I don't hate fullscreen submenus and am fishing for reasons to support my position, it's the other way around. I see a drawback in speed that has to be overcompensated by a large gain by full screen submenus - and in search of that gain I asked how much 3rd level menus are required, that's not "explaining away".

The other potential gain of full screen submenus is more space, so I was wondering how this gain is used in your mock up - and imho the left/right icon is nice, though imho not vital since it's very intuitive to figure it out. If you're stating that smart users can use full screen submenus, I guess you're not trying to be insulting but are missing the entire point: it's not about smartness, but about speed - and as I stated that my experience with full screen submenus is negative - and not in theory, but in actual practice on my very own camera just as you want it.

Quote from: stevefal on February 08, 2013, 10:27:24 PM
BTW I understand that the current left-hand icons do more than show toggle state, but I feel (well, I know) that those icons are vastly, grossly overloaded.

I am absolutely not against improved icons, though of course limited space calls for more integration. However I don't really feel like isolating the matter of fact arguments from your last post to endorse them because for example the "one hand navigation" seems to be mixed with personal sentiments. Reading back the entire thread is a suboptimal option, because many former ideas seem to have been cancelled to it's hard for me to figure out the current proposal except for the latest mockup - and I commented on this.
Title: Re: ML UI rationalization
Post by: scrax on February 09, 2013, 04:14:25 PM
Quote from: a1ex on February 09, 2013, 08:20:45 AM
Anyone is free to implement it. Good luck modifying all the 80 submenus ;)

Ok, got it.
Should be easier to have the quick launch menu instead of MyMenu, so.
Title: Re: ML UI rationalization
Post by: stevefal on February 09, 2013, 06:40:30 PM
Quote from: Marsu42 on February 09, 2013, 11:08:59 AM
...I would really like to ask you please cut back a little here?

I appreciate your candor and I agree - that language is a turn-off.
Title: Re: ML UI rationalization
Post by: stevefal on February 09, 2013, 06:45:30 PM
Still not sure why 3 levels is a problem.
Title: Re: ML UI rationalization
Post by: Marsu42 on February 09, 2013, 07:21:28 PM
Quote from: stevefal on February 09, 2013, 06:40:30 PM
I appreciate your candor and I agree - that language is a turn-off. I don't know how else to say it besides how I did earlier in the thread.

:-) and thanks in return for saying that - I would expect you to be rather sincere for improving ml or you wouldn't put as much work in it. I do hope we'll find a mutual acceptable approach w/o too much code complexity, though it's inevitable some decisions have to be taken - but afaik this is no time-critical matter and no need to rush, more people might want to try the latest trunk ui and suggest improvements that might very well meet yours.

Quote from: stevefal on February 09, 2013, 06:40:30 PM
I do wish that people would consider that they might not object to something in practice as much as they think they will. This can only be determined if they try. Why should they? Because the the benefits I'm trying to promote. The current approach closes doors, and I think unnecessarily.

I think one way to keep everyone happy is to implement a more beginner-friendly ui  - and I very much appreciate beginner's input, it's of course true that long-term ml usage creates some bias though I hope I can reflect it. But at the same time more direct access to critical features has to be added, "My Menu" is a first approach and more key shortcuts outside lv (I hope that's possible) to prevent clicking through menus if under stress while shooting.

Quote from: stevefal on February 09, 2013, 06:40:30 PM
I'm not following your point here. I don't disagree with the desire for one-handed operation. Again my confusion is how right-hand use of submenus is being to highly prioritzed when people also argue that submenus are "set and forget".

That's a misunderstanding - imho people (including me) think that *some* submenus are set & forget, but others certainly aren't like bracketing which I change all the time. This is is a bit eased because I could put the vital submenu items in "My Menu", but during the colder season (in Berlin about half of the year :-\) I usually wear gloves - a complete thick glove on the left, and one with fingers cut off on the right. That's why I like right-hand navigation so much, in other situations it's nice, but not essential.

Quote from: stevefal on February 09, 2013, 06:40:30 PM
With respect to 60D, I truly don't understand your point regarding one-handed operation, because all the buttons in my proposal are on the right side on that camera. I do want to understand.

Doh, sorry, you're correct and I was confused by your 600d mockup - on 60d/6d there's really no problem with your proposal for me personally. I can understand others with the Rebels though, but now no argument against 3rd level submenus from me :->
Title: Re: ML UI rationalization
Post by: stevefal on February 10, 2013, 07:29:09 AM
ML junkie idea:

(http://i.imgur.com/PfmxkBP.gif)
600D ML-Q Concept, ML Junkie Mode
Title: Re: ML UI rationalization
Post by: a1ex on February 10, 2013, 09:56:24 AM
You can see press/unpress events for:
- half-shutter
- arrow keys (left, right, up, down) - currently used for repeating keys with acceleration
- joystick center - currently used as alternate key for opening ML menu and submenus ( http://wiki.magiclantern.fm/userguide#magic_lantern_menu )
- SET on some cameras
- maybe Zoom In on some cameras, not sure

All other buttons send a single "press" event.

I like the junkie idea a lot, going to give it a try. Can be great for a quick glance of all the settings .
Title: Re: ML UI rationalization
Post by: Stedda on February 10, 2013, 11:33:08 AM
I've been loosely following this thread... I have to say this proposed junkie mode is the best idea I've seen yet.

Keep up the excellent work guys!
Title: Re: ML UI rationalization
Post by: scrax on February 10, 2013, 12:12:37 PM
Yeah, something like that I was proposing, great visual stevefal.
I really appreciate your contribution and hope that this discussion will go on like this in future.

/now updating my code to test alex implementation
Title: Re: ML UI rationalization
Post by: wolf on February 10, 2013, 12:34:26 PM
@stevefal
Looks great, as well as the idea and the whole artwork you propose.
Title: Re: ML UI rationalization
Post by: g3gg0 on February 10, 2013, 12:55:55 PM
junkie mode: WOW!
very very good idea!
Title: Re: ML UI rationalization
Post by: a1ex on February 10, 2013, 02:19:21 PM
Got it working... sort of :)

(http://a1ex.magiclantern.fm/bleeding-edge/junkie.png)
Title: Re: ML UI rationalization
Post by: wolf on February 10, 2013, 03:30:29 PM
Nice work and good improvement IMHO.
I don't know what the color orange should suggest. Go quick? Don't go? Is it meant to read as a traffic light logic?
And not to forget that some good photographers are color-blinded.
I think that the cell height should be equal like stevefal proposed for a better understanding and appearance of the items
Title: Re: ML UI rationalization
Post by: a1ex on February 10, 2013, 03:51:35 PM
It means "not working right now" (e.g. for a movie-only setting enabled in photo mode etc).
Title: Re: ML UI rationalization
Post by: scrax on February 10, 2013, 03:54:33 PM
Agree about cell height, orange are function not working with current camera settings/mode  (photo, LV, movie) I think they should be hidden from junkie mode so to have only usable things, or they could be useful in some cases?
Title: Re: ML UI rationalization
Post by: a1ex on February 10, 2013, 04:02:37 PM
I can try to hide these items, but then you may wonder where it disappeared (you can no longer see the reason why it's hidden).

As it's now, you can see what things you have enabled (and you know that the orange things won't work right now, but you still see that they are enabled).
Title: Re: ML UI rationalization
Post by: scrax on February 10, 2013, 04:13:05 PM
Yeah, right.
Actual implementation is good, I like the subtle darker green border in the mockup and the same height cell but those are just small subjective things I think.

What about a way to show the orange cell with an "inverted" black and white color scheme to differentiate them from Working but not active options? Right now orange is a bit too invasive, maybe just put the light gray on bottom and dark grey on font for example.

Or with the background color for the box color and the font white or gray like it's now?

btw: magic zoom don't show nothing in cell when enabled
Title: Re: ML UI rationalization
Post by: wolf on February 10, 2013, 04:40:17 PM
Thanks for reply.
I have a sort of gray layer over LV. With Magic_Off it's normal.
Title: Re: ML UI rationalization
Post by: 1% on February 10, 2013, 04:50:11 PM
i like this idea, shows you what's enabled quickly.

menu to open ML menu a bad idea, some things are only changed in the canon menu, as lumpy as it is. This actually improves one handed operation as there is less menu flipping. "menu" menu would take it back again.
Title: Re: ML UI rationalization
Post by: stevefal on February 10, 2013, 04:51:04 PM
Not sure what all the colors mean.

Moving LR could get funky with different heights.
Title: Re: ML UI rationalization
Post by: a1ex on February 10, 2013, 05:03:57 PM
Basically, the icons can be:

a) Feature can be used in current mode (normal items)
- ON (currently black on green)
- OFF (currently light gray on dark gray)

b) Feature can't be used in current mode (e.g. bitrate in photo mode)
- ON (currently black on light gray, was black on orange)
- OFF (currently dark gray on dark gray)
(in this case, there's a warning message at the bottom explaining why this feature is grayed out)

Optional: indicator for submenu.

I did the menus stretchable for the following reasons:
- to avoid scrollbars (if a menu gets too big)
- with a customized menu, to get decent spacing (try hiding some menus - the layout becomes more "relaxed" and with longer strings)

In the 1-year old ML version, there was a simple menu mode by default, where things that couldn't be used (e.g. photo functions in movie mode) were normally hidden (now they are grayed out). People had trouble finding things in it though.

(http://a1ex.magiclantern.fm/bleeding-edge/junkie2.png)
Title: Re: ML UI rationalization
Post by: scrax on February 10, 2013, 05:25:26 PM
Quote from: a1ex on February 10, 2013, 05:03:57 PM
- with a customized menu, to get decent spacing (try hiding some menus - the layout becomes more "relaxed" and with longer strings)

Yes, customizing the menu makes the awesome more awesome, but item hidden in normal menu should not be shared with junkies menu, because now isn't possible to hide all items that (for me) are settings from junkie menu and have those in main menu if needed.
Same thing for items like audio override that ideally can be keep visible only in junkie and hidden in main menu
Title: Re: ML UI rationalization
Post by: wolf on February 10, 2013, 05:38:03 PM
Can somebody try LV and check if there is a grey layer like I can observe.
http://i.imgur.com/RLg1j0W.jpg
Title: Re: ML UI rationalization
Post by: scrax on February 10, 2013, 05:41:58 PM
Quote from: wolf on February 10, 2013, 05:38:03 PM
Can somebody try LV and check if there is a grey layer like I can observe.
http://i.imgur.com/RLg1j0W.jpg

not on mine, scripts sometimes don't stop even hello world keeps running till switch off.
Title: Re: ML UI rationalization
Post by: wolf on February 10, 2013, 05:56:14 PM
Still there. An older version of ML works fine for me.
Have you tried LV with a dark setting, too high aperture or too high speed?

Edit:
Seems to be gone. Don't know why. Sorry my mistake.
Title: Re: ML UI rationalization
Post by: a1ex on February 10, 2013, 06:42:34 PM
Ultimate customizability - you can create a small junkie menu and have all other items in main menu. Or viceversa, if you prefer.
Title: Re: ML UI rationalization
Post by: wolf on February 10, 2013, 07:14:20 PM
Much better without blue row line IMHO.
But sometimes I wonder, maybe I'm the only one, where the next sidestep leads to.
(http://i.imgur.com/vmwGXlX.png?1)

Edit:
I like to add that I think the menu entry line at the bottom on top of the help text is not really needed.
The help text gives enough information for a ML junkie, I don't need even the help text ;)
It would also free horizontal space.
Title: Re: ML UI rationalization
Post by: a1ex on February 10, 2013, 08:24:22 PM
Here's my dashboard:
(http://a1ex.magiclantern.fm/bleeding-edge/junkie3.png)

If there's enough space, it switches to large font.

Everything else is in the normal menu.
Title: Re: ML UI rationalization
Post by: scrax on February 10, 2013, 08:47:24 PM
Quote from: wolf on February 10, 2013, 07:14:20 PM
Much better without blue row line IMHO.
But sometimes I wonder, maybe I'm the only one, where the next sidestep leads to.
(http://i.imgur.com/vmwGXlX.png?1)

Edit:
I like to add that I think the menu entry line at the bottom on top of the help text is not really needed.
The help text gives enough information for a ML junkie, I don't need even the help text ;)
It would also free horizontal space.

You have to hide things and keep same number for each column, get rid of something will be good. I've found 6x6 grid that so far seems good for me.
(https://dl.dropbox.com/u/123918/MagicLantern/redesign/junkie.png)
removed all overlay since will toggle them with LV presets
Quote from: a1ex on February 10, 2013, 08:24:22 PM
Here's my dashboard:
(http://a1ex.magiclantern.fm/bleeding-edge/junkie3.png)

If there's enough space, it switches to large font.

Everything else is in the normal menu.

Nice :)
I've not yet started to use MyMenu it will for sure make my 6x6 smaller...
Title: Re: ML UI rationalization
Post by: a1ex on February 10, 2013, 08:57:28 PM
Looks like a very good compromise - if you like a uniform grid layout, you can setup one; if you don't care, you can have 4 items on some columns and 10 on others, it will just work. I like this flexibility.

Canon has the same scrolling inconsistency in the Q menu (at least on 5D2) - the boxes do not have equal sizes.

@scrax: if you choose 5 columns, it will switch to large fonts.
Title: Re: ML UI rationalization
Post by: scrax on February 10, 2013, 09:08:14 PM
Quote from: a1ex on February 10, 2013, 08:57:28 PM
@scrax: if you choose 5 columns, it will switch to large fonts.

I've now set up a 5 colum layout with 2 item in audio 4 in Expo, shoot and Focus and 8 in MyMenu. Big font and really nice.
Now since PLAY can change value without opening dialogs can also be made to close the junkie menu after changing value? This will enable quick toggle of last changed item (since it will stay selected).

For example for Marsu42 he can close Junkie menu with ExpoLock selected and during shooting pressing Trash and then play will toggle it each time.
Title: Re: ML UI rationalization
Post by: wolf on February 10, 2013, 09:26:36 PM
QuoteLooks like a very good compromise
Yes - feels much better for me.

What do you think about replacing the help text with the menu entry?
Title: Re: ML UI rationalization
Post by: a1ex on February 10, 2013, 09:43:49 PM
I'd keep at least one help line (the warning). When something gets grayed out, it may not be obvious why, and the help lines will tell you. For example, enable expo lock and bracketing - these two don't work together, and you may wonder why.

Also I'd keep the big menu entry line at the bottom. Some things may not be obvious when there are few characters. With that line, you notice right away that you are operating on the same menu items, and it's just a different display style.
Title: Re: ML UI rationalization
Post by: 1% on February 10, 2013, 09:53:43 PM
Wanted to try but:

menu.o: In function `menu_redraw_do':
menu.c:(.text+0x6d80): undefined reference to `strncpy'
menu.c:(.text+0x7428): undefined reference to `strncpy'

*bulb ramping works in LV with silent pics? It seems to?
Title: Re: ML UI rationalization
Post by: Marsu42 on February 11, 2013, 12:01:35 AM
Quote from: stevefal on February 10, 2013, 07:29:09 AM
ML Junkie

This is absolutely terrific, thanks! And I have to mention junkie is very fast and mode looks great with traditional submenus :->

Quote from: scrax on February 10, 2013, 09:08:14 PM
For example for Marsu42 he can close Junkie menu with ExpoLock selected and during shooting pressing Trash and then play will toggle it each time.

Yup, at least that's a 2-click solution - though as in the feature request quick access keys for different features and a confirmation would enable keeping the eye to the vf, the junkie mode is a (very welcomed) shortcut when looking at the display.
Title: Re: ML UI rationalization
Post by: Greg on February 11, 2013, 01:15:00 AM
New menu for the camera with a touch screen?
Title: Re: ML UI rationalization
Post by: stevefal on February 11, 2013, 07:26:03 PM
Maybe!
Title: Re: ML UI rationalization
Post by: stevefal on February 11, 2013, 07:38:20 PM
How about putting the star and X in the same place.
Title: Re: ML UI rationalization
Post by: a1ex on February 11, 2013, 07:42:00 PM
This breaks the following scenario:

Let's say you only use overlays, analog gain, bitrate, follow focus and contrast adjustment. Overlays are grouped in one menu, the others are scattered (each one in a separate menu). You could group the scattered features in My Menu, keep the Overlay menu, hide everything else and end up with two small menus.

In other words, you will no longer be able to create this menu:
(http://a1ex.magiclantern.fm/bleeding-edge/junkie3.png)
Title: Re: ML UI rationalization
Post by: stevefal on February 11, 2013, 07:42:13 PM
Entire tabs could be hidden..

Title: Re: ML UI rationalization
Post by: stevefal on February 11, 2013, 08:09:44 PM
In fact, how about only one menu customization mode. SET rotates through no icon, star and X
Title: Re: ML UI rationalization
Post by: a1ex on February 11, 2013, 08:19:23 PM
That will work. Just don't ask me to move the focus on the tab bar (it's not easy to code).
Title: Re: ML UI rationalization
Post by: stevefal on February 11, 2013, 08:48:46 PM
Could have first item be the tab for hiding while in customization:

  [Overlay Tab]
  Global Draw
  Zebras
Title: Re: ML UI rationalization
Post by: Marsu42 on February 11, 2013, 09:15:02 PM
Quote from: stevefal on February 11, 2013, 07:42:13 PM
Polish/simplify: Only one menu customization mode. When in the mode, pressing SET rotates through displaying no icon (normal), <star> (MyMenu), and "X" (hidden). This essentially gives you three levels of importance.

I nearly wrote the same thing as a feature request, but didn't for a reason - so I have to be Mr. Killjoy again: Currently I have some (sub)menu items in "My Menu", but hid them in the original location to avoid duplication. I rather like this possibility, so if at all I'd suggest *four* modes: none/star/hidden/both(star+hidden), the latter with a new icon or both icons next to each other. I know this is not exactly intuitive to newbies (here we go...) but personally I'd rather keep the current trunk system than loose this functionality.
Title: Re: ML UI rationalization
Post by: stevefal on February 11, 2013, 09:23:35 PM
interesting...
Title: Re: ML UI rationalization
Post by: stevefal on February 11, 2013, 09:46:13 PM
..how about hide items in menus if they are in MyMenu
Title: Re: ML UI rationalization
Post by: screamer on February 11, 2013, 09:56:34 PM
or, the opposite alternative, could be to hide mymenu in junkie mode
Title: Re: ML UI rationalization
Post by: stevefal on February 11, 2013, 09:59:15 PM
but MyMenu is useful in junkie mode
Title: Re: ML UI rationalization
Post by: screamer on February 11, 2013, 10:05:23 PM
i can understand. The only reason because i've proposed it, is because hiding items around change the "visual apparence" of the menus, so you can have things in different locations than expected. A way to avoid this could be to have the mymenu and all the things already present in mymenu are not visible in the others menu, but the empty place is there (don't know if my english was understandable)
Title: Re: ML UI rationalization
Post by: stevefal on February 11, 2013, 10:12:42 PM
A gap could be weird. How about just hiding mymenu items in the regular menus
Title: Re: ML UI rationalization
Post by: stevefal on February 11, 2013, 10:29:08 PM
I think there's

1) ON
2) OFF but available
3) OFF but ON in another mode
4) OFF and OFF in all modes
Title: Re: ML UI rationalization
Post by: a1ex on February 11, 2013, 10:35:00 PM
(3) also includes some things like:
- HDR bracketing: can't be used if you also have Canon bracketing active.
- Expo Lock: can't be used if HDR bracketing is active
- Anamorphic preview can't be used together with defishing, so one of them is grayed out

I'd say there should be some sort of visual feedback when you enable a feature that's normally not available now.

Edit: implemented the simplified customizing mode (with implicit hiding). Seems straightforward, can't find any disadvantage compared to previous method.
Title: Re: ML UI rationalization
Post by: stevefal on February 11, 2013, 11:21:28 PM
Quote from: a1ex on February 11, 2013, 10:35:00 PM
I'd say there should be some sort of visual feedback when you enable a feature that's normally not available now.
I think not too strong though
Title: Re: ML UI rationalization
Post by: stevefal on February 11, 2013, 11:49:17 PM
It could be dark green only when on it..
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 01:07:41 AM
..like this

(http://i.imgur.com/tC4af49.gif)
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 02:28:17 AM
Nav icon ideas

(http://i.imgur.com/DzYMx2Z.gif)
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 02:31:25 AM
..Back too

(http://i.imgur.com/0iXz47w.gif)
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 05:09:33 AM
Submenu ideas:

(http://i.imgur.com/NjufvJU.gif)

Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 05:30:57 AM
Saw this today..

(http://i.imgur.com/BvtmCWQ.gif)
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 06:23:36 AM
Customize layout ideas

(http://i.imgur.com/Xn1hS9L.gif)
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 06:32:12 AM
How about hiding Audio, Movie tabs when not in movie mode..
Title: Re: ML UI rationalization
Post by: Marsu42 on February 12, 2013, 08:09:54 AM
Quote from: stevefal on February 12, 2013, 05:09:33 AM
Mask underlying menu completely.

What I like about the current opaque approach that most of the background is kept, so only information is added/subtracted and when the submenu disappears I know right where to read on. This basically is a modified reasoning like with full screen submenus, but the new "hide background" is a bit more agreeable since the menu bar is kept in place.

If I'm the only one with this perception please do implement it, but personally the "clean" argument is not sufficient for me, "clean" to what effect exactly? Is the opaque background just in the way of a specific idea about how design should be, or how does the opaque background hinder ml's usability - because this time there are no added benefits like more space. If the idea that the background is confusing, it's exactly the reverse of what I perceive.

Quote from: stevefal on February 12, 2013, 06:32:12 AM
Polish/simplify: Consider hiding Movie and Audio tabs when not in Movie mode - both regular and junkie modes.

Generally I'm in favor (<- please not this :-)) of your idea but see three problems:

* I recently discovered that "Audio Remote Shot" in is depending on the Audio stuff (Wind Filter, Mic Power...), and it's helpful to see the audio meters to have an idea of the trigger level vs. the background level, i.e. the danger of accidental release.

* The Movie menu has "Creative Effects" in it that is helpful for lv mode & manual focusing (focus peaking is easier with desaturate to b/w), actually that's the only item I have left in this menu

* People might want to leisurely change movie settings before going to movie mode because once in movie mode (at least on my 60d) the mirror flips instantly up, drawing battery power. Sure you can turn off lv again, but it's a hassle.

I hope these concerns can be worked out, esp. since I'm never doing a/v and even disabled these features in the binary.
Title: Re: ML UI rationalization
Post by: scrax on February 12, 2013, 09:22:23 AM
Quote from: stevefal on February 12, 2013, 06:32:12 AM
Polish/simplify: Consider hiding Movie and Audio tabs when not in Movie mode - both regular and junkie modes. The Audio beeps submenu would have to be inaccessible outside Movie mode, but I think that's a small price to pay to remove two tabs that are irrelevant to still shooters.

This would especially help junkie mode which will pick up two-columns worth of extra horizontal space for text in other columns.
I need audio override also in photo mode to enable audio when Audio release is on :)
Also audio rec could be used in photo mode.
I'll prefer a junkie2 menu for movie mode instead
Title: Re: ML UI rationalization
Post by: a1ex on February 12, 2013, 10:46:47 AM
Quote from: Marsu42 on February 12, 2013, 08:09:54 AM
focus peaking is easier with desaturate to b/w

Look in Focus Peaking submenu ;)

The movie image effects were not having any effect in photo mode last time I checked...
Title: Re: ML UI rationalization
Post by: a1ex on February 12, 2013, 11:36:49 AM
Quote from: stevefal on February 12, 2013, 02:28:17 AM
6) remove left-hand icon entirely from valueless nesting items.

This shows if any of the submenu items is enabled (so you know, I have some creative effect enabled). I'd keep this.
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 03:19:27 PM
I think the left-hand submenu icon should be round too.
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 04:05:23 PM
QuotePeople might want to leisurely change movie settings before going to movie mode

That's true.
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 05:00:32 PM
I still like fullscreen submenus, but that's just me..
Title: Re: ML UI rationalization
Post by: wolf on February 12, 2013, 05:30:21 PM
I guess I'm not the only one who likes full screen (sub)menus. ;-)
(http://www.magiclantern.fm/images/ml1.png)
Title: Re: ML UI rationalization
Post by: a1ex on February 12, 2013, 05:59:49 PM
Would be nice to have some history of how ML menu evolved, maybe starting from this (or even earlier):

(http://a1ex.magiclantern.fm/bleeding-edge/VideoMenu.jpg)

Title: Re: ML UI rationalization
Post by: a1ex on February 12, 2013, 06:20:19 PM
Back on-topic. I've implemented most of the proposed tweaks, and also added a few of my own. Here's how it looks now:

(http://a1ex.magiclantern.fm/bleeding-edge/MovieMenu.png) (http://a1ex.magiclantern.fm/bleeding-edge/EffectsMenu.png)

My additions:
- a discrete submenu indicator at the right (grayed out when not selected)
- submenus with a single item get promoted to pickbox or editbox
- pickboxes are working in submenus (more like an edit mode, rather than a nested submenu)
- icons keep the same shape when the item is disabled, just desaturated (grayed out). The exact shape is still subject to tweaking (e.g. icon for action items, or the volume sliders).

The navigation now feels quite logical to me with the new back/forward icons, these are effectively self-explaining. Great job!

Now, about those items that I chose not to implement:
- making OFF text white when selected - I don't see the point of this; it's already highlighted for readability, just not at full brightness.
- square LEDs: I actually like the round ones better
- crossout icon: I like the X better
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 07:21:03 PM
Quote from: a1ex on February 12, 2013, 06:20:19 PM
a discrete submenu indicator at the right (grayed out when not selected)
then maybe they should look like Q icon..
Title: Re: ML UI rationalization
Post by: wolf on February 12, 2013, 07:28:24 PM
I just tried the newest version and caught myself scanning the line from left to right to [Q> and back to the item descripton. I think I could read the button hint faster if it would be in the icon integrated. However good improvement - self explaining button hints.
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 07:32:48 PM
I think the original left-hand icons are too much.
Title: Re: ML UI rationalization
Post by: a1ex on February 12, 2013, 07:40:19 PM
My opinion is that the right submenu marker helps with discoverability. If you ask yourself what more advanced options are available, you can just look for those icons and try the submenus. If the hint is only on the selected item, you have to scroll through every single item and see if it shows [Q> at the end.
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 07:41:44 PM
I think the square icons and junkie tiles could look more alike.
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 07:44:25 PM
Quote from: a1ex on February 12, 2013, 07:40:19 PM
My opinion is that the right submenu marker helps with discoverability...

True..
Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 08:05:57 PM
dim Q button idea:
(http://i.imgur.com/X7UrOph.gif)
Title: Re: ML UI rationalization
Post by: g3gg0 on February 12, 2013, 09:49:03 PM
compliment to a1ex and stevefal for improving the menu on a daily basis :)
this gives magic lantern a fresh, comfortable look and feel.

Title: Re: ML UI rationalization
Post by: stevefal on February 12, 2013, 10:17:06 PM
Quote from: g3gg0 on February 12, 2013, 09:49:03 PM
compliment to a1ex and stevefal for improving the menu on a daily basis :)
this gives magic lantern a fresh, comfortable look and feel.
Thx :) just goofin' around..
Title: Re: ML UI rationalization
Post by: scrax on February 13, 2013, 01:05:09 AM
The new menu layout is almost perfect ot me, just missing some thing like full screen submenu and a clean font, but the biggest drawback I have with new layout vs old is that now we have only a decrease value button (PLAY) and not an increase value one (old Q). This makes me hate pickboxes cause I can remember what and where are the options I want to set in ML, but instead of doing it I get this list that always  tells me already know things and force me do the other way using decrease until I get where I want.

Can we have an option to use Q for increase and avoid pickboxes, sort of legacy mode?
Title: Re: ML UI rationalization
Post by: stevefal on February 13, 2013, 05:16:31 AM
I'm confused with LV Sat because SET and Q give different things..
Title: Re: ML UI rationalization
Post by: a1ex on February 13, 2013, 09:58:13 AM
That's an exception, it can be moved as the last item on the pickbox.
Title: Re: ML UI rationalization
Post by: Marsu42 on February 13, 2013, 11:00:21 AM
Quote from: scrax on February 13, 2013, 01:05:09 AM
Can we have an option to use Q for increase and avoid pickboxes, sort of legacy mode?

I can understand this with a Rebel-style camera, but with a back wheel like on 60d I happen to really like the changed navigation set -> wheel -> set, just two bugs:

* play *decreases* the values like with bracketing frames, the more intuitive way would to *increase* them

* for some menus there is a dropdown (like bracketing frames), for other with more there isn't (like bracketing increment). It would be really nice to have the dropdown for all options even if there are too many to fit on the screen, but in these cases the dropdown values should scoll up/down so it is immediately visible what the next & previous options are.
Title: Re: ML UI rationalization
Post by: scrax on February 13, 2013, 04:13:33 PM
Quote from: Marsu42 on February 13, 2013, 11:00:21 AM
* play *decreases* the values like with bracketing frames, the more intuitive way would to *increase* them

That's the same thing I'm having problem with, PLAY decrease values since I started using ML, SET increased them until that new rational layout and now we don't have any button to increase value anymore.
I'll really like to have an increase and a decrease button as it was before, since I don't digg in the menu to see if there is something that could help, I know what I need and just want to set it. So those pickboxes are annoying instead of helpful to me.

But if it can't be done at least as you proposed PLAY to increase would be more intuitive.
Title: Re: ML UI rationalization
Post by: a1ex on February 13, 2013, 04:31:55 PM
Q never increased afaik... it just opened submenus.

At the very beginning, SET was the only button, and it was just increasing.
Title: Re: ML UI rationalization
Post by: scrax on February 13, 2013, 04:43:39 PM
Quote from: a1ex on February 13, 2013, 04:31:55 PM
Q never increased afaik... it just opened submenus.

At the very beginning, SET was the only button, and it was just increasing.
ops, yes sorry I mean SET not Q.

So now we have for example in TrapFocus:
Q for showing pickbox,
SET for showing pickbox,
PLAY to decrease value.

Why SET don't increase value anymore?
Title: Re: ML UI rationalization
Post by: stevefal on February 13, 2013, 04:45:08 PM
I think things are a bit mixed up right now.
Title: Re: ML UI rationalization
Post by: scrax on February 13, 2013, 04:46:15 PM
Quote from: Marsu42 on February 13, 2013, 11:00:21 AM
* for some menus there is a dropdown (like bracketing frames), for other with more there isn't (like bracketing increment). It would be really nice to have the dropdown for all options even if there are too many to fit on the screen, but in these cases the dropdown values should scoll up/down so it is immediately visible what the next & previous options are.

+1 but could be that some menu like K don't have fixed values just min and max if I'm right.
Title: Re: ML UI rationalization
Post by: stevefal on February 13, 2013, 04:55:22 PM
I don't think the pickbox alone on black looks very good.
Title: Re: ML UI rationalization
Post by: scrax on February 13, 2013, 04:57:16 PM
Quote from: stevefal on February 13, 2013, 04:45:08 PM
Fast increment/decrement is what the concept in http://www.magiclantern.fm/forum/index.php?topic=4386.msg25371 (http://www.magiclantern.fm/forum/index.php?topic=4386.msg25371) and http://www.magiclantern.fm/forum/index.php?topic=4386.msg25396 (http://www.magiclantern.fm/forum/index.php?topic=4386.msg25396) were intended to provide. In this mode, L/R would step down and step up, just like in a submenu.

If I got it right, and correct me if not, please;
to change the setting I need to do:
a) now:
TRASH->arrow to select item->SET->ARROW->SET
b) with your concept:
TRASH->arrow to item->MENU->ARROW
c) old way:
TRASH->arrow to item->SET

a and c are one hand operations on 600D b is not.

So still can't justify SET and Q being used for same action in the actual implementation, probably you already explained it, Steve and i've just missed it...
Title: Re: ML UI rationalization
Post by: a1ex on February 13, 2013, 05:08:02 PM
Q always opens submenu. If there's no submenu, it opens the pickbox or enters the edit mode (those two are actually the same thing). It did that since 2.3, nothing changed.

SET does the most common thing - ON/OFF for booleans, pickbox/edit for 3+ choices. In 2.3 it did pretty much the same thing (edit mode wasn't used for just 3 choices though, it was used for ISO, kelvin, bitrate, audio and most other things with many choices).

So, the biggest change now is that SET uses pickbox/edit even if there are just 3 choices.

In submenus, LEFT/RIGHT were always incrementing/decrementing. This was not changed.
Title: Re: ML UI rationalization
Post by: stevefal on February 13, 2013, 05:08:52 PM
Quote from: scrax on February 13, 2013, 04:57:16 PM
b) with your concept:
TRASH->arrow to item->MENU->ARROW
You could have menu-wide editing without LR tabbing navigation, and then it would be TRASH -> UD to item -> LR to change value.
Title: Re: ML UI rationalization
Post by: a1ex on February 13, 2013, 05:42:28 PM
I made a temporary change: a preferences item from where you can choose the SET behavior.

It's just for experimentation, I'll probably remove it in the near future.

What's hard to do is to move the main value in the submenu - for this, one has to change all the submenus.
Title: Re: ML UI rationalization
Post by: stevefal on February 13, 2013, 07:15:06 PM
Suggested junkie colors:

(http://i.imgur.com/s6Wbw9S.gif)
Title: Re: ML UI rationalization
Post by: stevefal on February 13, 2013, 08:26:31 PM
junkie colors:


(http://i.imgur.com/rlwWfY1.gif)   (http://i.imgur.com/A7va3rH.gif)
normal                                       b/w
Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 07:47:05 AM
Suggest green hint text for enabling features.
Title: Re: ML UI rationalization
Post by: a1ex on February 14, 2013, 08:30:05 AM
The yellow message suggests that something went wrong (not neutral help). Was red before, but people suggested that it was too strong.
Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 08:32:49 AM
Quote from: a1ex on February 14, 2013, 08:30:05 AM
The yellow message suggests that something went wrong (not neutral help). Was red before, but people suggested that it was too strong.

You don't think green for the dependency message?
Title: Re: ML UI rationalization
Post by: a1ex on February 14, 2013, 08:36:33 AM
Green for warnings doesn't sound right to me.
Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 08:46:06 AM
Green message for item that won't turn green:

(http://i.imgur.com/5bM7M78.gif)
Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 09:38:42 AM
Working on an animated meter...
Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 11:38:56 AM
A better meter and bigger, rounder LED:

(http://i.imgur.com/c2liU50.gif)

Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 11:53:17 AM
Btw different animations can be made by flipping them around.
Title: Re: ML UI rationalization
Post by: Marsu42 on February 14, 2013, 04:00:14 PM
Quote from: stevefal on February 14, 2013, 08:46:06 AM
In the case of explaining what must be turned on for a feature to work, I don't see why you characterize it as a 'warning'. There is no pending harm or trouble, just information explaining dependent relationships between features.

I agree with that, green is ok for purely informational messages that the user can ignore since it won't do any harm or it'll obvious sooner or later (like things only working in lv).

Yellow should be reserved for information/warnings that could harm your next shot (like i.e. my recent confusion about bracketing only going to max. 30s shutter in non-m mode, the understated ml warning message is "This feature works best in Manual (M) mode") and red when something is about to critically wrong during shooting/video.
Title: Re: ML UI rationalization
Post by: Marsu42 on February 14, 2013, 05:19:07 PM
Optimization suggestion for junkie mode: If putting submenu items in "My Menu" they appear with bright green brackground, though they cannot be enabled or disabled but only triggered (like "Save Config now") or modified (like bracketing frames/step/type) -> imho these two tile types should have another background color altogether, maybe something between the dark and bright green.
Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 05:30:43 PM
I think too many colors is confusing.
Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 05:43:38 PM
Meters idea:

(http://i.imgur.com/HQBMvMl.gif)

Title: Re: ML UI rationalization
Post by: Marsu42 on February 14, 2013, 05:50:38 PM
Quote from: stevefal on February 14, 2013, 05:30:43 PM
I promote seeing green has representing non-default state.

I'm just talking about background colors in junkie mode here, not about icons. The default/non default state difference isn't my perception when úsing it. As a plain and simple ml user my I see that grey represents "disabled, but can be enabled", dark green "enabled but not active" (probably because lv only) and bright green "enabled and active".

* Tile type like "Save Config now" cannot be enabled, just triggered an imho doesn't qualify as either of these three former types - so another color (medium green or something completely else) makes sense to me.

* For tile types from submenus like "ev increment" that just trigger a setting menu it doesn't matter what the "default state" is (1ev? 2ev? who cares), it just should be clear that this neither enabled (green) nor disabled (grey) but simply a configurable tile - so the current bright green color is very confusing to me - another color would clear that up. This is for example also the case for items from the mainmenus like expo menu iso, aperture, picstyle, ...
Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 06:24:37 PM
I agree that bright green for things you can't turn off is confusing.
Title: Re: ML UI rationalization
Post by: Marsu42 on February 14, 2013, 07:05:41 PM
Quote from: stevefal on February 14, 2013, 06:24:37 PM
The system of colors is a language (or should be). It should apply to both so that what you learn from one applies to the other. This is my goal anyway.

Sure, I was just notifying you that I my comments only concerned the junkie menu and I didn't have a look at the recent icons at all.

Quote from: stevefal on February 14, 2013, 06:24:37 PM
In your example, 'EV increment' communicates bogus state through its ON/OFF green LED, and your confusion is a breakdown. But I don't think having no LED would create confusion. No LED and normal enabled tile color is what I recommend.

I recon you're very in depth with design, but if you arrive passing various theoretical stages at a proposal that creates confusion with simple /me, I dare to skip the whole process where you basically lost me (sorry) and still comment that bright green in junkie menu for non-on/off-switchable items is not helpful. I don't want to start with GNOME3 loosing their users again, but if is like real world shooting problems ("can I switch this on or off, or is it a setting?") interfere with design it's nearly like you're only talking to yourself here :-o

Edit: not to be misunderstood, now that we're beyond full screen submenus :-> I think most recent changes are great and will widen the ml userbase, but imho feedback from user experience now and further down the road has to be evaluated unbiased by a design philosophy but by the result for the final stage: shooting pictures and videos and not necessarily winning the "design of the year" award, though the latter would be a nice extra.
Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 07:19:08 PM
Edit: I think that good design is the mother of good results. Otherwise good design is pointless.
Title: Re: ML UI rationalization
Post by: scrax on February 14, 2013, 07:27:39 PM
I like a lot how it's going on this new UI, using it I found out thing that were not so clear to me even if I'm along time user.
Good work guys! thanks to all who participated in that discussion so far!

back to it, what do you think about merging the bulb ramping submenu with the Intervalometer one, since it's working only if intervalometer is enabled and now we have other way to have it two click away for quick toggle.

Another change in for quickness could be that in M mode on rebels bulb timer can set shutter time to bulb instead of give the warning that we have to do it manually, no?


btw: Is it just me or follow focus arrows are shown also in junkie menu?
Title: Re: ML UI rationalization
Post by: Marsu42 on February 14, 2013, 07:29:02 PM
Quote from: stevefal on February 14, 2013, 07:19:08 PM
I'm agreeing with you. The only question, which is debatable, is whether items that access ON things should show ON so that you know they are there.

I don't understand what items you're talking about exactly - could you give some examples? The items I don't think should be colored bright green (since they are settings and not on/off-switchable) are submenu items in "My Menu" plus mainmenu items like iso, aperture, picstyle, ... and imho in most cases it doesn't matters at all what "default" the ml devs happen to choose, so that's not a good basis for coloring the item. My suggestion is still to give these another color like medium green, that makes four background colors (1x grey + 2x green + 1x tba - how about black bg?) and should be under the confusion threshold.

But I'd also like other's opinions on that, it's great the ui is progressing at great speed but probably it's a good idea to isolate some "debatable" points in a list and then wait for ml users that don't visit the thread on a hourly basis.
Title: Re: ML UI rationalization
Post by: scrax on February 14, 2013, 08:38:23 PM
I've added ML Icon in my code, steve check if it could be improved,please: (https://bitbucket.org/600Dplus/magic-lantern-fixes/raw/51cdfb764e7b4fa0268006cb9995986af5b4b06c/icons/MLicon.png)

What I had more problem was the M it's still not really like the original but it's the closest I got.

(http://images.wikia.com/magiclantern/images/0/04/Custom_Mode_Setup.png)
Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 08:53:44 PM
Quote from: scrax on February 14, 2013, 08:38:23 PM
I've added ML Icon in my code, steve check if it could be improved, please

I think it looks pretty good but would want it bigger.

Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 08:56:17 PM
Quote from: Marsu42 on February 14, 2013, 07:29:02 PM
I don't understand what items you're talking about exactly - could you give some examples?

Bright green makes sense for these

- Shoot/Shoot Preferences
- Audio/Digital Gain
- Movie/Image Finetuning
- Movie/Movie Tweaks

not for these

- Audio/Input Source
- Expo/PictureStyle
- Expo/ LV Display
- Shoot/Silent Picture
- Focus/Focus Settings/Left-Right dir
- Focus/Focus Settings/Up-Down dir
- Overlay/Focus Peak/Filter Bias
- Overlay/FOcus Peak/Threshold
- Overlay/Cropmarks/Bitmap
- Overlay/Spotmeter/Unit
- Overlay/Spotmeter/Position
- Overlay/False color/Palette
- Overlay/Waveform/Size
- ...more
Title: Re: ML UI rationalization
Post by: Marsu42 on February 14, 2013, 09:17:50 PM
Quote from: stevefal on February 14, 2013, 08:56:17 PM
It's very hard in this phase because people are evaluating fragments in isolation, and drops that do not necessarily use the proposals as intended, have not yet implemented them or might not implement them.

Lots of it might be a moving target, but at the same time I guess some input from people using the current trunk might still be valuable - or you might be faced with more disappointment when it's a "do or die" proposal. And my only issue with the current junkie menu implementation is really only the green color for the setting tiles, otherwise I consider it near perfect (though I wouldn't be surprised if you've got some other ideas :-)).

The "normal" menu system is rather more complex and it's great you're trying to figure out a consistent approach for all the different ideas implemented in ml, hopefully without loosing the "toolbox" spirit - after all, it is assembled of various different ideas of different people, and it will continue to be a non-monolithic "bottom-up" product.

Quote from: stevefal on February 14, 2013, 08:56:17 PM
I'm glad people are seeing progress, but there's so much more that can be done. I know it can be much better and if we get there we'll be hearing more like scrax's "I found out thing that were not so clear to me even if I'm along time user". (thx scrax.)

At the same time, I hope you don't hear too many "But it's gotten dumbed down!" exclaims, but I'm positive it's on the right track at the moment - thanks for all your work!
Title: Re: ML UI rationalization
Post by: stevefal on February 14, 2013, 10:29:04 PM
Looking for a 'do it' icon:

(http://i.imgur.com/dhvvC5Z.gif)
Title: Re: ML UI rationalization
Post by: wolf on February 15, 2013, 01:36:55 AM
...
http://i.imgur.com/mPCG5b4.png?1
Title: Re: ML UI rationalization
Post by: stevefal on February 15, 2013, 02:21:32 AM
Quote from: wolf on February 15, 2013, 01:36:55 AM
...
http://i.imgur.com/mPCG5b4.png?1

I kinda like it..
Title: Re: ML UI rationalization
Post by: Marsu42 on February 15, 2013, 08:42:23 AM
Quote from: stevefal on February 14, 2013, 10:29:04 PM
Looking for an 'execute' icon for the center column.

The lightning icon looks like it has something to do about flash and/or I'll fry my camera with high voltage :-p ... wolf's version is more neutral, though not 100% intuitive. Aren't there any internationally acknowledged symbols for "start" or "on" like the power on symbol on just about any hifi equipment? http://www.clker.com/cliparts/d/9/0/3/1245640607507785093Soeb_Power_symbol.svg.hi.png
Title: Re: ML UI rationalization
Post by: a1ex on February 15, 2013, 04:56:16 PM
About booleans vs other types, what about:

Colors:
- booleans (just ON/OFF): use green LEDs
- integer: use blue indicators

Shapes:
- booleans: use round LEDs (green, of course)
- values in some min-max range (with some size-like meaning, e.g. audio gain, ISO, WB): use meters. Optional OFF position (the meter gets dimmed if the feature can be considered inactive, like WBShift 0 or bitrate 1.0x). Meters are blue.
- discrete choices (without any size meaning; show choice X out of N) - e.g. picture style, focus peaking algorithm: maybe a spin indicator (now looks like a pizza slice, before it looked like dice). Also blue. Better idea for this?

(http://a1ex.magiclantern.fm/bleeding-edge/meters-br.png)

(http://a1ex.magiclantern.fm/bleeding-edge/meters-bkt.png)

(http://a1ex.magiclantern.fm/bleeding-edge/junkie-blue.png)
Title: Re: ML UI rationalization
Post by: Pelican on February 15, 2013, 05:07:01 PM
Quote from: stevefal on February 14, 2013, 10:29:04 PM
Looking for an 'execute' icon for the center column.
Edit:
(http://pel.hu/down/Run.png)
Title: Re: ML UI rationalization
Post by: Pelican on February 15, 2013, 05:08:45 PM
Quote from: stevefal on February 14, 2013, 08:56:17 PM
My goal is to solidify a rational UI model for ML and then promote it across the system. The current system does not implement a consistent model (hence my post). It's very hard in this phase because people are evaluating fragments in isolation, and drops that do not necessarily use the proposals as intended, have not yet implemented them or might not implement them.

I'm glad people are seeing progress, but there's so much more that can be done. I know it can be much better and if we get there we'll be hearing more like scrax's "I found out thing that were not so clear to me even if I'm along time user". (thx scrax.)

working, working...
Agree 100%. Thank you very much for your effort to make ML GUI more rational and professional look.
Title: Re: ML UI rationalization
Post by: wolf on February 15, 2013, 05:13:36 PM
I don't know how does it look like in smaller form...

just try to increase the distance between you and your monitor ;-)
Title: Re: ML UI rationalization
Post by: 1% on February 15, 2013, 05:18:29 PM
Kinda like the blue

Briefly had a bug where black bars turned transparent in movie mode but that went away
Title: Re: ML UI rationalization
Post by: scrax on February 15, 2013, 05:39:17 PM
my proposal for meter icon:

(http://600dplus.bitbucket.org/hosted/metericon.png)

with more values bars can be thinner


For run icon: (http://leemason.github.com/NHP-Theme-Options-Framework/inc/glyphicons/glyphicons_150_check.png) or (http://flowlab.io//assets/icons/glyphicons_220_play_button.png) or simple this (http://imd.fbmd.h-da.de/images/glyphicons/png/glyphicons_223_chevron-right.png)
another way: (http://imd.fbmd.h-da.de/images/glyphicons/png/glyphicons_223_chevron-right.png)(http://imd.fbmd.h-da.de/images/glyphicons/png/glyphicons_223_chevron-right.png)
Title: Re: ML UI rationalization
Post by: a1ex on February 15, 2013, 05:49:35 PM
Good point. For non-size items I'd just slide the blue bar, like this:

(http://a1ex.magiclantern.fm/bleeding-edge/meters-bkt2.png)
Title: Re: ML UI rationalization
Post by: scrax on February 15, 2013, 06:11:17 PM
I've updated it slightly for values in some min-max range, the meter is now a little more long
Title: Re: ML UI rationalization
Post by: stevefal on February 15, 2013, 07:11:37 PM
Would like to know if toggling will be used everywhere there's an OFF or default.
Title: Re: ML UI rationalization
Post by: a1ex on February 15, 2013, 07:31:25 PM
Some meters have an OFF position (let's say flash exposure compensation, WB shift, bitrate, display gain), others don't (shutter speed, bulb exposure time, FPS, focus step size).

Same for discrete choices:
- some have OFF/A/B (Trap focus, Cartoon look)
- others OFF/A/B/C or OFF/A/B/C/D or more (REC/STBY notification)
- others just A/B but without the ON/OFF meaning (histogram scaling: linear/log; focus settings: left/right or up/down directions; defishing projection: rectilinear/panini)
- others have more choices, and can't be turned off (picture style, audio input source)
- edit: another type which was not addressed: Enable power saving: on standby, REC, or both. REC key actions: start, stop, or both.

I think it's important to show if a feature is active (highlighted somehow) or turned off (inactive).

I don't think that by setting picmode = standard you are "turning off" the picture style, or that by setting ISO auto you are "turning off" the ISO. But for bitrate, setting it at 1x means you are turning off ML bitrate modifications.
Title: Re: ML UI rationalization
Post by: stevefal on February 15, 2013, 08:24:39 PM
Great icon ideas. How about this..

(http://i.imgur.com/HpWSnxv.gif)
Title: Re: ML UI rationalization
Post by: screamer on February 15, 2013, 10:58:34 PM
had the same idea, what's better than a "play" icon?
+1 ;)
and i like all the other posts, the new gui concept is every day better. great work guys
Title: Re: ML UI rationalization
Post by: scrax on February 15, 2013, 11:34:05 PM
Is possible to have the border of the submenu rounded and same color of title background like in the example here? I think it's more modern that way.
(http://600dplus.bitbucket.org/hosted/metericon.png)
Title: Re: ML UI rationalization
Post by: wolf on February 16, 2013, 01:40:48 AM
I think that these variable icons only indicate the ability of changing a value for the item.
For values with an unknown range the icons are useful for displaying an approximately start, end and actual point of the value.
Didn't find yet an advantage in indicating that there are three values available.
So here the proposal which I tried to kept as simple as possible for not confusing anyone.

(http://i.imgur.com/GNTtN3r.png?1)

Edit: Think that the form of the icon shouldn't be round to display without color, think of the red mode, that these are different from the disc shaped ones.
(http://i.imgur.com/VNVYrKU.png)






Title: Re: ML UI rationalization
Post by: stevefal on February 16, 2013, 02:03:18 AM
I think there's too much in the left-hand icons, and trying to show choices (dice, etc) confuses me.
Title: Re: ML UI rationalization
Post by: wolf on February 16, 2013, 02:16:24 AM
QuoteIs the meter icon useful *just while setting it* for seeing how close you are to the beginning or end of a range?
For me it's sometimes helpful
Title: Re: ML UI rationalization
Post by: stevefal on February 16, 2013, 02:55:25 AM
Quote from: a1ex on February 15, 2013, 07:31:25 PM
I don't think that by setting picmode = standard you are "turning off" the picture style, or that by setting ISO auto you are "turning off" the ISO.
I agree. Was thinking more "defaulting" when it makes sense. ISO submenu has green/gray LEDs but Expo/ISO doesn't. I don't get that.

I also get confused because I never know if you figure things are done.
Title: Re: ML UI rationalization
Post by: a1ex on February 16, 2013, 09:08:56 AM
Of course, there are a few exceptions that are not consistent, you can't expect me to fine-tune every single menu item with every little change, no? (there are hundreds!)

But overall the menu looks quite logical to me. ML is designed for power users, so a bit of complexity shouldn't hurt. Can't figure out what each symbol means? just ignore it and look at the color: dark gray = OFF, some bright color = ON.
Title: Re: ML UI rationalization
Post by: basovandrey on February 16, 2013, 12:30:01 PM
Hello.
One question for you.
(http://rghost.ru/43836095/image.png) (http://rghost.ru/43836095.view)
Why "off" gray? In fact this tool is active and just disabled. This is only confusing.
Magic Zoom he correctly inactive and gray.
Propose that tools that are changing the button "Set", so make
(http://rghost.ru/43836286/image.png) (http://rghost.ru/43836286.view)
Title: Re: ML UI rationalization
Post by: Marsu42 on February 16, 2013, 12:45:59 PM
Quote from: a1ex on February 15, 2013, 04:56:16 PM
Colors:
- booleans (just ON/OFF): use green LEDs
- integer: use blue indicators

Nice solution, thanks! But why are some texts in junkie mode white like "AudioR" and and most other black when the feature is disabled (sorry if I didn't find the proposal concerning that)?

Plus a small suggestion: in junkie mode the black text on dark grey or dark green is rather hard to read for me, just a little brighter background might make it easier while preserving the distinction.

Title: Re: ML UI rationalization
Post by: a1ex on February 16, 2013, 12:50:25 PM
Gray OFF: see first post.

Junkie colors: #239, http://www.magiclantern.fm/forum/index.php?topic=4386.msg26451#msg26451

I also start to think that green for things that can be turned off, and blue for those that can't, is even more logical.

Readability fixes in progress.
Title: Re: ML UI rationalization
Post by: wolf on February 16, 2013, 01:12:35 PM
Quote from: stevefal on February 16, 2013, 02:03:18 AM
Overall I think it's a mistake to try putting too much information in the left-hand icons. It's a false promise if users really use the text area in the first place for non-binary information.

I also agree that trying to visualize non-numeric choices (pies, dice, etc) doesn't work.

Same here.
ML should be usable in the most basic display mode which is for me gray. I think colors shouldn't transport information. There are also color-blind users.
I propose to keep it as simple as possible, but not to simple and try not to display the status of an item with different methods twice at the same time.

This already existing menu without icons gives me all information I need. Maybe it could improved by others, but for me it's almost perfect.

(http://i.imgur.com/BNdarMs.png?1)
Title: Re: ML UI rationalization
Post by: stevefal on February 16, 2013, 02:22:11 PM
Quote from: a1ex on February 16, 2013, 09:08:56 AM
Of course, there are a few exceptions that are not consistent, you can't expect me to fine-tune every single menu item with every little change, no? (there are hundreds!)

Not sure if this means a few things don't need to change or hundreds do.

QuoteBut overall the menu looks quite logical to me. ML is designed for power users, so a bit of complexity shouldn't hurt. Can't figure out what each symbol means? just ignore it and look at the color: dark gray = OFF, some bright color = ON.

That answers my question. Thanks.
Title: Re: ML UI rationalization
Post by: Alex_TNT on February 19, 2013, 01:23:23 AM
gray dot = Not changed, Default
green dot = Changed, Active
red dot = Disabled, Inactive, Turned off




Title: Re: ML UI rationalization
Post by: scrax on February 22, 2013, 10:49:58 PM
Saw this and made me smile and think about ML too, so here you go:
(http://imgs.xkcd.com/comics/workflow.png)
Title: Re: ML UI rationalization
Post by: basovandrey on February 23, 2013, 05:31:15 PM
Hello.
(http://rghost.ru/44055951/image.png) (http://rghost.ru/44055951.view)

(http://rghost.ru/44055979/image.png) (http://rghost.ru/44055979.view)
Title: Re: ML UI rationalization
Post by: Greg on February 23, 2013, 11:51:32 PM
LV button is not used in the ML menu? (500D)

It's probably some error because the 500D does not have Q button.
Title: Re: ML UI rationalization
Post by: a1ex on February 24, 2013, 12:07:21 AM
Where's the error?
Title: Re: ML UI rationalization
Post by: Greg on February 24, 2013, 12:14:15 AM
Quote from: a1ex on February 24, 2013, 12:07:21 AM
Where's the error?
https://bitbucket.org/hudson/magic-lantern/commits/31a459b31637aa51e3572595662cf87da799f29f


Edit :
Problem solved thanks ;)
Title: Re: ML UI rationalization
Post by: Greg on February 24, 2013, 01:23:25 AM
Where is it in the new menu?
Stack focus -> Trigger mode: Take a pic
Title: Re: ML UI rationalization
Post by: scrax on February 24, 2013, 05:00:40 AM
Quote from: basovandrey on February 23, 2013, 05:31:15 PM
Hello.
(http://rghost.ru/44055951/image.png) (http://rghost.ru/44055951.view)

(http://rghost.ru/44055979/image.png) (http://rghost.ru/44055979.view)

I like it, similar to full screen submenus, but it gives more the idea of a submenu maybe.
Title: Re: ML UI rationalization
Post by: Pelican on February 24, 2013, 09:34:02 AM
Quote from: basovandrey on February 23, 2013, 05:31:15 PM
Hello.
I like it.
Title: Re: ML UI rationalization
Post by: Marsu42 on February 24, 2013, 10:00:05 AM
Quote from: scrax on February 24, 2013, 05:00:40 AM
I like it, similar to full screen submenus, but it gives more the idea of a submenu maybe.

Well, since unfortunately :-( the nice transparency is gone and only a black background remains the pop up menu idea is perverted and I guess it makes sense to use all available space for the submenu - however I still like the current approach better since there's at least the static top navigation part of the screen that doesn't change creating less visual confusion, maybe that's just me :-\ ... my 2 cents is to restore the transparency.
Title: Re: ML UI rationalization
Post by: Alex_TNT on February 25, 2013, 11:10:45 AM
I agree about transparency, as a graphic designer, the current "theme" looks like an MS-DOS interface.

Not the entire menu to be hard to see.

Quote from: Marsu42 on February 24, 2013, 10:00:05 AM
Well, since unfortunately :-( the nice transparency is gone and only a black background remains the pop up menu idea is perverted and I guess it makes sense to use all available space for the submenu - however I still like the current approach better since there's at least the static top navigation part of the screen that doesn't change creating less visual confusion, maybe that's just me :-\ ... my 2 cents is to restore the transparency.
Title: Re: ML UI rationalization
Post by: Marsu42 on February 25, 2013, 08:01:01 PM
Quote from: Alex_TNT on February 25, 2013, 11:10:45 AM
I agree about transparency, as a graphic designer, the current "theme" looks like an MS-DOS interface.

Lol, I'd like to see you discuss with stevefal :-> who argued that the "cleaner" menus are the one sane design approach - not being a graphic designer I was unable to deny that, so it's nice there are different opinions here.

Btw I really like most of the new ui and stevefal's junkie mode, however the current submenu design is neither here nor there, so if I count the recent posts it's 2:2 full screen submenus vs. old school popup+transparency :-o
Title: Re: ML UI rationalization
Post by: Alex_TNT on February 25, 2013, 08:58:06 PM
Quote from: Marsu42 on February 25, 2013, 08:01:01 PM
Btw I really like most of the new ui and stevefal's junkie mode, however the current submenu design is neither here nor there

As the current menu may look old, I have to agree that currently there's no other better design that the current one.
It's not like building an website or new app. There are limitations.
Again I have to agree with you
Title: Re: ML UI rationalization
Post by: basovandrey on March 02, 2013, 02:37:13 PM
Developers stop, think again.
For photographers need a simple, intuitive interface.
Instead of an abundance of circles, stars, rectangles of different colors.
When you do not know what will happen if you press the SET button.

(http://www.e1.ru/fun/photo/view_pic.php/p/0b8ade395a836912f985b363e3fd8f59/view.pic)
Title: Re: ML UI rationalization
Post by: Michael Zöller on March 02, 2013, 05:06:32 PM
Quote from: basovandrey on March 02, 2013, 02:37:13 PMWhen you do not know what will happen if you press the SET button.
You have not actually used the "new" interface, have you?
Title: Re: ML UI rationalization
Post by: 1% on March 02, 2013, 05:35:14 PM
Works alright compared to the old menus. Indications are much clearer if a bit overzealous. Broke adv. bracketing (video), the other focus stacking we had, property viewer, memory browser (somewhat fixed), separate wav stuff on 600D (this one easy fix I think).

I find myself hitting the trash button and reloading the whole menu vs hitting menu to go back when holding camera with one hand tho.

Junkie mode is convenient with 2 wheels, you can really zoom through it and glad you can hide things separately.

Overall, I'd say its a win, even if a bit painful. Can't really be so stuck on the menus either way, they're just there to let you get your shit done.
Title: Re: ML UI rationalization
Post by: basovandrey on March 02, 2013, 07:14:22 PM
Quote from: Michael Zöller on March 02, 2013, 05:06:32 PM
You have not actually used the "new" interface, have you?
Old menu.
for example menu DISPLAY. Press SET
LV BRIGHTNESS (good)
LV CONTRAST (good)
LV SATURATION (good)
LV DISPLAY GAIN (?) - Press Q -? Please do the as (LV SATURATION). There only 8 values​​.
COLOR SCHEME (good)
CLEAR OVERLAYS (good)
DEFISHING (!?) - Press Q - there only 2 values​​. Please do the as (CLEAR OVERLAYS).
ANAMORPHIC (!?) - Press Q - there only 5 values​​. Please do the as (CLEAR OVERLAYS).
ADAVANCED SETTING (good)

New Junkie mode i can not understand, so i use the old menu/

thanks for understanding
Title: Re: ML UI rationalization
Post by: wolf on March 02, 2013, 08:25:56 PM
@basovandrey
nice visualization of the complex looking menu. I feel that way too.

For my personal use I disable the icons in the source code. I also don't use the junkie menu, there are too many greys and colors and I can't get used to the different heights of the fields. But, I guess the people like it the way it is better and I have to accept it.

All in all ML is great tool for my EOS camera. I think it's really useful to trigger the camera with a wave gesture on a tripod not to mention the other great features.
 


Title: Re: ML UI rationalization
Post by: basovandrey on March 03, 2013, 03:58:29 AM
ML is very, very, very great software. But I'm talking about the management that is they are complex as the management of the spacecraft.

continued MENU DISPLAY.
ADVANSED SETTING Press SET open the submenu. This confuses my because in the menu ANAMORPHIC opens a submenu only button Q.

Icons...
(http://www.e1.ru/fun/photo/view_pic.php/p/cc887c309acd40fe3e11229c0265961b/view.pic)
(http://www.e1.ru/fun/photo/view_pic.php/p/8abaf41da1137b8134132ed9b3bd7409/view.pic)
Title: Re: ML UI rationalization
Post by: basovandrey on March 03, 2013, 03:41:58 PM
proposal to replace these icons are (http://www.e1.ru/fun/photo/view_pic.php/p/1d94359255fcd8d136cf780b03be8af4/view.pic)
line is visible only when you hover over.
(http://rghost.ru/44242446/image.png)
Title: Re: ML UI rationalization
Post by: wolf on March 03, 2013, 06:53:46 PM
@a1ex
like the new square icons. [:-)]

I don't understand why the half circle indicator is sometimes blue and sometimes green. Because I found it in the script parameters I think it's a bug.
Title: Re: ML UI rationalization
Post by: g3gg0 on March 03, 2013, 08:28:09 PM
Quote from: basovandrey on March 03, 2013, 03:58:29 AM
ML is very, very, very great software. But I'm talking about the management that is they are complex as the management of the spacecraft.

well, for this reason there are two different visualization types for the menu.
the plain old DOS-look and the star trek look ;)
Title: Re: ML UI rationalization
Post by: basovandrey on March 04, 2013, 05:04:21 PM
Alex menu DISPLAY it became very good.
let me write some more

MENU AUDIO 
submenu DIGITAL Gain - LEFT  DIGITAL GAIN please do pickbox-friendly. There only 7 values​​.
DIGITAL Gain - LEFT  DIGITAL GAIN please do pickbox-friendly. There only 7 values​​.

MENU EXPO
submenu ISO - CANON DIGITAL ISO please do pickbox-friendly. There only 5 values​​.
submenu ISO everywhere is incorrect icon. !?
submenu PICTURESTYLE - SHARPNESS please do pickbox-friendly. There only 8 values​​.
submenu PICTURESTYLE - CONTRAST please do pickbox-friendly. There only 8 values​​.

MENU OVERLAY
submenu MAGICZOOM - SIZE  incorrect icon. !?

MENU MOVIE
GRADUAL EXPO  please do pickbox-friendly. There only 7 values​​.
submenu IMAGE FINETUNING - ML DIGITAL ISO incorrect icon. !?

MENU SHOOT
submenu ADVANCED BRACKET - EV INCREMENT please do pickbox-friendly. There only 8 values​​.
submenu MOTION DETECT - DETECT SIZE incorrect icon. !?

MENU FOCUS
FOLLOW FOCUS please do pickbox-friendly. There only 2 values​​.

thanks for understanding
Title: Re: ML UI rationalization
Post by: 1% on March 04, 2013, 05:07:27 PM
On all cameras or just for you?

*not a fan of pickbox at all for numerical values that increment.
Title: Re: ML UI rationalization
Post by: basovandrey on March 04, 2013, 05:22:51 PM
Quote from: 1% on March 04, 2013, 05:07:27 PM
On all cameras or just for you?

*not a fan of pickbox at all for numerical values that increment.
it is only on the values ​​when it is convenient and does not disturb do not complicate management
Title: Re: ML UI rationalization
Post by: Marsu42 on March 04, 2013, 08:04:03 PM
Quote from: 1% on March 04, 2013, 05:07:27 PM
*not a fan of pickbox at all for numerical values that increment.

+1 with two exceptions:

* ISO values should go into a dropdown because they are basically a setting and not continuous, iso just happens to be numerical

* The 8 values of "EV increment" for bracketing should also be a dropdown because "frames"  above is and also the rest of this submenu
Title: Re: ML UI rationalization
Post by: a1ex on March 04, 2013, 08:29:39 PM
QuoteGRADUAL EXPO  please do pickbox-friendly. There only 7 values​​.

I highly doubt you want to think which of these values you need every time you are using this feature...
Title: Re: ML UI rationalization
Post by: basovandrey on March 09, 2013, 07:46:56 AM
variants of icons

(http://www.e1.ru/fun/photo/view_pic.php/p/2f7541f6f824adb0cb24452e547d8915/view.pic)
Title: Re: ML UI rationalization
Post by: basovandrey on April 14, 2013, 09:41:49 AM
Propose to change the sequence in the custom menu: first press of the set to hide what is not in use, and the second to add to my menu.

My example: hide 51 points and added to my menu 5
up to 51 * 2 +5 = 107 button clicks set
after 51 +5 * 2 = 61 button clicks set
Title: Re: ML UI rationalization
Post by: basovandrey on June 13, 2013, 03:42:19 PM
Hello. Suggest to give up the submenu. Thus.
(http://www.e1.ru/fun/photo/view_pic.php/p/32051c8872505f79d3522b154040845b/view.pic)

(http://www.e1.ru/fun/photo/view_pic.php/p/9da8963871acbdde156ae1715f99b748/view.pic)

(http://www.e1.ru/fun/photo/view_pic.php/p/98e35b0016ed7004e3570422e92a19e6/view.pic)

(http://www.e1.ru/fun/photo/view_pic.php/p/ffd282925f7a3706300ffe57103255b5/view.pic)
Title: Re: ML UI rationalization
Post by: Marsu42 on June 13, 2013, 03:58:43 PM
Quote from: basovandrey on June 13, 2013, 03:42:19 PM
Hello. Suggest to give up the submenu.

My quick first impression: interesting idea, because it'd be a good way to further nest structures if required.

The tree approach also could be quicker if ml would automatically close the "submenu" tree once you move away from a "submenu" item, so you could save the current "back to main menu" q press (though q still should close the tree from any submenu item if the user wants it). Also after opening the tree with Q the cursor should auto-jump to the first item or you have to q-down all the time.

Possible issue that come to my mind, ymmv:
* a tree might be more confusing since now everything looks like one big config (like gnome's settings file...) even though it's hierarchical - submenus make a clearer distinction between main item and config.
* the tree really looks crappy in junkie mode, maybe the submenus could/should be kept there?
* some submenus have a lot of items filling the whole screen, so a submenu might look cleaner than a big tree expanding
* the dead space on the left leaves even less room for the submenu item discription - it's often crammed as it is now.
Title: Re: ML UI rationalization
Post by: basovandrey on June 14, 2013, 04:46:52 PM
Quote from: Marsu42 on June 13, 2013, 03:58:43 PM
* the dead space on the left leaves even less room for the submenu item discription - it's often crammed as it is now.
Example. a wide menu is suitable 1:1
(http://www.e1.ru/fun/photo/view_pic.php/p/f149ee54ee817021bceff6f6a601a7dc/view.pic)

(http://www.e1.ru/fun/photo/view_pic.php/p/77ea3b19a5921c4b1816d2893a3ac9c7/view.pic)

- icon tabs when you open a submenu, less bright
- new submenu, you can open without closing the previous
Title: Re: ML UI rationalization
Post by: brapodam on July 19, 2013, 03:23:15 AM
I have a quick suggestion on the UI.

Change "Customize Menus" under Preferences tab to "Customize 'My Menu'" or "Customize Favourites Tab". While it may be obvious to some people what "customize menus" mean, it was not immediately obvious to me what it did, and I only "found" the feature accidentally. Such a useful feature should not be hidden; it should be immediately obvious even to first time users of ML.
Title: Re: ML UI rationalization
Post by: a1ex on September 06, 2013, 08:11:30 AM
@stevefal:

Just remembered a little inconsistency in the UI regarding bulb timer. Scenarios:

- You enable bulb timer, you configure the bulb duration there => it works, fine.

- You enable intervalometer, you are in bulb mode. Currently it uses the bulb timer duration (even if bulb timer is off). So, a setting from submenu gets used if the main menu entry is turned off.

What solution would you choose?

- take a 1-second exposure if bulb timer is off (or use some other reasonable value?)

- move bulb timer duration in a new menu - e.g. Bulb preferences, near Shoot preferences (but you lose convenience of adjusting it near the bulb timer where you enabled it)

- move duration in a new menu, but also keep a mirrored setting in the bulb timer submenu? (may create confusion since there are two different menus that do the same thing)

- ???

Same with auto ETTR (you know the story).
Title: Re: ML UI rationalization
Post by: stevefal on September 07, 2013, 02:47:25 AM
Sorry, just saw this (no notifications).

For the Bulb/Intervalometer case, two choices, assuming current structure.

1) put a new independent 'Exposure duration' setting in Intervalometer menu
2) put a shared setting 'Exposure duration' setting in both Intervalometer and Bulb Timer menus. Note in lower help that "Setting is shared with <other feature>"

I think the only argument for #2 is if intervalometer users very commonly use the same exposure duration in both features. Perhaps they always take take a test shot using bulb timer, and then setup the Intervalometer using the same setting. A shared setting makes that official.

and then 'the works":

3) In Intervalometer, offer:

   Exposure duration
         Same as bulb timer (5s)
         1s
         2s
         ...etc
Title: Re: ML UI rationalization
Post by: a1ex on September 07, 2013, 05:33:11 AM
Exposure duration is normally Canon shutter speed. Bulb timer is not that widely used, since you rarely need exposures longer than 30 seconds. So, a menu for this under Intervalometer looks a bit weird.

If you enable both bulb timer and intervalometer, it's obvious what you want to do. But if you are in bulb mode and you only enable intervalometer, there's no Canon shutter speed that you can use (so I used the bulb timer setting because that was the only reasonable value I could think of).
Title: Re: ML UI rationalization
Post by: stevefal on September 07, 2013, 06:44:35 AM
Ok I didn't even understand what you were asking. I thought you wanted a way to set long shutter speeds (exposure duration) in Intervalometer, assuming that very long exposures might be wanted sometimes - star-fields etc.

The root problem is that "Bulb timer" is a misnomer. "Bulb" by definition, is not a timed exposure at all, but manual exposure. The feature is really an extra long exposure. "Long exposure"

So by the true definition of "bulb" you should not be able to use Intervalometer in Bulb mode, because it doesn't make sense to use a manual exposure when doing time-lapse.

If you say ML needs Bulb mode to implement extra long exposures, then I'd say, answering your question, that if the user enables Intervalometer in Bulb mode, they should be told to enable Bulb timer (thereby providing long exposures), or exit Bulb mode in order to choose a normal shutter speed normally.

It's best to avoid perversion of understood concepts.
Title: Re: ML UI rationalization
Post by: a1ex on September 07, 2013, 06:49:43 AM
So, would it make sense to rename Bulb timer to Long exposure?
Title: Re: ML UI rationalization
Post by: xNiNELiVES on September 07, 2013, 07:30:39 AM
Well your the admin can't you apply the change? Nice of you to check with the community here though. Yeah it would make sense to change the name.
Title: Re: ML UI rationalization
Post by: stevefal on September 07, 2013, 07:33:22 AM
That hinges on implementation. Does long timed exposure rely on the camera being in bulb mode?

- long exposure relies on bulb mode
      call it "Bulb timer"
      in bulb mode, when intervalometer is enabled, warn "In bulb mode you must turn on 'Bulb timer' to use intervalometer"

- long exposure does not rely on bulb mode
      call it "Long exposure"
      lock out "Long exposure" and Intervalometer in bulb mode (neither makes sense in bulb mode)
Title: Re: ML UI rationalization
Post by: a1ex on September 07, 2013, 07:37:55 AM
Yes, it does (try it).
Title: Re: ML UI rationalization
Post by: stevefal on September 07, 2013, 08:39:17 AM
Yes, I realize it is currently disabled outside bulb mode. But the question is whether it *must* rely on bulb mode. If so, then the "Bulb timer" concept is sort of necessary. Therefore:

- long exposure relies on bulb mode
      call it "Bulb timer"
      in bulb mode, when user tries to enable intervalometer, warn "In bulb mode you must turn on 'Bulb timer' to use intervalometer".

If the user doesn't want that, they can leave bulb mode, and use standard timed shutter speeds.
Title: Re: ML UI rationalization
Post by: a1ex on March 19, 2018, 10:40:36 PM
Even if this thread is old, I think it's still the best place to discuss UI changes.

Suggestion under review: long-press SET/Q to open ML submenus on EOS M (https://bitbucket.org/hudson/magic-lantern/pull-requests/722/eos-m-long-press-set-q-to-open-submenus/).
- advantage: using the Q button as on all other models
- disadvantage: long-press handling means short-press actions will be executed on release (slower feedback; I've found it unnatural after playing with it for a while)

Alternative:
- use the PLAY button to open submenus, in addition to Q (either only on EOS M, or possibly on all models)
- currently, this button decrements values for historical reasons, but I've never found myself using it... until Walter noticed it:

Quote from: Walter Schulz on March 15, 2018, 03:43:11 PM
4.) Triangle icon. Used to start an action ("Play Button") and used show/hide menu options. Seen in MLV lite submenu: Playback will start playback and Advanced ... will show hidden items. Not that great IMO.

Another issue: many users end up pressing the MENU key and then they don't know how to go back.
Suggestion: disable the Junkie menu (anyone using it?) and just make the MENU key go back (until exiting ML menu).

Disabling the Junkie menu would save 4.5K of RAM (might be useful for e.g. 1100D).

MENU could also be reused for opening ML submenus, but that's a bit inconsistent with Canon menus (where it always goes back).
Title: Re: ML UI rationalization
Post by: nikfreak on March 20, 2018, 04:45:17 PM
+1 for removing the Junkie menu.
Title: Re: ML UI rationalization
Post by: Walter Schulz on March 20, 2018, 05:07:06 PM
Wasn't there a suggestion about using "junkie tech" to enable touchscreen controls for ML?
Title: Re: ML UI rationalization
Post by: a1ex on March 20, 2018, 05:12:25 PM
There was (https://www.magiclantern.fm/forum/index.php?topic=18544.0), but the interest in pushing it forward seems pretty low (https://www.magiclantern.fm/forum/index.php?topic=18884.msg192812#msg192812).

None of my cameras has touch screen, btw, so it will take a while until I'll get it working in QEMU.
Title: Re: ML UI rationalization
Post by: a1ex on March 21, 2018, 02:56:20 PM
Some UI updates committed to lua_fix (will be in the next build; feel free to compile from source for early testing):

- EOS M has SET/Q, just like 100D; now this button is handled in the same way on both models:
    -> short press = SET (including ETTR trigger, exposure presets and whatever else uses the SET key in ML)
    -> long press = Q (Canon settings)
- 100D, EOSM: hold SET at startup to bypass ML (just like all other models; previously, these two used INFO)
- all models: disabled the Junkie menu (can be re-enabled with FEATURE_JUNKIE_MENU in features.h); MENU just goes back
- all models: PLAY opens submenus (in addition to Q)

All of the above were tested in QEMU.

Let me know how it feels (I can revert any of them if needed).
Title: Re: ML UI rationalization
Post by: aprofiti on September 13, 2018, 02:46:49 PM
Just wondering if could be possible to map long press of Joystick as a shortcut to quick open a user customizable ML submenu.

Currently from lua_fix changes it play an animation and then simply open last ML category tab.

As example it could be used in conjunction with manual lenses to quickly changes Aperture and Focal Length values by pointing to his specific submenu.
Title: Re: ML UI rationalization
Post by: a1ex on September 13, 2018, 03:19:53 PM
Right, currently it simply opens ML menu. Sometimes I use the camera with one hand, so it's nice to be able to navigate ML menu without reaching to the other side for the Delete button.

There are a couple of shortcuts that go to specific menu entries. For example, ISO + Q opens the Expo menu, and AF mode + Q opens the Focus menu. I've even forgotten the shortcut for these and had to look them up in the source, so it's probably time for some cleanup.

Some more ideas about shortcut keys: https://www.magiclantern.fm/forum/index.php?topic=7816

For lens parameters, the DOF button would have been nice; unfortunately it's not triggered at all with a manual lens.




Misc notes, possibly unrelated:

- On 5D2, WB + SET triggers ML's auto white balance. I remember some people found this less than handy, as they were expecting to start recording instead.

- I liked a tweak from a script in the lua_touch branch: opening ML menu by dragging the finger from top to bottom, and was thinking to enable it by default.
Title: Re: ML UI rationalization
Post by: aprofiti on September 13, 2018, 04:09:15 PM
From a quick check it appears to do nothing when pressing ISO + Joistick (Q equivalent) or AF mode + Joistick on 50D.
Does this do not works on camera without dedicated Q button?

Quote from: a1ex on September 13, 2018, 03:19:53 PM
For lens parameters, the DOF button would have been nice; unfortunately it's not triggered at all with a manual lens.
Maybe can be used with Chipped Adapter? If I switch to LV and press DOF button, it will hang a moment (where it will close aperture with an AF Lens) and doesn't append if I simply remove lens, like if it is receiving interrupt from button press event

Extending with touch interface could also be useful for some users with a compatible camera
Title: Re: ML UI rationalization
Post by: a1ex on September 13, 2018, 07:05:23 PM
These shortcuts are not enabled on cameras without Q button (see menu.c, handle_quick_access_menu_items).

My experience with third party chipped adapters was not the best; I'm not sure the behavior is even repeatable. The DOF button is also not easiest to detect, as it first sends a half-shutter press and then - after several hundred ms - it triggers the DOF property.
Title: Re: ML UI rationalization
Post by: scrax on March 09, 2019, 04:53:01 PM
Quote from: a1ex on September 13, 2018, 03:19:53 PM
Right, currently it simply opens ML menu. Sometimes I use the camera with one hand, so it's nice to be able to navigate ML menu without reaching to the other side for the Delete button.

There are a couple of shortcuts that go to specific menu entries. For example, ISO + Q opens the Expo menu, and AF mode + Q opens the Focus menu. I've even forgotten the shortcut for these and had to look them up in the source, so it's probably time for some cleanup.

Some more ideas about shortcut keys: https://www.magiclantern.fm/forum/index.php?topic=7816

For lens parameters, the DOF button would have been nice; unfortunately it's not triggered at all with a manual lens.




Misc notes, possibly unrelated:

- On 5D2, WB + SET triggers ML's auto white balance. I remember some people found this less than handy, as they were expecting to start recording instead.

- I liked a tweak from a script in the lua_touch branch: opening ML menu by dragging the finger from top to bottom, and was thinking to enable it by default.

years agou i've added some shortcut to ML menus for 600D and got used to them, I've now updated those changes to unified here (https://bitbucket.org/600dplus/magiclantern_eyefi_trick_cleanup/branch/feat_more_quick_access#diff) in those days.
I've not made any PR because I was thinking to be the only one needing it, but if. there is need we can define together what shortcut to use

for now they are triggered by trash button when in some gui mode:


FOCUS    + trash = TrapFocus
WB       + trash = WB
ISO      + trash = ISO
PICSTYLE + trash = GlobalDraw
Q_ACTIVE + trash = Beep, test tone


I'm also used to the junkie menu and find useful to remove all menu that are set and forget and keep only stuff that has to be switched on and off here, only for photo.
I have like 3 or 4 column only with max 9 options shown.
It's really easy to use like this and fast to change setting.

One nice improvement imho will be an option to remove the info bar under it when in junkie mode since it's an advanced feature an (at least as I use it) should provide a more clean approach for user that are not first time user, not?
Without the bottom bar with the help strings it will have more space to render the buttons bigger and be more clean.

NOTE on the picture attached: since i've finally manged to port my old old old PR for c-modes and gui options to a module i can now change fast K and othr basic photo setting without ML menu so the first four blue button are not needed anymore making more simple and faster junkie mode ever for me :D

Another great feat i think could be if junkie mode differentiate from photo mode and video mode (sort of like canon does), so to being able to have different buttons enabled for the two mode.
In my junkie menu I have 15 button displayed for photo only, in movie mode are all useless apart from focus settings, so having junkie mode switch to aother set of configuration in movie mode will let me use it also there instead of standard ML menu.
Title: Re: ML UI rationalization
Post by: a1ex on March 09, 2019, 05:09:28 PM
Heh, that means I need to re-enable the Junkie menu; possibly as a menu option. It's already disabled from the lua_fix builds.

The info bar at bottom is mostly a way to print the complete description of each menu, since it usually doesn't fit in the small "junkie" box. Not sure what to do with it; I'd still print the full name and value of the menus somewhere, maybe in smaller font or as tooltip?

The delete button makes more sense in various GUI modes, though I'd probably just pop the ML menu and scroll to the relevant place (and require a confirmation with SET). For example, WB + Delete could open the White Balance submenu from ML menu. Other suggestions welcome.

The good news is that I'll now be able to test it in QEMU, since the GUI modes are pretty much model-specific.
Title: Re: ML UI rationalization
Post by: scrax on March 09, 2019, 05:21:31 PM
Quote from: a1ex on March 09, 2019, 05:09:28 PM
The delete button makes more sense in various GUI modes, though I'd probably just pop the ML menu and scroll to the relevant place (and require a confirmation with SET). For example, WB + Delete could open the White Balance submenu from ML menu. Other suggestions welcome.

The good news is that I'll now be able to test it in QEMU, since the GUI modes are pretty much model-specific.

About trash button is just what I thought and added to my mod of ML, trash button already means ML and since in those GUIMODE was unused I've added shortcut to related options in ML when possible and other arbritrary choices for other dialog screen,


about the bottom bar, i was thinking that only the grey area should not be shown, not the black one with the name of the menu entry, that should stay as you explained is needed there.
Title: Re: ML UI rationalization
Post by: scrax on March 18, 2019, 11:22:39 PM
Quote from: a1ex on March 21, 2018, 02:56:20 PM
- all models: disabled the Junkie menu (can be re-enabled with FEATURE_JUNKIE_MENU in features.h); MENU just goes back

not sure where to post this but in menuindex.c there is #if instead of #ifdef and won't compile if junkie menu is re enabled in features.h
Title: Re: ML UI rationalization
Post by: garry23 on January 25, 2021, 07:32:44 PM
I've just got another 'new' EOSM and am setting it up with the lates Lua fix.

Tested my DOFIS and MUSIC scripts, all ok.

But I can't turn off the long SET simulated Q feature, that I thought was in the junkie menu, that I can't find.

I need access to the SET, as my script uses a long press here, that I need to control.

Can anyone suggest how to switch off the long SET Q in the EOSM.

Cheers

Garry
Title: Re: ML UI rationalization
Post by: garry23 on January 25, 2021, 11:53:17 PM
Looks like I can't switch off the ML owned long SET press on the EOSM, so I've moved to using the touch feature on the EOSM.