App ecologies: Mapping apps and their support networks
Oct. 7, 2016•0 likes•823 views
Download to read offline
Report
Social Media
Presentation by Anne Helmond, Fernando van der Vlist, Esther Weltevrede and Carolin Gerlitz at the Association of Internet Researchers Conference Berlin 2016
App ecologies: Mapping apps and their support networks
1. App ecologies:
Mapping apps and their support networks
Carolin Gerlitz, Anne Helmond,
Fernando van der Vlist, and Esther Weltevrede
AoIR 2016 Berlin: "Internet Rules!", 5–8 October 2016, Humboldt-Universität zu Berlin, Germany
University of Siegen / University of Amsterdam
2. Intersecting app & platform
studies
Move beyond studying apps from a single
medium perspective.
Intricate relation between apps and platforms:
platform incentive developers to build on
top of their data and features.
Aim: understand apps as relational and situated
software entities.
3. Creating the conditions for
app development
Characteristics of social media platforms
(1) programmability (Bogost & Montfort
2009; Helmond 2015)
(2) affordances & constraints (Langlois
& Elmer 2013)
(3) involvement of heterogeneous
stakeholders (Gillespie 2010).
Developers realise the programmability and
interpretative flexibility (Bijker & Pinch 1987)
of platforms.
4. Making engagement with
platforms visible
How do developers engage with platform data &
features? How do they recombine, expand,
reinterpret and twist it?
What relations between platforms and apps
emerge?
New method repurposes app stores to identify
and map apps built on top of or in relation to
platforms.
17. Conditions for app
development
Implications of API politics
Few alternative clients or readers (Instagram
and Snapchat)
Few content aggregation or search-related apps
Relative absence of automated or bot-related
apps (Twitter)
18. Negotiating openness &
closure
Platforms create the conditions within which
app development on top of their data can
take place.
API politics (cf. Bucher 2013) as central means
to regulate openness and closure of the
platform’s interpretative flexibility.
Negotiation involves a variety of stakeholders
(platforms, developers, users).
19. From platform politics to
stakeholder politics
Stakeholder politics: how developers twist and
tweak platform data and features to make them fit
their own objectives and valuation regimes.
Intersects developers - platform - users.
Understanding stakeholder politics contributes to
both app and platform studies - allows to study
apps as situated software & platforms as
open/closed.
Editor's Notes
S1 Intro
So the first presentation concerns understanding apps through their support networks.
We would like to present a collaborative project we started over two years ago with Carolin Gerlitz, Anne Helmond, Fernando van der Vlist, and Esther Weltevrede.
S2 Intersecting app and platform studies
In recent years, apps have been addressed from a series of methodological and disciplinary perspectives. The majority of contributions have focused on apps from a single medium perspective, attending to their interfaces and affordances, their affective and sensory capacities or explored questions of political economy or privacy in relation to specific apps.
But a growing number of apps are not designed as self-sufficient or standalone software objects, but are embedded in, built on top of or in relation to platforms and their databases. Platforms, we argue, create the socio-technical conditions for such support apps and are at the same time enhanced, expanded, reinterpreted or reduced through apps that take up and recombine their data and functionalities.
This presentation sets out to advance app studies at the intersection of platform studies and explores what the respective fields can gain from each other. It suggests to think of apps as relational and situated software entities which are part of wider ecologies of programmable infrastructures and data flows and devises a new methodological approach to explore the intricate relations between apps and platforms.
S3 Creating the conditions for app development
Social media platforms have been characterised by at least 3 main features. First, their programmability: Platforms allow external developers to connect to their data, features and functionalities by providing application programming interfaces which allow structured but also controlled access to their databases. Secondly, platforms have been perceived to come with distinct affordances and constraints for users, enabling them to perform some actions whilst disallowing others. Third, platforms are designed to speak to and involve a series of stakeholders, including users, partners, advertisers, analysts, organisations but also developers and offer distinct interfaces to address their divergent objectives.
Platforms thus create the conditions within which app developers can participate in platform data an platform features and repurpose them for their very own objectives, most notably through the provision of application programming interfaces, their rules, regulations and documentation. In this presentation, we will focus on apps built on top of platforms that are addressed to the wider public and which create new interfaces between developers and users to jointly to re-interpret and advance platforms and their affordances.
Platforms are reliant on developers as their use cases, meaning and value are not fixed but open to interpretative flexibility, to draw on STS scholars Bijker and Pinch. Therefore, platforms partly outsource experimentation and exploration of their interpretative flexibility to developers who test out new recombinations of data, use cases of features or interpretations of what the platform can stand for.
S4 Making engagement with platforms visible
To explore the intricate relation between apps and platforms, we are interested in how developers realise the interpretative flexibility of platforms and how platforms negotiate and respond to their own re-interpretation.
To answer these questions we have devised a new empirical approach to map app-platform ecologies. We have done so by taking a set of most used social media platforms as starting point and used the analytical capacities of one of the main app stores to identify apps built on top of or in relation to these respective platforms and the relations between these apps
Today we will focus on 4 of the main social media players, namely Facebook, Twitter, Instagram and Snapchat.
S5 Method I
Starting point of our method is the Google Play Store, one of the main app stores as they provide the native environment in which users encounter apps. We queried the Google Play Store for the names of the four platforms and retrieved the top 100 apps that were returned for each platform.
S6 Method II
For each of these result sets for the four platforms, we then identified which apps were considered similar according to the Google Play Store. We extracted these similar apps with a purpose-built Google Play Store Similar Apps tool, which scrapes and formats data for further analysis and visualization.
S7 Method III
Having identified the similar app networks, we were interested in how the apps use and potentially re-interpret platform data and features. We then used the self description of apps to identify support apps and through emergent, semi-automated categorisation based on keyword prominence, and we then we clustered apps based on the ways in which they take up and repurpose platform data and features.
//SWITCH TO FERNANDO
S8 Types of relating to platforms
In the four platforms that we studied, we found both shared and very specific types of apps. Most significantly, apps mainly take up platform data and functionalities, whilst developers seem to pay less attention to content. We found three types of shared support apps:
1. First, there is a significant portion of apps that focus on popularity growth and strategic engagement with platforms.
2. Second, there is a cluster focusing on enhancing existing platform functions, for instance by enabling users to edit their content, enhance selfie-making or by offering alternative clients.
3. And third, a cluster of apps that add functionalities which are in fact not supported by the platform itself.
So let’s explore these support clusters in relation to the four platforms.
S9 Facebook Sunburst
For each of the platform support ecologies we created two types of visualisations.
First, a sunburst diagram (or radial treemap), which shows the types of apps constitute the support ecology – the top categories are shown in the center and the more fine-grained, nested subcategories extend into the peripheries.
At first glance, both Facebook and Twitter seem to have a similar profile in terms of their app support ecologies – both platforms are characterised by apps that enhance existing functionalities, most notably by offering alternative clients, support apps for sharing, editing and camera-based apps, content downloaders, and ‘prefab content’ providers.
S10 Twitter Sunburst
However, what distinguishes these two is that there are more alternative clients and managers for Twitter, more apps for strategic popularity, follower and audience growth, and apps focused on searching and discovering new content. Facebook on the other hand, has more profile and activity monitoring apps.
S11 Facebook Gephi graph
Zooming in on the category of alternative clients, we can further distinguish characteristics of these support ecologies. This is shown using network visualisations per support app network., showing app clusters and relations based on the Google Play Store similarity algorithm.
In this particular graph, we have highlighted all alternative clients. For Facebook, these clients include many ‘lite’ clients, reducing chat, photo, and other functionality into an alternative interface (see terms like ‘lite’, ‘fast’, ‘simply’ in app titles). These apps reinterpret the platform into a minimal version with reduced functionalities catering to those with e.g. low-bandwidth connections.
S12 Twitter Gephi graph
Alternative clients for Twitter on the other hand focus more on enhancing existing functionality for professional and multi-account users or strategic use practices.
S13 Instagram sunburst
Instagram and Snapchat also show similarities as both platforms assemble a large array of editor and popularity growth apps.
In the case of Instagram, editor apps are often dedicated to specific tasks, such as assisting in creating selfies, music videos and no-crop squared pictures. Also very prominent are managers that offer: user and hashtag analytics for follower and like growth and profile & activity monitors, used to track activity on one's profile.
S14 Instagram gephi
Let us zoom in to the second largest category of support apps, namely downloaders and repost apps. Here it becomes apparent that developers indeed seek to re-interpret the platform as Instagram explicitly does not allow users to share other users’ posts in order to direct them towards creating original content. Users have already devised manual workarounds but repost apps allow to add standards which users are missing in the platform.
S15 Snapchat sunburst
Finally, Snapchat’s support ecology is similar to Instagram’s but has some specific other categories. The majority are: editor apps that enhance or alter image editing. These editors focus on additional lenses, formats, and beauty/selfie enhancement.
The second largest category of apps focuses on functionality, including battery life and app-locks, followed by follower growth, networking and dating apps.
S16 Snapchat gephi
Zooming into the fourth largest category: Guides, which explain how to use Snapchat and filters. This category is indicative of the specific status of Snapchat, being the only ‘native app’ in the set with no official API and the least established platform of the four.
//SWITCH TO CAROLIN
S17 Conditions for app development
Different than in the case of Facebook and Twitter, very few alternative clients or readers have been found for Instagram and Snapchat.
This is due to the increasingly restrictive API politics both platforms have been following: Instagram, for instance, has discontinued its support for alternative clients and readers in late 2015. In the case of Snapchat, the platform does not offer an official API at all and access to the platform data is mediated by an unofficial third party API or other means.
In a similar vein, very few content aggregation or search related apps were found across all platforms which would enable users to explore content via alternative modes of sorting and ordering.
In the case of Twitter, we are further missing the presence of automation or bot related apps, as one very known form of engagement with Twitter by developers is the creation of automated accounts and scripts. This developer practice is thus more web-based than app-based.
S18 Negotiating openness and closure
Platforms may incentivise developers to explore the interpretative flexibility of their data, content and features, but only within limits that are in line with the platform’s own aims and interpretation. API rules and regulations pose a central means to negotiate the openness and closure of platform data and features and the question emerges how and when platforms seek to stabilise or open up their own interpretation.
Historical research on app ecologies is needed to explore how the openness and closure of platforms has been negotiated by its different stakeholders.
S19 From platform politics to stakeholder politics
Whilst previous research has mainly focused on the ways in which platforms negotiate their relations with stakeholders via API politics (Bucher 2013), this presentation has taken on the perspective of app developers and thus allowed to explore what we understand as stakeholder politics.
Stakeholders politics refers to the ways in which developers twist and tweak platform data and features to make them fit their very own objectives and valuation regimes.
Doing so, they not only negotiate their own relation to the platform, but also the relation between users and platforms, as they respond to, transform and are reliant on user practices.
Some apps may overstep the conditions that platforms create, for instance reposting apps for Instagram or downloading apps for Snapchat, but they remain closely watched by the platforms and their API regulations. Platform and stakeholder politics are inextricably entwined, as both emerge in relation to each other.
Exploring support app ecologies not only contributes to app studies by empirically mapping how they are situated and distributed software entities. It also contributes to platform studies by offering insights into stakeholder practices and politics which are essential to understand programmability, affordances, stakeholders but also openness and closure of platforms.
//Q&A
Q&A anticipated questions/thoughts:
Why only focus on these four social media platforms (e.g. WhatsApp and Messenger are 1 and 2 according to Statista)?
We are interested in different types of support networks and we expect to find more diverse forms with these platforms:
with fairly large developer communities - also enabled by the offering of APIs (except Snapchat).
have a wide variety of features (WhatsApp not)
that also have a web presence
that invite different use practices
Further research: include these other types of apps, such as messengers (we have explored Uber)
But what about non-Western platforms? You're focusing on Western dominated platforms
Dominance of Western app stores (Google en FB)
then outline the bias of App stores and the limits of repurposing
These are top worldwide downloaded, next up we want to take the top x which includes WeChat and Line.
See Poell & de Kloet
The algorithm question: But what about the algorithm? You don’t know how Google does this!?
According to Apptamin, Google also uses these app details provided by developers themselves to derive keywords and rank app search results.
http://www.apptamin.com/blog/optimize-play-store-app/
https://support.google.com/googleplay/android-developer/answer/4448378?hl=en (see also the two included videos #towatch)
https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&utm_source=helpcenter&utm_medium=page&utm_campaign=evergreen