Powered Up - A tear down...

[kbalage]

Just now, Tcm0 said:

I don't think that a "simple designer" would be necessary if there were simple examples and error messages.

I'm sorry but I disagree. There's a huge crowd out there who does not want to touch Powered Up because it requires coding and understanding coding principles like start blocks, loops, variables, conditions etc. A straightforward step by step configuration in the app is fundamentally different from coding, even if the latter has examples and error messages. 

The basic user experience needs to be simplified to a level that becomes comparable to the physical assembly of a Power Functions motor/controller/remote combination.

[Thyraz]

@Tcm0

Yes error messages would be very nice. Maybe even with suggestions what they think you wanted to do.
For example using the select-specific-hub icon when you try to use a remote button as input, but the first device isn't a remote.

About the touchscreen sliders: 
Sure, but this still won't give you fixed increments on a click and won't help with the physical remote (but I'm not sure if they see it as a that important device in the Powered Up family).

edit: and another thing that would be so helpful:
Instead of a preview of the code when selecting a project,
I would really love to add a photo of the lego creation that it controls instead.

That would also help kids a lot to identify their projects.

Edited March 29, 2021 by Thyraz

[Tcm0]

28 minutes ago, kbalage said:

I'm sorry but I disagree. There's a huge crowd out there who does not want to touch Powered Up because it requires coding and understanding coding principles like start blocks, loops, variables, conditions etc. A straightforward step by step configuration in the app is fundamentally different from coding, even if the latter has examples and error messages. 

The basic user experience needs to be simplified to a level that becomes comparable to the physical assembly of a Power Functions motor/controller/remote combination.

You wouldn't need to understand start blocks, loops, conditions etc with a very simple examle.

Take this, maybe remove the *-1 block. It would be ready to go, only the ports might have to be adjusted. And that wouldn't be a problem if there was an error message that told you about the wrong port.

[kbalage]

@Tcm0 this is the simplification approach the PU dev team chose to follow and it is not necessarily a bad one. I still think the example of the -1 multiplier, or the fact that you cannot simply add a toggle button to turn on/off the specific output or the complicated way to assign the remote's buttons shows that it is created with a coder's mindset. 

Anyway, I would be still super happy if such simple blocks would already cover the basic controls and controllers, but for me this is not the most logical/simple way to create the setup sequence.

 

[Lok24]

Hi all,

there are constructions within the Powered Up App to improve that.

First is the idea of the "Bricks" (1-3) to show more or less icons
Second is the idea of composite blocks.

If you combined that with
- the possibility  to enter comment fields for text
- easy to use copy & paste of "code-snippets" from a website to your own project
many things  would be easier.

So the two blocks in the example above would be standard composite blocks that could be inspected and changed/adapted.
(Without the knowledge of any  JSON files)

[Thyraz]

yes, import and export of snippets or whole project is another thing that should have been in the app from the beginning...

[Tcm0]

21 minutes ago, kbalage said:

@Tcm0 this is the simplification approach the PU dev team chose to follow and it is not necessarily a bad one. I still think the example of the -1 multiplier, or the fact that you cannot simply add a toggle button to turn on/off the specific output or the complicated way to assign the remote's buttons shows that it is created with a coder's mindset. 

Anyway, I would be still super happy if such simple blocks would already cover the basic controls and controllers, but for me this is not the most logical/simple way to create the setup sequence.

 

It's actually very easy to change this for the remote. Change the multiplier to 100, add one to the first block and change the input to the remote sensor block. The "problem" is the hub selection block which has to be added, too.

5 minutes ago, Lok24 said:

Second is the idea of composite blocks.

If you combined that with
- the possibility  to enter comment fields for text
- easy to use copy & paste of "code-snippets" from a website to your own project
many things  would be easier.

So the two blocks in the example above would be standard composite blocks that could be inspected and changed/adapted.
(Without the knowledge of any  JSON files)

I don't really like the idea of composite blocks. They just add more blocks and the current amount of blocks is already a chaos.

Maybe it would make sense to compare the PUP app to the mindstorms ev3 and mindstorms nxt software. They were very similar but yet easier to understand. The blocks were "categories" that could be modified in behaviour (move, move for seconds, move for degrees, all of them were in one block). Also, there was way better documentation.

[Lok24]

5 minutes ago, Tcm0 said:

Maybe it would make sense to compare the PUP app to the mindstorms ev3 and mindstorms nxt software. They were very similar but yet easier to understand.

Yes. And the behavior was described as text, like with RI scratch
The PUP App comes without any text (except the name of the project).

So your idea would be to have a few motor blocks only, with the options well known from EV3.
But you could have i.e. for the two "stop motor" blocks only one with two input fields ("port", "break/float").

And "break/float" must in this context show two small icons (like the color palette or the remote-buttons) describing the function.

But: to "learn" the difference you need: start prog, start motor, wait 1 sec, stop. In both cases.
It would not be "easier" to learn,but would decrease the number of very similar icons.

 

[kbalage]

29 minutes ago, Tcm0 said:

It's actually very easy to change this for the remote. Change the multiplier to 100, add one to the first block and change the input to the remote sensor block. The "problem" is the hub selection block which has to be added, too.

I think you are missing the point here... it seems to be "easy" because you already figured out that the remote block has a numerical output of +1 and -1 for the + and - buttons. But this still does not resolve the case of the red button since that has a value of 127, so any time you press it (which is easy to do accidentally) that will give full power to the motor. So this is very much like a limited workaround rather then a well designed and easy to use solution to handle the controls on the remote.

[Tcm0]

1 hour ago, Lok24 said:

Yes. And the behavior was described as text, like with RI scratch
The PUP App comes without any text (except the name of the project).

The NXT and EV3 programming environments used mostly icons like the powered up app, but there was text if you put the mouse on the icons (and a few things had descriptions for EV3. The scratch-like programming came with RI and SPIKE (and the new EV3 software).

1 hour ago, Lok24 said:

So your idea would be to have a few motor blocks only, with the options well known from EV3.
But you could have i.e. for the two "stop motor" blocks only one with two input fields ("port", "break/float").

 

The EV3 programming environment had 2 blocks for motors: one for the medium and one for the large motor. I don't think that we'd need such a separation.

You can integrate the "stop motor" option into the normal motor block.

1 hour ago, kbalage said:

I think you are missing the point here... it seems to be "easy" because you already figured out that the remote block has a numerical output of +1 and -1 for the + and - buttons. But this still does not resolve the case of the red button since that has a value of 127, so any time you press it (which is easy to do accidentally) that will give full power to the motor. So this is very much like a limited workaround rather then a well designed and easy to use solution to handle the controls on the remote.

I don't think that the 127 thing is a big issue. You don't press the stop button by accident and if you do you see the behaviour and you can think about why it does that. Yeah, it's not an "elegant" solution but it works perfectly fine for most use cases.

[kbalage]

5 minutes ago, Tcm0 said:

I don't think that the 127 thing is a big issue. You don't press the stop button by accident and if you do you see the behaviour and you can think about why it does that. Yeah, it's not an "elegant" solution but it works perfectly fine for most use cases.

Well if you buy a remote and the red button that normally means "stop" in every other scenario would increase the power to 100% instead then I guess you would return the remote as faulty... Usable software for novice users should not be a guessing game by design. That's one of the fundamental issues with the current Powered Up app, why would you want to force users to figure out the irrational and unexpected behaviors of the app instead of designing it in a simple and logical way from the ground up? 

[Gimmick]

2 hours ago, kbalage said:

Well if you buy a remote and the red button that normally means "stop" in every other scenario would increase the power to 100% instead then I guess you would return the remote as faulty... Usable software for novice users should not be a guessing game by design. That's one of the fundamental issues with the current Powered Up app, why would you want to force users to figure out the irrational and unexpected behaviors of the app instead of designing it in a simple and logical way from the ground up? 

I would not call it "illogical", since you can always use "=" which reduces every remote-button-action to "is pressed? yes/no".

But I agree: It's created with/for a coders mindset. But that's not a bad thing, you can and will learn some basic things while toying around with this app. It's just by far not the optimal solution for everything and everyone. And since I do not see the one approach that solves everything, I would add a second, graphical interface without any programming, but with direct control -> port connection.

[Bartosz]

Has anyone figured out how to avoid repetition when it comes to port inputs? Suppose i have a sequence that consists of couple of motor blocks that relate to same motor. If i have more than one hub this means each block input is in fact "hub port selection" input which is bordersome and requires lots of changes if hub/port changes.

I haven't used the custom blocks yet, I can imagine this would be even more annoying there (or perhaps there's possibility to pass hub/port as an argument?)

[Lok24]

2 minutes ago, Bartosz said:

I haven't used the custom blocks yet, I can imagine this would be even more annoying there (or perhaps there's possibility to pass hub/port as an argument?)

Yes, that is possible. But as far as I remember hubs start with 0, just try it.

[Bartosz]

3 hours ago, Lok24 said:

Yes, that is possible. 

Indeed, I created custom block, inside i put some motor action with hub/port selector as input, for that selectors input I've assigned blue blocks 1 and 2 (I'd call them parameters blocks), and then from the top level it correctly recognized that one input is hub number while the other is port number.

[dr_spock]

On 3/28/2021 at 12:07 AM, UltraViolet said:

  My father has owned and operated a mainframe software company since the mid 80's.  He'd sure know what you're talking about.  I occasionally did some hardware maintenance work for the company, but programming, particularly in the mainframe environment, never really grabbed me.  It's unfortunate, because no one even teaches that stuff any longer.  Anyone with that knowledge and experience is now in demand, as much of the 'old guard' has retired.  It's gotten to the point now that mainframe is even running in emulation on production systems, but there are still large corporate mainframes in service running original code my father wrote back in the late 70's/early 80's when he was working for IBM.  One of my earliest memories as a child (couldn't have been more than 5 or 6 years old at the time) was visiting my father at the IBM facility and seeing the reel-to-reel data tape machines as large as refrigerators running in service.  He still owns in storage a compact desktop reel-to-reel model from much later which attached to a PC with an ISA card.

Cool.  Which IBM business unit did your father work for?  Probably should continue the IBM convo in this other chit chat topic to keep this one PU centered ->

On 3/28/2021 at 3:08 PM, Toastie said:

And: It was a very nice read ... only after things turned very ugly of course - and you simply had to revert to the books (and the big mouthed "I don't read manuals" statement was never ever said - because you suddenly realized it was all nicely written up, sometimes it came with "is discouraged" - "may cause unpredictable behavior" on the side ... . I can't even remember how often the books said: Don't do this (what I did).

Would that also include the don't pour water into concentrated acid as noted in the lab safety manual?   The PU team probably should have taken the IBM course on User Interface and Experience.  Programming with my chubby fingers on a small phone screen isn't all that fun.

[Toastie]

18 minutes ago, dr_spock said:

Would that also include the don't pour water into concentrated acid as noted in the lab safety manual?   The PU team probably should have taken the IBM course on User Interface and Experience.  Programming with my chubby fingers on a small phone screen isn't all that fun.

With regard to the acid: Not to the extent of needing a textbook/manual. They told us that a million times. But when you are left with a volume-reduced sulfuric acid digestion mix ... It works though. Just be patient. Same happened when my advisor told me: The LiAlH4 is old. Very old. Just use it up for that step. Well. It was maybe old. But from the sound of one small droplet of water diving into the reaction mixture (to decompose any excess) - it was this ffffffouppp type sound. Not that loud, but - somehow - serious. And for the rest of the lab day I was adding water to the mixture, one fffffouppp after the other.

With regard to chubby fingers: For the exact same reason I have installed the WhatsApp client, the Zoom client, the Teams client, the XYZ smart multi and media client available on my laptop. Good sized keys, maybe even designed along the lines of old books/manuals ... But: Kids don't have chubby fingers! They ride the screen ...

Best
Thorsten 

[Thyraz]

My son just discovered how to keep the motors running without the need to keep the buttons pressed on the Powered Up remote when using the 4 port Move/Boost hub with non-train motors.
Not sure it this is already known.

- Keep e.g. the + button pressed to start the motor
- Press the green button to switch to controlling the other 2 motors (C+D instead of A+B)
- The motor will keep spinning even that the remote is now controlling the 2 other ports
- You can start more motors like that with the same procedure, pressing the green button again will not stop the motors
- Pressing +/-/stop will stop the corresponding motor

This will most likely not work with the city hub, as it has only 2 ports instead of 4...

[Toastie]

9 hours ago, Thyraz said:

when using the 4 port Move/Boost hub

You mean the 2 port M/B hub with the two motors installed, right? I am always confused with these names ...

Best,
Thorsten

[Thyraz]

Yes, sorry. The one that has 2 "fixed ports" and 2 user-connectable ports.

I like this hub, as it's cheaper than the 2 port city hub on Bricklink and has already 2 tacho/sensor motors integrated.
So it has a very nice value/price ratio.

But it's definitely not the smallest of the hubs. ;)
The width is less than the the control+/technic hub on the other side...

[UltraViolet]

On 3/29/2021 at 6:09 PM, dr_spock said:

Cool.  Which IBM business unit did your father work for?  Probably should continue the IBM convo in this other chit chat topic to keep this one PU centered ->

Would that also include the don't pour water into concentrated acid as noted in the lab safety manual?   The PU team probably should have taken the IBM course on User Interface and Experience.  Programming with my chubby fingers on a small phone screen isn't all that fun.

  It took a little while before I could ask my dad about IBM, but the answer I can give you is that he was primarily working with financial data processing services.  In the early days of his career this goes all the way back to the era of punched cards in the 60's, as well as sending/receiving reel-to-reel tape data across the country over phone lines long before most people even knew the concept of a modem.  (Likely wasn't even 300 baud.)

  I will move any further discussion to the other thread after this.

[C-Brick]

Hi everyone

I have recently started making PUP/PF/EV3 adapter cables out of cut up knockoff pf cable, 3D-printed PUP connectors and self-crimped EV3/NXT cables. There are also PUP connectors for sale on AliExpress but TLG seems to use some sort of crimping tool to attach the cable firmly, better than I could ever do with screwdriver. Has anyone any knowledge on what tools the use and if they are able to be purchased? Any information on this topic would be appreciated.

[Asher]

Hello,

With the PU Remote Control, Technic Large Motor, and the Hub: Is there a way to have the remote's +/- buttons to use variable speed instead of just full speed?

[kbalage]

3 minutes ago, Asher said:

Hello,

With the PU Remote Control, Technic Large Motor, and the Hub: Is there a way to have the remote's +/- buttons to use variable speed instead of just full speed?

Yes, but you need to create a code for that in the Powered Up app, using the remote as an input device.

[Asher]

On 5/4/2021 at 3:59 PM, kbalage said:

Yes, but you need to create a code for that in the Powered Up app, using the remote as an input device.

Thanks where is a good reference to do this?