Settings window: Next Generation

[techninja]

I've been kicking around how to do settings windows forever, and the strange floaty shadow window we've got now came to be because we wanted to see that everything was still working below, and to emphasize the immediacy of its settings (you can change the color set and see it change the mode below).

As I build out the new settings for fills and strokes, all I can feel is... cramped. Default window size less the all around margin means all that useful text and stuff we want to help the user with is trying to do its magic in almost no space. Feels cramped and hard to parse. So I'm now proposing to pull from a very successful settings window model: Google Chrome!

• In Chrome, settings is a regular tab. in RP, would be the equal of a mode (though would not switch away).
• Clean white background & vertical tabs for easy expansion for longish text and lots of tab groupings.
• Somewhat clear interface, takes up the whole screen.

Here's what I've got so far. Exactly WHAT the tabs are reflect a few other yet to be flushed out changes, but it's a start.

Notes:

• This "window" is revealed by sliding down from the top, this looks nice and doesn't get in the way with a transition time of 750ms, but I'm not sure if that will continue to not be ever so slightly annoying.
• No transparency, but it's non blocking. Closed with the Done button, or pressing "Esc". Spacing at the top allows for Reset and done to expand as needed for other languages.
• Z-index is such that the translate button is still visible and fits well next to the other options.
• I've never been fully sold on the wraparound borders for fieldsets I've been using (and visible for "Carriage Movement speed"). Removing them from the main sub-sections has been freeing, but I need more visual design to help with keeping spacing for all these elements at bay.
• Revealed here is the live fill/stroke preview. This is still a brand new work in progress, but it's what I've wanted since the start, and Paper.js makes it work beautifully.
• Tabbed interfaces within tabs: I've not decided on looks, but I think no colors, light greys are usually a win.
• Where stuff lives is.. always up for contention. I'm now thinking hard that Movement speed is not part of "style" at all, unless it changed how things look (which it shouldn't). I'd suggest maybe we get together on a call after I figure out what COULD be in all the various sections, and we can figure out what goes where. But I do know that Movement speed should be up front on top with whatever we choose.

[techninja]

Also, in light of redoing a bit of UI here, how do we feel about a update to the checkbox styling into something iOS9-like:

http://abpetkov.github.io/switchery

[oskay]

+1 on updating UI to slider buttons.

If you look at the settings in (e.g.,) iOS 9, there is a neat consistency about them: Each item title is in plain text, left justified. Each setting is on the same line, right justified. There is no "explanation text." Net result: It's all very readable.

What if we make the explanation text only visible if you click an element to "unhide it", like so?

[techninja]

Been thinking about that. Usually the explanation text is so huge that it just doesn't fit in a tooltip. I've been musing on hiding them for quite some time now, especially considering just these three checkboxes take up SO MUCH ROOM with helper text!

Admittedly this could be partially solved by having an editor of some sort... But yes, people don't care about thus stuff unless they're deciding if they want to use it. Unfortunately, the label of the checkbox itself is part of the checkbox, and will activate the check/uncheck. It's unlikely that would ever do something bad, but it's not an intended reaction if someone is looking to get more details. Perhaps... some kind of question mark icon after the label (putting the switchery checkbox before the label), when clicked (or hovered) reveals the text in the current location as above. Only one would ever show, shrinking away when another one opens.

Eh?

[oskay]

That should work....

[techninja]

Eh?

[oskay]

Neat!

Some suggestions:

1. If possible, do require a click to open/close the "helper text."
2. Do not italicize the helper text.
3. If possible, slightly indent the helper text. 20px, maybe?
4. Opening a new helper text "pane" should not close the others. Often, people want to read through more than one to see how they compare. Also, it will make it more visually clear what is happening when you reveal the helper text.
5. If you have a mac laptop handy, take a look at System Preferences > Trackpad. It has a great example of how to do just what you have here with the preview.
6. I like the example of the visual preview. However, it's a little hard to tell exactly what is being shown, since it is hard to see the full progression from original artwork to its final form. Maybe slow it down a bit?
7. Does the preview replay if you click on it?
8. Again, I think that it would be better if the sliders were fixed on the right-hand side.
9. The sliders could be much less wide, allowing the preview to be taller.

[techninja]

1. Click to open: Changed from hover, done!
2. Nix italics: Done.
3. Indent: Done.
4. Don't close others: Done
5. See Mac trackpad prefs: No mac at the moment, I assume you mean this
6. Hard to tell what's being drawn: I think part of the problem is that it's hard to tell what the source image is because before you know it, it's being drawn on top of.
   • Perhaps taking from point # 5 above, I should expand vertically and include an original untouched copy of the image. The actual process of drawing is less important than the output (directly effected by everything within the tabs).
   • The speed is effected by the iteration slider, so a user can easily change how quickly the tracing progresses. The idea here is that what you see is exactly what print mode is going to do.
7. Does it replay: Nope, no click action defined yet. But it will show you path point details. Click refresh added.
8. Sliders on right: Range input sliders are only as good as their available width, if we restrict their width, we actually limit the available values for sliders with a greater number of values than pixels in width. Right now they try to be 50% of available width, but if squished below that, will collapse to below their label (otherwise they stay on the right). The image below is a slightly wider window view of the same controls.
   • 
   • I can force the range controls to the right, though the actual range they provide will be less for small window views. Of course it's all better at this point because we're using basically the whole window.
9. Sliders could be less wide: I think I've covered this in the above comment.

Once I get return feedback on this, I'll go ahead and make another mini screencast.

[oskay]

1-5: Yes! 6: Yes-- also showing an untouched original SVG would be ideal. Perhaps label them: "original" and "preview"

7. Great. 8-9: OK... So... all siders have to be the same width, due to GUI constraints? Got it. I'm not clear on what "iteration count" does here, but my best guess is that these two could be replaced with a pop-up menu with 3-5 choices.

[techninja]

Else: Awesome! Original SVG included now. Haven't put any text on it that says original, I suspect it will be somewhat obvious.

Iteration count: The new tracing paradigm for generating both live preview and machine paths at once works on an animation frame iterator. This most importantly makes it easy to process very complex art in the exact same way as non-complex art without slowing down the UI or blocking anything.

For every requested frame, a little loop runs based on the iterator count for fills and strokes to do more than one frames worth of work in the space for one frame. This is basically a tracing "speed" slider. And yes, this could easily be replaced with possibly 5 or so options in a drop down. Maybe..

• Slow (1x)
• Default (2x)
• Quad speed (4x)
• Super (10x)
• Max (20x)

I don't know how well "[N]x" translates to other languages, but it does make sense in English. Note that 20x may seem crazy, but for the One Line Tree drawing, with "Fine" trace precision, it takes ~6:40 at 1x to just trace it, at 20x it's about 19 seconds.

[oskay]

Can you use the multiplication symbol "×", rather than "x"?

[techninja]

Sure. You happy with it otherwise? I can also change out the "line width" from a range to a dropdown. The "line width" is the size of the motion paths shown. Really this should probably be taken from implement config and not shown here at all, but I figure it should be an option.

• Automatic (set by implement)
• Minimum (1)
• Medium (5)
• Default (10)
• Wide (20)
• Extreme (30)

[oskay]

Yes, all looks good. I may have additional feedback after trying it out. :)

[techninja]

Will have a new build out tonight for testing.

[techninja]

Leaving for GitHub universe tomorrow morning(!), so have failed to build tonight, but I did finish all the intro work for the features and settings! All I really need to do is add the translation strings correctly (cheated and hard coded english for now).

Doing stuff for translation string heavy settings is easily the most tedious thing to do in RP, and I can't say I have a good solution to make it easier, apart from some kind of JSON definition and settings renderer.. which doesn't immediately allow for awesome stuff like the live preview.. so I'm leaving it. Here's latest screencast:

[techninja]

@oskay No rest for you I suppose! Close this if you think the new settings in the 2.0 beta are to your liking, otherwise add comments for any issues you see.

[oskay]

1. The "Use white media" option is hard to understand: Does "media" mean the paper or the paint?
   • I would normally assume that it means the paper ("print media"), but the context shows that it means the paint. Maybe it should be changed to read "Skip white paint", default to true, and has helper text: "When your media settings (paint colors) contain white, ignore any paths that would be painted in that color. You may want to turn this off when painting on a background that is not white."
2. Change title of option to "Trace path strokes and outlines". Helper text: "Allow robopaint to trace along paths and outlines automatically."
3. Should the "Stroke invisible paths" have a new (invisible) path appear in the preview?
4. In the "Stroke occlusion & overlap detection" option, indicate that the Stroke Precision value will improve the precision of overlap detection.
5. Move the "Randomize fill angle" option right below "Line fills angle", and change its helper text to "If enabled, each object will be filled with paths at a random angle, instead of at the 'line fills angle' above."

6. The "Dynamic line fill options" apply to the three "zig zag" fills, but it is not immediately obvious that "dynamic line fill" is the same thing as zig-zag. I suggest changing the text as follows:

   (Type pop-up) Zig-Zag :arrow_right: Hatch (Zig-zag) (Type pop-up) Zig-Zag Straight :arrow_right: Hatch (Straight) (Type pop-up) Zig-Zag Smooth :arrow_right: Hatch (Smooth) Dynamic line fill options :arrow_right: Hatch fill options Line fills angle :arrow_right: Hatch angle Line Spacing :arrow_right: Hatch line spacing Randomize fill angle :arrow_right: Randomize hatch angle

7. Grouping threshold needs a clear description.
8. Suggest the following default fill settings: Zig-zag smooth, randomize fill angle True, secondary hatch fill false.
9. Is there a setting for adjusting the precision of fills? Should there be?
10. Tool menu: Maybe change the name of this menu to something else? Like "mode" for example? Not sure.
11. Tool menu: Move "Implements" up to right below Carriage Speed, and above "Media"
12. When selecting alternate modes such as pen/pencil mode, parts but not all of the "Refill media" area are darkened. Looks like this could use some tweaking.

[techninja]

1. "Use white media" was kind of a placeholder for an idea that I haven't actually implemented. The idea being that painting with white paint on things like Mona Lisa happens automatically when printing with certain color set that have white in them. I wanted a way to avoid doing that silliness in a switchable way. So yea, the text was definitely below first draft.
2. Change title/info: Done
3. Show invisible example: Yea, I was thinking about that. Wasn't sure where to put it. Also not sure that should even be an option. I added it as soon as I realized that that was an edge case, but it's an afterthought as what color should a path be if it doesn't have one? (SVG spec says black)
4. Add text on overlap precision: Done, though I've been thinking about the brand new version of Paper has the ability to do full boolean with open paths that may throw all my crazy work out the window and allow for basically instant overlapping stroke/fill calculations. Of course we still need to flatten these paths for output, it just wouldn't effect overlap precision anymore (they'd all be exactingly accurate). Will look into it.
5. Move randomize and change text: Done. Certainly fits better there.
6. Change Line fill for hatch: Done. I thought "hatch" specifically referred to the opposing angle lines, but I guess it's just lines together.
7. Desc for group threshold: It has one, I just didn't add the data-i18n tag for some silly reason, it reads like this:
   • Minimum threshold for grouping hatch line endings together into connected groups. Large value connects more groups with fewer tool lifts, 0 will ensure no groups are made.
8. Suggested Defaults: Done.
9. Fill precision: You must have missed it, it's stuck down there in with spiral fill options. BASICALLY how this happened was this:
   • I came up with how to do zig zag fill, a polygonal direct point to point fill using overlayed line intersections on the path. No precision value needed.
   • I then wanted to try to make the connections straight, so I modified the zig zag to connect the lines with a point halfway between, flipping the line ends then connecting them, works great, still completely polygonal.
   • I then wanted to attempt to emulate some kind of smoothing like what inkscape does, but didn't look into it, so I just run the paper.js smoothing function on the zig-zag straight. Now it's made of curves, we have to make it polygonal before we can generate our motion paths, so zig-zag smooth is the only one that has to use precision.
   • I readily admit this is less than great. It's likely if I spent some time I could easily emulate it directly, but it hasn't been a priority (getting the app out is).
   • Oddly enough the latest updates for Paper.js might take precision completely out of the equation for spiral fill accuracy (though we still need an idea of how many points along the line for polygon creation).
10. Change tool menu name: Yeaaa, yea. Implement, tool, media. All these "generic" names for stuff are hard to deal with and I've been trying to fold them into the app to make a future transition to a more globally useful RoboPaint easier, but some stuff is just hard to swallow. I can't recommend "Mode", as I've broken out modes from "Advanced" into its own menu. If people think of pens/brushes as tools I think it makes sense. Maybe what these left hand menus need are small 1 color icons? Where's our pro-bono UI designer intern?? :crying_cat_face:
11. Move implements: Done.
12. Disabling is wonky on pen mode change: Yup. Somewhat broken. Now Fixed.

[techninja]

"Skip White Paint" is now fully implemented and tested, it relies on the translation key being known "white". Note that the algorithm always has a "perfect white" available to select to be ignored, so #FFFFFF is going to match far better than the color I've selected to approximately match the paint color given (which is a very, very light gray), so it must be closer to that otherwise it'll always be ignored.

[oskay]

Is there a (good) reason that the brush height controls migrated to the "Advanced" tab?

[techninja]

Fitting everything all over the place with everything else is difficult. I was left with the feeling that these controls are (as by design) less required for the average user. Their defaults are perfectly workable for most "default" situations. Knowing where to put stuff and make it reasonably easy for a user to find and use are very tricky, and settings has almost grown to be its own gigantic application. Also I never considered settings "done" as it was in quite a bit of flux trying to figure out how to incorporate everything.

This is why I worked for a couple weeks to see if I could encapsulate all of it into a set of configuration files, that way moving and weighting each piece would be incredibly easy. Unfortunately that step proved more difficult than simply cutting/pasting elements around in HTML (as that's basically all these are anyways).

If you've got a good idea of where you want em, I'll happily accept a PR with it moved where you think it works best :smile:.

[techninja]

I'm going to call this done as we seem to be living quite well with the majority of the big changes made here. Piecemeal improvement should continue to happen in other tickets.