Origami Survey Results, Building Components
TL;DR:Some charts outlining the results of our recent survey titled "Origami Survey: Building Components"
We recently sent out an internal survey titled “Origami Survey: Building Components”. The survey was designed to gather some quantititive data from our users, and the aim was to help us understand the barriers that teams have to developing their own Origami (or Origami-compatible) components. We sent the survey to engineers, and indicated that we were interested in responses from engineers of all seniorities and levels of experience with Origami.
After two weeks, we had 27 responses from different groups within Product and Technology. This post will explore some of the results, and what we can learn from them. (Bear in mind that while great that we’ve got this many responses, we should be wary of drawing too many conclusions from 27 out of all the engineers in Product and Technology).
To help segment the data, we asked each respondent which area of Product and Technology they worked in, as well as asking them to self-report their level of familiarity with using Origami components.
We’d like to say a big thanks to everyone who filled out the survey 🙂
Familiarity
We asked the question “How familiar are you with using Origami components?”, and asked respondents to mark themselves 1 (What are origami components?) to 5 (I’m an expert). Most people responded with 3 or 4:
Area | 1 | 2 | 3 | 4 | 5 |
---|---|---|---|---|---|
CRM | 1 | 0 | 0 | 0 | 0 |
Customer Products | 0 | 0 | 3 | 2 | 1 |
Enterprise Services and Security | 1 | 1 | 2 | 0 | 0 |
FT Core | 1 | 0 | 1 | 0 | 0 |
FT Group Products | 0 | 1 | 0 | 0 | 0 |
Internal Products | 0 | 3 | 1 | 5 | 0 |
Operations and Reliability | 0 | 1 | 0 | 1 | 1 |
Product | 0 | 0 | 1 | 0 | 0 |
When you filter this by the area that the person works in, you can see that the groups who have been using Origami for the longest (Customer Products, Internal Products) generally self-report as having more experience.
Creating Components
We asked the question “Did you know that any engineer can create an Origami component?”, and asked respondents to answer yes or no. There ended up being a roughly 50/50 split:
Response | Respondents |
---|---|
Yes | 13 |
No | 14 |
When you filter this by the area that the person works in, you can see that Customer Products leans more towards “Yes” as an answer. This aligns with some of our assumptions, as Customer Products have some of their own shared components.
Response | Respondents |
---|---|
Yes | 0 |
No | 1 |
Response | Respondents |
---|---|
Yes | 5 |
No | 1 |
Response | Respondents |
---|---|
Yes | 2 |
No | 2 |
Response | Respondents |
---|---|
Yes | 1 |
No | 1 |
Response | Respondents |
---|---|
Yes | 0 |
No | 1 |
Response | Respondents |
---|---|
Yes | 3 |
No | 6 |
Response | Respondents |
---|---|
Yes | 2 |
No | 1 |
Response | Respondents |
---|---|
Yes | 0 |
No | 1 |
Prior Experience
We also asked “Have you ever built or contributed to an Origami component?”, and gave respondents the ability to indicate whether they’ve either built a component, contributed to a component, or both. The vast majority of respondents have neither built nor contributed to the development of a component:
Response | Respondents |
---|---|
Built a component | 2 |
Contributed to a component | 3 |
Both | 3 |
Neither | 19 |
What if an Origami component doesn’t exist?
To get an idea of how people are building their front ends, we asked “If there isn’t an Origami component that suits your needs, how do you build that part of your website?”, and gave respondents the ability to select multiple options from the following, or provide their own response:
- We build and use our own Origami components (Own Origami)
- We build and use our own reusable non-Origami components, which are used across multiple applications (Own Non-Origami)
- We build it directly into our application codebase (Directly Into App)
- We never need anything other than Origami components (Only Origami)
- We use third-party libraries and components (Third-Party)
Ignoring responses of “Other” for now, the results look like this. You can see that in the majority of cases, if an Origami component is not available then front-end code gets built directly into people’s application codebase:
Area | We build and use our own Origami components | We build and use our own reusable non-Origami components, which are used across multiple applications | We build it directly into our application codebase | We never need anything other than Origami components | We use third-party libraries and components |
---|---|---|---|---|---|
CRM | 0 | 1 | 1 | 0 | 1 |
Customer Products | 2 | 2 | 4 | 1 | 1 |
Enterprise Services and Security | 0 | 0 | 2 | 0 | 3 |
FT Core | 0 | 0 | 0 | 0 | 0 |
FT Group Products | 0 | 0 | 0 | 0 | 0 |
Internal Products | 0 | 3 | 7 | 0 | 4 |
Operations and Reliability | 0 | 0 | 3 | 0 | 1 |
Product | 0 | 0 | 1 | 0 | 0 |
The “Other” responses to this question are as follows:
- We beg origami to consider it for their roadmap 🙏, rally others who may benefit from it too
- Didn’t hit such case. Even if I did, would use some simple custom elements. Instead of including other third party libs
- We copy/paste it from another repo that’s done something similar
- Sorry, I’m just not familiar with Origami components
- I’m new :D Never had to touch an Origami component yet!
- Talked to Origami developers who then worked with us improving existing components to meet our requirements
We can see that very few people build Origami-compatible components outside of the Origami team. Engineers are also more likely to use third-party code than build their own reusable components.
Other Feedback
We also got a lot of useful responses in free-text fields at the end of the survey. We’ll be reading and understanding these over the next few weeks. We’ll keep you posted on any work that we decide to do based on the results of this survey.
Thanks again!
The Origami team