 Okay, let's jump into it. Welcome, thank you for coming. I know this has been a long and intense week and thank you for choosing to spend your last hour of session with me. What I'm gonna do is I'm gonna, first of all, explain a little bit about who I am. And also, I'm just gonna go over what I wanna do in the presentation, just so that you can be sure that this is the one you want to be in. So, who am I? I'm a user interface systems architect with my Planet Digital based in Toronto. They're a wonderful design and technology company that are very, very committed to excellence in user experience. And that's why I'm there because it's a very, very hospital atmosphere for being productive along those lines and that's my passion. So, thank you my planet for being there. What does it mean to be a user interface systems architect? Well, what it means is I've got two heads. The first head has big ears because it likes to listen to users. And what I mean by that is I like to put myself into a deep empathy with users to find out as much as possible about what they're doing as they use applications so that I can help them have better experiences doing that. The other head, a propeller head, is a software developer. So, I've actually spent a couple of, well over two decades doing software development and pretty much I think two decades doing usability design and whatever the current phrase is to describe that kind of work, user interface or user experience. So, the idea is that there's two kinds of consciousness that I like to try and fuse, try to bring together. I like to bridge the gap between those two perspectives. So, you'll see some of that in this presentation. What I wanna do in this presentation is open two doors. Behind the first door is a warm and sunny place where users are happy and they're happy because they can comprehend their user interfaces. Behind the other door is where developers build components for user interfaces. Now, if we can open both those doors, I would like to think that we could have new conversations about how to bring the values, the perspectives, the needs and so on from the door there, the sunny place into this room so that developers can actually build the components in a way that is actually easy that does help users comprehend those interfaces. That's the goal, that's the goal of this presentation. To do that, I wanna present you with two keys. The first key is the concept of user narratives and that will touch on one of my big passions, role-oriented UX design. I'll be touching on what that is. Also, the idea of idioms, which is really a way of looking at language beyond language as English, French, native language, that kind of thing. And then also talking about the, what do I mean by narratives in terms of real life and what do I mean by narratives in terms of user interface design? It involves roles and idioms. It's gonna get a drink. So, the second key is some critical technical information that helps explain things that would be useful. If you care about how words get on the screen, I want to show you how that happens from a technical point of view. It won't be complicated, it won't be deep, it won't be difficult. I guarantee you'll be able to understand it. And I also want to talk about how, from a user experience design point of view, it's really important to organize the words that get on the screen because that's part of the dimension of user experience design. I also need to touch on this, the fact that Drupal currently excludes that dimension of user experience design from those designers. From that, we'll get into it. And then finally, I want to touch on an alternative approach, which is actually inclusive of that perspective from the user experience design perspective. So that's what I'm gonna be doing. If you want these two keys, please stay. If you don't, then there's still time to go and catch something else, so you're welcome to make that adjustment. Let's go ahead and switch. So first, I want to talk about three fundamental concepts from the user experience point of view. These are sort of three tricks of the trade that I use routinely. The first is a good definition of usability. From my point of view, usability is simply the lack of suffering on the part of the user. That's why I like this image, the image of barbed wire dancing shoes, because of course, if you were to use them, it would hurt, you would be suffering. It's a good visual metaphor for the scenario that we're trying to avoid in terms of UX design. The next thing is the concept of usage context. I use this symbol, this is kind of my mascot, because it defines for me the meaning of functionality. Functionality has no meaning outside of the usage context. This, the function of the traffic cone, is absolutely meaningless outside of its usage context. It simply is there to point to all the things around it. So to me, it's a very handy symbol, and you'll see that coming up through the presentation where I'm wanting to draw your attention to usage context. And the last thing, the main weapon, is these two questions. If you want to do user experience analysis, these are very, very useful questions. Who is the user, what are their tasks? They're very simple questions, but if you've done user experience design, you'll know they're often very difficult to answer, but they're very important. So through the presentation, I want to make reference to a project that we're doing at my plant. It's still underway. We're still in the process of doing it. And it's basically a registration system for music exams in two countries. That's Canada and the US. In Canada, it's with the Royal Conservatory of Music. And the same system exams are being used by Carnegie Hall for the Retreatment Program in the US. We've built two websites at my planet, separate websites, there's two contexts of usage. Now the main thing is, they both share this. The business of selling exams is a core part of their business. So the registration for exams has to be very easy, because if it's not, people will drop out of the process and they will lose money, or they will call customer support and it will be a drain on their resources. So there's an economic factor in both those things. So it's very important that we get that process right. And the other thing which is very important here is that there's different user types. And that's gonna come up a lot through this presentation. So the US situation is actually, it's a smaller population of students. And that's where we've begun the process of in terms of building the pilot project. And this is what we've built. And before we got there, we actually prototyped it. We had a very richly interactive prototype that we used to sort of proof the concept of the main function of the registration interaction system. And from that, we built this site. I'll just give you a quick video tour of what that looks like from this point of view. So people coming there, they get into the registration through that gateway. They declare who they are. Are they a student registering for themselves? Are they a parent registering for their children? Or are they a teacher registering on behalf of their students? Now, these are checkboxes. They could theoretically be all of those things. As they press those checkboxes, the user interface itself is extended to provide new tabs. And under those tabs are the interfaces that they use to begin the registration process from that perspective, from that individual perspective. Now, they all funnel back into this common wizard that takes you through those steps of basically identifying who you are, picking the exam that you want to take, choosing time and date that you'd like to take it on, and then heading off to the checkout page to pay for it. That's it. That's what we were trying to do. And that's what we want to be really, really simple. So we did user testing on this. And we learned a couple of things, well, a few things, but in two categories. Some was structural. Some was just about how is the arrangement of the elements and the interaction methods that we use. We learned things about how to improve that. There also were a lot of things about the language that was used in the interface as well that sort of gets people through it. And that's what I want to focus on. And here I want to play a couple of clips which are basically very, very articulate feedback from one of the testers. I didn't pay him, but he did actually say precisely what we needed to hear in terms of the feedback around these issues. So it's really, really excellent sound clips that I want to hear. So hopefully this will work. So this is the, so I've got two of these. You won't be able to see it. I didn't make it big enough for you to see because it's not about seeing it, it's about listening. Founding school is, I'll leave it blank. So I don't know if that's the school I teach at as the teacher, or if that's the school that the student goes to. Yeah, well, because I don't know what an assessment is in a way. I mean, I'm assuming it's like, I sort of can work it out, but I wouldn't have like, schedule an exam. I mean, here we're trying to book an exam and really everything is worded around assessment. I would not think exam for an assessment. But if there was a log as to what all of these things meant and maybe a glossary of terms so we could find out what founding school meant. If you have a user asking for a glossary of terms, you know you have a problem. So that's what we're trying to solve, right? So terminology was one of the big issues and then there's another one. Summarize again what your overall impression is. Needs to change for each type of person. But if I'm a teacher, I would want to see the words that say register my student. Yeah. The language, since I'm a teacher and I had to, the language was written for the student and not for the teacher. Yeah, because I'm not, because I'm trying to do something as a teacher and all of the words are guiding students rather than teachers. So I don't know if it makes sense to have three different types of language that click up when you see student parent teacher. Because there are three different positions in the information stream. So here he's picking up on the fact that there are different types of users and that he was being spoken to from the wrong angle. He was being spoken to as a student and he's not a student. It didn't make sense to him and he was very frustrated by that. So those are the two major issues that we're trying to address. So really it's about the language but it's about the language from the point of view of going beyond the native language it's not English, it's not French, it's not German, et cetera. It's about idioms and whatever is involved in association with speaking to someone is playing a particular role. So I want to go into those two areas just to clarify some more details about that. So in terms of idioms, let's just take a quick look at that. We want this to be comfortable. If we have unfamiliar terms in the interface it's not comfortable. We've got barbed wire shoes. If we have generic terms which is often a solution in UX design because you want to make it fit for everybody but I would say that's equally uncomfortable because it's not speaking in a resonant kind of way. If we have familiar terms, then it's comfortable. At which point we've achieved our nirvana as UX designers the entire interface becomes invisible. No one notices. That's the best we can hope for. Other than that, it's pain. We want no pain. We want people to just go dancing. Roles. Life is a sequence of roles. Roles happen all the time. Roles are about what your mind is focused on at a given time and that's constantly shifting. So a given day might be something like this. I'm cooking breakfast. I walk the dog. I'm commuting to work. I'm emailing. I'm not really a music student but I could be in a music student and if I am I may at some point want to take an exam so I become an exam candidate and I want to register for them. So in order to fulfill roles like this we also need tools. So the kind of tools we need to cook breakfast, we might need a stove and a toaster. To walk a dog, we might need a leash and a dog. To be a commuter we need something like a subway train. So all of these things are outside things that we need to carry out those roles. So the objective and the capability of role-oriented design is to supply the right tools at the right time. If, for example, you decide to cook breakfast while walking your dog on the subway, you know you probably have a confusing time with probably a problem. So the point is you wouldn't do that but why in terms of user interface would we throw up all of the tools that someone could possibly use in one space and expect them to get through it? The whole point behind role-oriented design is that you wouldn't do that. Just the right tools, nothing missing and nothing in excess. That's the objective. The other thing about role-oriented design, this is my other brain speaking, is it actually provides a very good pathway between those two doors. From that sunny spots where the user should be to the back room where the developers are, role-oriented design provides a pathway that informs, it shines light from one space into the other. Let's just follow it through quickly. So here's all our users on the outside. Mary is a music teacher. She does exam registration for her students. She's a music examiner as well and she's been doing that for so long that she's now an exam center representative. Those are all various roles that she could play. The one I want to look at is exam registration and that consists of a set of tasks. She wants to manage her student list so that she can decide who she's dealing with in this session. She picks out a student from there. She then assigns the exam selection that that student should be taking, makes the booking and pays on their behalf and presumably she'll build them afterwards. And in order to do that, she has the tools on the screen to get through all those tasks. Now I like to call these things screenware. All these things that appear on the screen is like software, it's like hardware, it's screenware and it's something to consider in terms of tools or tool sets, which things do you need and which things don't you need. So the nice thing about that too then is that once you're looking at screenware from the point of view of the tools, there's a relationship between those elements on the screen and the information architecture which is behind the screen which the user doesn't really see in an explicit way except through these kinds of representations. And from the IA point of view, it doesn't take very long to get into the actual data itself, that's where it all lives. Of course you'd go through something like a view screen or some kind of means of extracting that data from the database. So role-oriented design has an impact on all these layers, what it looks like on the screen, the layout and so on, the information architecture, how that's shaped, the data retrieval methods, the kind of views you might construct and even perhaps the data structures themselves. So we want light from the user's perspective, the user's world to shine all the way through these layers so that it can actually be shaped properly in such a way that it makes it comfortable and comprehensible for those users. So let's get into the narratives. Connect a few dots to define what that means. So user narrative, basically I said it involves idioms so we have to look at it from the point of view of the terminology differences. So this is a critical factor. In Canada, we register for exams. In the US, we register for assessments. What we did cruelly was we tested a Canadian with the American application and that's why he was so confused. He didn't understand the language but it did point out the importance of getting that language right. And then we have to handle roles. A good way to look at roles is in terms of mindsets. We have three. We have the student, we have the parent, we have the teacher and the mindsets are register me, register my child or register my students. They're quite different, they're subtle. It's a subtle difference but they are different. Enough different that it confused our user and he spoke verbally or extensively about that. And of course they're all different usage contexts. So life, if life is a set of changing roles, if it's a set of shifting mindsets, it probably doesn't look like this in graphic terms. It probably looks more like this. Our consciousness is shifting from one set of tasks, one set of goals to another. So in very crude graphical terms, it looks like a wavy line, not a flat line. Now applications try to mimic that in a way. So they try to accommodate these mindsets to a degree that people will sort of resonate with it but unfortunately doesn't always work out because it's actually going to a different pattern. And we need to understand why that happens. This is where it hurts. Role-oriented designs allow this harmonization to take place between the narratives, the user narratives within the application and the narratives of real life that the user is simply passing through. Now within the Drupal UX community we have some obstacles for this. One is it's inconvenient but it's there. The Drupal defines roles differently than I'm using it. It defines roles as sets of permissions. That may seem like a small thing but I think actually it's just one of those things where it's an unfortunate sort of lack of power of use of that term. Permission sets are fixed for any given user. Roles because they're shifting mindsets can change constantly. So if you're trying to design a user interface that accommodates those shifting mindsets, it doesn't make sense to use a fixed reference point. You cannot do it from that fixed set of permissions. You have to look at it from the point of view of what are the shifting goals, the shifting task sets that they're trying to get through. Drupal also doesn't support the ability to express idiomatically. And that's something I want to go into. And this is where we get, we pick up the other key. This is where we're gonna get into a little bit of technical stuff. What is a string? I'm just curious, does anybody know what I mean when I say what is a string? Could you raise your hand if you do know? And if you don't know, could you raise your hand? Okay, glad you came. This is a string. A string is basically just a set of characters bounded between quotes and these are the things that end up on the screen. That's kind of the formal structure of it. Now, here's a thought experiment. If we think of strings, we have to of course think of words which of course is related to thoughts. If we think about the kinds of thoughts that we have in our heads in this room, there might be certain words that are sort of more common in all of our heads compared to another room next door where they're talking about perhaps Drupal security or even theming. There are different kind of resonant spots in terms of the terms and sort of population densities and so on. So I use this metaphor, this grass metaphor, to describe the idea that thoughts actually come in clusters. And so therefore, so with the words, so with all the terminology and so on. And if we look at it from the point of view of what I see role-oriented strings being organized like, they would be in these kinds of groups where you can see some kind of self-consistency. But in Drupal, if you were to look at where the strings are arranged, it looks like this. This presents a kind of practical problem for you UX designers in that there's no systematic way to go in there and fine-tune any of those strings because it's basically a hunt and destroy mission individually one at a time. And that's not cost-effective and it's not likely to happen. So therefore, the wrong strings end up on the screen. So what do we do about that? Let's go into it a little bit deeper and see if we can find a way towards a solution. Strings have a secret life. There's the strings that you can see on the front of the screen, that's what the users see. And there's strings on the inside behind the screen on the inside of the code that users never see. This is an example, plucked out of the code in Drupal. The string on the left, founded in quotes, is the word name. As a user, you wouldn't see that. On the right, in quotes, is the words blog entry. That's what you're gonna see. So there it is, that's where I got it from. And you can see all those red words on the left are the words that are internal. And these are the words that developers care very much about. The words on the right, which are blue, are the ones that get on the screen. And you can see, for example, the second one there, it's actually HTML. HTML is basically one long string. So the thing is, these code strings, the red ones, should never change unless there's some kind of functional change intended by the developer. I think of them more as nails. You knock them into place to hold things together in a specific way, and if you change that, things fall apart and it breaks. So you can't change those strings. On the other hand, the strings on the outside, the blue ones, have to be flexible. Otherwise, we'll never achieve those comfort levels. So by definition, we have to be able to modify those. They're quite different in nature and character. There's a logical problem. And that is that all of those strings are really red because they're all inside the code. They're all inside that field of grass that I was talking about. And therefore, they're generally inaccessible to UX design processes because it's really too difficult to manage them like that. So this could be a complete disaster, except for one thing. From early on, Drupal has made itself a goal to dominate the world, which of course required that it has the capacity to speak in different languages. So it does have a very strong language translation function called the T function. So if you look at this again, you'll notice that the blue string on the right is actually embedded inside a T function. What that means is that you can find them and you can translate them. But you can't translate them into idioms or role-based perspectives like that. You can't nuance them to that degree. Just change them from English to French to Spanish or whatever. So in terms of our exam registration system, that presents a bit of a problem. Here's the T function dimension. We have the original words, my examination. Then we have a French equivalent. I'm not gonna try and pronounce these. And a German one and a Spanish one. That's how it works right now with Drupal. That's the T function basically in terms of the space of the words. Already, as soon as we take on the task of building this site to work in America in the US, we have a problem because they use different terms. And the T doesn't really accomplish that. It's not designed to. So the idiomatic dimension is missing. It gets even more complex when you consider those roles. That each of these sets of terms, each of these pairs of terms in each language also has to be modified to be comfortable for the actual role, the mindset of the type of user. So we actually got a lot of things to look after here to make it comfortable in all instances. So why have we just restricted ourselves to that one dimension of language translation? I think it's just because it's been hidden, because those strings are in the code and people that care about that perhaps don't know it. That's one reason why I'm giving this presentation. There's also a convenience factor from the development point of view. It is a bit convenient or it's considered convenient to be able to just type those words in as you're busy doing the rest of your work and you don't have to do anything very complicated. But there's a problem with convenience. This is convenient for situations like this. But we know in extended use, it's a different matter. It means these things are actually a bad idea. Now the equivalent here, where we've seen this before, we have seen this before, because not only have embedded strings, we have embedded styles, we have embedded scripts, history, we know that the graphic designers would not allow embedded styles to happen now. We know that interaction designers would not allow embedded JavaScript to happen now. What I'm saying is that embedded strings are no different. That's the kind of situation we're talking about. So if we want to go into those other dimensions, we have to go beyond the T function. So I wanna describe how we've approached this with our application at my planet to address that real problem that we need to fix with the usability. So basically the idea is to extract these strings from the code. We need to go on a rescue mission. Pull them out of there. And we do that by substituting, not user-facing through, we substitute for that, what I would call semantic keys. What I mean by semantic keys is that they do two things. They describe the usage context for this string, and they link the internal code to an external file, in our case we used a file, where the strings are actually defined. So we produce something like this. So what I mean by semantic is that you can tell when it says label underscore blog that it's probably a label, and it probably has something to do with blog. You don't have to really guess too much of that. And therefore it's not a big surprise to see the blue words, blog entry associated with that. Then we have another one, label first name. It's obviously a label that's associated with an input that gathers the person's first name. Same with label last name. Then we have a prompt. We ask a question on the screen. Are you male or female? We have prompt gender. Then we have a couple of answers that they could possibly give. Option underscore gender underscore male, and then the equivalent for female. So there's the semantic sort of meanings on the left that actually I think is very easy from the developer point of view to simply describe those things as you're doing the rest of the logic of your code. You don't have to think about the meaning and the nuance of what the user should be seeing there. When we saw that graph where the wavy line wasn't jiving with the user's real life, it's because the developer puts their mindset into the user interface, because that's what they're forced to do in this system. That's why it disconnects from the user experience. So we also need to help the developers here as well. I think this could be equally helpful for them. Certainly I found it that way in my own experience. So we can also handle the role dimension through the use of what is called a variable. So that thing over the very far right dollar sign role is basically like a little box. And in that box, it will be strings and the string could be, it's gonna be one of student, parent, or teacher. And that is glued to the piece on the left where it says label, blog, underscore, underscore, and that little dot there glues those two things together. So you end up with these kinds of things. Label blog is our original one. Then you can actually modify that string through this system without changing the code. You can get access to a student version where it says student's blog entry and a teacher version, which says teacher's journal or whatever you want it to say. You can change those blue strings without risking breaking the code without having to change the code whatsoever. So that means the strings are freed and accessible to UX design. So we've got these two usage contexts. We're dealing with idioms, we're dealing with roles. We end up with basically these kinds of strings for that one expression, my examination. We've got it in two languages in Canada. We've got English and French. Two languages in the US, English and Spanish. And we've got the three role sort of expressions of it. Now we've done that through a module. It's a module I wrote, we call it the user narratives module. And I'll just explain very quickly how it works. It's really, its job is to help us organize those strings. So this is where the grass is. It's all in there in the random order. Core and contrib modules. We want them to basically look like this where we can get to them and tune them nicely. What we do is we build a custom adapter module and we use the user narrative module to basically root things through to where the strings files are. I should explain, the custom adapter module is simply, it is custom. This is not a generic solution. This is where we're at. It's just simply a custom solution. It's using the form API, which is basically going through all the input forms, pulling out the specific strings that we want to change and then rooting them through to a different place. And that different place is something that the user experience designer can look at, evaluate, discuss with the client and get those strings exactly right for the situation. So we don't have to touch code. So update on the project. This is one, I'll just briefly touch on it. This is one area where it's the student's perspective. Just before the registration wizard, this is how they would launch it. There's a register now button there. It's a fairly straightforward, simple interface. It's a button and basically a list of previous exams or pending requests for exams. But when we get to the parent, it's a bit different. We have a list and on the left, it says manage your family list. So it speaks to the parent in their language. It says, does the family member have a student ID? And it says something which I can't quite read about the student's name, about the child's name, sorry. And for the teacher, it changes the language to manage your student list. Does the student have a student ID? Add new students. So it's just speaking in the right terms for that role. It's not huge, it's not a huge difference, but it's just enough to make it comfortable. We're just shaving those pointy bits off the shoes here. So that's basically it. That's the concept. Those are the keys. Hopefully the doors are open. And what I'd like to see now is if we, using this knowledge, could now start to have new discussions about this concept to see, is it generally valuable? And if so, what can we do in terms of evolving Drupal to allow us as UX designers to have access to those two additional dimensions? So that's my presentation. I think I should do this bit too, that I think you're supposed to do your homework here. You go to that place. If you like it, go to this place and give us your feedback. If you don't like it, you're 45 minutes late for the session and you should have been in. So yeah, I think we still got time for questions. So if anybody would like to do that. When you put the string into a specific file to define separately, how do you handle the search? Speaking from what point of view? Me as a developer or me as a user experience designer? As a user, try to click search on the web. So because the string defined separately, so the search engine need to handle that? Well, because it's basically a resource file that the user experience designer has access to. In a text editor, you could simply look through and find the string that you want or you could search within that. It's just a text file. So I've never actually experienced a problem with that. And from the developer point of view, it also works because when you're looking at the code, you see the semantic key and if you do a search through your directories for definitions for that, I found it relatively easy. I haven't seen a problem with that. Thanks for that. I had a question which is generally, I needed some information. I don't know if this is the right place to ask but it's really quick. I also had a similar problem in which I'm trying to make sure that I don't actually check out or do geo IP to check where the user's coming from. But I want to make sure that the language is suitable for American English users and British English users. And so I was confused how to do this because I was actually thinking, should I use Google translate API and translate everything on a Chrome or how do you actually approach this problem? Well, first of all, this technique I should say comes from a desktop application building. I used to work for commercial desktop vendors and this was the standard practice and there we would actually treat that in the same way as we treat translation, we translate to different languages as well. So it kind of handled both those things at once. One story I've heard in terms of the English versus American, for example, is that Amazon I think had this problem where the word shipping didn't work in the UK. It just didn't make sense because we'd say delivery. And it's always small things like that. But as they add up, it alienates the user and they get confused. So the idea is again, remove those pointy bits and just make it comfortable. So I think this type of approach is required across the board basically if we're serious about delivering that degree of comfort to all our users. So this is great in terms of functionality. I'm just thinking if you have a very content heavy side and I'm talking about something that's content created and edited by users, is there automation behind this? You know, why should, yeah. Yeah, that's actually a different, that's a different problem. And this doesn't address that at all. This is really about user interface strings as opposed to content. Do you know anything on that front that could possibly work with this module? For content? Yeah, yeah, just the automation of translation. No, I'm afraid I don't actually. But hopefully maybe somebody else does. But no, I've only looked at it from the point of view of the structural strings in the interface. But yeah, it's probably generally a problem. And I think it always needs some degree of attention. And search engines are great to help us reduce the amount of time we need to spend on it. But ultimately we have to take responsibility for those things. Thanks for your question. My question is more from the UI designer standpoint in speaking to your users and what you were saying about idioms in the language. You basically use the term role in two different ways, how Drupal defines roles with permissions and then how the UI designer would define the role from the user's perspective. We have a very similar situation to what you've demonstrated here. And we reached a lot of the same conclusions as you did. Identify who you're registering first is it yourself, your child, whoever, and start from there. One thing I'm stumbling over is the use of the term role. Have you been in a situation where you've had to expose the term role? For example, if you're registering your child and they have three different roles to choose from, I've stumbled over the word role. I'm just uncomfortable exposing that word to a user in the context of our application. Have you run into that? My interpretation of the word role is it's kind of like shop talk. It's not something I'd want to expose. Yeah, same thing here. And I haven't found the work around for that word to expose to the user. I think it's an important concept. But I see it as it always translates to something very specific. For example, in our case here, it's register me, register my child, register. There's always some specific expression which is natural to the narrative aspect, the mindset. And so I don't think there's need to actually expose the word in that kind of abstract way. We just have to focus on what is the flow of thought that's probably gonna be happening. And of course that we can measure by talking to actual users. Okay, yeah, so we probably just need to reword like we've got a screen that says, choose the role you want to register for. Player, coach, volunteer, blah, blah, blah. So we just need to look at getting that out of there. Yeah, I think it's not uncommon. As you can probably see the story I've been telling here is that those words, when they are defined as part of the development process, what happens naturally is development terms leak out onto the screen and that's what often confuses users. What I'm suggesting here of course is let's put a buffer in there and let's take control of that language. Great, thank you. Thanks. In your module or in your implementation, do you see, I mean, do you see a, it looks like what we need here is a parallel. So you have roles in Drupal and then you have, for lack of a better term, now narratives. And if you could add narratives like you could add roles and possibly a narrative could, somebody could have two different narratives and have bunches of different roles and now with fieldable entities and all that they can have. We could do that. But are you working toward that or where are you on that? I think, yes, I've been wanting to work towards this for years. I've used the module in other websites before just because it seemed to be the right thing to do. For example, a year ago I had a situation where we did something for science fair projects and we found out at the last minute that the students that were registering their science fairs were actually much younger than we realized. We thought it was high school, it was actually junior school and the teacher gave us a feedback. They won't understand these words because we use slightly technical, slightly complex words. It was no problem to change it. We had the string resource file. We simply changed it. We didn't have to break the code. We didn't have to risk breaking the code. It's just a very useful tool in that sense and I think it helps de-risk all those things. In terms of where it could go, I don't know. This is the first kind of coming out of the closet in the Drupal community, right? So we'll have to see where it goes. If people want it, then hopefully that snowballs and that is registered. We still would then have to deal with the technical things and how to keep developers happy because there's obviously a change for the developer experience and we don't want to break that because most of them are volunteers anyway, right? So we have to be careful on both sides. But for now, the idea is just to put out here and get those discussions going. First, thank you. Very excellent presentation. One of the issues that I think that one of the other questioners was asking that I also have a trouble with is we have a large website for multiple users. How do you get to the point where you can understand which narrative they're coming from? I think it's talking to them, isn't it? It's always starts from that and if we have the time and budget to do that, it's much better, I think, isn't it? Because they always, and that's why that one head has big ears, right? That's where it really starts, isn't it? So they will give clues. You can't take, I don't think, you probably find this as well. I don't think we can take users literally when they ask for things. You really have to sort of step back a bit and see what's the goal, not what was the expression of the goal. And I think all of that is part of the design process and that's where you start to formulate a sense of, okay, generally, are there clusters of user types that we can give a name to and ultimately assign it to a variable like that one we had? So from a user interface perspective, how would you ask the user to self-identify as, for instance, we're at a university or a college, a faculty member or a staff person or a student? I think it really gets down to asking them at a very high level about their goals. What are you trying to do? What gets in your way? And then certainly we'd want to avoid asking them how they use a given application because that's probably a workaround. So couch it in terms of in an ideal world, in that sunny place, what would life be like as you carry out your job or do your entertainment, whatever it is, right? And then listening attentively to that to see what are the patterns that are suggested. Especially if you do, I mean the pattern's coming from multiple people, of course, like you'd see something in common and that's what you can actually build upon, I think. Thank you. Thanks. From a prior session, we were looking at entities and fields and how all that's changing. And one of the thoughts that came in my mind when you were talking about this was fields are fieldable now. So that might be a possible solution for an implementation of something like this. Yeah, I'm not gonna say I know a lot about fields. I haven't had a chance to look at the fields API yet, but I'm very excited about the idea that you can get into that degree of articulation of data. I think that's really a good thing. So I have two questions. The first question is, you said that a person could log in and have multiple roles. How do you deal with something like that? Well, what we did was we used parallel sort of interface mechanism like check boxes as opposed to radio buttons or dropdown selectors and then tabs within a reasonable number. You can afford the real estate to do that. We could fit three additional tabs in that space. I've had other, the thing about roles is that there's always some form of role switching. There's always some point at which the user changes hats. I've designed other interfaces where there was a dropdown system, a dropdown menu where they could look at things from quite different points of view, but it was expressed in terms that would relate to their jobs. So I'm gonna do this now and then the user interface changes somewhat to allow, changes the tool set. So there is a kind of a conscious switch on the part of the user, I think. In this case, we're picking it up on the implicit decision. When they go to a tab that's labeled accordingly, my family or whatever, my students, there's an implicit role selection there and then we keep that knowledge inside the system and then that's what flavors the common wizard that they all share in the appropriate way. So it's kind of like a default role that you... I think you do have to build for defaults as well. But ideally you wouldn't let that leak out too much. Right, right. The second is, is this gonna be a project on Drupal.org? Oh, I meant to mention, if people are interested, we'd certainly be happy to contribute the module and set out doing whatever follow-up tutorials or sort of helping out with that that we can do. So if people are interested in that, let me know after and we'll know. I think it'd be a good contribution. Thanks. Sorry, I'm not tall enough. No, the microphone is too tall. Yeah, so I just had a question. I'm from a university and I'm interested in using this for our faculty and students, but I'm wondering is there, do you see any problem in terms of instruction? So if a faculty member has a different view and they're trying to teach the student how to use the website, they'll have to learn both sites or both language and idioms. So do you have any suggestions on how to overcome that or do we just tell them too bad? You have to learn both. I may be misunderstanding this, but what I'm thinking that has to happen first is you need to have a developer build that custom module. Well, yeah. Okay. I'm assuming that after. Okay. So then the other part is again to have the conversations with the teachers, right? And with the students and to find out what their expressions are, what are their word sets. And then to identify the points, you can do it with user testing. If you already have something to test or it's a mock-up, you can do it that way as well. But find out where all those difficult spots are and identify those as the strings that you want to actually modulate. And then that's what your developer would focus on doing. I don't know if I answered your question though. Thank you. Okay, thanks. Any more questions? Well, thank you so much. I really appreciate you coming and staying through the whole thing. Thanks a lot. Thank you.