2. Design Blueprint¶

What is this section?

This document is the official Design Blueprint for Smartup Zero's ONLIFE project. It defines the user experience (UX) principles for Deckpack, the citizen's 'browser' for the Onlife network. It is the primary responsibility of the 3_2_design_team.

Attacker (A): The members of the 3_2_design_team are the "attackers" who research, design, and propose the user experience.
Defender (D): The 4_1_2_tc_design_team (the Team Captain) is the "defender," responsible for reviewing designs and ensuring they align with our core principles.
Midfielder (M): The Engelbot is the "midfielder," which automates the process of publishing the approved version of this document to the 0_timeline.org website.

1. Mission Summary¶

Our mission is to design Deckpack as a generic and resilient "Operating System" for crisis situations, empowering citizens and organizations to build and deploy their own tools on the Onlife network.

2. Main Part: The Deckpack Platform Design¶

Deckpack is not a single-purpose app; it is a platform. Its design is based on a generic, powerful, and adaptable model that can be configured for any type of emergency. The core of this design rests on three fundamental elements: Groups, Plugins, and Cards.

2.1. The Three Core UX Elements¶

2.1.1. Groups: The Shared Computer¶

A Group is a temporary, ad-hoc network formed by a cluster of smartphones running Deckpack in the same physical area. It is, in effect, a shared, decentralized "computer" that exists only as long as the devices are near each other. We define two types of groups:

Group Type	Description	Host	MVP Focus?
Onlife Group	The default, public group that forms automatically. Anyone in range can join. It contains a set of essential, pre-loaded emergency plugins.	"Hosted by nobody" - it is self-forming.	Yes, this is the core of the MVP.
Context Group	A private group created by a specific citizen or organization for a specific purpose (e.g., a "Red Cross Team" group).	Hosted by its creator.	No, this is a future capability.

2.1.2. Plugins: The Emergency Software¶

Plugins are the applications that provide functionality within a Group. They are the "software" that runs on the shared "computer." They define the actions a citizen can take. For the MVP, Smartup Zero will create a basic set of emergency plugins. In the future, our SDK will allow trusted partners (like NGOs and local governments) to develop and deploy their own Plugins for specific crises.

2.1.3. Cards: The Citizen's Files¶

Cards are the tangible, digital objects that citizens interact with. They are like the "files" on a computer. A citizen uses a Plugin to create a Card, which is then shared with the Group. For example, a "Broadcast Message" Plugin would create a "Message" Card. The design of these interactions is inspired by the simple, universally understood dynamics of a card game (playing, saving, discarding), but this is a design hypothesis to be validated by the team.

2.2. Use Case Example: The MVP in Action¶

Now, let's see how these generic elements work together in a real-world MVP scenario.

Scenario: A massive earthquake has hit Istanbul. Power is out, and cellular networks are down.

Forming the Group: A citizen, Ayse, opens Deckpack. The app automatically discovers other nearby users and connects them, forming a public Onlife Group for her immediate neighborhood.
Using a Plugin: The Onlife Group comes pre-loaded with a basic SOS Plugin. Ayse taps the "I Need Help" button to activate it.
Creating a Card: The SOS Plugin presents Ayse with a simple interface. She selects "Medical" for her injured neighbor. The plugin bundles this information with her location into a new SOS Card.
Sharing the Card: Ayse "plays" her SOS Card to the group's shared "Stage." Everyone else in the Onlife Group can now see this card, showing a need for medical help at her location.
Coordination: A Red Cross worker moving through the area also joins the local Onlife Group. She uses a special Responder Plugin that aggregates all the active SOS Cards onto a map, allowing her to coordinate an effective response.

In this example, the Deckpack platform did not need to know what an "earthquake" was. It simply provided the environment (Group), the tools (Plugins), and the interface (Cards) for citizens and responders to coordinate.

3. Submissions: The Design Roadmap¶

To design this platform and its inaugural MVP, the team will complete the following submissions.

Objective ID	Submission Title	Core Goal	Status
`5_1_2_2...`	Design the Core Deckpack Environment	To create the wireframes and UI for the generic platform: group discovery, the `Stage`, and the `Hand`.	Planned
`5_2_2_2...`	Design the "First Response" MVP Pack	To create the high-fidelity, validated designs for the essential `SOS` and `Aid` plugins and the `Cards` they produce.	Planned
`5_3_2_2...`	Define the Plugin SDK Design Guidelines	To create the initial design specifications and UI kit that future partners will use to build their own `Plugins`.	Planned

4. Role Management: Call for Contributions¶

To design a platform of this ambition, we need designers who can think in systems.

Role ID	Role Title	Your Mission If You Join
`4_1_2`	Platform UX Designer	You will design the core, generic Deckpack experience, ensuring it is a simple and powerful foundation for any plugin.
`4_2_2`	Crisis Interaction Designer	You will focus on the MVP "First Response Plugin Pack," ensuring the experience of sending an SOS is foolproof under extreme stress.
`4_3_2`	SDK/Partner Experience Designer	You will design the SDK guidelines and UI kit, creating an amazing experience for our partners like the Red Cross to build their own tools.

5. Team Budget¶

Item	Value (SC)	Status
Total Phase 1 Budget:	0	Awaiting initial crowdfunding
SC Minted to Date:	0	-
Remaining Budget:	0	Our first goal is to meet the Validation Phase crowdfunding target.