profiles are a great way to group services in compose, and has been around for a while, but the current tree view only lists services as flat under compose project name. and actions like stop and down at project level are not intuitive, as they stop and down only default services. and profile services are required to be removed manually.
major ux issues
- no visual distinction between profile services and default services, so users cannot tell which services belong to which profile just by looking at the tree view.
- no profile level actions, so users cannot right click a specific profile to start, stop, or view logs for just that profile. they are forced to fall back to the terminal
- cluttered ui, projects with many optional profile(s) services look cluttered, which defeats the purpose of profiles.
fixes or suggested design decisions
- profile subtrees, any services belonging to a profile should be grouped into a nested folder (e.g.
[debug], [testing]) (could show more services as duplicates across profiles but at least visually grouped and informed/intuitive)
- context commands, right clicking a profile folder should allow the user to execute compose commands (up, stop, down, restart, logs) scoped specifically to that profile. though there are nuances:
- context command to be applied to profile only services(as visible in the profile subtree) or include default services as well? i suggest an option menu selection to choose between the three, third being avoiding actions on shared services that are part of multiple profiles.
- why option menu is better: current behaviour requires manual execution on each profile service, and not directly applicable via project level commands, which is not intuitive. and the option menu allows for more flexibility and control over the actions and selection of services, and additional step is still better than having to manually stop or down each profile service which is current behaviour.
- default services keep showing up as flat under the compose project name, keeping native
docker compose up cli expectations.
above design choices are consistent with the cli behaviour, and no existing user behaviour drifts occur, feature in itself is additive, adding more control and flexibility to the user for managing profile services, and is more intuitive and user friendly.
profiles are a great way to group services in compose, and has been around for a while, but the current tree view only lists services as flat under compose project name. and actions like stop and down at project level are not intuitive, as they stop and down only default services. and profile services are required to be removed manually.
major ux issues
fixes or suggested design decisions
[debug],[testing]) (could show more services as duplicates across profiles but at least visually grouped and informed/intuitive)docker compose upcli expectations.above design choices are consistent with the cli behaviour, and no existing user behaviour drifts occur, feature in itself is additive, adding more control and flexibility to the user for managing profile services, and is more intuitive and user friendly.