Simple Flow: Democratizing Social App Development through Process-Based Design
From a Simple Flow to Social Applications
This paper introduces Simple Flow, a process-based tool designed to simplify the creation of social applications. It abstracts complex social network APIs and authentication protocols into a visual "action graph," enabling end-users and non-programmers to build applications by concatenating social actions like posting, commenting, or voting.
TL;DR
Social applications are everywhere, yet building them remains a hurdle for most due to the "API tax"—the complex overhead of authentication, permissions, and RESTful endpoints. Simple Flow solves this by treating social applications as simple, directed processes. It allows non-programmers to "stitch" social actions together, handling the technical plumbing (like OAuth) behind the scenes in pre-configured templates.
Problem & Motivation: The Hidden Complexity of "Going Social"
Why isn't everyone building their own social apps? The authors identify three major friction points:
- API Cognitive Load: Learning RESTful structures just to post a photo is time-consuming.
- Authentication Silos: Managing tokens and app-level authentication is a nightmare for beginners.
- Permission Management: Only small portions of social data are public; requesting the right scopes (User Permissions) is technically demanding.
Existing solutions like IFTTT are simple but limited to 1-step "if-this-then-that" rules. On the other end, BPMN offers professional process modeling but is far too complex for a marketing manager or a researcher wanting to run a quick social experiment.
Methodology: Actions as Building Blocks
The core innovation of Simple Flow is its Action Conceptual Model. Instead of thinking in endpoints, users think in Actions (e.g., "Select a Friend," "Upload Photo").
The Action Graph
To prevent users from creating illogical flows, the system uses an Action Graph. This graph represents the "legal" navigation structures of a social network. For example, you can't "Like" a photo before you have "Selected" or "Uploaded" one.
Two-Phase Execution
- Design Phase: A visual interface where users select the next possible action from a curated list determined by the Action Graph.
- Execution Phase: The system generates a sequence of "Action Pages"—web templates that handle the UI and the backend API calls automatically.
Experiments & Results: Bridging the Gap
The authors demonstrated that complex social logic—such as a Crowdsourced Photo Contest (Login -> Select Photo -> Comment with Context -> End)—could be modeled as a linear process.
- Abstraction Benefit: By splitting one generic "Upload" action into specific "Upload to Stream" and "Upload to Album" actions, the UI remains clean with fewer input fields.
- Deployment Ease: Users don't need to register an "App" on Facebook or host a server; they just share a link generated by Simple Flow.
Critical Analysis & Conclusion
Simple Flow is a powerful example of Domain-Specific Mashups. While it trades off the total flexibility of a programming language, it gains massive usability for 80% of common use cases (voting, contests, analytics).
Future Outlook: The main limitation is the reliance on the tool's own social network registration. If the tool's master API key is revoked, all user-designed processes fail. Future iterations could allow users to export their flows as standalone "installable packages," balancing ease of use with ownership.
Key Takeaway: For end-user development, constraints are a feature. By limiting choices through an Action Graph, you don't just make development faster; you make it possible for a whole new class of creators.