 All right. Well, let's get going. Good morning, everyone to Drupal North Day 2 Thanks for waking up early coming out on a Saturday morning a little Drupal Hello My name is Crispin Bailey. I'm the director of design and UX at Kalamuna I'm responsible for design and content strategy practice There I also manage the design and content team and oversee Kalamuna's discovery and design phases for our larger plane projects I'm really excited to be here today Talking about something I really love which is web design But first I want to give you a little context and tell you how I got here I initially started out as a print designer in the early 90s working for my dad But I couldn't stand no fussy and stressful print was so what I really wanted to get into was interaction design And thanks to an NDP sponsored job training program back then we used to have those kind of things I was able to take a multimedia production course and not long after got my first job as a web designer in 1996 so that tells you how old I am back then the notion of a CMS was Much less an open-source CMS was a bit of a foreign concept I used to design in Photoshop and painstakingly build websites Page by page using tables with all these one by one pixel spacer GIFs, you know holding the pages together. It was good times But then sometime around 2005 I learned about this thing called Drupal and for me the clouds opened up and Rainbows appeared and I saw the future. This was version Drupal 4.6 These were exciting times. We made blogs. We made websites anyone could use even our clients But I pulled up together a few Pictures of Drupal 4.6 sites. This was there's a website actually features some of the greatest Drupal websites of the day And they're not exactly works of art, but they were again ground breaking at the time So I could see that there was potential and then in 2007 Drupal 5 came out and it was like a whole new era So I got really excited and I got totally caught up in the Drupal movement It was a small community back then as it is now, but it was even smaller. There weren't many designers doing Drupal But my wife and I who's also a designer we were and we were asked if we would design the t-shirts for Drupal Can't to in 2007 and then again in 2008 and some of you may remember might remember that and those t-shirts I still see some of them around By that point I was an associate director at Sympatico MSN Working with the ad operations team working really hard to put banner ads on Nokia and Samsung smart cell phones This is before the iPhone and smartphones But I still doing web design and building websites on the side with my wife and partner Patricia Rodriguez she's here today and we built all of our sites using Drupal Then for various reasons we decided to leave Toronto and move down to Mexico and you know six months turned into a lot longer And it was the next five years kind of bouncing around Mexico and in Canada Freelancing designing iPhone apps trying to launch a couple startups that eventually failed And we returned to Toronto in 2013 At that point I reconnected with the Drupal community here We did the branding the website for Drupal Camp to 2013 And I also designed the Doug Teal over on that time. That's my connection to Drupal So that ended up getting me a job there for interactive Where I worked for a couple years as a digital producer before I was lured away by Andrew at Calamuna And the chance to work for a Bay Area company So that brings me to Calamuna. We're a digital agency that partners with socially impactful institutions associations agencies and organizations to help solve today's most pressing problems using strategy design and technology And a lot of Drupal to empower them to accomplish their missions We're a distributed team with half the company working remotely I'm still based here in Toronto Our headquarters is in downtown Oakland, California Bay Area a hotbed of West Coast activism education and innovation The kind of work we do is largely working with universities and research institutes Non-profits government agencies utilities and progressive companies in the media and health sectors So large by and large we use Drupal for good So I just wanted to get a quick show of hands Get you kind of moving a little bit this morning. How many people in the room are developers keep it up your hands developers Okay, most of you. All right. How many designers are in the room? Okay, this mattering. Okay, and how many project managers? Okay, good diverse crowd any product owners or clients All right, cool Any content people? Yay. Oh, wow. Some people put their hands up more than once good many hats I'm a designer. I'm not a developer full disclosure I can kind of hack around a little bit, but I do not pretend to be a coder But as a designer, I'm always trying to solve problems and I like to follow process May have heard designers love the process At Calamona, we also enjoyed processes and improving them and being creative and giving back to the community So that's why I'm here talking today I'm going to be speaking about how we fixed one of the biggest problems with the old web design process I Don't know how many of you have been around long enough to remember this but you used to hear this quite often All Drupal sites look the same usually Snickers coming from the flash designers at the time And it was for a good reason I have my theories but one is because The sites were usually designed by the same person who was going to build it so, you know, you know that you were aware of the Drupal limitations the Drupal is He would start with a basic Drupal distribution, right and come in a common base thing Garland And use contribute modules out of the box So what what does this mean, right? It means that essentially the websites are being designed backwards The solution was dictating the design many times So, you know, this is what the typical project workflow would look like and I was I was a part of this So I'm not proud of it, but this is how this way used to do it, right figure out what the client wants You know what they want a website. We got Drupal no problem Install the Drupal distribution, you know, usually the base one That would do about 80% of what you needed it to do and then you'd you know, install a few contribute modules to do the rest like views Start building the site of course without any real content And you spend the next three to four weeks just hacking the theme trying to make it not look like Drupal But it still looks like Drupal because you're not really doing much except Putting a little bit of paint and varnish on it Eventually get the content into the site, right? Hopefully client Keep writing Spend the next two weeks tweaking things because now you've got content in it So you've got to like start adjusting everything to actually make it fit and work and then finally you'll launch the site and Hopefully it doesn't look something like this, but it might Excuse me. Here's your Drupal website enjoy But it doesn't have to be that way There is a more ideal project workflow to designing a beautiful web experience This is my little attempt at a hand-drawn Effort to kind of lay it out nice and simply right on the far left You have the research and design phase where you're actually like full blue sky. What should this do? What should it be? And then you're working with your client collaboratively they give you a thumbs up. Yeah, I love it this. Let's go with it and then you want to prototype it and And this is a big part of my talk today is about this the importance of this prototyping because if you prototype things and you can test things and That's when you can like blow them up and break them and realize what doesn't work and fix it Before you implement it. Okay, so you've done your prototyping. You've done your testing. You know what you're going to do now Just build it build it really efficiently once ideally then Get your content in and you've thought this all through because hopefully the content's been coming along the whole time You've been using some of that in your prototyping and You migrate your site. You went up to the server and you launched with great fanfare. Yay So that's the dream, right Calamona we do things Very similarly we have a more slick diagram to demonstrate to depict it But it's basically the same approach, right? We start with discovery. We're asking a lot of questions We're trying to uncover the reasons why we're even building this thing who we're building it for what are the business objectives? What are the end user goals those sort of things? Then we move into designing and coding Testing right and eventually launching and support because the website has never been So where does prototyping fit in right in that juicy middle part and there should be a lot of it, right? This is the part of the process. I want to focus on today prototyping and testing and the benefits of that so Why prototype? Maybe you haven't heard that this is a great thing to add to your process. So I'm gonna just go over some of the basics First you want to test your designs before you spend time and effort Implementing it's a lot easier to fix things when they're not as precious and when you're not actually Monkeying around with the back end and with the CMS It allows you to find usability issues and fix them at a much lower cost effectively for that reason And finally you get plant feedback and buy-in before things get complicated and and costly to change So the three really good reasons to implement prototyping into your process When does it make sense I would say almost every project But in particular if you're working on a large complex web projects that need to minimize risk because again It could be very expensive to make changes later on It allows you to test your designs before committing to development. So that's like that's really the key You can use static content files To eliminate the reliance in CMS setup, right? So if you if you have a good prototyping framework, you don't need to have a CMS And you don't need to hand code everything there are ways and I'll show you a little bit later how to do that Also allows you to explore design ideas without impacting the CMS site build in fact those two things can be happening at the same time in parallel and It's also really great on big projects with tight timelines Why because your front-end UX and UI work can happen ahead of the implementation? I especially if you're in an agile or a lean UX kind of workflow You can be innovating and designing things and testing them before you the one sprint ahead of the dev team Also, you this will encourage tighter collaboration between your front-end and back-end developers Because you're going to be having those conversations earlier on in the process about how you should be naming things How you should what your namespaces are going to look like And working out and thinking through a little bit more how you want the CMS to be built and effectively designed What about small projects? I mean is this really just for big enterprise-sized projects? No, absolutely not. You might not need a CMS at all. If you're just building a small site You can just go static and build a completely static website This will allow you to build your site or one page or layout at a time Use simple markdown files to edit content. It's not that hard to learn And you can leverage popular HTML or CSSJS frameworks like bootstrapper foundation to get a lot of those common components out of the box Who should prototype? Everyone You can prototype your designs of course, but you can also prototype your content You can prototype your business model again. It's just so much quicker to do it earlier on before you're monkeying around the CMS and you can test and validate your concepts earlier on and with real people and You know validate all those assumptions But back to process and systems designers love systems, too so if you haven't seen any talks already about this whole notion of prototyping and Designing with components in mind There's this principle called atomic design principles brought coined by Brad Frost whereby you have this this kind of old chemistry model where the smallest elements of a component are like the atoms and You can build up these atoms to form your molecules like in this case a search input tool or component and then those Molecules can be combined to form greater organisms like the header of your website So this is this is the way a lot of modern design teams are going because it's just a It was a bit radical as an idea But when you're getting into again these these component-based architectures where you're having lots of little bits that you want to use Across not necessarily one website perhaps multiple websites or or products It just makes a lot of sense to think these stuff through this way And then you use these components right to build your web page you combine your components with your layouts and your content and Magic you have a web page so This is the idea there have been a number of people who have been innovating on these kind of the concepts over the last few years But where we were were chipped up was that a lot of the time You had to you would basically build your prototype then in you'd you'd design and code up all your components But then you'd have to actually redo a lot of this stuff To make it work in triple and it seemed wasteful because you weren't able to reuse the code That was powering your prototype and your style guides in your Drupal theme So we sought to fix that And we came up with this this was the dream where we would have the system to simplify and streamline the process of going from Their design files to work in code. So as when we're designing and we're not even you know Not into code at all yet. We're doing it We're you know coming up with things like style tiles and you know a few mock-ups or comps And the idea would be to you know Take those elements and build them into a style guide in code HTML and CSS You can test and look at in the browser and then that code That's in this that's powering a style guide is also powering combining with your layers To form your Drupal theme templates So this was the idea was to have reusable code The you know our twig templates and our CSS and our SAS file all being used to power Not just the style guide and our prototypes, but also our Drupal sites So to do that We came up with a system we call calisthenic and it's really a framework for prototyping and Delivering documentation in the form of a living style guide So what is calisthenic as I mentioned it's a prototyping framework for websites and web apps It's a static site generator So you can like I said design entire pages you can build a whole website using it page at a time It's a living style guide generator with reusable code a Bridge builder between atomic design components and the Drupal theme layer therefore and It's a solution for modern web design and dev teams We're practicing the UX because once you start using this as a part of your methodology You realize that there's going to be a lot more collaboration between your front end and your back end teams and your design teams So who is calisthenic for well as I mentioned earlier on you know, it's for everyone But the people who are looking to develop html prototypes and style guides can use it right into the box so to speak It's great for for agencies who are collaborating with other shops So you might be a design more of a design focused agency or you might be a more of a dev shop And this can be a way for two different agencies to work together more effectively It's for anyone who wants to share the style guide components CSS and JS with Drupal steam layer as I mentioned before For anyone who wants to decouple the front-end design system from the content and there may be a number of reasons why you would do this We've been talking I've been talking mostly about you know the economies of inefficiencies that you gain from using this for Drupal steam layer But you can also use it for other legacy backend systems You may have old databases that you need to also support to pull in legacy data And you can have it you can reuse the same components and layouts To have a seamless experience across multiple back ends, but it still feels like the same website And it allows you to build a large number of custom components in a short amount of time Again, because you're thinking through things a little bit more efficiently more differently You're breaking things down into their elements and then building them up in a very logical efficient way So who is it for specifically? Well, it's really gets the front-end developers excited at least that's what I've noticed and at our shop Code savvy designers though can definitely get in there get their hands dirty if you are not afraid of code You can embrace this Back-end devs who are working with front-end designer and developer might want to encourage this as part of the workflow because it will again facilitate that collaboration in-house teams, so maybe your product team You can adopt this it makes a lot of sense again As I mentioned earlier if you're if you've got more than one product or more than one website And you're looking to reuse and have a central repository for your your components And of course for agencies, it's great and that's why we came up with it. Okay, so how does it help? Here's the compelling kind of sales pitch prototyping the browser is Just miles ahead of prototyping with static files flat files that aren't responsive We live in a responsive age people are using Smartphones tablets laptops desktops you name it so you want to get into the browser as quickly as possible and validate How your designs are going to look and behave? That allows you to design and test pages and components before site building So I keep hammering this home because doing this before implementation starts and staying one step ahead of the implementation development is really efficient and Having a living style guide provides you with both documentation and reusable code that can be shared with people seeing files and static site pages And finally why calisthenics specials because it actually supports Drupal 7 as well as Drupal 8 Thanks to tweak support that we built We use this module called twitching which allows us to use tweak templates for Drupal 7 sites And this will make migrating Drupal 8 that much easier later on Right, so time for a little case study. I've been talking a lot about this. Let's see it in action First of all, I'm going to be talking about one of our project. We did for client They're a genetic testing lab based in La Jolla, California They needed a single website that spoke to both doctors and patients. So we had an interesting challenge there They rebranded the entire company in the product line during the project Which normally would make designers and developers pull their hair out, but we actually were able to take it in stride The content was mostly ready when the project started They had a few pages And they had planned to unveil the website at the company's annual sales meeting Which was like less than three months away. So it was a very tight timeline Now this also to give a little bit of context. This was a Drupal 7 project. This was we started it About a year and a half ago. So it was before Drupal 8 was really Mature and ready But we were thinking about Drupal 8 already and where we wanted to go with this So it was the perfect case study for this and use case for this for this framework All right, so here's kind of what it looks like on desktop and Smartphones now But we're going to jump out and see this in real life. Let's see if I can get this thing to work Yes, I do. Oh jeez. I can't see what I'm doing. Where's my mouse? Hold on Is it over there? Up, up, down, up, down. I cannot see where it is That's the last tab. I want the second tab. Okay, go to the left a bit. Left Down, down, right, down a bit. Down a bit. Up a bit. There, there No, that's not going. Oh wait, this way, this way, this way, this way Yeah, all right. Now I want the green dot. Oh jeez This is ridiculous. Where is it? There it is There it is All right. Okay, this is, okay. Thank you everybody for your patience. Okay, so this is actually an Envision prototype. So I wanted to show you this first because before we got into code we do like to prototype even earlier in the process using Static mock-ups. So we would normally start with a like an interactive wireframe prototype But the client wants to see cops. They want to see what it's going to look like. So we actually mock up a few pages, get them in Envision, and allow people to click around. Here's what's going to get crazy again. How am I going to do this? Well, do you think you're going to go back and then the number of the tab you want to go to? Well, I'll have to click around on this. You know what I'm going to do? Hold on. I'm going to mirror my displays. Mirror displays. Now where'd it go? Okay. I'm mirroring displays and I lost my thing completely. Okay, bring it back. Hey, all right. Now I see what you see. Okay. So this is an Envision prototype. It's a flat file. It looks like a cop, but it's clickable. So this is just I just want to give you a quick little tour. I'll show you how, you know, we came up with the a few key pages and everything on this site was kind of thought through with this component design model. Right. So these are not interactive elements, but some things are. So let's click around. Here's a product page has various tabs, you know, we have carousel, all these little different elements, right? So that was fine. We got sign off and approval from the client. Yes, we love it. Let's go. Let's go. So like, okay, let's do this. Let's think this through in terms of breaking it down into individual components in our style guide and in, but let's prototype the pages as well. So this page is the actual, this is a calisthenic prototype page. This is also, I should note that it doesn't look like the previous one because the site has evolved since. Where you're, you're, where you're on. So you can see they've added some lovely video effects. This is all interactive, right? So these are the actual components. We've got a nice little rising parallax effect on the, on the flowers there and various parts of site. Now, this is just one page. I'm not going to click all the way through, but I do want to show you how the elements here are also in our style guide. So open this up. So from a brand perspective, you know, we're making sure we got all the brand colors that are used throughout the site. And we've got our UI components. So we have things like breadcrumbs, buttons, and these are, these are actually interactive. And one of the key things for this, this style guide is that we actually, you can get the markup. So when I was mentioning it, you're getting documentation as well. You can click this little link here and you can see the markup for that component. Right. And there's your little, little tweak variables in here. And we have some more fancy ones. Let's see. Let's close this up. Charts. So we can even do things like interactive charts. So, and when I say interactive, I wanted to show this bit. Let's get out of the green mode here for a second. Oh, that's going to show it. This is a responsive graph. Right. So every component that we have here, including our tables, we have our responsive tables is documented in the style guide full screen. And then here's the actual site. Now, all of these components, and you can see, I wanted to actually, I noticed something last night when it was getting ready for the, for this presentation, see how this, this point of differentiation here is an image with the round circle. It's a beautiful circle, full circle. But in our prototype page calisthenic, I noticed that it was being cut off. And just to prove the point that we're sharing the same code between our living style guide and our prototype pages, when I was looking, when I confirmed here, I went to the, I think it's under the content. And no, it's not the content one. Or is it, it might be UI? Where is that circle? It's not here. One of these tabs. There it is. So I tried fussing around with those a little bit to try and fix it for today's demo, and I thought, you know what, I'm going to go with this. This is actually proving that there's a connection between the style guide and the prototype page, but it's reusing the same code. Fortunately, this hasn't made it up to production yet. It's not on the live site. So there's another reason why this is a compelling element to add to your workflow, because you can spot these issues before they go live. Of course we have dev staging and live environments, so we can test these things beforehand. But there's just another example. Okay, back to the deck. I'm not even going to try to do the presenter mode yet for this thing. Stick with screen mirror. Okay, so that was progenity.com. Drupal 7 site. We did user testing. We did the H&L prototyping. We saw that. We saw the living style guide. And then site building. So the interesting thing about this website, because we were using components to define every single element on the page, we only used one content type to build the entire site. It was called a page. And every page was basically built up using these different components. So you can see on this, we've got down the left hand side a bunch of tabs. So in this panel you can define the hero part of the site. Define the accent color, load an accent image, upload a logo for the product if necessary. If you don't fill out any of those things, it doesn't display them. Simple. The next tab is content. And again, for our clients they were like, wow, this is like blowing our minds. This is so much easier than any other Drupal website I've ever used before. I can build the page just the way I want it. So they would just add components, add a list, add a bar graph, add a teaser, whatever they needed to add to a page to build it up. And it was all contextually aware of what was being added to the page in order to display things the way the client expected them to turn out. So here's an example of a basic component. We could have a button or a footnote or a block of text or a four up kind of feature toad thing. So the client was delighted. They had a very simple editing and website management experience. We were really delighted because we could manage the whole front end and all the code and all the look and feel without getting into monkeying around with the CMS and having to come up with new content types and all sorts of things. And then even for their product tabs. So that whole site that I showed you which had all these different pages is actually just one content type. Okay, so wrapped up for the tech folks, techie folks in the audience. We do have some exciting features that may appeal to you with Calistatic. What does it give you? First of all, it's easy to install. Node is the only language dependency. It's a living customizable style guide and component library. We fancied it up for this client and make it look pretty and to match their brand. And you can do the same for your clients. They love it. It's got the CI build chain locally or remotely via Circle and Travis. It's styling framework agnostic. So we've done now projects with Bootstrap and Foundation as a kind of underlying component architecture. But you can roll your own as well. And as I mentioned, full Drupal integration with the Calistatic.module. And this gives you a few useful settings right out of the box. And you get production ready code. As I mentioned, you can use this for standalone sites. The Kalimuna website outside of the blog is built in Calistatic. We only have like less than a dozen pages. We don't need all the CMS for that. And we've actually spent a lot of time writing up documentation. So if you go to the GitHub project, you'll find lots of material, lots of examples. Flexibility is included. So it favors convention over configuration. There's little to no configuration required. You can use Twig. As I mentioned earlier, we were really excited to get Twig into it. But you can use any other templating language using JS Transformers. So it's for SaaS, Markdown, etc. You can do easy content modeling. With YAML and or JSON. It can integrate with external JSON content sources. So this is the other thing as I was mentioning earlier. You don't have to use it with Drupal. You can have Markdown files. But you could also pull in a feed from any other content source that can spit at JSON. So this might be prismic.io. Gather content. If you're using that to stage your content with your client before the CMS has been built and is ready. Or you can use Drupal like a headless version. It doesn't have to be used for the Drupal theme layer. You can actually have a headless site. So a few additional features. Easy JS concatenation and compression. Built-in web server. This is cool because it's got browser sync built-in. It supports live reload for simultaneous cross-device testing. And I'll show you in a minute how that works. Cash busting. I don't even know what that means. But Rob Lodge put this in my slide. So some of you might. And it supports kind of collections for content loops. Again, just to be able to quickly generate prototypes. Render tables and stuff like that. Dependency management is built-in as well. So it'll pull in node library files into the project without having to reference them. And to give you a taste of what it's like. So we've got a little demo. And I'm not going to do a live demo. I'm going to play a video. And I really hope the audio works. Otherwise I'm going to have to talk along with this. No. Can you guys hear this? This is a simple project. That's not the audio. It sounds great though. Should we try again? Have sound, please. Should have warned you, shouldn't I? Is there another jack I should plug in? One more time. I'll be showing you the different kind of where the files are that you would want to manipulate in particular in the source directory. So he's going to open that up. This is a boilerplate project. So just a really simple example of Callistatic. It's a Hello World page. Just got a couple pages. A little bit of content on it just to prove the point. You can see it's got a title. It's got some elements. Now he's going to go into source directory. And show you there's an index markdown file and resources markdown file. And a directory of layouts. So he's going to open the index markdown file. And you can see it's got a few elements, which we saw in the page a moment ago. And we're going to edit this file. All right. So you can see where it's defining the layout. HTML.tweg. It's got a title, Hello World, and a description. And then below that, that's like the metadata. Then below that, there's a little bit of actual markdown for the page itself. So Rob's just going to add a little awesome sauce to this file. He's going to save it. And then he's going to, you can just see that other tab just flashed. And there it says awesome sauce in the page now. Yeehaw. So that was just a really quick update. And then he's going to go back. And while he's actually talking in the background, he's going to make another edit. Actually just pointing out, here's the layout.html.tweg file. That's building that page. It's a layout file, just a single file here. So there you can see it's basically, it looks like HTML, but it's got some twig references right in it. So there's the title that it was pulling in. Yeah, title, easy edits. There's the title reference in the markdown file. And as I was saying earlier, it can be a markdown file, but it can also pull in JSON. Again, you just really have to cross-reference the right file type, put in your CSS, and away you go. All right, that was the end of my spectacular multimedia demo. Let's get into this. All right, so as I mentioned, we do have this boilerplate project up on GitHub. I'll be putting these slides up on the Drupal North website after the presentation today, so you can download it and play with it yourself. Another point to point out that CalStatic is free as in speech, not as in beer. For those of you who don't know what that means, beer is free if I give it to you, but you can't really do anything except drink it. You can't modify it. Which I still like to make a sample would be like a flash plugin. But CalStatic is free as in open source. So we've built it using open source libraries and packages, and in turn have made the project open source. So please feel free to go and get up, look it up, find it, download it, play with it, contribute back to it. We'd love to hear how you're using it and how you think it can be better. You'll see on the right there are a number of other projects that we've also open sourced that make it even more powerful and extend it. So in there there's like the CalStatic.module, so you'll need this for Drupal. We have some bootstrap components, the twig filters, things like that. And the boilerplate. And I would be remiss if I didn't mention these fine people who are actually the contributors and the architects behind CalStatic. Rob Loach is our director of technology. Director of senior architect, our senior designer, Josh Walker, who's no longer with us but still contributing to the project and our fearless leader, Andrew Miles. And that's it, that's CalStatic. Once I wanted to thank you all so much for coming up this morning and if you have any questions I'll try to answer them. If they're too technical I'll field them to either Andrew who's in the audience now or take your questions and get back to you. Yeah, questions at the back? Yeah, if anyone asks another question I'll moment it. All right, other questions? Architecture. How is the back end experience for the admittance? So the question was if the front end is being designed and developed ahead of the information architecture how is the back end for the admittance, how's that experience being handled? So when I was referring earlier to the ability for the front end team to be working ahead of the back end team I've already gone through an exercise of defining information architecture so maybe I didn't make that clear enough that the information architecture which includes, you know, your content types, your taxonomy, your site map even your layouts, right, like your wireframes all inform that information architecture so we've already got a very good understanding of what we need to build in the CMS but the difference is the coding of the front end can happen ahead of the implementation on the back end so that those static prototypes that are just really a look and feel with some dummy content in them or even real content can still be used to validate that content model and that information architecture before we commit to building it in Drupal or in the CMS so that's the principle. So it's not that it's actually being considered more thoroughly because we're not going to be building out the back end, the CMS, and making assumptions about how it should be organized before validating that that's exactly the design we want to build. Does that answer your question? You've got the important information on things you're doing. I guess I'm just thinking, if you haven't actually prototyped the back end as well which you might, but it's not clearly from what you're saying then there's no, the admittance haven't tested the back end. So again, the question is like what about the back end? Do you prototype the back end to ensure that that experience will be good for the admins or the content editors or so on and so forth? Yeah, that's a really, really, really good point. I'm glad you brought it up because we have had some challenges with that where it's very easy I think for us to get as cutting edge innovative developers to get excited about a new paradigm or a new way of building the back end and then we give it to the client and say, okay, here's your interface and we did have one project where that was a disaster and we had to re-architect the back end experience to make it easier for them to build their pages. So it is an important consideration, so thank you for bringing it up. It's not something that Callistatic really has anything to do with but it is something that the back end team should be thinking about because the user experience is not just for the end user on the front end. It is also for the people managing the content. Got a question, Sir? Yeah, it's kind of related. How well does Callistatic handle assistive tech? I'm coming in with a screen reader. Does it navigate well through it or not? So the question was how well does Callistatic handle assistive technology like screen readers? And when you say Callistatic, do you mean the code that gets spit out and is rendering of your page or do you mean like the project files and what not? If someone with low vision or cognitive impairment uses a screen reader and wants to do some prototyping or wants to look at the prototype that's being built and then go and code from it, how easily can you navigate through it? So you're not necessarily trying to do creative work. You're trying to look at content that other people have manipulated. Okay, so again to clarify that we're asking, he's asking about how good is Callistatic as a prototyping and style guiding tool for people using assistive technology. Fantastic question and that is something that we have been made even more cognizant of as an important element to work on on our product because we just started working with the American Foundation for the Blind. We're doing the design in the front end and they're going to be implementing the code in the back end using Drupal. So I can't say that right now it's fantastic but by the end of this project it will be because we're going to be working with blind developers and they're going to be taking the Callistatic code to build their front end. I asked him, I work for CNIB here in Toronto. So similar problem. Now what kind of time scale are you talking about with AFB? When do you think the tools are going to be able to do that? Well, we're hoping to put something in their hands by the end of September. So in the next month and a half or so. And again, everything we do will be updating the repo so it's just going to get better and better. Thanks for asking. Any other questions? Alright, well thank you very much everyone. Like many other agencies here we are hiring looking in particular for Drupal developers and front end developers. So if this is the kind of stuff that you're excited about please either check out our website, look for the jobs page or come up and chat with me at any point during the conference. So enjoy the rest of your day. Thank you very much.