Open nelliputkonen opened 7 months ago
Impressive what you put together in so little time @nelliputkonen . I only have time for a brief review right now. Below are my initial thoughts. I hope I find the time to go through your points again with the user interface in front of me later. When I quote your bullet points, they are in bold.
Thank you for the excellent comments @OleMussmann! My answers and comments in bold.
What are User function categories? A workflow you want to analyze/showcase? The DB editor serves many functions, and these are the different use cases what the user needs the database editor for. Typically user is only using one of these at a time, or same user might not ever need all of them.
Allow creation of use modes on multiple levels If "guessed", these need to be spot on, or very easy to change Indeed. I would go for very easy to change.
We need to carefully think about accessing functionality from multiple locations. It's a more fundamental question about design philosophy. The two extremes are 1) there should be only one, obvious way to do things; 2) Make functionality available in every location where it could be used from. I'm not saying we should pick one of those, but we should try to formulate a design approach and implement it consistently through the user interface. Good point and new to me. Deserves a discussion.
Move the hamburger menu to the top as dropdown menus (like in workflow editor and typical Windows programs) If I recall correctly, it's the "ribbon" style of user interface. Updated to listing
Entity tree (used for creating/editing entity classes and entities) The concept of "entities" should probably be outlined in a tutorial that you mention. New users might not know what those mean yet. Same with "alternative names" and other concepts. Updated to listing an icon or menu selection to offer short description and link to tutorial in github
Hide database column (if only viewing a single database) (then can also hide 1st columns name 'name') Should we really hide the 1st column? It would create two different views, depending on how many databases are shown. Could the name column also be used to re-name the database? Then we should definitely leave it. Updated to that maybe we toggle entity tree/parameters by database instead. This way we don't have to repeat the database name as typical use case (I guess) is a single database
User interface changes should be done in dialogue with different types of users. What could be a quality-of-life improvement for someone, could brake the workflow from someone else. Yes, you are better experts on this and we need to discuss how to implement this
Entity graph (used for visualizing entities and their relationships) -> Right-click menu: This list is very long, could we break it down and cluster some of those in some sub-menus? Updated to listing
This is a parent issue for all DB editor UI development issues. The parent issue lists all current functionalities (bullets) in DB editor (Toolbox 0.8) and lists suggested improvements (checkboxes) under functionalities. The suggestions can be easily opened as new issues hierarchically under the parent issue. The list is not yet comprehensive and the suggested improvements as well as their order of priority has to be discussed (e.g. starting in Leuven sessions Jan 2024). The listing also needs cross-checking with existing issues and planned improvements - therefore this is a live listing that should be edited as the UI development process moves along.
Spine Toolbox database editor
User function categories:
General UX suggestions:
Top menu and Toolbar
Hamburger menu (in Toolbar)
Entity tree (used for creating/editing entity classes and entities)
Parameter value (used for assigning parameters and parameter values to entities)
Parameter definition (used for viewing the list of all parameters or adding/editing parameter definitions)
Entity alternative (used for selecting which entities are active in which alternative)
Alternative (used to give alternative parameters/parameter values for entities for scenario creation)
Scenario tree (used to build scenarios based on alternatives)
Parameter value list (used for defining a list of possible values for a parameter)
Entity graph (used for visualizing entities and their relationships)
Not covered in this list (yet)