supplierdeeply

CHDK UI version 2.0 ?

  • 542 Replies
  • 33149 Views
  • Publish
    CHDK UI version 2.0 ?
    « on: 26 / May / 2012, 19:47:51 »
    Advertisements
    Based on a recent conversation here, I'd like to open discussion about CHDK ease of use and its user interface.  This is partly based on a discussion I found on another camera forum by people who had found and loaded CHDK but stopped using it because the menus were just too complex to navigate.

    Over the years, I've noticed that interfaces for new software products are often heavily skewed towards setup and configuration functionality.  This seems to be a natural reflection of the developers focusing on the parts of the code they actually use as they create a new system.   But it does not always translate to a great user experience.

    For example, the CHDK menu frequently required quite a bit of menu clicking to get to frequently needed functionality.   And the menus are logically grouped by function with setup & configuration options intermingled with options actually used during shooting.

    The "user menu'" feature in CHDK partially addresses this.  (Except that its currently broken in the new dev / unstable version).  And the use of the Func/Set button to go straight to the scripting menu helps too.

    IMHO,  changing UI code is usually fairly easy (although tedious at times).  Much harder is coming up with something that people generally consider "easy to use".  Just watch people try to use an Android tablet instead of an iPad if you want an example.

    On a related note,  the CHDK philosophy has been to implement shooting functionality in scripts.  This has many advantages but makes it somewhat complicated to quickly switch between shooting modes.  Again,   the trade-off between ease of use and flexibility.

    So what would people like to see ?   

    HDR,  Motion detection and intervalometer as built-in functions ? 

    How about the ability to fully customize the menus ?  Or at least to hide things you don't use ? 
    Or separate setup menu functionality from shooting functionality ? 

    How about having the menus open as soon as you hit the <ALT> key ?   Right now the only other thing you can do is start a script while in <ALT> mode.  And as that is done via the shutter button,  you could just make that happen with the menus open.

    Or maybe we just accept that CHDK is a hack and not worth "polishing" ?





     
     

    *

    Offline dvip

    • ****
    • 451
  • Publish
    Re: CHDK UI version 2.0 ?
    « Reply #1 on: 26 / May / 2012, 21:13:51 »
    I haven't seem much benefit from all the ISO stuff on
    the menu system. Unless this works fine on some
    cameras and not on mine (A590IS). Perhaps all those
    can be removed or hidden? You can always do ISO
    bracketing with a script.

    Override Shutter Speed and Override Aperture Value
    should be one of the first things you see. This should
    be helpful too for those cameras that don't have M
    mode. Perhaps also there, we can have presets like
    1/2500...1/4000 or F2.6...F11... a customized Shutter
    or Aperture for fast access and use. A customized
    focus distance?

    RAW/DNG, Histogram and Zebra are fine the way they are.

    Well, those are some ideas...


    *

    Offline reyalp

    • ******
    • 9858
  • Publish
    Re: CHDK UI version 2.0 ?
    « Reply #2 on: 27 / May / 2012, 00:27:19 »
    A complete UI re-work could certainly be nice. However, doing it sanely would require a lot more than just shuffling some menu options around or some cosmetic GUI changes, it would be a major re-write. One big improvement would be to make the shortcuts more sane and configurable, but this requires a significant re-write of the keyboard system so it isn't done with ifdefs scattered all over the code.

    Making the menu open as soon as you hit alt would completely break the shortcuts. If the shortcuts were assignable, that could be a big improvement. A further step in this direction would be to allow the user to pick a few things that would be adjustable on the initial alt screen, something like the canon func menu.

    Quickly selectable presets are also a great idea.

    Regarding scripts: IMO, it would make far more sense to let scripts integrate with the UI more rather than bloat the core code with "script" functionality (although I suppose you could do the same thing with modules instead). If you are going to re-write the UI anyway, you may as well do script integration from the start. If I were doing a ground-up redesign, I'd be strongly tempted to put menu definitions, UI logic etc entirely in Lua.

    RE the user menu: It's broken and needs to be fixed, but the reason we have a development version and a stable version is so things can be broken for more than a couple revisions.
    Don't forget what the H stands for.

    *

    Offline msl

    • *****
    • 1173
    • A720 IS, SX220 HS 1.01a
      • CHDK inside
  • Publish
    Re: CHDK UI version 2.0 ?
    « Reply #3 on: 27 / May / 2012, 05:41:23 »
    I'm not a friend of a complete new CHDK Ui structure! It is a historically grown piece of software over more than 5 years.Then we could also say, UI version 2.0 only for DryOS. It would much easier for the further development.

    In general we need a better description of the CHDK UI and maybe some improvements.

    Useful would be the revision of the CHDK menu structure and UI, e.g.

    - availability of the remote functions in main menu
    - an easy to use (user) menu (editable on PC with a config file)
    - in-built functions for motion detection and timelapse (most important CHDK functions in addition to HDR!)
    - uniform color system (Different colors are a good way to simply display informations.)
    - understandable functions (see e.g. disable overrides - really difficult to understand; only one override system for tv; maybe also 'Market' ISO anstead real ISO)
    - selectable presets (editable on PC with a config file)
    - set layout editor (for me one of the most important (GUI) functions) in the center point with more options

    Open CHDK menu over ALT button and menu button is a proven concept and should not be changed. The problem is more the ALT button since cameras have no print button.

    msl
    German CHDK pages:  CHDK forum | CHDK inside | CHDK Twitter News by msl | Download CHDK-DE (Autobuild)
    Note: SDM violates the GPL rules!


    *

    Offline blackhole

    • ****
    • 429
    • A590IS 101b
      • Planetary astrophotography
  • Publish
    Re: CHDK UI version 2.0 ?
    « Reply #4 on: 27 / May / 2012, 10:20:32 »
    Based on a recent conversation here, I'd like to open discussion about CHDK ease of use and its user interface.  This is partly based on a discussion I found on another camera forum by people who had found and loaded CHDK but stopped using it because the menus were just too complex to navigate.


    My opinion is that the biggest problem of new users is what they do not want make an effort in finding and reading the user manual.
    Maybe it would help rename "Read Me" file in another name, for example, the name "User Quick Start Guide" might persuade the user to open a file and view the links contained in a file.
    I am not a programmer and can not talk too much about making a new UI, but from conversations I had with new users which asked me for some advice I have concluded that almost nobody not open a "Read Me" file because the filename is not associated as something important , and no one knew that there is a link to "User Quick Start Guide".

    Amendments proposed by msl me look very useful.

  • Publish
    Re: CHDK UI version 2.0 ?
    « Reply #5 on: 27 / May / 2012, 12:59:54 »
    Some good discussion here - thanks to all.  Here's a few of my thoughts too.

    tl;dr version -> make a better user menu,  add a user menu for scripts,  make shortcuts configurable,  add docs to distribution files.


    A complete UI re-work could certainly be nice. However, doing it sanely would require a lot more than just shuffling some menu options around or some cosmetic GUI changes, it would be a major re-write.
    I'm not a friend of a complete new CHDK Ui structure! It is a historically grown piece of software over more than 5 years.Then we could also say, UI version 2.0 only for DryOS. It would much easier for the further development.
    I think we can all agree that nobody is likely to volunteer to do a "ground up" rewrite.  The current menu code is very functional IMO,  just not organized for the end user.  But one big problem with even simple changes to the menu order is what to do with existing documentation.


    One big improvement would be to make the shortcuts more sane and configurable, but this requires a significant re-write of the keyboard system so it isn't done with ifdefs scattered all over the code.
    I wonder how many CHDK users actually use the shortcuts (other than when they accidentally trigger them) ?  This sounds like a good standalone project that could definitely improve the user experience.  Are you thinking something like making the key sequences user configurable so that people can pick and choose what shortcuts to enable and which keys to use for them ?


    Making the menu open as soon as you hit alt would completely break the shortcuts.
    This doesn't sound to hard to fix  / work around ?  The user menu already has this functionality when you enable it with the [On Direct] option.


    Regarding scripts: IMO, it would make far more sense to let scripts integrate with the UI more rather than bloat the core code with "script" functionality (although I suppose you could do the same thing with modules instead).
    Hmmm .. something like the "user menu" but for scripts ? Lets you select scripts from the SD card and displays each by the embedded title on a seperate menu.   Now that should be another relatively easy function to add that would be great !


    If you are going to re-write the UI anyway, you may as well do script integration from the start. If I were doing a ground-up redesign, I'd be strongly tempted to put menu definitions, UI logic etc entirely in Lua.
    Compile LUA code into the existing build ?  (i.e. some Lua in the place of C ?)   Or allow user written Lua scripts that "autoload" and override built-n functionality ?


    RE the user menu: It's broken and needs to be fixed, but the reason we have a development version and a stable version is so things can be broken for more than a couple revisions.
    Yes - I know.  Sorry to nag - philmoz suggested that I just back out the menus from the modules to fix this.  I just haven't gotten around to it but it got me thinking about this topic.


    A further step in this direction would be to allow the user to pick a few things that would be adjustable on the initial alt screen, something like the canon func menu.
    Quickly selectable presets are also a great idea.
    Useful would be the revision of the CHDK menu structure and UI, e.g.
    - availability of the remote functions in main menu
    - an easy to use (user) menu (editable on PC with a config file)
    - in-built functions for motion detection and timelapse (most important CHDK functions in addition to HDR!)
    - uniform color system (Different colors are a good way to simply display informations.)
    - understandable functions (see e.g. disable overrides - really difficult to understand; only one override system for tv; maybe also 'Market' ISO anstead real ISO)
    - selectable presets (editable on PC with a config file)
    - set layout editor (for me one of the most important (GUI) functions) in the center point with more options
    Override Shutter Speed and Override Aperture Value should be one of the first things you see. This should be helpful too for those cameras that don't have M mode. Perhaps also there, we can have presets like1/2500...1/4000 or F2.6...F11... a customized Shutter or Aperture for fast access and use. A customized focus distance?
    I was thinking that maybe a new "startup screen" that appears before the menus might be the way to do.  The "user menu" function already gives you this in a way.  Maybe it just needs to be expanded ?


    My opinion is that the biggest problem of new users is what they do not want make an effort in finding and reading the user manual. Maybe it would help rename "Read Me" file in another name, for example, the name "User Quick Start Guide" might persuade the user to open a file and view the links contained in a file.
    This is a good example of a simple idea - put one or more of the "User Manual" pdf files in the distribution zip file.

    *

    Offline fudgey

    • *****
    • 1705
    • a570is
  • Publish
    Re: CHDK UI version 2.0 ?
    « Reply #6 on: 27 / May / 2012, 17:42:40 »
    One tiny thing that might help some surprisingly much would be to make ALT mode more visible on the screen e.g. by drawing a bright border around the edges and/or simulate Canon's OSD style and flash a big "CHDK ALT" icon in the middle of the screen when entering alt mode.

    it's currently rather easy to not know you're in alt mode, causing confusion when trying to shoot (script starts, no photo shot).

  • Publish
    Re: CHDK UI version 2.0 ?
    « Reply #7 on: 28 / May / 2012, 11:49:46 »
    One tiny thing that might help some surprisingly much would be to make ALT mode more visible on the screen e.g. by drawing a bright border around the edges and/or simulate Canon's OSD style and flash a big "CHDK ALT" icon in the middle of the screen when entering alt mode. Iit's currently rather easy to not know you're in alt mode, causing confusion when trying to shoot (script starts, no photo shot).

    I don't know if you noticed,  but the stable version uses this code for the <ALT> indicator :

    Code: [Select]
    draw_string(((vid_get_bitmap_screen_width()/2)-(FONT_WIDTH*5/2)), (vid_get_bitmap_screen_height()-FONT_HEIGHT), "<ALT>", MAKE_COLOR(COLOR_ALT_BG, COLOR_FG));

    and the dev / unstable trunk uses

    Code: [Select]
    draw_string(((CAM_SCREEN_WIDTH/2)-(FONT_WIDTH*5/2)), (CAM_SCREEN_HEIGHT-FONT_HEIGHT), "<ALT>", MAKE_COLOR(COLOR_RED, COLOR_WHITE));
    The stable <CHDK> symbol tends to be BLACK on tranparent/grey (pallete dependent) while the unstable shows as RED on WHITE.  Much more visible.   In fact,  IIRC when I originally submitted the patch for that change,  I had wanted to use RED on YELLOW but that was not greeted with much enthusiasm so we compromised on RED on WHITE.


  • Publish
    Re: CHDK UI version 2.0 ?
    « Reply #8 on: 28 / May / 2012, 17:49:35 »
    This post on the CHDK facebook page is coincidentally somewhat on topic:

    https://www.facebook.com/permalink.php?story_fbid=448672595160887&id=134056233289193&notif_t=wall

    Quote
    finally got chdk loaded on my sx40hs, but the menu language is so geeky that i am having a hell of a tough time in understanding the directions on how to choose correct settings ("override" = "yes" or "no" or "override" -- how obscure and unnecessarily obtuse is that??) . The main reason I wanted CHDK was to manually control ISO settings in all situations (including "AUTO"), especially the Scene choice of High Speed Burst HQ (8 shots a second), because left on its own the camera always chooses a much higher ISO than I would, making High Speed Burst HQ pretty much useless (so called "continuous" shooting is more like 2 shots a second, which is pretty lousy!) I have been utterly unable to choose the correct settings to get this accomplished. The camera still chooses high ISO settings even though I have tried to limit it to a high setting of 400). Any help would be much appreciated. I am about ready to ditch the camera (which I love in many ways!) and buy a Panasonic FZ150 which has a non-complex way of taking up to 10 shots a second, with settings manually controlled by the user.

    *

    Offline reyalp

    • ******
    • 9858
  • Publish
    Re: CHDK UI version 2.0 ?
    « Reply #9 on: 29 / May / 2012, 00:55:47 »
    I wonder how many CHDK users actually use the shortcuts (other than when they accidentally trigger them) ?
    This is a good question.
    Quote
      This sounds like a good standalone project that could definitely improve the user experience.  Are you thinking something like making the key sequences user configurable so that people can pick and choose what shortcuts to enable and which keys to use for them ?
    Yes. Ideally this wouldn't just mean pick the key for the things that already have shortcuts, but also give the option of assigning things that don't currently have them.

    Being able disable the current shortcuts would also be plus for many users.

    Another thing that would be helpful is some (optional) OSD that shows you the shortcuts when you are in alt mode.

    Quote
    Quote
    Making the menu open as soon as you hit alt would completely break the shortcuts.
    This doesn't sound to hard to fix  / work around ?  The user menu already has this functionality when you enable it with the [On Direct] option.
    Probably not, although there might be key conflicts, especially on the cameras with limited keys.

    Quote
    Hmmm .. something like the "user menu" but for scripts ? Lets you select scripts from the SD card and displays each by the embedded title on a seperate menu.   Now that should be another relatively easy function to add that would be great !
    That wasn't exactly what I had in mind, but it sounds like a good idea. Rather than having a separate user menu for scripts, it might be good if you could add them directly to the user menu.

    My thought was more general: If the reason for putting say timelapse in C code is just because the script menu is too confusing, the solution should be improving the script UI, not porting the scripts to C code.

    If you could assign scripts to CHDK menus like you suggested, and allow scripts to draw their own menus (could be done with drawings and/or console, but having a standard library that was more consistent with the rest of the UI might be good) then it shouldn't matter to the user whether they are running a script or not.

    Having scripts like this on an easily accessible user menu could also be used to implement the pre-sets idea.
    Quote
    Compile LUA code into the existing build ?  (i.e. some Lua in the place of C ?)   Or allow user written Lua scripts that "autoload" and override built-n functionality ?
    With this one I really did mean a ground up re-write. The menu system (and probably the config system) would be completely replaced. C would do the drawing, all the logic would be in Lua. Lua is much nicer for describing UIs, and it would make everything customizable. Pie in the sky ;)
    Don't forget what the H stands for.

     

    Related Topics