-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Grouping of sensor, processors and actuators should be more intuitive and user friendly. #23
Comments
Hm...I experience the current division into Sensors, Processors and Actuators as rather logical. If you start pulling out subgroups, I don't see how this makes things more intuitive. Currently you start off by asking yourself, what you want to do: am I gathering data (Sensors), am I processing data (Processors) or am I using the data to control something (Actuators). |
Hi, But I still think, there is could be some improvement, especially when considering the empty space on the right. I agree with what you've said. The current subdivision into sensors, actuators and processors is rather logical, and intuitive as well. When I opened the issue, I didn't know myself, what would be a better alternative. Hope we can discuss some options. What about following approach: We could keep the subdivision, but provide subgroups the flatten the hierarchy a bit. |
Hi Alija, Don't worry about being a critic - your input is much appreciated! I think your idea with subgoups sounds very good - as long as there is space left for the quickselect, which I think is rather handy. Be aware though, that the current structure is reflected in the xml of the component collection - changing the structure would mean changing that too. |
We've discussed issues regarding a static structure of these groups. I thought, maybe we can wrap the (xml) structure to rearrange it without refactoring the complete code base, or at least those parts concerned with grouping of those components. |
Actually there are several ideas of how we could improve the search for a needed plugin. One problem is that the sorting with sensors, processors and actuators ist not always correct, because sometimes it happens that a plugin started as a sensor and then also got an input port and hence should be a processor subsequently. Additionally, some users might want to directly browse by categories or tags like GUI, Filtering, Computer Vision,... Additionally, the searching could be improved to include searching in description texts and fuzzy search. To realize this we could either introduce tags in the model xml structure or at least use the additional information of a plugin description in a more intelligent way. |
Another idea for improvement: When creating/editing a model it's very annoying that you need several steps for inserting a new plugin (Click on components tab, click into search field, Press Enter, Press Enter). Why not adding a direct short cut for inserting a plugin via search? Extracted this idea as new issue: #27 |
a shortcut for the searchfield is a great idea - I'd use the existing one though - it can be adapted accordingly |
I'm new in the AsTeRICS world. I guess I'm not all too used to the concept behind asterics.
However, every time I look for new components, I have to look through nearly every group to discover new items but also to find components I used before.
Would be great if we could wrap the currently static group assignment into a more intuitive and flatter hierarchy.
We could add more groups to the components "ribbon", like sensors, user input, visual output, word processing, string processing, etc. and make more use of the great empty space..
The text was updated successfully, but these errors were encountered: