BowlerStudio UI Roadmap Discussion

[madhephaestus]

From @madhephaestus on January 19, 2016 19:31

Copied from original issue: NeuronRobotics/BowlerStudio#1

[madhephaestus]

From @egolden-bowler on January 21, 2016 15:26

_Email: From Ed to Kevin 1/18/26_
Okay, let me hit you with a big bulleted list as far as my suggestions go.
-I think the package as it stands now is great as a teaching tool. If you were going to teach a class on how to use computers to 3D print robots, I think this would be the best way to go. Maybe fix one or two copy editing things in that tutorial bar, and mess around with the window size and display a bit, but it's fairly straightforward and instructive as is.
-The first thing I would add for the commercial release are graphical interface tools. For instance if you wanted to make a sphere you click on the sphere tool and click and drag it out to make a sphere however big you want it. I don't actually know how much use you'd get out of spheres in laying out your robot, but that's just an example.
-As I see it you are going to need 5 main windows for various stages of designing your robot.

1.) The Workspace Window: This is where you create, or import joints and limbs for your robot and connect them together, and give them whatever physical properties you want. It's a great way to get an overview of the project so far and to navigate tot the part of the project you want to work on.

2.) The Command Window: This is essentially the Java Command Window from the current version of Bowler. Ideally with the UI tools we are about to give the user they could design a robot without ever having to use this Window, but it should be included for those who find it easier to work this way.

3.) The Programming Window: This is where the user programs in instructions for the robot. This way we can keep the commands for the robot out of the Java Command lines in case they want to copy over whatever program they're writing to some other program down the line that maybe doesn't use Java. Anyways it's probably cleaner to have a segregated area just for the robots programming.

4.) The Output Window: This window allows a user to quickly edit which servo or sensor or what have you goes to which port on the DiYo. Here the user can see how many outputs he has, how many DiYo's he's going to need to support the outputs he wants, and let Bowler know what kind of action each servo or sensor is performing.

5.) The Kinematics Window: A window to see how your robot will perform when built. You can assign your controls, like the game control you often use, or keyboard inputs here, as well as see which limbs maybe need more attention when this thing gets moving around.

Each window will have various sub-windows and tool panels as needed, and you could have all 5 windows up at once if you wanted. It'd be cluttered as heck, but the users can do what they want.

_Email From Kevin to Ed 1/19/16_
Cool! Its funny you mention teaching with this, i just picked up a contract teaching job at Bancroft schools teaching robotics with BowlerStudio ;)

It seems like 1 and 5 could be merged together, if we are taking a reimagining of this, id love for the Workspace to be running a "live simulation" kinda like a corrector creator from an mmo ro Spores creature creator (The ideal modality from my point of view).

Command window, maybe this should be called Advanced Mode if its just the old Creature Lab tab?

So rather than getting caught thinking in DOM, you should be aware how easy it is to make 3d (2.5d in the case of menus) objects that exist in the 3d window and that the user can send click events to. For instance this is how i select the source when an object is clicked on:
https://github.com/NeuronRobotics/BowlerStudio/blob/development/src/main/java/com/neuronrobotics/bowlerstudio/threed/BowlerStudio3dEngine.java#L332

That works for any 3d object.

Also you can drop in standard DOM widgets into the 3d window and they more or less work. thats what i did for the x, y and z labels on the axis labels.

Lets just try to think about 3d first, and DOM as a fall back.

I like where you're going with this train of thought, isolating the kinds of functionality.

_Comments Ed to Kevin 1/21/16_

Addressing your points in order:

1 and 5 could definitely be merged, with kinematics being something a super sub-window of the larger Workspace Window. I get that there's functionally no difference between the creating and kinematics on our end of things, but on the user end of things I'm thinking that when a new user first boots Bowler Studios up, the first thing they are going to do is play around and make something that looks cool and not worry too much about how it moves just to get the basic controls down. Separating creation and kinematics out into different steps in different areas creates a little buffer between creative free play and the user watching their totally impractical first creation fall all over itself right away.

Also Kinematics is going to require a lot of little controllers on its own, like camera controls and a little window for binding your control device and probably a few other panels as well. Having Kinematics be its own window lets us design nice little slots for these controls that don't need to be around when just building the robot. But there are ways to solve both these problems with having them both be the same window and if that's your preference, (and for all I know it'll probably save you hundreds of coding hours to have them both in one place), we can totally merge the Workspace with the Kinematics window.

We can call the Command Window whatever you want, I'm making up jargon as I go here and I'm not really attached to any of the names I'm putting to things. I just called it the Command Window because it reminded me of CAD's Command box as far as functionality goes. For the sake of argument I'll mention that calling it "The Command Window" is a bit more descriptive to users than "Advanced Mode," but we can make it clear through UI what that window does no matter what we call it. In fact we could probably find an even more descriptive name than "The Command Window" but it doesn't really seem like a big issue at the moment.

As for 3D vs. DOM, I'm not quite sure which way to go myself. There are ways of doing it with just selecting things from menus or sub-windows which don't require any tool trays at all. A lot of it depends on how you imagine having these robots built in the studio. We should meet up in person and talk out how the user builds out the robot, then I can get a clearer idea of what assumptions we can make about a user building a robot.

[madhephaestus]

So i made some updates of the UI layout model in an attempt to make it easier to modify the layout (without recompiling). I made this change so a non-programmer friend could do some work making icons, and having the application load the assets live at runtime. We are now all moved in and ready to start a serious collaboration in UI design/workflow.

[madhephaestus]

From @egolden-bowler on May 5, 2016 16:53

Oh good we've got this going again. We sort of lost touch during the move, but I'm ready to get back into the swing of things if you guys are ready again.

[madhephaestus]

Yeah, are Saturdays at 3 at Technocopia a possibility for you?

[madhephaestus]

From @egolden-bowler on May 6, 2016 1:32

In general yes. But this weekend I've got a commitment. I could make it for 4 or 5 this weekend, and also I'd need to know the new address.

[madhephaestus]

44 portland St, Worcester MA, 6th floor.

[madhephaestus]

From @egolden-bowler on May 8, 2016 0:29

Okay, see you next Saturday at 3.

[madhephaestus]

@egolden-bowler I have made a bunch of progress, we should meet start back up development.

[Octogonapus]

@madhephaestus Anything worth saving in here?