Browser Control: On/Off Toggle

[dtex]

Description: Can be used to turn on/off misc devices, or switch between two values. Visual representation (switch, slider, checkbox, etc) can be set with a CSS class defined in a theme. Can be updated by johnny-five to reflect physical device status.

Sample:

<input type="checkbox" data-device-type="led" data-pin="13" />

Required Attributes:

• data-device-type - button | led | motor | servo | switch
• data-pin - The pin number

Optional Attributes:

• disabled - Indicates that this element is used for output only
• data-min - Overrides default off value
• data-max - Overrides default on value

Default Output|Input range: 0|1

Sample Uses:

• Toggle an LED
• Move a servo from data-min to data-max
• Display the status of a physical switch

[rockbot]

Random question: will we be including styling for these elements? i.e. I think it's fairly obvious that the toggle should look like a switch - will Nodebot(s)UI include the styling for said switch? Or will styling be left as an exercise for the user?

(Given the Bootstrap-y ness of this project, I'd think the answer is 'yes', but I just wanted to make sure :-))

[dtex]

Short answer, "yes".

My personal hope is it can work three ways:

1. No CSS - For the subset of Browser Controls that depend entirely on HTML elements (i.e. checkboxes, buttons and ranges) un-styled elements will work fine. There are of course Browser Controls that won't be covered by the browser (i.e. the x/y coordinate control) that will require CSS and JS to function.
2. Default CSS - A default CSS stylesheet that does handle all the Browser Controls. It would be bundled with NodebotUI.
3. Inherited CSS - For that subset of browser controls that depend entirely on HTML elements there is a heck of a lot of styles out there already (jQueryUI, jQueryMobile, Bootstrap, etc). As long as we are thoughtful and don't introduce non-standard markup for these controls then those inherited styles should work fine.

Looking at @davatron5000 's comment I think another "Themeroller-like" utility that is specifically for NodebotUI is something he is interested in having which of course would be very cool.

[davatron5000]

I think you've outlined a pretty good roadmap actually.

• "v1" API "bridge" and repo of CSS-agnostic HTML (avoiding conflict with popular CSS frameworks out there)
• "v2" Bundled CSS theme with keyboard/mouse/multitouch support to make it uniquely Nodebot'y.

I think getting our own visual framework in there is helpful so that we can be a one stop shop forgetting robots built quickly and learners don't have to futz around with HTML n' crap.

Full steam ahead!

[dtex]

Oh wow, I feel dumb now. I never considered generating HTML for the user. That's a great idea of course. I was thinking of a CSS theme generator which is not nearly as helpful. I'll update the overview tonight to reflect this, but instead of versions what do you think of treating these as components that add on to core? The components could be categorized as:

• Core - The server and client side JS that works with CSS-agnostic HTML (let's call this subset "Standard Controls")
• Custom Controls - These are add-ons that would allow controls to be defined outside of core. All non-standard controls would be custom controls, though some should be bundled with core.
• Builder - A GUI interface for dropping Browser Controls and Browser Outputs into a Dashboard that generates HTML. Should use the same custom control add-on definitions that augment core.
• Themes - These are just CSS files that style Browser Controls and Outputs, the first of which would be our default CSS theme with support for all the components.