Is it possible to add short description of these sliders and check boxes.
Also what does the change of the slider means quantitative value, is it a percentage of some sort does it have a unit value?
Is it possible to add short description of these sliders and check boxes.
Also what does the change of the slider means quantitative value, is it a percentage of some sort does it have a unit value?
As long as you do not want use the Physic attributies of objects (like gravity and collision), so when you only use Connections, you do not have to worry about these setting.
You know what one of the Bongo 2 problems was? It was unclear what’s what and what does what. Everything was trial and error. Waste of time unknowing if the result will be even close to what you expect. Not knowing even if it was possible to be done with Bongo.
I do want to use the physics engine, of course, that is I believe your best selling point, but if people are unable to understand how things work and predict how each slider and value will affect their “animation”, before the actual calculation is run, version 3 will suffer the same major issue of version 2.
Users need to know even reminded before clicking or sliding some setting. There are so many software out there, and very few people focus on just one, and you can’t know everything. You go use some software to complete a task then go on to another, go back and forth. Especially with the niche that Bongo is targeting, you don’t use this kind of simulations very often. People forget.
What kind of answer is that? What if the user DOES want to use Physics?
I don’t think Ivelin wanted help on the specific window. I think he was making a general observation about Bongo’s usability and a suggestion for improvement. He subsequently made that quite clear.
Tooltips everywhere a field is available for input is a good suggestion. Even better might be McNeel’s dynamic help as used in Rhino. Both would be best.
As long as Bongo is a “figure it out for yourself with no available clues” experimental app it will not - cannot - be a successful usable product.
Hi,
I logged a bug here for adding tooltips and making it a bit clearer. Please understand this is still a WIP and these settings are likely to change. As a result documentation is not a priority. We want to stabilize the software before we begin the documentation process.
As for your question, here’s a quick overview.
I totally understand that @Joshua_Kennedy , but if I’m unable to understand what’s what I am unable to test, in that case what is the purpose of WIP access?
I know this is a catch 22, but I’m more than happy to clarify these things when you ask. I appreciate the fact that you’re testing these features and reporting bugs, giving feedback, and asking questions.
For starters, could we get more videos with some explanations and not just clicking. Even not talking but some labels on the screen will be enough.
I can try to whip something up. Is there a specific feature you’d like me to go over?
Excuse me for the annoyance, yesterday night I was:
a. kind of in a hurry and not sure I had some time left today for an extensive reply (I’m leaving for a week holiday in Berlin).
b. from Jansen's linkage - #11 by Luc under the impression that Ivelin was trying to animate the Jansen’s linkage, nothing more.
Sorry and goodbye. I have a plane to catch.
Luc
I presume that you mean they could be removed entirely and maybe even reinserted later, rather than just that the value ranges, data entry method, or cosmetics might change.
In either case, however, a potential feature tester needs to know what it’s for and generally what the program expects for data. Remember: users know very well whether a feature is likely to do them any good or not but may not have a clue how the magic happens, what he/she needs to supply as data to make it work, nor even what exactly a certain piece of data represents and why it’s needed or what it does. So the WIP needs to do a certain level of education about the details of your particular implementation, even if it presupposes the tester has an elementary (or even sophisticated) knowledge of what the feature is trying to do.
As a sometime developer/programmer I understand that proper detailed documentation and help takes time and effort so any possible way it can be delayed until design is finalized is very tempting. But I also know how easy it is to include a tooltip - essentially no harder than putting in a debugging msg box or print statement - so IMHO I think it should be standard practice for every new data entry thing included for tryout in a WIP. I think it would be a significant lowering of the barriers to testing for many users and would likely generate much more user input for you to consider. If done with the requirement in mind, it should be straightforward to devise a script that would go through the source and turn them off, back on or completely remove them for release, though I’m not sure that removal would be good for any other reason but company policy.
that reminds me how much I struggled at first to figure out what all subd commands do.