Glide's mission is to create a billion software developers. To do that we'll have to explore many new ways of building software that don't involve writing code. Glide's engineering team is mostly focused on taking the next incremental steps in our product, but we also need to look further ahead, to scout out the possible future directions of our "visual programming" model.
This is a short-term residency, around 3 to 6 months. It should culminate in working prototypes and optionally some kind of publication, which could be in the form of a paper, blog post, or video.
You'll spend your time
- Building working prototypes that explore what Glide could look, feel, and work like in 2-5 years.
- Working with design and engineering to evaluate the feasibility of those ideas.
- Reviewing existing work and exchanging ideas with other people working in the field.
- Working with design and engineering to bring some of those ideas to present-day Glide.
- Presenting old and new ideas and prototypes to the team on a regular basis.
- Working with customers and sales to figure out the most important areas of improvement/research.
Some problems you'll work on
- Data representations. How can Glide represent data that’s not primarily tabular, such as trees and graphs, in a way that’s easy to understand and to work with?
- Screen management. How will Glide show all the screens in an app, and how they connect? How do we explain which screens can be used in a particular situation? How do we facilitate passing additional data from screen to screen?
- Scope. The problem of scope is maybe the most difficult problem in “visual programming”: How does one refer to pieces of data that reside somewhere else? How can Glide make it clear which pieces of data can be referred to in a particular context?
- App and data. How can Glide present both the live app and the data that’s showing in the app at the same time? How can it show where that data is coming from? Why is this row included, but not that? Why is this component showing, but not that?
- Loops. What’s a good UI for building loops in actions? Does Glide even need loops? If not, how is it possible to “do X for all of these”?
- Conditions. How does one build complex boolean conditions? Right now Glide only allows conjunctions and disjunctions of multiple primitive conditions, but they can’t be nested.
- Action semantics. How does one specify which actions should run concurrently and which sequentially? How do we even explain what that means? Or can we infer which one it should be? How does one specify that some actions should run as an atomic transaction, or is that even necessary? How do we explain that?
This job might be perfect for you if...
- You love exploring new ideas and building prototypes
- You have a research track record in the areas of visual programming/no-code in the industry or in academia
- You are passionate about helping non-technical people use the full power of computation
- You enjoy diving into research
- You love presenting your ideas, designs and prototypes, and can do it coherently