Status Network Categorization - Marketing Terminology

We are building a series of communications that explain the various projects in the Status Network, how they are related, and why each is a necessary component in building toward the mission.

We have a list of projects that we would like to categorize in order to explain them to non-technical audiences, but we also do not want to use technical terms incorrectly. Therefore, I’m bringing our list and categories to you all to solicit feedback in the category names we’ve drafted.

Are these category names accurate? Do they introduce additional confusion when thinking about the form and functions of the projects? What technical information is conveyed or left out if we use these terms vs others? What other terms are suggestions for category names?

Applications & Hardware
Status App
KeyCard
Teller
Assemble
Dap.ps
Etc

Developer Tools
Embark
Subspace

Networking Layer
vac

Infrastructure layer
Nimbus

Very much appreciate your thoughts around these.

5 Likes

Im curious to hear what @oskarth and @decanus think of the categorization label “Networking Layer”. Is this accurate? Is it scalable if we start to work on other protocols?

Also curious what Nimbus team think about placing Nimbus at the bottom and calling it “Infrastructure”. @arnetheduck @mamy

1 Like

I suspect there’s not much point in separating vac and nimbus into separate categories - might as well stick both under Research or maybe Infrastructure - we also might want a line for libp2p there

3 Likes

Would Products cover it? Seems more conventional and thereby eases the search.
Developer tools and infrastructure could also be bundled into Technology.

I’d say the level of abstraction depends on the menu structure and interaction on the site. If each item goes to a page directly more items make sense. If each item opens a mega menu fewer items make sense.

For reference, I checked intel.com, sap.com,tencent.com, nxp.com, asml.com

1 Like

Products could work for apps and hardware. I don’t think “Technology” does the work justice. One of the primary goals of categorizing, is the display and showcase the breadth of work happening within the Network. We want o showcase how we build at each layer in the “stack” to create a well rounded ecosystem.

This should be appealing for both, people looking to contribute to the network (at any level), as well as signal the massive potential of the ecosystem.

With that, I think the following works well:

Products:
Status App
KeyCard
Teller
Assemble
Dap.ps

Developer Tools
Embark

Infrastructure
Vac
Nimbus
libp2p?

@arnetheduck just to be clear - libp2p would live under infrastructure?

1 Like

yep …

1 Like

Following up on this from a domain and blog structure perspective. As we now have multiple projects all connected via “The Status Network” it makes sense to built up more individual brand equity in each project. Also, our projects, and channels need a ton of clean up (its all a bit of a mess tbh)

Challenge
There is a challenge of leveraging the brand equity of Status while also building communities and brand around our individual projects. They are all tied together and we want people to understand the breadth of what we do as a “Network”. But each project should also maintain autonomy and a unique brand as not to seem reliant on one another.

Current State

  • Currently we have created unique visual identities for each project.
  • New projects such as Vac, Assemble, Teller, dap.ps, and soon to be keycard have their own domains (as opposed to subdomains on status.im). Embark, Subspace, Nimbus live as subdomains on status.im
  • We will launch The Status Network (status.network) which will drive to each individual project
  • Some projects have their own blogs (embark, vac) but others leverage our.status.im
  • no consistency anywhere

Proposal

  • Launch the Status Network (status.network). This will tie all projects together and discuss the role of each initiative in the network as part of a larger mission and vision
  • Launch status network blog and pull in via RSS feed all posts from individual project blogs
  • Each project in the network gets its own domain (no longer a subdomain on status.im). Only projects left for this are keycard, nimbus, embark, subspace
  • Each project will have its own blog which can be much more tailored to the specific audience of the project
    -our.status.im gets a restructuring and becomes the blog for Status App

Blog Structure
39%20AM

Open Questions
@iurimatias @arnetheduck this will require new domains for embark, subspace, nimbus. Are you guys cool with that?
@all - each project should set up its own blog (as vac and embark have already done)

3 Likes

Hey All,

We are getting ready to launch The Status Network website and campaign in attempt to build brand equity in The Network as a whole and shift perception of Status from an app into an ecosystem/network.

We will be moving all projects off of the status.im domain (no more subdomains i.e. nimbus .status.im) and each project will have thier own blog which will be pulled into a master Network newsfeed via rss.

However, we still want to have the tie between all projects. A suggestions of creating a global header item on all sites that notes each project is part of the Status Network. This can be a small logo/icon with a drop down menu for all projects.

Some examples:
https://canonical.com/

49%20AM

06%20AM

33%20AM

26%20AM

Before we implement I would like to know how the teams feel about this as it does imply some level of “centralization”. We can design it in a way that is not intrusive but rather implies the project is part of a larger network.

Super rough mock up of how we could make it work (this is not designed though) https://www.figma.com/file/QGvWthEtkQKVjRcvGTazpZ7S/Status-Network?node-id=806%3A2

cc @iurimatias @arnetheduck @oskarth @guylouis @carl @jarradhope

This will take a bit of design time so i appreciate your thoughts.

1 Like

Thanks for this! I really appreciate the work that’s been done to push things in this direction. It’s definitely a tricky design/marketing consideration.

One aspect that I think is worth highlighting is the mental model we use to illustrate these things. Right now it’s all implicitly based on: X under Status Network. I think this is not the best mental model. Why? It means it is very tricky to put X under Y and Z. Instead, thinking of X as supported and amplified by Y opens up the possibility that Z is doing the same thing too. To illustrate this point further, I made these diagrams.

Here’s the current mental model:

image

In terms of money flows it looks more like this:
image

Here’s a more accurate representation in terms of potential money flows, project independences and symbiosis.:

image|691*9URhEXAfylGDyAwpTsncVw|690x387 0x498

For reference, here’s what the Ethereum ecosystem looks like today:

1*9URhEXAfylGDyAwpTsncVw

This is what we want the Status Network to look like.

What does that look like design wise? I don’t know. But a good litmus test is that a project should be able to have two or more stakeholders/supporters, and the design should still work.

1 Like

Thanks for this writeup @oskarth. I totally hear you on multiple stakeholders and the mental model. We need to keep this open and flexible to account for multiple partners.

However, these projects are in large part funded and established by The Status Network and we should earn the recognition for that as well as build brand equity and perceived value in The Network on the whole.

I personally am not in favor of a global nav as things become far too centralized and do not account for edge cases.

Perhaps we add a consistent item in the footer of each website that calls out and links back to The Status Network website. We can also find interesting ways to build cross links into the web pages themselves. This can be done in the future.

There is a real challenge in graphically representing complex systems without 4th dimension. I agree that the network should look like the ethereum ecosystem graphic, but I don’t think that’s a helpful way to explain the ecosystem.

Elements of Venn may be helpful to show where projects intersect. Feedback loops can be useful if they don’t clutter up the design, but everytime I see feedback loops or system diagrams they very quickly get out of hand and lose relevance for a lot of the audience.

Something with this aesthetic could be useful as it can show overlap and relationships while staying neat and clean.

1_dCzjT5TE6VzRe_tN1taCTA

It won’t get at every project and relationship, but it might be a bridge between needing to show interactivity vs needing to create clear first impressions of what the network is and does.