## 6 Discussion and Practical Implications for Service Composition
A new observation in our study showed that the task of 'adding a parallel activity' proved to be less problematic for the non-programmers than the condition definition and data flow connection tasks. However, the dilemma for the non-programmers revolved around understanding and using the appropriate notations, e.g., split notation and merge, to specify parallel execution of events (i.e., H1a partially-supported). Indeed, they took longer to complete this task than the programmers, which may be attributed to their unfamiliarity with programming languages and visual notations. Interestingly, manual service composition took longer and resulted in more conceptual problems than usability problems when compared to assisted composition (i.e., H1d supported), thus leading to a negative view towards manual service composition by non-programmers. This demonstrates the complex nature of manual service composition and the need for strong development and analytical skills to undertake these tasks. Despite its perceived complexity, a few non-programmers liked the control and freedom offered by manual service composition. The low performance scores, coupled with user feedback, demonstrate that non-programmers are unable to comprehend the concepts of condition definition and data flow connection, primarily due to their unfamiliarity with such tasks that demand vast technical knowledge and due to the weak support provided by the tool. Satisfaction scores show that non-programmers perceive manual service composition as less easy to learn and use, the visual notation as less easy to understand, and feel confused during the composition process (i.e., H1e supported). This may be attributed to their unfamiliarity with programming languages and composition notations. These observations suggest a strong link between a user's self-efficacy, technical background and skills, and ability to learn and perform development tasks. Our design recommendations to lower the barriers to manual service composition by non-programmers are as below. * **DR1:**_\"Employ user language and familiar terminology and avoid technical and low-level language.\"_ Non-programmers have a deficient syntactic knowledge, and using specialized terms aggravates the perceived complexity of service composition and lowers self-esteem. This guideline agrees with the previous recommendations [11; 73]. * **DR2:**_\"Implement a robust and rich manipulation mechanism by which non-programmers can perform differing manual service composition tasks and operations directly on services.\"_ For non-programmers who are unwilling to learn computational concepts and languages, using approaches such as \"user interface service composition\" [41; 42], the \"what you see is what you get\" approach [5], or \"composition at the presentation layer\" [74] might be viable solutions to reducing the cognitive challenges and effort. Demonstrating composition approaches through a dedicated software tutor has also been shown to be an effective method [75]. * **DR3:**_\"Abstract composition activities that require analytical skills from technical details and employ more natural metaphors to achieve complex operations, such as conditional statements, dataflow, and parallel events.\"_ Manual service composition tasks that require a strong understanding of service composition concepts and programming constructs (e.g., if-else statements and loops) are beyond the capabilities of non-programmers and impose high cognitive loads. An alternative strategy may be to use natural language [76; 77] and programming by example [75] to express complex concepts. Trigger-action programming (e.g., IFTTT) is another approach that has demonstrated promising results, although further research is required [78; 65; 79]. Recently, the 5W model showed promising results for the expression of causes and effects (i.e., conditions) [74]. Programming constructs may also be visualized, and this has been showed to enhance a learner's understandability [72].