More focus on laser settings

[peteruithoven]

At the moment Visicut focuses on lasercut presets and let's people edit specifics in a separate window. As I mentioned in issue #70 a portion of the users always edit the lasercut settings, it's actually the most important part of the interface for them.

At the moment this separate window presents the settings in different sub pages. This for example enables the user to add multiple treatments to one preset, but I'm not sure if many users use that feature. Would it not be better to show the different treatments (cut, engrave etc) in one list? As I believe this is a important part of the interface for some of the users I would even go one step further and integrate it into the main window.

I've made a mockup to show what I mean:

To clarify, the settings next to the selected profile change when you select another profile. When you have the same profile selected twice changing one power field for example should also update the other power field.

I do agree that this adds a lot of clutter, especially when few people change settings like ventilation and purge. But I would also suggest ways to hide these especially for lasercutters that don't support these. Showing these options could be customized with a "edit lasersettings inline" checkbox in preferences.

This is a part of my overall issues with the focus of Visicut at the moment:

68

[t-oster]

As I already mentioned, the profile e.g. "cut" should represent the action of cutting, independent from the laser-settings needed for that goal, because this will change per laser-cutter and material and thickness.

Another problem with the interface you suggest is, that VisiCut supports multiple actions for one goal, e.g. when engraving acrylic, we achieve best results when rastering twice with different settings on each path. For the user, this still means "engrave".

What you want to achieve seems like the old-fashioned printer-dialog like only the settings power,speed and frequency. The goal on VisiCut intentionally was to hide such settings from the user, because he does not need to know what power,speed etc means. The user just wants to cut something, so he tells the software what he wants.

I am no sure if your suggestion really represents the majority of users.

Either we have to conduct some kind of survey to find out or we have to find a way to integrate this in the UI without removing the advantages.

[peteruithoven]

I think a profile like cut does still represents the action of cutting, it just shows you what it does next to it. But yes, this does limit the user to only one treatment which isn't an option for you at the moment.

Yes, that's kind of my suggestion, see issue #70 for my thoughts on workflow and my rough designs for a Lasercutting application / printer driver for Fablab contexts: http://redmine.laoslaser.org/boards/3/topics/254

I'm planning to post something about this on the dutch fablab newsgroup, hopefully we can get a good discussion going.

[t-oster]

Well... I think we are having two different user groups here. We kind of had already what you suggest: A simple-mapping, where you just specify ONE property (e.g. Color) and then get a list of all occurences in the current file where you can map profiles to (I think it was in 1.4 or 1.5). On the other hand, people are angry that I removed the really complicated mapping features (#51) and even want an SQL like language. It is not easy to make every user happy. (e.g. how to achieve things like #42)

But I think we have two workflows here:

1. The file is specifically created for laser-cutting. Thus you can advise the users to use e.g. color=red for cutting and color=green for engraving etc. That way you could create a predefined mapping with exactly those colors and there is no need to inspect the file
2. The file is from somewhere and you want to laser-cut it without modifying the file. That's what all those possibilities are for. Currently you can specify things like "All elements on layer 2 and all elements with stroke-color=red -> cut"... the complexity could of cause be much more increased by supporting AND and NOT and things like >= and <= (see #14)

[pbrier]

In the context i see the laos laser being used, it is mostly 3 classes, that you Can differentiate in advance:

• mark black lines lines
• raster all bitmaps
• cut all red lines Ignore the rest.

If the ui could provide a minimal 'simple mode' to achieve this with minimal Setting that would be great.

[peteruithoven]

I'm actually against most "modes". http://en.wikipedia.org/wiki/Mode_(computer_interface)#Avoid_when_possible

Your suggestion could be put into a custom mapping, showing up in the dropdown menu. Then it would be nice to enable some kind of default mapping, or change the order and always default to the first. I'll make an issue for that.

[mgmax]

@pbrier could you specify in more detail which UI elements (in a current nightly version) are useless to your "simple mode" users? Maybe we could add "gradually hiding/showing complexity" just like for the "multiple files" feature #71

[peteruithoven]

I finally have another suggestion.

My suggestion is to add the lasersettings in the main interface, but make it collapsable. This makes it optionally accesible just like the Edit laser settings button and the Edit settings before Executing checkbox, but probably more convenient. I've placed it underneath Mapping and positioning because you might want to check how settings where mapped. An alternative would be to place reminders next to the profile titles like:

I also made lots of changes to the inside of this interface.

• List all profiles that are used underneath each other (less clicking around and I feel there is enough room).
• Create tables per profile, because in the future the possible settings might start to differ between profile types. (raser profile vs line profile for example).
• This table starts with just one line, but when you press the [+] button it will add a line and buttons like [-] [up] [down]. I'm not sure about adding the [+] next to the table or underneath the table next tot the other buttons.
• We can display information about settings (like focus) in tooltips that show up when you hover the table headers.
• I've added an Advanced button that will link to Profile edit windows. (The edit button in custom mappings now links to only advances, but actually forgets about the basic laser settings)
• I've added an log button, see issue #92 .

Basically unfolding this part and having no material presets goes a long way in making it more appropriate for Fablabs (in my opinion)

I'm very curious what you guys think about this.

[mgmax]

Wow. I instantly like your idea in the third picture. Easy interfaces with full features (and as few "modes" as possible), really good. Please keep pushing if we forget this :)

Do you already have suggestions how to implement the feature "Edit before sending, Ask for saving later"?. I liked this when trying out changes, so I could discard my changes if they were wrong. I propose: After sending the job, show a message box asking if you would like to save your changes, continue working on then (without saving) or revert to the old settings. I feel this is a bit too complicated, you possibly have better ideas.

[peteruithoven]

I forgot about how that worked. I don't think that would make sense with this interface. What about some kind of undo button: Or a prev / rewind button:

I've also bin thinking about a combination of the mapping and settings ui, but I can't find a simple enough way.

[t-oster]

See here: http://137.226.142.25:5080/wwwshare/VisiCutNightly/feature-laserproperties

for builds including the interface draft.

[peteruithoven]

Nice! I was wondering what you thought about my suggestion, but apparently you liked it?

I had some strange resize bugs and other small bugs, is that something you want me to report? Where would you like feedback in general about this? in this issue of in issue #94 (your pull request)

[t-oster]

I know the UI is not nice yet.I will check the resizing etc and I will replace the +/-/edit/save/up/down buttons by icons (suggestions welcome) to make the table panels smaller. Suggestions etc please in the pull request.

[t-oster]

I think this is fixed by the merge of #94