## 4 Results: Manual Service Composition
### Manual Composition Problems and Overall Perception
\"... am not 100% sure which output to select,\" P11, programmer. \"The only misleading part is that you need to specify the output of the previous service and I did not know that,\" P7, programmer. The remaining conceptual problems were dispersed and included weak understanding of service binding (i.e., attaching a service to an activity notation), not knowing the meaning of some workflow-based notation, and confusion throughout the compositional process. Notably, the programmers doubted that manual service composition was achievable by non-programmers; e.g., \"This is supposed to be for non-programmers; I think it will be difficult for them,\" P1, programmer; \"The notation is not easy to understand for non-technical users,\" P6, programmer. With respect to usability, the non-programmers were more judgmental about the inability to directly manipulate visual notation and perform certain actions, such as removing unwanted services (54% of themes), than the programmers (36% of themes). Direct manipulation is an important feature to non-programmers since they use it heavily to program the behaviour of composite services. They were more concerned about the immediacy and complexity of the feedback which was beyond their technical knowledge (23% of themes) than the programmers (11% of themes). Two interesting and unexpected results emerged in relation to manual service composition by non-programmers. Firstly, despite the difficulties experienced, some non-programmers claimed that manual service composition is easy to perform (Table 6). Secondly, several non-programmers praised manual service composition for providing more details and offering more freedom to develop powerful personalized applications; e.g., \"This way provides much more detail and gives you freedom,\" said P6, non-programmer. \"It is good to have this application, as I can make powerful and complex tools with it,\" P8, non-programmer. He highlighted the fact that the service composition can be manipulated and personalized according to personal needs; e.g., \"The diagram is very good, as you can add many things and make it specific,\" P8, non-programmer. The ability to see what is happening using theprocess editor was appreciated even by the non-programmers; e.g., \"I like this one as I can see what is going on,\" P9, non-programmer. As expected, programmers valued the control offered by manual service composition and the use of visual notation to represent services and activities (30% of the total themes). The non-programmers emphasized the need for guidance and instructions during the process of composing software services, especially data flow specification which demonstrates the social learning aspect of users; e.g., \"It would be good to have some sort of help guide during the data flow process,\" P5, non-programmer (Table 7). However, this was less of a concern for the expert sample, who focused more on user interface improvements, such as efficient navigation and the provision of immediate results (runtime effects). One non-programmer requested to simplify the terminology and stay away from technical jargon: \"You should use more general words; e.g., \"function' instead of 'operator,\" especially that this is for lay people,\" P1, non-programmer. Two non-programmers suggested a basic and advanced view for different types of users; e.g., \"Perhaps it should have basic and advanced settings for different types of users and keep certain things hidden, as at the moment it puts me off,\" P9, non-programmer. This recommendation supports the notion of progressive learning.