From silo-first to task-oriented federated app design

Fediversity Fediverse Futures
1

task-oriented-fedi-development
task-oriented-fedi-development800×597 71.8 KB

What if we considered ActivityPub less as enabling ‘distributed Microblogging’, and more as a universal interoperability standard to knit together any kind of business and application domain?

In Fediverse Futures until now I have highlighted the opportunities to extend federated capabilities to many different domains (making more use of AP’s Linked Data foundations). Another thing then to address is how these domains are working together. The interoperability story, let’s say…

Now the AS/AP specs lend themself very well in interoperable application designs… witness the Fediverse. But they are only a small part in the overall picture. As we are planning to pitch ActivityPub to the European Union as the interoperability standard to be chosen for the EU Services Act (see: #meeting:fediverse-policy) we have to admit that interop is very, very hard to achieve, atm.

We are now at a stage where the grassroots and ad-hoc evolution of the Fediverse starts to work against us!

There is ever growing (accidental) complexity if we continue this way. At this moment:

  • Onboarding has new devs following the steepest of learning curves (by experimenting, hearsay, and studying codebases).
  • Documentation materials, tutorials, reference material is sorely lacking or incomplete.
  • The very small SocialHub community currently simply lacks the time to improve things. We move at a crawl.

I digress. This is not new, of course, we know this very well. What I want to address in this topic is the way in which we design federated apps.

Silo-based application design

I co-maintain the very interesting and ever growing ActivityPub application watchlist, and what I observe is that - while federated apps are the goal - application design approach is more or less as follows:

  • I want forum → I develop forum → How can forum federate?
  • I want video → I develop video → How can video federate?

And because the federation is mostly a Microblogging domain, the last step boils down to “How can I map my domain to microblogging?”. App domains being added are pictured as boxed sets of features. They are application silo’s still, and the federation is mostly a bolt-on capability.

Task-oriented application design

Wouldn’t it be great if from the outset we’d design for the tasks (workflows, procedures, whatever…) we’d like people to achieve with our app, and be able to easily knit things together that are already out there, choosing from a growing ‘library’ of federated capabilities and services?

Isn’t that what we are working towards in the end? A situation where the individual application boundaries are no longer visible in the end result for the people performing these tasks?

I would like to dedicate this thread to discuss what is possible here, what already exists, and where we can make progress.

(For this topic also see a related set of toots posted on the Rethinking Humanity and Role of the Fediverse? toot thread)

6 Likes
2

Overall Ack and Thank You for this post.
Just some remarks

The specs do but certain “Actors” do not.
For the felt 1000th times I am linking the

SECTION 2 OF THE SPECS: “Conformance”

ActivityPub conformant Client
This designation applies to any implementation of the entirety of the client portion of the client to server protocol.

ActivityPub conformant Server
This designation applies to any implementation of the entirety of the server portion of the client to server protocol.

ActivityPub conformant Federated Server
This designation applies to any implementation of the entirety of the federation protocols.

It is called out whenever a portion of the specification only applies to implementation of the federation protocol. In addition, whenever requirements are specified, it is called out whether they apply to the client or server (for the client-to-server protocol) or whether referring to a sending or receiving server in the server-to-server protocol.

So can we, can the authors PLEASE DEFINE

entirety ???

As we are planning to pitch ActivityPub to the European Union as the interoperability standard to be chosen for the EU Services Act (see: #meeting:fediverse-policy) we have to admit that interop is very, very hard to achieve, atm.

If I understand “entirety” like I do, interop is easy if we speak (talk) more and not less like now again with the SocialCG which otherwise makes no sense at all.

We should say “webstandards” and W3C recommendations (hard to understand for politicians) and then name ActivityPub as the probably best matching “interoperability standard” see Sandro’s tweet to Evan

What I favour in first place is what MdB Anke Domscheit-Berg demanded in the German Parliament and several MEPs support:
An EU funded fediverse

And I would like to leave here:

and

https://ethicsfordesign.com

and unfortunately

3

Both a healthy and active SocialCG as well as strong SocialHub community are vital, imho, to get anywhere in this effort. One of the big hurdles in this is: People doing the chores of community-building and knitting things together. An EU-funded fediverse is a great idea, and we should consider having a funded community commons, to alleviate time investment and commitment issues.

Think the focus should be on “standards and processes”, offering the methods and practices to ease interoperable implemention of the standards.

(wow, the Ethics for Design page is horribly designed for unusability)

Update: See also the discussion in Organizing for SocialHub Community Empowerment

4

THIS IS SO IMPORTANT. Thank you for posting.

I was chatting with @rhiaro recently…

I think we can share product and design planning across protocol-specific ecosystems

eg the same “reference design” for a given use case can be an input to [many ecosystems (e.g. socialhub, web3)]

What is the “north star” of “What should it look like to use the fediverse?” Regardless of whether ActivityPub is the implementation detail 100% of the time.

IMO it’s obvious that the fediverse must be multi-protocol and (in blockchain jargon) “multi-chain”. ActivityPub is only a tool for certain use cases, but the goal isn’t ActivityPub its serving the humans trying to communicate.

I think one way of organizing community around this is to go back to SocialWG use cases document and “see how we’ve done [so far]”.

Crowdsource feedback on each one, celebrate the “done” ones (and solicit champions to evangelize/document).

Reprioritize the “not done” ones and have their be ONE SINGLE TOP PRIORITY that people are encouraged to work on if they just want to do a high value small thing (#good-first-issue)

Organizations or individuals with funds can the place bounties on the use cases…

The idea is to cooperate on ‘reference designs’ for important use cases for social computing. And prioritize that as its own end over code. It’s making what needs to be coded easier to code when the time is right.

The idea is to avoid doing anything about any particular protocol, and to cooperatively design our social computation.

I’m quite optimistic that ActivityStreams and ActivityPub can represent all kinds of things, not just a ‘general purpose’ social network or twitdeck-style UI.

I’d like to work more on brainstorming which specific experiences we should prioritize actually proving out that are valuable, and subsequently people can propose candidate solutions with specific UML or protocols.

These kinds of design artifacts (e.g. ‘use cases’ or ‘jobs to be done’ or ‘frequently asked question’) may be the most valuable encoding of information out there. If we can articulate those, then they will be useful to all kinds of stakeholders, inside socialhub, EC, and beyond. Those design artifacts could inspired hundreds or millions of different ‘homegrown’ solutions that make sense in their natural/local context (or jurisdiction).

Inspiration:

Backstory:

You know, I first heard about ‘activity streams’ in 2010 from a handful of Google, Microsoft, and Facebook employees…

In 2010, things weren’t quite like they were now. Everyday people consumed ‘news’ in a very different way than they do now…
Upstart news products had to bootstrap their Activity dataset somehow so the Activity Streams weren’t empty. It made sense to cooperate and interoperate to gain early traction… (this was also at a time when gchat and fb chat used XMPP…).

Early versions of Facebooks Open API used ActivityStreams XML. Same with MySpace and Microsoft products. Google Buzz tech may have been quite similar to Open Social tech. Google indexer understands a lot about JSON-LD.

Over the last 10+ years, many of these companies have made some quite successful products that everyday people like to use in part because the product marketing does not focus on protocols or theoretical use cases that don’t work in practice. Instead, a lot of those people worked on products that if not decentralized (nee ‘distributed’ e.g. ‘DiSo’), were often useful to people and helped them perform their daily activities in the easiest way available. Let’s learn from that.

These same early ideators about activity streams syntax also talked about various semantics. For example, one presentation around 2011 is where I first learned about “Activity Theory” (SSAT or CHAT).

@aschrijver What you describe in this thread reminds me of “Activity-Centered Design”. I think there’s something awesome about the genealogy of ideas looping back on itself as it does in this strange loop.

Activity-centered design ( ACD ) is an extension of the Human-centered design paradigm in interaction design.[1] ACD features heavier emphasis on the activities that a user would perform with a given piece of technology. ACD has its theoretical underpinnings in activity theory,[2] from which activities can be defined as actions taken by a user to achieve a goal.[3]

When working with activity-centered design, the designers use research to get insights of the users. Observations and interviews are typical approaches to learn more about the users’ behavior. By mapping users’ activities and tasks, the designer may notice missing tasks for the activity to become more easy to perform, and thus design solutions to accomplish those tasks.

2 Likes
5

I sent another toot this morning pointing to this topic (with an example of Shopping and Shipping domains in a federated app).

And to that I 100% agree. We have this thread Scaling Up Cooperation that’s really not much more than one of the Open Issues of this community at this moment in time. A missed opportunity, while different groups are reinventing wheels.

Currently I believe less in a full-blown semantic web, but I do believe in standardizing on a whole bunch of small closed vocabularies in the Linked Data space. Well, maybe not even standardizing as in ‘adopting a spec’, but move about having a library of design patterns for different domains, where vocabularies are part of the best-practice for each pattern.

For instance on Community and aligning to ValueFlows with @lynnfoster and @bhaugen or - say - entire new fields like PonyUPS, and aforementioned Shopping and Shipping may be library patterns.

The patterns themselves are just knowledge in a growing knowledge base, but they each have a growing list of implementations in various programming languages, API’s and UI component designs (where @Sebastian is also focusing for #software:redaktor-me).

Great that you point to the Use Cases document @bengo - this text had slipped my notice thus far - because, as I see it:

Pattern library: Contains both process + artifacts to design building blocks for Devs representing domain-specific use cases.

(Continuing from earlier today)

The focus on use cases that’s combined in the pattern library is a more hands-on approach than the initial WG document, because we have a fediverse in production to build on and any activity is directly related to practice in the field. It should be ideal for crowdsourcing.

When it is tied to this community (the forum) we can facilitate social interaction here. The community aspect is really important, and indeed championing success / advocating direction. For instance we have a FEP initiative now (thanks to great efforts of @cjs and @pukkamustard), but arguably the process is hard to get under steam without people actively monitoring and rallying things up. But this is time-consuming.

Other than that the use case pursuit can be less bound to direct standards evolution. There are other holes in the fediverse interoperability story where we can place attention in this regard (e.g. privacy, encryption, identity, p2p), probably in different standards.

Exactly. I created #fediversity:fediverse-futures to address the ideation part of this, encourage ‘thinking out of the box’… as a starter. We can just bring stuff up here, and see which ideas are inspiring enough to stick. I see that work like this (video).

The pattern library approach then, is a follow-up that encompasses all the above. Where documents such as a “Smart Vaccination Certificate” - if there’s community interest for that - are gradually elaborated further via crowdsourcing. At top-level there’s only domain knowledge, and a drilldown involves choosing technological directions.

Yes, so should we, AP devs. As it gets too little attention still.

Here it gets really interesting to me. So far, even while we reached out above deeply technical matters, we haven’t really addressed some very important aspects to evolving the Fediverse to a ubiquitous interoperable “social fabric” and that is: the Processes and Methods by which things are woven and stitched together.

I really like those links you mentioned, and - in terms of both involving non-technical people and focus on functionality that truly match their needs - I’d like to introduce another term to this mix, and that is Domain Driven Design. I feel this is a really good match when working with closed vocabularies modeled as AP (or Solid, or what-have-you) extensions.

2 Likes
6

3 posts were split to a new topic: Federated Processes: Combining Valueflows and ActivityPub

8

DDD, CQRS, Event Sourcing, Actor Model… Oh, my!

A lot of concepts come together in this thread. Luckily they fit perfectly together. In the following video Vaughn Vernon, who is an export in DDD, Actor model and designing of Reactive systems, explain how they fit together.

The video is about one hour, but - if you are impatient - you can skip to 32.30min to get the gist and then to 55.30min to learn a bit more about Event Storming.

CC @anon20068248 @hamishcampbell in follow-up to DDD-related discussion here and here (among others). And @cjs in relation to #software:go-fed (and sharedInbox, but that’s for another topic)

2 Likes
9

I agree with this whole thread but may I suggest that “task” might be too small, depending on what you mean by it? For example, look at the discussion of the limitations of the Trello UI in User Interface potentials for Valueflows — Write.as

Bonfire is working on variations of these more flow-oriented coordination approaches. @aschrijver you’ve mentioned them a few times in related fedi threads so I know you are aware.

1 Like
10

I am using ‘task-oriented’ to loosely refer to a set of UX patterns that focus on the outcome of what a person wants to achieve, and the process with which they do so. And do it in a familiar way that closely matches a particular domain. What one does can be very complex. And tasks need not be manual, they can be automated, call back-end / 3rd-party services, etc. Other names are task-based, task-driven, workflow-oriented. But using these names can be confusing.

What I want to highlight is how a more component-based federated architecture could faciltate more modular flexible, dynamic UI’s. In a regular application a full-blown UI usually comes bundled with the app and is tightly bound to an API made for the purpose of displaying it. Even if another party builds a separate UI they need to build on this entire API and the choices already made restrict their freedom and make it hard to integrate with other app UI’s.

Yes, Bonfire Networks is the federated project that most aligns with this topic, and it is exciting to see that. Other projects that come close to exploring these ideas are Go-Fed, where you can codegen AP extensions from OWL vocabulary definitions, and I guess openEngiadina, since that platform wants to surface many different semantic knowledge concepts to end users.

Note that distributed, component-based task-driven and composable UI’s have been a dream for a very long time, and the fact that they didn’t materialize in significant ways is indicator of the underlying complexity of this paradigm. Implementing this for a single platform is do-able, but to have a more universal approach requires more standardization and, well… complexity increases rapidly.

A great inspiration can be Mercury OS by Jason Yuan. See this article:

Note that @sean has some nice plans on creating an app to explore UI components that are based on AP message format. Still investigating how that might look like. You can find more info here:

11

I’m fascinated by MercuryOS UX as i’ve experimented with similar approaches a few times.
Is there any active effort to research and develop it? And I agree that it fits pretty well as a generic UX for federated systems that deal with multiple activity types.

3 Likes
12

I just looked at Mercury. Very interesting! But looks like a single-person-oriented experience, not a social experience. How do you think it would be different in a multi-person flow?

1 Like
13

Here’s the multi-person approach from the Mercury designer, Jason Yuan:

Or maybe they already changed the name? https://sprout.place/

1 Like
14

I am not an UX chap, but I can imagine timelines to be consisting of rich widgets, where currently an app can e.g. only display a fixed ‘toot’ widget that comes with some functionality to it (e.g. content warnings, polls), there can be many different response types. Polls can be separate timeline widgets and they might have additional functionality e.g. they support full-blown form surveys. There will be Event widgets, Geolocation widgets, Image gallery widgets, Slideshow widgets, whatever one wants…

People may interact in all kinds of ways to them. Like indicate their interest so that a group forms, until they decide to break out into a parallel timeline session where they go through some kind of workflow. Or there may be different layouts associated to that.

Breaking out of the strict timeline jacket, like in the cool site links you added… In a Miro/Mural/Prezi-like canvas UI things can be great. Have different-privileged areas on the space where friends and others pop in and out, interact with the widgets there and leave inter-connected stuff behind.

There can be a bigger role for the graph structures of the social web and navigating all kinds of relationships between actors and other objects.

1 Like
15

Just putting this up here. An article by Geoffrey Litt:

Writing among others:

Finer granularity

Today we generally think about BYOC at the “app” level. But can we go finer-grained than that, picking individual interface elements?

Instead of needing to pick a single email client, can I compose my favorite email client out of an inbox, a compose window, and a spam filter?

I found the article before, and just bumped into it again via the Malleable Systems website. Geoffrey is involved in some very inspirational projects like some of the Ink & Switch stuff.

(My ‘surf wave’ towards the article started with this toot by Kartik Agaram)

2 Likes
16

Along similar lines of the product above, plus with malleability aspects, passing this on (via Ryuno-Ki):

The Mirrorverse