Through the Interface

Design choices for the next Plugin of the Month

, , , ,

I'm currently thinking about using the code from this previous post as a basis for November's Plugin of the Month.

This simple AutoCAD application would provide three main capabilities:

  1. Take a screenshot of the entire AutoCAD application window
  2. Take a screenshot of the current drawing window
  3. Take a screenshot of a user-specified section of the current drawing

Each of these options would result in a bitmap being either saved to file or placed on the clipboard.

The thing I'm chewing on, right now, is how best to design the command interface for these operations. It occurred to me that this would make a fun topic for a blog post: why not throw it out there and gather some options? An experiment in crowdsourced product design. 🙂

So, here are the options I'm considering:

  • A single command (perhaps called CAPTURE or SCREENSHOT)
    • Prompts:
      1. Select first point of capture window or [Document/Application]
        • If point selected…
          • Select second point of capture window:
      2. Save to file or place on the clipboard [File/Clipboard]:
        • If "File" selected, file dialog appears, with various image format options:
          • Select image location
    • Pros
      • Simplicity: a single command is easier to remember
    • Cons
      • Somewhat cumbersome, especially if regularly using only one of "copy to clipboard" and "save to file"
  • Two commands (example names below)
    • CAPTURECLIP [saves the results of the capture operation to the clipboard]
      1. Select first point of capture window or [Document/Application]
        • If point selected…
          • Select second point of capture window:
    • CAPTUREFILE [saves the results of the capture operation to a file]
      1. Select first point of capture window or [Document/Application]
        • If point selected…
          • Select second point of capture window:
      2. File dialog appears, with various image format options:
        • Select image location
    • Pros
      • Streamlined for regular use
    • Cons
      • Double the commands: twice as complex for the user (OK, perhaps that's not such a big deal… 🙂

Overall I'm more in favour of the second choice, right now, as it feels like it'd be better suited for regular use.

Another option would be to have all 3 commands: the general command, CAPTURE, would probably be better for novices, and the specific commands, CAPTURECLIP & CAPTUREFILE, would probably be better for power-users. But that adds testing/coding/documentation complexity, which may well be unnecessary.

There are other options I haven't listed, such as using some kind of application setting (like a system variable) to decide whether to save the captured image to file or copy it to the clipboard. I'd probably rather not go down that particular path, as it adds complexity and feels a little  less intuitive, but it's certainly an option.

Does anyone out there have an opinion they'd like to share? If you suggest something compelling that leads to a change in the design of the plugin, I'll be sure to give you credit in the supporting documentation. 🙂

14 responses to “Design choices for the next Plugin of the Month”

  1. Fred Dickinson Avatar
    Fred Dickinson

    How about a single CAPTURE command with a secondary OPTIONS branch within the main command to change settings when required?

    CAPTURE
    Press ENTER or [Options]

    The Options branch would let the user choose
    File/Clipboard
    Application/Drawing/Window

    I'm guessing that users would use the command in the same way most of the time, for example to capture a window area to a file or to capture a drawing to the clipboard. This would let the user set the most common of 6 possible combinations once and change it when necessary.

    On a somewhat related note I would be interested in seeing how a single menubar button could be cycled between 2 or more states with each state represented by a different graphic in the button and a different tooltip.

    PS - Thanks for all of the great ideas in your blog.

    Reply
  2. Kean Walmsley Avatar
    Kean Walmsley

    Interesting suggestion - thanks, Fred.

    I'll have a think on this one - my instinctive reaction is that having the options hidden away may prove a little confusing and possibly harder to automate (but it all depends on how it's done, of course).

    Regarding the n-state control: you could probably achieve what you want with a custom WPF control (assuming it's to be embedded in a ribbon). The WPF session recordings on the API training schedule may help.

    Regards,

    Kean

    Reply
  3. MJohnston Avatar
    MJohnston

    I like Fred's suggestion and understand Kean's concerns about hiding options. Why not display the last used options at the command line. If the user pressed enter they are used, if they enter an "O" they can change the option.
    That would be something like the native FILLET command.
    It shows current settings but allows for changes.

    On another note this tool will be interesting but unusable for me. I draw with a black editor background. That makes screenshots a real problem when it comes to printing.
    At the risk of causing scope creep, a black-and-white option would make this a real winner for me.

    Reply
  4. Mark Avatar
    Mark

    I'd go with the single command similar to Fred's suggestions, but change it around so the output is under the options and input is through the command line...

    Command: SCREENSHOT
    Current settings: Output=File (or Clipboard)
    Specify input [Application/Document/Window/Settings] <window>:

    another input option might be to screenshot selected entities, using the extmin / extmax of all selected objects to pass into the points of the capture window

    Reply
  5. james Avatar
    james

    as long as you give command line access to options, do whatever you want. The hard part is if you put options in a dialog only (no command line interface).
    I'll make three key-ins, one for each window option or more if there are any.
    The classic command that got this wrong was qleader. That one was sure a pain to implement with real users.
    thx

    Reply
  6. Kean Walmsley Avatar
    Kean Walmsley

    I'm coming round to the options idea. And the "use white background" option seems a good one, too (I suspect it'll be easier in 2D than 3D, but we'll see).

    Thanks!

    Kean

    Reply
  7. Kean Walmsley Avatar
    Kean Walmsley

    I like it... although I'd maybe even ask for the screen coordinates automatically, with the rest as keywords:

    "Select first corner of capture window or[Application/Document/Entities/Settings]: "

    This assumes the most popular mode is likely to be "window", which is perhaps an incorrect assumption on my part.

    Kean

    Reply
  8. Kean Walmsley Avatar
    Kean Walmsley

    Thanks, James. The focus here is firmly on a command-line interface. Dialogs tend to add complexity, and [coding/usage] simplicity is a primary design goal behind these tools.

    Kean

    Reply
  9. Nikolay Poleshchuk Avatar
    Nikolay Poleshchuk

    Kean, sometimes it is very important to get higher resolution than it is used in current AutoCAD window (e.g. the drawing is too big to be seen all). So I vote for having option to control resolution.

    Reply
  10. Kean Walmsley Avatar
    Kean Walmsley

    Nikolay,

    The current implementation is just capturing the screen graphics, so I'm not sure how this could be made to work. You could certainly take a snapshot at a custom resolution if using a GsView, but that's quite different.

    Maybe you have some ideas on how this could work?

    Kean

    Reply
  11. Chris Bray Avatar
    Chris Bray

    Following on from that you could always make the default 'sticky' so that it defaults to whatever was done last? Either on a per-drawing, per-user or per-machine basis?

    Reply
  12. Kean Walmsley Avatar
    Kean Walmsley

    Chris,

    It's certainly feasible, but I suspect it might be confusing... And selecting a window is two picks, while selecting the document or application is only a single letter (plus space/return), so I'm going to see how it feels with the window as default.

    I'm hoping to post a test later today - please do let me know what you think once you try it...

    Kean

    Reply
  13. Tony Tanzillo Avatar
    Tony Tanzillo

    Congradulations on reinventing the SAVEIMG command.

    Reply
  14. Kean Walmsley Avatar
    Kean Walmsley

    Actually the "save to image" capability of an entire document isn't the most siginificant part of this app's functionality, IMO: personally I find the more interesting functionality to be around selection and copying to clipboard (which will mean I'll use it more for certain tasks than SnagIt, which I currently use on a daily basis).

    Thanks for the congrats, though, even if I can't help but feel they're not completely heartfelt. 🙂

    Kean

    Reply

Leave a Reply to james Cancel reply

Your email address will not be published. Required fields are marked *