Introduce complex template fields

[ThoAppelsin]

About

The web front-end code is very suitable for extending template fields to include further inputs. We should, and easily can come up with many more complex template fields than the simple, single-input fields.

Currently, the only complex field is the multisel field. We could, for example, prepare one with two text type input fields next to each other, and call it doubletext, which could then be customized by our users for a "Name" field with two inputs as "First" and "Last".

More importantly, we have the example of price input, which is what our customer's heart desires. We need a number/select combination for that. We do not yet support the <select> input, though. Check the related issues for that.

• Related Issues: #167 (prerequisite)

To-do

• [ ] Complete the prerequisites.
• [x] Simplify the template field designing process on the JavaScript.
• [ ] Prepare a number/select field for the amount/currency of money.
• [ ] Prepare a couple of more specialized template fields.

[ThoAppelsin]

I have changed the template field registration process, and it hopefully is simpler now. It is now on the feature/frontend-specialized-template-fields branch, which is the branch we will be using for this and the prerequisite issue.

[karacasoft]

Anything you do in backend/frontend of data templates, has to be implemented in the Android, too. So, I'm hoping you're adding these changes to the documentation of template fields as well.

[ThoAppelsin]

Not everything I do in the frontend of data templates affects the backend and/or Android. The change I have mentioned above is behind an encapsulation, it barely even affects the frontend itself.

You have a point. Not with this issue, however, but the related issue: #167

The support for the <select> input will likely need some further fields on the input object. This extension was mentioned in the documentation, right below the table.

The extension will not affect the existing structures, and no changes will be made to the existing fields. It will only affect the <select> objects, which are brand new to our templates anyway. They should only be of concern to Android, if/when the Android team decides to support the <select> objects, as well.

I have a couple of ideas, but did not make any designs nor implementations on this regard. Let's discuss this extension to the JSON schema together, if you want, under the #167. Or I could again design and implement it on my own, see it working, and when I am sure that it's working, document it.

[karacasoft]

I said, whatever you add to the data templates, we have to add them to the Android project, too. If you support select fields on frontend but not on Android, it will definitely be a problem.

I think the overcomplexity of the current structure of the data template schemas disturb me. So I'll open a separate issue for this.

[smddzcy]

I wouldn't say this is a major importance for us, but we can do it if we still have time after implementing our last milestone requirements.

[ThoAppelsin]

Our customer would be very pleased if we were to implement a feature she was looking for during our presentation last week. Implementing this would indicate that we were listening their feedback, and have taken them seriously.

It is very easy to implement, and is like x2 bonus lying right in front of us. I don't think it is a feature that we can leave out in the end-product, either. The functionality it will offer currently has no alternative. Users have no way of properly placing down the price of a product without it, for example.

[karacasoft]

Our customer would have a complete product, instead of some fancy features. Of course, adding more features are bonus, but without completing the product itself, they're useless.

It is very easy to implement,

Once again, you're just talking about what YOU are going to implement. But, whatever you make, should be also implemented on Android. Dropdown menus(Spinners, as they call) on Android requires an Adapter implementation, and a data class implementation. We also have to have bindings from selections to the api.

[smddzcy]

Complete product with basic functionality (i.e. an MVP) > incomplete product with sophisticated features. I think we should postpone this and first work on privacy options, moderative features, annotations and so on.

[ThoAppelsin]

You should define what you consider as "complete", because I do not consider a product complete when it lacks the features its customer wants.

Our customer specifically mentioned this as a feedback during the demo. I truly believe that implementation of this is a step towards making our product complete.

[smddzcy]

Incomplete = the product can't provide the basic functionality. Complex data templates is not a part of the basic functionality of our product.

Prioritization is the key to product management, and this is very poor prioritization. Please try to understand what we're saying and defend your case from an objective point-of-view 😄 If you still can't agree with us, we can use a good method of Scrum and choose what to implement next (or, prioritize) by a majority vote. I strongly believe we won't choose this.

[ThoAppelsin]

We can do that, I am in, let's do a vote. Here are my arguments:

• Given that this is a very small and easy task, I believe this is a perfect opportunity to prove ourselves to our customer that we are listening to their feedback, and not taking our decisions regardless of what they are telling us.
• It won't take that so long for us to do it. It won't be taking away the valuable time we would instead be spending on another work, but rather the time we would be spending slacking off.

Lastly, if the decision out of the vote happens to be against implementing this feature, I think we should all together bring this dispute to Suzan hoca, not as a customer but as our instructor, to learn something out of this lecture:

She repeatedly had told us that we should take the demonstrations as a valuable opportunity of taking feedback from our customer. I had been thinking that we really should be doing that, and what you are defending now is the complete opposite. Maybe you are right, maybe I have somehow misunderstood her. Maybe she didn't mean us to be that so strict about the feedbacks, and it indeed is okay to disregard feedbacks, if the idea of acting over those feedbacks makes the majority of the team scared about not coming up with the product that is entirely ready for their requested basic functionality.

Mind you, I am not 100% strict about acting over all the feedbacks, either. I am not saying that we should implement the geolocation thing right away, for example, because I, too, fear that it may take longer than we may ever guess. On the other hand, I can see that it is at least 95% certain that resolving this very issue won't take longer than 2 days, and some time later, 2 days more on the Android part. I am flexibly disregarding the other feedback, and offering to act over this other feedback that I have seen as a low-hanging fruit.

If you won't, I personally will. I definitely want to learn about this. After all, this is the only real aim of this course, to teach us about how to take actions in a project and cooperate with the customer. I want to know how okay it is to put the customer feedbacks on hold, how beneficial are the either one of our options.

[smddzcy]

Taking feedback from your customer(s) and iterating your product is perfectly fine, as long as you prioritize what to do next. I'm just saying improving a feature without having a product with a complete set of basic features is poor product management. I think the aim of the course is to learn how to work as a team, work with a customer, plan & implement a software and so on; not to do everything your customer says immediately 😄 We can do the voting in our next meeting, until then, I'm putting this one on hold.