 Good afternoon friends. Thank you for joining us today at this session. I am Rajat Lal from Region Technologies. I am business head for Region. I work mainly in UK and Europe and this is my colleague Shashank, Shashank Merothia. He's senior business analyst and he's the person going to lead this session for you. I just want to begin with a quick introduction on what we are covering. This session arose out of an engagement we are in with the large telco giant in the UK and we are implementing digital price tag solutions for their digital source concept which essentially talks about how CMS, that is Drupal, is used as the backbone to push content onto the front end platforms which could be anything from an iPad to a mobile device to a screen to a television display in effect providing the same content, same messaging across channels, across products while allowing the company to customize the content it want to show at the country level or at the market level. So it's a very powerful new concept in transforming digital stores, be it for telecoms or be it for other industries such as retail or hospitality for that matter. So that's what the session intends to cover. How we went about this project or are going about this project trying to ensure that there is greater user engagement and experience at the stores of the telco giant. How this concept can be extended by the company across markets and across new products and new devices and new channels that it brings into play. And thirdly, how the entire concept can be extended to other industries. So that's what we are intending to cover today. Some sense in terms of where we see the digital stores or the digital transformation heading. There's a lot of transformation already happening in the retail sector, which is also spreading to other sectors like malls, like hotels, like cruise companies. And we'll talk about this as we go along. So the problem that the company wanted to solve was how to have a common platform, a common platform which feeds the content onto different devices, which can be used by the customer or by virtual assistants in the stores or on screen displays. A common content being fed across a common set of templates being used across device screens. So that's what how the system was implemented is what Shishank is going to talk today. Thank you. Thanks, Rajat. I'll quickly also explain a little bit more about the business expectations. What it started with really was a simple concept that the client wanted to digitize the price tags. In every physical store that you go, you'll see that a lot of price tags are placed across the devices along with those same devices. Now, when they are placed on a particular paper, then it's at the mercy of the stores that they will decide what price will go for a certain device or it could be instructed by someone else. And hence you would see that a lot of different stores can actually have different pricing. What our client wanted to do was take over that control, wanted to ensure that the pricing of the devices was being handled at one place or at a local market level, where the local market can define what all pricing will go for each of the devices. So that was a small problem that they wanted to solve. When we went into a workshop with them for one month and when we came out of their workshop, we realized that it had a potential, that simple concept had that potential where we could actually transform the whole digital stores and retail store space by providing flexibility in offering content and yet a control at one level so that there is control at one level and there is a lot of flexibility in providing content to different stores. And when I say content, it could not be just the pricing but it could also be promotions, offers, different plans that you could offer in different markets and it could vary across different markets and stores of course. So that was the need that Rajat just mentioned and from that need what arose was a concept with which we want to share with all of us. This was a retail store vision that we had come up with after we realized that there was a digital price tagging required. You'll see at one corner there is a digital pricing that we are talking about for each of the devices. There are certain price tags that are in place and you could show the pricing. But what it evolved to was more a kind of omnichannel integration where you would see different screens, different medias being at one place and being controlled by a central group. It could be integrated business ops, omnichannel integration, a self-service terminal where it reduces your wait time and the product comparisons could be done. You could do e-commerce. There are already a lot of stores like Argos which are already doing pickups. You go to a self-service terminal and then ask for what you really want and they'll deliver it in a couple of days and you just come back to the store and pick it up. A lot of people are already doing it but having it in an integrated manner at one level, at one place is something that is what we are trying to achieve. This was a proposition that we came out with and we'll talk about the composition of it. We said that there could be an omnichannel CMS for digital stores. What we would like to do is innovate using Groupalade and we'd like to keep it as a decoupled architecture and we'll come to the architecture in a bit. But we'll keep the reusable content assets so that multiple customer experiences can be achieved. There would be a global templates framework that we'll look at which would have dynamic templating, layouts, components and again, like I said, I will come to this in a moment but this was a proposition that we had given. We wanted to make it future-ready to one centralized CMS controlling store across local markets and there could be one solution for all digital store applications and other media. We would of course like to do a lot of integrations with analytics, ERM, ERP platforms but that's something that we would like to tackle in the future but we want to ensure that we have a system in place which can be integrated well. This was the architecture that we came up with. A very broad architecture that we wanted to look at. There was a omnichannel CMS that we had proposed which had intelligent and active components, reusable layouts and a scalable experience was to be provided. Content APIs would then provide all that content to the global templates framework. The global templates framework itself would have a lot of templates, layouts and components in place. Content would be pulled in and we'll be able to create flexible content across different markets. So you could have one template which could be running across two different markets but could have completely different content in terms of language, in terms of how you are toning it down, whether it's an offer, whether it's a promotion, all of them could be accommodated. Let's talk about it in a little deeper manner. We'll talk about the omnichannels CMS itself. In general, we said that it would be a single omnichannel content management system which would provide configurable, multi-site template-driven user experience and we'll get into more details of it. Consumers will be presented with digital content formats that are fit for purpose format and the messaging would go across all medias, whether it is large screens, whether these are phones, whether these are tablets. Across all medias, you could repurpose your content and make sure that that content goes through friction easily. Of course, we would have to create a backbone. This would become a backbone to deliver customer centric digital store capabilities. Omnichannels CMS, the architecture that we would be looking at, you'd see that there are certain integrations that we are looking at. The omnichannels CMS right at the bottom, it provides you with a lot of different configurations and features. You could feed in the plans into it, the device reporting, the device management, the template management, which is the global template framework that we'd be looking at, would feed the layouts and components there. We'll do scheduling separately rather than keeping into the CMS itself. A content was played into Amazon API, Amazon S3, and then there was an API gateway that was placed so that they could interact with the external systems pretty easily. It could, of course, serve content to all the other systems. These are retail stores. The LDs, DPTs and LDMs are all different varieties of products where the content would be served across one channel only. You don't need multiple channels here. Like I said, there would be a separate template management system that would independently interface with omnichannels CMS backbone, multiple internal enterprise systems. What we wanted to ensure was that Drupal was used for what it does really best. It does content management best. We wanted to ensure Drupal was handling that. Everything else should be moved out of Drupal, which is not Drupal's core capability. For example, we wanted to make sure that the scheduling was handled via SQS and SNS rather than Drupal because Drupal doesn't do that well. We wanted to reduce the stress of the Drupal system because we wanted to, of course, maintain the NFRs and we also wanted to move away all the functions which it shouldn't really handle. Technology choices, like I said, we wanted to move to Drupal. We also made sure that we were choosing the same way as we did with Drupal 8 over Drupal 7 as a core platform. This was primarily decided because we wanted to ensure we wanted to stay with the latest technology. We didn't want to falter back doing Drupal 7 and then finding it hard to replace at a later stage. This was going to be a larger system. So we wanted to take a chance. We wanted to ensure that we were doing Drupal 8, not Drupal 7. We wanted to make sure that we were having a lot of skillful services. It also helped us in having independent cadents and governance around development. We could actually repurpose two different teams who could, one, do CMS and the other one could actually look at the global templates framework. The global template framework itself, we chose PHP as the back end. We didn't really merge it with We saw a lot of them, a lot of other companies doing why we wanted to choose PHP because we wanted to be able to make the system scalable and really connect with any other system at any other given time. We don't have to really struggle by combining it with Drupal. We of course had jQuery as the front end. We have planned that it will be replaced with ReactJS simply because we also have timeline constraints. Yes, integration with Drupal CMS also. We'll talk a little bit more about global templates framework itself. Like I said, it's a central group where we can add layouts, components and templates. Markets can reuse these components and templates. We were also, we have been planning to actually create a markup language which can be in place and it can allow standardized creation of templates and components. We want this system to be able to plug itself into the external systems. It should ideally be able to lift and shift itself and connect with any other system. And of course we want to be able to ensure that there is a serialized and exported content available whenever we need. This is largely the concept that we were looking at. You would see that there was, there was going to be a layout repository at the group level or at the administrative level. The administrators will provide a certain repository of layouts, certain set of components. These components are going to be reusable. Provide the system as placeholders as to what kind of content would go in. So if you would see a video, an image, or a carousel kind of icon there, that simply means that you would be able to fill in some kind of, some specific kind of content there. So you give them that flexibility of components and later on any kind of content which pertains to that component will be, could be fit in. So we don't want to restrict them by saying that you can only give this content, but the component can decide that for you. Of course we had given the local markets the flexibility of creating their own components. They could of course reuse the ones that were already available. They could even combine a lot of components and create their own new components that they can use. These components would fit into these layouts, and these layouts of course are predefined. We could create multiple templates out of it, and these templates again become reusable. Like I said, we have still not fit in the content here, which means that these templates become reusable for different markets, for different purposes. A same video component at the same place could host a news feed for you or even a football match for you. So that makes the whole system very reusable in nature. The template itself can of course be created or reused. Once these templates are created, we can then feed in the content into the components and that would create a complete story or a user experience across different apps or devices that we would look at. A little technicalities of how we wanted to look at it, global template framework architecture. We see that there is a template management system which is primarily based on PHP. There is a layout builder and a widget configuration which primarily are components. There would be a package compiler to compile all of it and then serialize and then provide a persistence layer. The CMS, of course, would have an interaction via the API where the UI and input and output is provided by the CMS, but there is an access control from the CMS because Drupal does that best and of course all the data management relationships because the content stays at the CMS level. Just quickly going through the technology choices again, the templating engine is being created in jQuery. We really want to make sure that we are meeting the timelines. We plan to move to React.js on this, but right now this is all jQuery. The CMS will be parsing jQuery objects which will come out of the templating system and it will be converted into HTML and JSONs which will be then passed on to the CMS client, which actually is the app that we are going to produce. Delving a little deeper, I know there were a few concepts that I have talked about, the templates and components, so I wanted to also touch upon what exactly they meant so that we understand them better. Component would be an intelligent building block that can be reused to create multiple templates with similar layouts. You would see that a lot of elements have been placed on the left-hand side. By the way, this is the actual design that we are going to work on. In fact, it's being worked upon right now. So you would see at the left-hand, there are form elements or different kinds of elements that are in place. As an editor, what you would be able to do is drag and drop each of these elements into the canvas area. So you could drag a couple of text fields or, in fact, three text fields, one label, two in the large description. You could also drag an image element. And then this can create a component for you. For each of the elements that you have placed, there are certain properties that are available. You'll be able to assign them properties, whether you want to place them at the right, place them at the bottom top, wherever you want to place them. You could even define whether it's going to be positioned over a certain other element or behind a certain element. So you could have those placements done. You could have some source types defined. Now, these source types are tightly coupled with the CMS itself at this point of time because the content is largely produced by CMS itself. So we have provided certain source types, which can then define that what kind of content would go into that element itself when this is finally fit with the content. The plan pricing or the plan title, plan images, anything. Of course, the fields are all filterable by the kind of element that you have selected. But once you have grouped these elements, what we intend to do is create a component out of it. And this component can be reused at later places. There's an example given there could be a banner component which could comprise of a text and an image and a button element. This can all form a banner for you. Once we have created the components, like I said, these components are fed into the templates. You would see that a mobile template has been provided as a layout. You could select from one of the layouts that you would want to. But what you can do is the pre-created components in the system can be then dragged and dropped into the system, into your templates, sorry, the layouts, and you can create a template out of it. And like I have already explained that these templates are going to be reusable. And it could be reused at multiple markets with different content mapping. What we finally want to be able to do is we are talking about placing components in templates. But what it finally gives is an experience, a kind of a story that could be run. This could be a story which could typically comprise of multiple templates. Each template would have its own set of components. A story could cater to group type of devices in general or single device. I mean, if you've got an iPhone X launch, you want to be able to ensure that you have got a story running for it. You don't really have to wait for it at the end. You can just keep it creative. It would be able to receive the data from CMS, of course, ranging from the set of plans for a device to a necessary, to some pricing information, to a promotion, or just a related video. This is something that we have proposed right now. You would see there are a lot of templates that have been already selected. For one of the templates that you have selected, you will be able to place what are the elements that are part of that template. You would be able to assign content here. Remember, we have already assigned what kind of content that would go in. Mapping has already been done. When you come to this screen, you are actually able to assign the exact content that you would want to. And the content is, of course, filterable by markets and other criteria. We would, of course, like to create interactive stories. We want to make them impactful. They have to be interactive. People should be able to interact with it. We are providing these stories with a lot of interactions. In fact, in the previous screen, you must have seen there is a select gesture and a select action where I am able to assign a gesture and an action to each of the component or different elements to create that kind of an experience. It becomes interactive in nature. It becomes more immersive. Finally, we have created the story. We want to be able to schedule it also. And a comprehensive scheduler is also in place in the system. While the stories have been created, of course, we would like to schedule them. There is a drag and drop interface that we would like to provide to visualize and schedule stories. We could schedule it for a particular time slot or for a particular week or a day completely. I mean, the editors can then plan ahead. They don't really want to wait till 4th of October to get the Google Pixel launched. This is something that we are working on. This would follow up something, a pattern of a Google calendar. But you would be able to assign stories and, of course, delete them and look at the larger details of it. I do the future. Rajat, would you like to come to it? So we will also talk about, very quickly, talk about how exactly this system is going to be useful at other places also. Yes, and as Shashank has already said, in addition to telco, the system can well apply to retail stores. He's already talked about in Argus or Addixons or any other retail store in the consumer electronic space for that matter. Anything where, any space where a store is needed to sell physical products. The other areas where it could be applied to retail stores, is malls. You have a lot of signages in malls which can be complemented in terms of the same kind of content being displayed on a visitor's mobile phone or on iPads, digital assistants. The concept is essentially the same. A very interesting concept comes in, in the case of cruises, where you have experiences for cruise passengers. So even before the board, they have a certain amount of interaction and digital experience with regard to their itinerary, their program, their bookings, and once they board, they need to be made aware of different experiences, different services, be it the restaurants, be it the art displays, be it the other services, be it the play areas for the children, and the programs on each day of the cruise. Programs for the stops, the board sat with the cruise stops. So all this content needs to come from somewhere and come on to the customer's devices, come on to the display screens, come on to the kiosks, and really the concept is the same as we've been just talking about in the case of telcos. So the application is vast. It's just the imagination that is needed. The kind of business challenges that are there for, you know, business opportunities rather that are there for digital transformation in different verticals. And that's what our plan is, is to be able to extend this concept in more and more business use cases across industries. So that's what we are. This is how a retail store could look for, for example, you know, you could have weighted appointment, queue management, cell service kiosks, displays, and essentially the same floor map directory also. So it all extends. The concept keeps extending. Thank you. Just quickly also talking about what do we have planned for this product at a later stage. We would like to incorporate a lot more features, face recognition. We get to know who you are and when we have got to know about you, then this leads to personalized content. When I know that you are here, I would like to ask you a question. I would like to ask you a question. I actually offer you a lot of content that serves your purpose and not just for everyone. This can also be achieved by observing patterns of your interactions with my app or with my web portal, which of course helps me in refining my interactions, which of course leads to a lot more engagement. Thank you. Thanks a lot, guys. Any questions that you might have, please? The content would be entered by the editors and how they are basically going to do it and I'll take a quick example here, images. When you are dealing with images, you won't be able to fit in one image in all the criteria or all the areas. What we are trying to do is have a node in Drupal itself, which can collect all sorts of images. So for example, there could be a list of images that you would see. It could have an aspect ratio of 2 S2 3 and 1 S2 2 or even 1 S2 1. So they'll club all such images at one place and ensure that all these images are available with me. Now, when I'm going to assign this content to that particular component or a template, I'll ensure that the correct aspect ratio is appeared in. In fact, the system is being made intelligent enough that it knows that the component has a certain aspect ratio and it knows that the component is being made intelligent. These are the aspect ratios that are applicable to the system. So I'll be able to handle that specific content, drag and drop it to the component and say this is now assigned to the content. Does that answer your question? The templating, of course. Any other questions? We are the digital agency which is working with Vodafone to do this implementation. We were initially going to have this presentation by Shashank, along with the representative of Vodafone, but it was decided that since the engagement is still undergoing and the solution hasn't actually gone live, so we would prefer not to have it branded as a Vodafone session. So we are Shrijan Technologies. We are a Drupal development company based in India and based in USA, Europe and Asia as well. And we are working with Vodafone and its registered partners to implement the solution, especially coming in as the Drupal expertise company on this engagement. Right. Thank you guys. There are no more questions. Thank you. Thanks a lot for coming over and really, thank you. If you do have more questions, you can just write into Shash, you saw your Yes. Yes, so there's a Twitter and we have a booth here, booth number 32 so you can just drop in, drop by and have a conversation if you'd like to. Thank you. Thanks a lot guys.