Super App

[pchainho]

Based on our Smart Contextual Assistance scenario (I guess the Participate app somehow is also aligned with this approach) we have been thinking about this "Super App" as a generic powerful App and business concept enabled by reTHINK technical concepts.

The main rational is to enhance user experience by radicaly reducing the high number of Apps users have to manage in the device. Instead, there would be this Super App that could host a high number of dynamicaly loaded smaller Services. At each point in time, there would be a focus Service dynamicaly selected according to users' context. For example. if my context is, "I'm at home playing with my kids" a certain service would be selected and by default my main focus would be handled by this Service (eg reject business communiactions)

The design of the Super App would not be constrained by the services it can host. This means, new services designed after the installation of the Super App could be created and loaded in the Super App according to user subscriptions.

In terms of Business Models, the Super App provider could play the Broker role handling all business transactions between the consumer and service providers, in a collaborative Adhoc App driven ecosystem.

[jmcrom]

if i follow you correctly:

1. This SuperApp will be like an application container that will dynamically fetch new "sub-apps" (aka functionalities/services) based on context. It has some resmblance with this FB announcement but on a more generic approach. This poses some AI-related problematics.
2. As for business model, this SuperApp looks like a generic Uber to me.

[pchainho]

It has some resmblance with this FB announcement but on a more generic approach.

somehow, yes, but this Super App would not be limited to Bots that interacts through Message User Interface. It would also support "normal" GUI. One of the technical impacts on the Hyperty concept would be to have Hyperties featuring GUIs.

As for business model, this SuperApp looks like a generic Uber to me.

Interesting ... but could you further elaborate on this? Would this business model relate somehow with sharing economy business model?

[sbecot]

The "super app" concept can be generalized in "service composition" concept. At least, Service Composition is needed. It is possible because reThink is a framework that can embed hyperties that are executable components. They are described and discoverable in a catalogue of a service provider. What is missing? A search/discovery service more general than the domain catalogue (would mean a global catalogue), possibly a business engine to share revenues (if services are not free, and as long as you compose them, that can be a big deal). This is much related to Servery project (https://www.celticplus.eu/project-servery/ https://www.celticplus.eu/wp-content/uploads/2014/09/Servery-final_lq.pdf) and this paper http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5640945&tag=1 . reThink adds one more element that is the context of the apps. All the elements mentioned here can be a reseach area in itself, so let's be careful to stay within reasonable bounds.

[pchainho]

I would suggest to analyse for D5.2 the requirements a Super App would demand like perhaps having the Hyperties globally discoverable. I think, in D5.1 we have described in the hyperty and partnership life cycle management process that in a partnership ecosystem, each Hyperty Provider would have its own catalogue that would be advertised through the different ecosystems. In a broker business model this would mean, eg, that the Broker Business stakeholder catalogue could have a link to each partner's catalogue.

Regarding business transactions, like revenue sharing, I agree with you that in general this should be out of scope of the project in terms of implementation. I would say, we should only analyse them in WP1 business model scope and perhaps some high level design studies in WP2 on its impact in the high level architecture.

In terms of demonstration we can skip

[Dimitrie]

I think we have with your approach a very good chance to illustrate some important service aspects: a) provide some smart services via a catalogue (acting as control point from a BM perspective), which overcomes current technical restrictions like Android or iphone version b) context based services are in front, e.g. based on location - at home other services are dominant than in the office c) a more generic look out for services via a global "catalogue"

We should take some time in Rennes to go through this!! Question: How do you plan to combine this in an App? Which device is your core device?

[Dimitrie]

-- comment by Joachim :-)

[sbecot]

This is out of topic, but next meeting was relocated in Châtillon (Paris). Indeed, in Rennes I could not find a book shop that meets Denise requirements.

[Dimitrie]

Bonjour Simon,

What is out of topic? I did not get it, bookshop Denise?

Best regards Joachim

Mit freundlichen Grüßen / Best Regards

Joachim Schonowski

Deutsche Telekom AG T-Labs (Research & Development) Joachim Schonowski Ernst-Reuter-Platz 7, 10587 Berlinx-apple-data-detectors://1/0 +4930835358554tel:+4930835358554 (Tel.) +49391580242899tel:+49391580242899 (Fax) +491712298768tel:+491712298768 (Mobil) E-Mail: joachim.schonowski@telekom.demailto:joachim.schonowski@telekom.de www.telekom.comx-apple-msg-load://0CC898E3-EDFD-4087-9F41-7F01D2204B2A/www.telekom.com

ERLEBEN, WAS VERBINDET.

DEUTSCHE TELEKOM AG Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender) Vorstand: Timotheus Höttges (Vorsitzender), Reinhard Clemens, Niek Jan van Damme, Thomas Dannenfeldt, Dr. Thomas Kremer, Claudia Nemat Handelsregister: Amtsgericht Bonn HRB 6794 Sitz der Gesellschaft: Bonn

Am 22.03.2016 um 10:51 schrieb sbecot notifications@github.com<mailto:notifications@github.com>:

This is out of topic, but next meeting was relocated in Châtillon (Paris). Indeed, in Rennes I could not find a book shop that meets Denise requirements.

— You are receiving this because you commented. Reply to this email directly or view it on GitHubhttps://github.com/reTHINK-project/use-cases/issues/104#issuecomment-199724943

[frankob]

A CSP who follows the rethink Approach is able to temporary load additional Services depending on the context. We are always talking about hyperty and loadable functionality. What's about the UI of those temporary loadable functionality? Thinking about Fraunhofer's Hotel room controler: For the time of beeing guest of the Hotel, I will load the Hotel room control Panel but who provides the UI? In case of the Hotel room controler it's quit clear that this would not be the (super) app of the CSP but the Provider of the loadable context, i.e. the Hotel itsself. So we should think also about loadable UIs together with the loadable hyperties.

[pchainho]

Hi @frankob, that's why I mentioned above that one of the impacts of the Super App would be to have some Hyperties featuring GUIs. In WP3 we are studying this possibility.

@Dimitrie

How do you plan to combine this in an App?

In our Super App - let's call it "smartie" for now - we have the MyContext Hyperty that will be in charge of identifying the User Focus based on input from other Context Producer hyperties. There is no dependency between MyContext and Context Producer hyperty. At any time, the user can ask My Context to collect new User Context data from a new Hyperty, say MyLisbonWeekend Hyperty, that it can be done on the fly, without having to install any new App.

Which device is your core device?

We intend to support both Browser (PC) and Smartphone devices.

[sgoendoer]

Hi,

I am joining the discussion a little late. Maybe I misunderstood some things so far.

As far as I understood now, we would propose a SuperApp as a "GUI-Runtime environment" for frontend applications. So What we defined as "app" in reThink until now would be executable code downloaded/installed on the fly on demand? This SuperApp will be a requirement for ALL reThink apps. The rest of the reThink architecture would be left unchanged/unaffected?

This would add a lot of complexity to the ecosystem. A user attempting to run a reThink application/service on a smartphone would do this:

1.) Install the SuperApp 2.) Install the reThink runtime 3.) (Do some setup and configuration if necessary) 4.) Chose and install some app from a SuperAppAppStore (trade mark ;) ) inside of his SuperApp 5.) Now this app downloads/installs the required Hyperties from the reThink catalogue 6.) When connecting to a MN, the ProtocolStub is downloaded

So all in all, I (or my device on behalf of me) would fetch and install 5 different (types of) pieces of code: SuperApp, Runtime, App, Hyperty, ProtocolStub.

Did I summarize this correctly? If yes: Do we want to go in this direction? I mean - as of today, the user installs an app and thats it. Thats easy for the user to understand and easy for the developer to implement. I think we should introduce as little additional steps for a user as possible.

In general, Joachim proposed a similar idea with "Participate", where a buch of functionality and features are bundled in one frontend application. I am not generally against such a SuperApp-Approach, but I would propose to make it optional.

[pchainho]

Hi @sgoendoer

from the user perspective it would install the Super App as a normal "App", that could bring by default a set of available "Contexts" (provided by Hyperties).

In terms of usability we still have to further study how additional "Contexts" can be added but I would say, from the user perspective one option is to have it as part of the Super App settings from where you can add / remove "Contexts". Another option, is to have a "context discovery" feature from where new contexts could be discovered and added.

[sbecot]

To summarize, we could go one step further than what we have planed, but this can bring a lot of complexity. I tried to point this out from a development and business perspective, @sgoendoer tried to point out the complexity for the user. It is true that we have claimed context aware application from the beginning but I totally support @sgoendoer as for this time the framework is very complex, and we don't have a single application running. By the way, this is more related to WP1 and WP2 than WP3.

[frankob]

Some questions/ from my side for discussion 1) Hyperties could be delivered together with an default UI, so that an app, which loads temporary the hyperty, isn't always forced to implement an own UI when integrating the functionality of this hyperty. 2) Who is it, who provides the messaging node and the domain registry in the reThink archtitecture? The CSP? Can we also migrate this funktionality into devices like a router in order to make CSPs redundant in future architectures? 3) Don't we have already a super app in the web? Isn't it called "web browser"! What is it exactly , what a super app we are discussing about should be able to do and what a browser isn't able to do? 4) We have discussed the City voting Scenario and the Hotel Controller Scenario. Isn't it possible to solve these scenario by providing an ordinary web page? What is the benefit of doing it with rethink?

[pchainho]

@sbecot , I think the complexity you mention is related with the App deployment that we discussed yesterday, not the App usability issue raised by @sgoendoer, which, as I mentioned above, shouldn't be an issue.

Regarding the deployment process, as also discussed yesterday, its current complexity is because the 3 demos that we have now, were implemented to run from the development service framework environment. When prepared to be executed from a separated environment, the deployment process will be much easier.

[frankob]

We should also think about the question who will be the one who provides such an (super) app? This will have a strong impact on how such an app looks like 1) Is it a CSP, who comes rather from the side of a network provider, who wants to extend his service by integrating the rethink approach, adding connectivity with other networks to his own domain. 2) Or is it a discovery service provider? Interconnectivity between networks requires an instance, which enables search for communication partners beyond the address book, we call it discovery in our architecture. The discovery enables each rethink user to publish a profile which helps others to find them via the rethink search. It can be assumed, that providers of such a rethink search/discovery don’t stop at the point, where the search results are presented but will also provide the loading of the stub to connect with the selected search result. If the service is also personalized, such a rethink search could also provide the rethink contacts, history, etc… of a user and we come closer and closer to the super app. 3) Or someone else?

[pchainho]

@frankob, that's a good question.

Probably we can say the Business Role that would provide the Super App would still be an Application Service Provider. Now, a stakeholder can play several Business Roles and it will depend a lot on the Business Strategy/Model and market competence of each stakeholder. I see the Brokerage Business Model and the Broker role as a good candidate to also be played by the Super App provider, since it will require lots of skills in terms of partnership ecosystem management.

[ingofriese]

I'm still struggeling with the Super App (before I can see the business I need to be clear what does it mean). For the communication scenario I can more o less explain the benefit of reTHINK. But everytime I show to someone the IoT scenario "Hotel room" or even "Voting", "citizen service" etc. I've been asked. "What is new. Control of a Hotelroom? I can do the same with a web-page today". Look at your WLAN Router. We configure it with an Web-interface. Why to use a hyperty?"

So in fact the super app would be a browser. Every new Tab is a new context.right?

Hope you can help me out to find good arguments why reTHINK helps the IoT scenarios. best Ingo

[sbecot]

@ingofriese we have not only Hyperties on ReThink, and Voting or citizen services have the opportunity to develop identity framework. @pchainho I understand pretty good the issues raised by Sebastian. What I meant is that we should achieve the first phase before pretending to solve other issues.

[rebecca-copeland]

Finally, all my ideas of last year are coming up again.I was talking then about the need to separate the role of the CSP that provides the connectivity and the user application, the webApp. I argued about that for many weeks. It would have had an impact on the design... I wanted to design the relationship with the idea that users select webApp, and webApp selects CSP (and allow for default CSP too), remember? The webApp and CSP are likely to be provided by different entities (especially if webRTC complexity grows), and users have different approaches to selecting them - different criteria. Also, the webApp knows the context, so can improve user experience and decide on QoS, privacy and Policy. This was all in my slides from March 2015 which the reTHINK community ignored so far! I also see that you are having trouble with justifying IoT - another of my old points... There is nothing new in reTHINK for IoT except that the endpoint is where the communication is processed, not in middleware or core. Not only there is nothing that is new, but actually this is worse for most IoT devices, because they tend to be constraint with memory, buttery etc. So, reTHINK mandates usage of Middleware instead of the endpoint for all the hyperties interaction, even if it is not needed otherwise. I doubt that reTHINK has been properly designed for such middleware communication. None of the reTHINK use cases really demonstrate what advantages reTHINK brings.The only benefit is in to operators who want a 'no-back-end', i.e. processing at the endpoint, not on big core systems. This may allow web newcomers (operators) to start with low cost entry barrier. However distribution of processing always involves greater network/software management costs. Nevertheless, since edge computing is now a hot topic, reTHINK may be shown as an implementation of it, or one side of it. That's one positive angle! Is there any benefit to users? Why should they care where things are processed? Independent identity is nice-to-have and there are several important benefits (privacy, mobility, identity security) - but is the reTHINK version really independent - with special IdP?? And then there is the incredibly unfriendly GUID...

My Best Rebecca

  From: Frank Oberle <notifications@github.com>

To: reTHINK-project/use-cases use-cases@noreply.github.com Sent: Wednesday, 23 March 2016, 16:08 Subject: Re: [use-cases] Super App (#104)

We should also think about the question who will be the one who provides such an (super) app? This will have a strong impact on how such an app looks like 1) Is it a CSP, who comes rather from the side of a network provider, who wants to extend his service by integrating the rethink approach, adding connectivity with other networks to his own domain. 2) Or is it a discovery service provider? Interconnectivity between networks requires an instance, which enables search for communication partners beyond the address book, we call it discovery in our architecture. The discovery enables each rethink user to publish a profile which helps others to find them via the rethink search. It can be assumed, that providers of such a rethink search/discovery don’t stop at the point, where the search results are presented but will also provide the loading of the stub to connect with the selected search result. If the service is also personalized, such a rethink search could also provide the rethink contacts, history, etc… of a user and we come closer and closer to the super app. 3) Or someone else?— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

[frankob]

I think its the right moment to discuss and sharpen once again our demo cases in the meaning of "are they really able to show exactly where reTHink makes the difference" because that is first of all what they should do. Also we should reactivate our discussion about roles and Players and who provides which components of our architecture because this question should also strongly affect our demo cases. Shouldn't we open a new thread for this discussion?

[ingofriese]

To me reTHINK is a very powerfull and flexible framework. Thus the question "What is the role of a CSP" cannot answered with just one answer. We can distribute reTHINK functionalities like, providing stub, hyperty, registry, discovery, contacts etc. to different players or even to one. That’s great and this proves that we are technically on a right way. This makes things on the business side a bit more complex, but that’s ok.

Regarding "ugly GUID"...Yes I tend to agree but e.g. IP-addresses are also ugly but they are not designed to used directly.

And again I think for the communication use case reTHINK is great. It enables Endpoints to find other endpoints (in a very flexible world were hyperties come to life and die minutes later). Furthermore reTHINF provides a way to signaling across different domains with different protocols. So reTHINk adds a missing part to WebRTC communication.

Unfortunatly the "different domain and protocol"Thing doesn't work for me with IoT use-cases or even e.g. Voting use-cases"

[sbecot]

The WebApp and CSP can be different, nothing prevent that. As Ingo says, we have a functional framework which is very rich. And we have real arguments for this framework, code at the edge, interoperability, portable identity, QoS on demand.... The counter part of this richness is that it has to be explained in a very straightforward way, which is probably not enough done (maybe too techno push). But I'm not sure this is the stream to discuss about it. I suppose this discussion should be done during next meeting (in Paris), as it will be easier in face to face. At least this "Super App" idea reveals that it is not so clear for everybody. Sorry to repeat myself, but I do think we must achieve first phase before trying to design new things.

[pchainho]

@ingofriese in terms of IoT/M2M, the benefits should be the same as for H2H. Eg I should be able to demo that PTIN Smartie (Smart Contextual Assistance App) can be used to control FOKUS HotelRoom and vice-versa. In D5.1 we have an "interoperability" section where we should have described how the demo can illustrate these benefits. So, I'm expecting that "Participate" scenario is designed to also demo IoT/M2M interoperability.

Regarding having Super App as a Browser where each "Context" is a tab, this is a GUI design issue. In my opinion, with this kind of design you are not taking advantage of reTHINK "on-the-fly" benefits. Eg with Smartie, we are challenging our designers to get a User Experience where GUIs are dynamicaly downloaded or selected through some kind of "Context Browsing"