ArcSphere 2.0: ARC's Mobile Application Surface
ArcSphere 1.0 started out as an AI web browser for the phone. It let us work through browsing, tabs and AI interaction on mobile, and along the way a more concrete question surfaced: when someone picks up a phone, what they want is rarely to look at a web page. It is to move something forward.
Its interface has always had one clear design thread. Pages and experiences that are already open can be organized inside the app spatially, as spheres, so nobody has to guess what is still open somewhere down a long list. A person can see the current context as one simple whole and return to whatever needs to continue. The spatial metaphor is not there to produce elaborate visuals. It is there so that "in progress" has a quiet, recognizable place on a phone.
The phone experience today tends to cut one task into many pieces. You come in from a message, jump to a profile, finish something on another page, then go back to confirm the next step. Every piece opens. Not every piece connects back to the one before it. The difficulty is not a shortage of entry points, it is that context goes missing between them.
ArcSphere 2.0, now in preparation, will carry that design thread into the ARC era. It will no longer be only an AI browser. It will be the mobile user interface for ARC-native experiences, giving the ARC Blocklet experiences that suit a phone a coherent, close-to-native way to be used. What changes is what gets presented, not any intent to make the interface more complicated. We want it to keep the minimalism, the sense of space and the continuity ArcSphere has always had. The interactions themselves will be whatever the finished product does.
See the thing to be done, not a URL
A web browser's main job is to open a page on the web from a URL. It faces arbitrary sites, web standards and links. That model is what connects the open web, and it shaped the forward, back and hierarchical navigation people already know.
ArcSphere 2.0 faces something else. It will face experiences run by ARC. ARC is the runtime environment ArcBlock is building, and a Blocklet is the application unit inside it: a Blocklet describes the pages, data, identity or other capabilities one experience needs, and the ARC runtime supplies them.
When an experience suited to ArcSphere opens, the user should first see the thing to be done, not a string of addresses, page jumps and scattered entry points waiting to be interpreted. Reading a document, filling in information, checking progress, going back to the step just taken: on a phone these should add up to one process a person can follow. A future ArcSphere screen should make it obvious at a glance which experiences are open and where you currently are, rather than putting more pages in competition for attention.
This is not a web page shrunk to fit a phone. The goal is to put an ARC experience inside a mobile interface that has continuity, so a user can enter the current experience, finish what is in front of them, and come back up a clear hierarchy. The interface can borrow the sense of direction a browser gives people, but it serves the context of one ARC experience instead of browsing the whole web.
Why the phone needs this layer most
A phone lives between interruption and resumption. Someone finishes a piece of content on the commute, comes back later to add information, or returns from a different piece of work to confirm a step that was never completed. The screen is small and attention is short. Anywhere a person has to work out again where they are and what they had already done, a simple task turns into an effortful one.
ARC lets a Blocklet keep evolving, but the product experience cannot leave that evolution for the user to stitch together. On mobile devices, ArcSphere 2.0 will give supported Blocklet experiences a stable user interface. It will put the current action, the paths that can continue and the way back on the same surface, so nobody has to understand which runtime sits underneath before they know what to do next.
This is also where ArcSphere parts ways with a traditional web browser. A browser makes "where do I go" the first question. ArcSphere cares more about "how does this continue". A web page does not become an ARC experience just because it opens on a phone, and ArcSphere will not turn arbitrary pages into applications. It presents the ARC Blocklet experiences that are actually supported and that suit being used there.
Browser-like orientation, in service of an application
Nobody should have to relearn their phone to use a new interface. Back, hierarchical navigation and stepping up a level are worth keeping because they tell a person they have not lost their place. ArcSphere 2.0 will keep those habits and redefine what they act on.
Back will not mean leaving a web address. It will mean returning to the previous meaningful position inside the current ARC experience. Hierarchical navigation should not drop the user into another set of links either. It should help them recognize the experience they are using, the step they are on, and how to keep going. For the user, that difference should show up as less terminology and more not having to find the way again.
The same tradeoff shapes the interface itself. ArcSphere 2.0 does not need to import every browser element in order to feel familiar. It will keep the parts that help a phone user stay oriented and continue the task. The rest of the complexity is handled by ARC, AUP and Blocklet in the background, and only becomes something a developer or a technical reader has to understand when it actually matters.
For product builders, the interface does not restart at every screen
The design of ArcSphere 2.0 will be built on AUP. AUP describes what an interface means and what its key actions are, instead of fixing it first to one particular set of pages. A Blocklet states what an ARC experience needs, AUP makes the interface inside it legible to different clients, and the ARC runtime renders it against what the device can do.
For product builders, this does not mean thinking less about user experience. It moves the attention to questions closer to the product itself: what does the user see now, what can they do, and where do they land when it is finished. Layout, input methods and available actions on a phone still depend on the real capabilities of the device, but an interface no longer has to be assumed to belong to a single screen size.
For the user, the result should be plain. An experience supported by ArcSphere should feel on a phone like one complete run through an application, not a set of pages waiting to be assembled by hand. Nobody needs to know what AUP is, or which capability came from the runtime. They only need to know whether the thing can be finished right here.
One interface declaration, more than one screen
The value of AUP is not that every device ends up looking the same. It is that one experience stays understandable inside different capability boundaries. Every device running ARC has its own set of capabilities, and the runtime negotiates from that set which parts of the interface it can present and which inputs are available.
The same AUP experience can be a touchable, navigable interface on a phone. On a voice-first device it might read the text out loud and accept only a limited set of buttons or recognized voice commands. Neither has to reproduce the other's screen, and both can still work around the same experience. When several devices have the runtime and the capability support, they can also cooperate inside one experience.
ArcSphere 2.0 will concentrate on the most common of those screens: the phone. It does not treat a phone as a shrunken desktop, and it does not wrap a fixed web page in a phone frame. It lets an ARC experience treat touch, navigation and limited attention as design conditions from the start.
Scope at release
ArcSphere 2.0 does not mean every Blocklet, every page and every device capability will be presented the same way. The real experience will depend on the ARC runtime, on device capabilities, and on whether a given Blocklet suits the mobile interface in ArcSphere.
The supported scope will be documented with the product. The value of ArcSphere is not in trying to hold every experience. It is in giving the ARC experiences that already suit mobile a clear, continuous path on a phone.
What changes in ArcSphere is not that it gives up the sense of direction a browser provides. It is that the sense of direction gets a new use: letting someone continue one thing on a phone instead of starting over between entry points.