B4J Library [ABMaterial Poll] What to do next?

It has come to my attention that a lot of the ABMaterial users would ask for multiple new features for ABMaterial. However, as I only have two hands , I thought it may be a good idea to set up a poll to prioritize on what I should work on next. Some people are not that patient and start writing there own tools, but the chances they become obsolete in the future is very possible. I have my own ideas on how ABMaterial will develop in the long run and I cannot take into account other tools.

I came up with 3 things to do. Note: All of them will be implemented, but you'll have a say in what order they will be worked on. All three would require about the same develop time.

1. ABMXPlay
This is the component you have seen some demos of in this forum and will be more for game developers. It still needs a lot of attention before it can be released.

2. B4JS
The Basic to Javascript transpiler is now in its very early stages. It is a tough one to write without finishing ABMXplay first, as the ABMXPlay component would be the first to really benefit from it. The B4J core functions have been covered, but big parts of all ABMComponents need to be refactored to start using B4JS.

3. ABMAbstractDesigner
A full blown Abstract Visual Designer like the one in B4J. This is NOT a code generator but the real deal. Code generators may look nice at first sight, but like Harris pointed out in another topic, have a huge disadvantage: they go one way. ABMAbstractDesigner would work like the B4X ones: you create a layout, develop, change the layout, continue to develop and so on without losing what you have written in code. I'll use the Grid Designer I've shown as a proof of concept in another post + the possibility to put ABMComponents on them. I've done some tests this weekend and it would work very similar as the other B4X tools.

So, it is up to you now: Vote! My fingers are eager to start typing

Alwaysbusy

 

[Ed Brown]

I have voted!

But, I thought I might explain my vote.

I have tried several times to understand the grid mechanism but so far the old gray matter just doesn't get it. A designer would allow me to create the apps that I want and what my potential clients want and do it quickly.

The other advantage to the designer is that I can give the design work to be done by someone else while I develop the code - makes it easy to allow for collaboration on a project.

I'm all for the designer

Thanks for the opportunity to steer the development for ABM products!!

 

[alwaysbusy]

@Ed Brown Thank you for your vote!

I have tried several times to understand the grid mechanism

I'm very aware of this. Once you grab the concept, it's straightforward. But getting there is a whole other story. A Designer would indeed solve this issue.

 

[Cableguy]

I have voted, and I will explain why I did my choice...
I am an ABMaterial supporter almost from day one, but, other than running the demo, I haven't really done anything with it....
It's not the grid that puzzles me...
I am not a full-time developer, and do NOT have very precise visual idea of what I would like to build with ABMATERIAL...
A visual designer would help doing just that... Explore eithout having a too specific visual in mind... Try outs, proof of concept... These are near to impossible without a visual designer

 

[alwaysbusy]

@Cableguy Thanks for the vote!

Note that it will be an Abstract Visual Designer. ABMaterials multi device layouts are way to complex to show 'real time' what a page would look like. You still will need to run the .jar to see the result in the browser.

 

[lemonisdead]

I am more for B4JS

 

[alwaysbusy]

I am more for B4JS

That is exactly where this topic is for: to get a feeling what lives with the ABMaterial users. Thanks for the vote!

 

[amminf]

Certainly for my B4J-ABMaterial it is the fastest, most productive way to generate pretty modern webapps.

Now, I believe the implementation of new modules (classes), might help improve productivity even more, avoiding repetitions in the code, taking classes support code, etc.

Possible improvements:

- Class :: DataSet class to facilitate data entry and data recording.
- Ability to use the keyboard. For example in grids: up-down keys.
- Improvement in modalsheet for their content is better modalsheet size adjustment, better utilizing the space, at least in desktop mode.


For me the grid itself is already a designer. He is responsible for doing the work of placement of components on the screen. So I do not think it takes a designer.

Instead B4JS if you see it as a great option: it will speed the interaction with the user, and the webapp as much as we can interact with the user without fear of delays.

Thanks for your great work

 

[Cableguy]

@Cableguy Thanks for the vote!

Note that it will be an Abstract Visual Designer. ABMaterials multi device layouts are way to complex to show 'real time' what a page would look like. You still will need to run the .jar to see the result in the browser.

So, like in b4x, we will have place holders, instead of the actual components, right? For me is enough, to be able to build the web app GUI(no functionality), the rest is just like in b4x, we need to code the actual behaviour...
Still, a theming function with preview would be really welcomed

 

[alwaysbusy]

So, like in b4x, we will have place holders, instead of the actual components, right?

Yes, something like that. You see what components are in which row/cell. It can't show more as it has no idea where it actually will end up in the browser of the device.
The only way to see it, is running the app.

But is just the start. We'll see where we end up with

 

[Philip Chatzig.]

Abstract Designer!

 

[alwaysbusy]

Thank you all for voting and giving me a direction on what to work on the next upcoming nights

It was from the beginning kind of obvious (and my preference too) that the designer was the most wanted feature. Surprising was the non-interest in the gaming aspect of ABMaterial, but @Harris pointed this out to me before (but I wouldn't listen ). Still, one day this is going to be part of ABMaterial too.

I've written a little article on my blog that shows a bit the road ahead. Have a read at:

https://alwaysbusycorner.com/2016/09/28/b4j-future-steps-for-abmaterial/

 

[Cableguy]

Very happy to have read what I did in your blog! Specially the bidirectional aspect of the What You See Is Almost what You Get (WYSIAWYG) designer!
Now you should star a naming poll for the tool!

 

[alwaysbusy]

I agree although ABMAD as a working title kind of grows on me for the moment. For the final name, a poll could be helpful to get some ideas.

 

[Cableguy]

If a designer is all that is going to be created, then the name is just that, but with the CRUD modal form helper, I would consider building an all in one integrated suite

 

[amminf]

I think the most valuable in a survey are the reasons why people voted. In my view, after a few months working in production ABM, the most interesting is to improve and enhanced user interaction and new events on the components: that requires speed and that it offers B4JS.

Instead, a designer ... but if the grid itself Material design is already a designer !
I not think we need designer. Perhaps they starting if created, because they believe it makes them easier learning curve, but IMHO wrong: when they know the GRID see that it is not necessary.

My 2 cents.

 

[alwaysbusy]

I can agree with you @amminf. Once you understand Grid, it is no barrier at all. But it seems this is a to big no-go for a lot of people so I certainly understand why people prefer it. But no worries, both ways of working will be possible and B4JS is coming for sure. I consider this a real asset too.

 

[amminf]

it may be easier to document well the grid than build a AMBDesigner. IMHO the designer is a waste of time ... your time

And what is worse, it could complicate the entire internal design ABMaterial.

I think the best would poll: Do you understand as the GRID work?

You do not understand? We improve the documentation, because when you understand it, you have already a automated designer.

Regards

 

[Ed Brown]

I personally look forward to seeing the designer. Being able to place and position components and visually see it BEFORE writing a single line of code is a HUGE time saver and will have a more consistent development/design approach to the other B4X products. ie. A designer is used for the layouts/activities used in B4A/i/J. After reading your blog post I can see that you do have a fair amount of work ahead and the features being added are more than I was expecting.

If I could vote what would be my second choice would have been then it would have been B4JS - I see a lot of value with this too and look forward to combining both products in the future.

Thanks again AB for the opportunity to vote on the road map.

 

[Erel]

Just a thought...
It is not difficult to read B4X layout files: https://www.b4x.com/android/forum/t...s-files-to-json-and-vice-versa.41623/#content
Maybe you can create a set of custom controls and use B4J designer to create the layout.