 Okay. So hello. We're today talking about doing conference websites with Drupal Cod. It is a distribution of Drupal. So all the fun modules within its own distribution. And specifically, we're going to go over Linux Fest Northwest, which is a regional conference. We'll talk about that in a moment. So first of all, I'm Jacob Perry. I'm the Drupal 7 Cod maintainer and an organizer for Linux Fest. I'm Emily Nouveau. I'm also an organizer for Linux Fest, and the work I've done around Cod is mainly in theming and scheduling. I'm Jason Yee. I wrote the ticket module, which Cod leverages to do all of the ticketing and registration, so I also built the integration from ticket to Cod. And you'll notice that picture makes sense at the end, or actually in the next slide. So what is Linux Fest Northwest? So Linux Fest Northwest is basically an annual conference that has a little less than people here. We have about 1,500 people that come. It's a free conference, so anyone can come and attend. We have about 40 sponsors and about 80 sessions that are over two days and about 10 rooms. So it's a somewhat complex schedule, and it's all volunteer ran. We have a budget that's extremely small, which is awesome, and it's all volunteer ran by Nali Us, but we have about 100 students from Bellingham Technical College who do it as part of their IT degree, which is pretty awesome. So with that, we have a whole bunch of needs. We have registration that happens online before the Fest, but we also need to be able to take that information and do it on site. We have these pre-scheduled curated sessions, very similar to DrupalCon. We have Berzo Feather sessions, where you talk about things on an ad hoc basis. We have a schedule. We don't print anything out besides our badges. We have these e-signage that are like 50-inch screens, and we need to support that and the desktop as well as mobile. And then we have our sponsors that we'll need to sign up and somehow display that data in an efficient way so that we don't have to duplicate work. So then some more technology side. We have a whole bunch of open-source contributors who want to write third-party apps, so mobile apps to do their own fun things with our data. We have session workflows that we need to work on, so we need to figure out if sessions should be published or unpublished. A few years ago, we used to just let people submit things, and now we don't do that. We have personalized schedules, so you can actually add things to your schedule, very similar to DrupalCon. And then we have part of that workflow. We can have a two-month call for papers, and we can assign multiple speakers. And it's not very much like DrupalCon because Cod also runs DrupalCon. So why Cod? Back in 2009, we were using this Java framework called DXP. Probably no one's heard of it because it only has one contributor to it who was in our organizing committee. It was open-source, but the problem was we didn't have community, it wasn't community-driven. And so we needed to find something that had the support of the community and we could really move forward with all the things we needed. So that's what Cod's about, and we'll start with the ticket module and Jason. Yeah, so as Jacob said, community-driven is pretty big with Cod, and so I actually haven't been involved with Linux Fest Northwest, but Jacob came to me and we were talking about things, and so I decided to jump in on this. When we were talking about ticketing, we tried to figure out what the best user experience would be, and we settled upon Eventbrite, which if you're familiar with that service, it's an online service that provides ticketing and registration for a variety of events as software as a service. So we took a look at how their workflow happened and the checkout process, and we decided that we would replicate that. So the key points that it provides are the ability to have multiple tickets or ticket types per event. So in that way you can have a paid ticket and a premium ticket and a free ticket and as many as you can imagine. And each of those ticket types should support different prices, different availabilities based on time or based on quantity, and collect different information when somebody checks out and purchases those tickets. So with the checkout, we did integration into Drupal Commerce, and for all of the reporting we use views, so it's really easy to customize those. This screen, which is probably fairly small to you, shows what it looks like if you edit an event. You're allowed to create a ticket type. It's simply a field, just like any other field in Drupal or a collection of fields. So the subfields that it provides are the name of the ticket that's displayed to the end user and a description. For the back end, it provides a date interface so you can say when a ticket is available and when it becomes unavailable. It also provides fields for you to set the quantity, so the actual total stock that's available to your users, and to limit them to order certain numbers of tickets, both a minimum and a maximum. And then it provides integration to commerce, as I mentioned. When you create a product in commerce, you're allowed to associate that to the ticket type here. So when a user purchases a ticket, it will add that product to their cart, and then they can go check out. After you create the event and you have some ticket types, the top screenshot here shows what it looks like to go into the ticket tab of your event. So here it's listing two ticket types. It shows the number of registrations per ticket type, and it shows whether they are currently available. So if you had a ticket type that was time-based and available for next week, let's say, that would display as not available and that would be updated. The links following it include the ability to view registrations and then to manage the fields. So all of the ticket types are entities. So just like any other entity in Drupal, you can see on the lower screenshot that you can adjust the fields. So in this way, you can customize each individual ticket type to collect the information that you want. This is what it looks like to view the tickets that are for a ticket type. So here, the example we see that Jacob has registered twice, both of his registrations for tickets are pending. We can use the operations links to view those registrations or to edit them or to cancel them. And then since we have integration with Drupal Commerce in Cod, there's a link to the order, so it takes you to Drupal Commerce's order UI. Once you have modified the fields for a ticket type, you can see with that last screen it only provided you basic information. You may want to modify that. So one of the nice things that we've done is with views, we've got a ticket registration display handler. So the first screenshot shows that just like you would add a page or a block from a view, you can select a ticket registration. When you do that, the views interface will then ask you which ticket type you would like. So you could create a custom view that would show some amount of information and say that when you click the administrative page for a specific ticket type, it would use that view that you just created. On the front end, like I said, we pattern things after Eventbrite and that makes the flow really simple for your end user. So from the event page, they would simply select the quantity of tickets and the type of tickets that they want to purchase. That takes them to the registration page here, which gives them the options to fill out the information for each of those ticket types. And it also gives them up at the top the fields to set the person information for the person who's registering. So in this way, you could have someone register for other users and it would be able to associate not only the tickets for the person who's supposed to be using it and actually attending your event, but the person who registered for them could go back in and make modifications. So obviously with integration into commerce and this flow, it's fairly complex in the code. So we had a few issues with the integration, mostly with if someone had bought a ticket and then went through the checkout process and decided to stop halfway, those tickets at one point were being lost and they would go missing. Those issues have been fixed, but we do have some ways to go on the user interface, particularly around user feedback. So we'd love your help if you do use Cod to give that a try and provide feedback on ways that that can be improved. Session submission is the other big area where we have users submitting information and interacting with the site. So with Sessions and Linux Fest Northwest, we wanted to be able to allow users who had registered on the site and had a user account, but who had not yet purchased tickets. We wanted to allow those people to submit sessions. If you're all familiar with Drupal, that's really easy. That's just stock Drupal permissioning, which is great. So Sessions are just standard nodes, so we could take advantage of that. Along with being standard nodes, there's the standard fields for things like uploading your slides or having images. We also set it up so that you could have multiple speakers. So a panel like we have today with three speakers up here is easily managed with Cod. And then we have a flag to mark speaker confirmation. So when someone submits a session, you can follow up and flag that they actually have confirmed that they are able to present. The workflow for Sessions is fairly standard with Drupal. There are two feedback mechanisms that are built into Cod. The first is FiveStar. So with Linux Fest Northwest, the programming and the session committee decides which sessions are actually going to be selected. So that's more of an administrative backend. So FiveStar is in place for that so that people who are within the conference planning committee can rate sessions and determine which ones they'd like to select. On the front end, we have Flag. And Flag simply is there for people to say whether they like a session or don't like a session. And this is there to provide feedback for resource planning. So you could see how many of your potential attendees are interested in a particular session. And you can budget your rooms if you have a large room versus a small room. You can plan accordingly. So I'm going to talk about scheduling. We obviously use the schedule everywhere from our e-signage to our print schedule to allowing people to sign up for buffs. So Linux Fest had some scheduling needs that a lot of conference software didn't quite meet. Like the ability to schedule a session across multiple rooms and multiple times. So this is really helpful if you have, say, one session that needs to go from one time slot into the next one. So you might have other sessions running alongside and you want this one to continue for an extra time. This is also helpful if you have, say, a session on Saturday that's really popular and now you'd like to give people the opportunity to attend it on Sunday without, say, creating a new session that's just a copy of what you've got. We also needed the ability to constrain when and where certain schedule items might occur. So the ability to, say, a buff will occur in this room at this time and give people the option to create buffs through that sort of schedule. We wanted to provide an intuitive UI for admins to create a schedule. So a lot of our admins aren't necessarily technical people and we wanted this to be really intuitive for them to use. Then we wanted to display the schedule in multiple formats, like the Usignage and the website display. To do this, we created this concept of rooms and times and time slash which tie the two together. So rooms are a pretty basic entity, mostly they consist of just a title and you can add things like capacity for rooms, you know, how many people attend help organizers and how many people can fit into there. And then times are just a start time and an end time. The really awesome thing about this grid is that these time slots designate when the rooms and times go together. So you no longer have these loosely coupled concepts. So it allows you to say these buffs can appear in these rooms at these times. But then later in the day, you might have a session occurring in that room, but you didn't need that room for sessions. So you don't have to say mark a room as being just a buff room, for example. So after you've built out your whole grid, then you have the schedule display. It was really important for us to be able to have this responsive schedule so users can maybe look on their desktop and set up their schedule and then they come in and they're walking through the Fest and they have the schedule available where they can just see it on their phone and see what they're going to next in a really clear, concise way. So we had some scheduling issues. There were different permissions and access problems, like not allowing the session organizers to have a certain role to be able to see the ability to mark a session as accepted as opposed to just the original unprocessed state. Those are all fixed. Sort of a minor bug. One of the things that we'd like to fix is the user interface for this grid. So one of the things that we have a patch in the queue for is... So you should see the video playing of a drag and drop schedule or where people can just take an unprocessed session and just drag it into a certain time. And this should make it really easy for admins to actually create their schedule without needing to go into sessions and identify what time slot things occur in. So that's in the queue. So if people would like to come and sprint on that and we'd like to get in a cod soon. Then, of course, we have birds of a feather. So with that grid, that's where people can set up this template, which says when buffs can occur. And then in this image, you'll see this generates a view that shows a time slot and a room. And the registered attendees can just click create a buff and it works just like sessions. So when they submit a time, they might add some slides and users can add that to their schedule through the same flag and it will appear in the same row with sessions. So just like most conferences, LinuxFest has sponsors. And our needs for sponsors were that sponsors can apply and when they submit their application form online, it fires an email off to organizers. An organizer will email them back and be able to walk them through this whole process for maybe getting their description in in a way that will work for them. Might talk to them about other sponsorship levels that they might be interested in. So our sponsorship levels are taxonomy terms. This allows us to have different sponsor types from event to event. So you might have a platinum, gold and bronze. And then in another event, another system, you might have their completely on separate terms. And then we use Drupal Commerce to allow the sponsors to buy these sponsorships after they've been walked through this application process and then at the end they pay for these. Once the application has been submitted, all of that information is used everywhere throughout the site. So you might have a block that displays the sponsors and a gold sponsor in one block, different sponsors in another block. And then that description will appear on the sponsors page as well. Cool. So I'm going to talk a little bit about on-site check-in. So with 1500 people, it is extremely expensive to print out badges and merge sort your badges. As you can see here, Lisa Lange from FreeBSD Project, that whole part is a label that we stick on the badge. And so what we do with Cod is allow for fast check-in where we are searching for someone's name and then hit the check-in button and then print it out. This allows us to get someone through check-in in about 15 to 25 seconds if they're already registered. And then if you aren't registered, you can go through the same process through the ticket module and then it gets to the on-site check-in, which is a little longer, but it's still faster than having to reprint badges and whatnot. This provides all of our admins with a view of all the users, and then it captures the time when they were checking in. So we can get metrics on when people checked in to say, okay, next year maybe we should have a few more people at this time and we can have less staff at another time. And then we do PDF printing right from there. And you can probably guess their Linux desktops on a Zebra 2844 printer, so the industrial-style label printers. I mentioned a little bit earlier we talked about web services, so specifically there is an Android application that a volunteer was wanting to make. So we've been working on making JSON feeds as a part of all of the views that are in Cod. Here are a few of them, so you have your schedule, sessions, etc. The other cool parts with the RESTful process is having this barcode scanner, which will allow us to register people on our phones and do it quickly. We had an after-party where we were scanning badges in because Washington State has some weird laws about things. And then what we did with that this year, we're thinking about doing barcode scanning instead of searching for people's names. So if you have your phone and you've already registered, we just scan your phone and it'll print it out. So we're figuring out ways to make it even faster to get people registered. So some more general timelines a lot of people ask when Cod's going to be fully released. The betas out now and beta 4 is what we're aiming for probably at the end of this week. We want to address there's a bunch of critical issues in the queue that people have given feedback on that are worthy to get in before the next beta. We want to work on improving the administrative user interface for some of those who may have used... How many people have used Alpha Cod before? Okay, so you probably know what that's like. Sort of night and day from what it used to be. That's because we spent about 250 hours between eight people at DrupalCon Austin and got it almost totally revamped and it's pretty awesome now. Working on completing this drag and drop scheduling system. It's probably the biggest request we've seen all the way since Cod 6 and I'm excited to get it up. And then do a full permissions and security review. There are a lot of features. There are a lot of roles and we want to make sure that's all really well vetted before we do a full release because that would mean we'd need a security release even for small things. So we're aiming for the beginning of next year to do a full 1.0 and we're working on moving DrupalCon sites in line with Cod. They're on a certain branch that we're using right now. All this couldn't be done without the help of a lot of volunteers. Cod is a distribution that's not really supported. We don't have paid people do it. We do have help from Acquia and MongoDB and Stanford were organizations that sponsored some time to help work on the project. But the vast majority of time is actually all volunteer based. And here are some of them. And actually yesterday we had another five people show up at the sprint and are at the community summit and we had two issues fixed there. So thanks for those for coming out yesterday. That was pretty awesome. So talking about that there's ways to contribute. We will have a box tomorrow that's a little more in depth of 1045 and G110. So if you have questions or concerns problems you've been having we can talk about them there. We'll have a sprint going on pretty much all week but officially on Friday come out and see what's happening. We can help you get installed and hopefully we can fix some of those issues in the issue queue. You can also contribute at project slash Cod support on Drupal.org. There's also the Cod module. That is the install profile but the Cod support project is the meat and potatoes basically of all the features that you see in Cod. And not to leave LinuxFest out. A little spiel for LinuxFest. It's happening April 25, 2015. It's about 70 kilometers south of Vancouver, BC about 100 kilometers north of Seattle, Washington. And we have people from all over the world. It's a great place to take vacation the end of April. It's sunny. That's 60% of the time last 15 years. So it's been pretty good. November, just basically next month, we'll do the call for papers and of course sponsorships and then registration starting early next year. So with that, take some questions and yeah. Any questions? Okay, go for it. And yeah, if we can get on the microphone, cool. Hello. So my name is Roman. I'm from Lamberg and we developed an application for Amsterdam. Both for Android and iOS. And the problem is like Amsterdam Cod installation actually has only one feed. And that was there just like last Friday, I suppose. You're talking about the DrupalCon feed, right? So do you have some plans to have more web services there for like not only for session, for example, for speakers and other information that is publicly available anywhere. And the other thing, for example, I think it would be great to be able to connect your code account with mobile app and see your own schedule on the mobile site as well. I think we can help you with that. Yeah, but just want to know if you have these plans in your pipeline or not. So yeah, so real briefly, a while back, one of the issues with distributions in general with Drupal is that when you go off and make an implementation of a distribution, it's very easy to go off on your own side. So the DrupalCon sites right now use their own version of Cod, split off from a very early version of Cod 7. So a lot of the features that are in here now are not in there. And actually Emily and I just joined the Drupal Association and one of the key things about that is actually getting Cod and the Drupal Association and DrupalCons back in alignment. And so when it's back in alignment, you'll see those features that are in the base distribution come up to all the DrupalCons. So that should hopefully help on that spot. But I'd love to, I'm trying to think speakers. I don't think we provide a feed for yet. So it'd be awesome to get more of those feeds in there. So yeah, hopefully that helps. First of all, thank you. It's a really, really cool distribution. And we also used it in 2014 with the Drupal Jam. And there we noticed one thing that if sponsors sign up, they have to, for Dutch legality, they have to really sign and then upload a PDF. So it had to hack some fields in the signup process. So that could be a giveaway for future development. And also with OHM in mind, they had a great Badger-Badger system where you got a black hat and everybody was a volunteer. And I think it would be a great opportunity to include organizing all the volunteers in the COD process. And the question about that is, is this on the future plans? So specifically about, sorry, your question about volunteers and how they're being shown on the site. Is that what you're talking about? No, not really shown on the site. More on a managerial scale that you have a bunch of people who sign up and another bunch of people who not necessarily have to be the same who show up. So in order to plan and chase your volunteers and keep the community manager's job easy, it would be nice just to... Right. So that actually is something where we have internal discussion about Atlantic SESS because people show up because it's a free event and we don't have caps. That is something we're looking at this year. Right now we sort of require everyone to register, but you don't have to register at 9 a.m. You can register whenever you want. It would be cool to be able to facilitate or make that process faster. And so one of the things we did the first few years, we had a very long registration form and this year it's like first name, last name, boom. That's it. So if you register on the site, you can get more data if you want. But if you're there, when you times 20 seconds by 600 people, it goes long. So hopefully that helps. I would love to figure out better ways to make it easier for people on site because that is certainly a thing we deal with. So did that answer the question about volunteer? Yeah. Thank you. Yeah. Hi. I'm just wondering if it is possible how hard it would be to change the acceptance process to code something like a multi-level approach. Would it be easy, do you think? What do you mean by multi-level approach? I mean, there's some master referees about session acceptance and they just give the papers or the sessions to minor referees and they really evaluate them and then it gets back to the quality assurance stuff like this. That I think would be, that's one of the nice things with cod since we used a lot of Drupal standards. Session submissions are simply nodes. So that would be really easy for any conference to implement using the workflow or the workbench moderation module. You use workbench. So cod doesn't use workbench out of the box, but because we do have standard nodes for session submissions, it's easy for anyone to customize as they see fit. So workbench moderation would easily handle that. But we don't have any plans at this point to edit workbench moderation into cod because it's a solution that doesn't apply to all conferences. Okay. And one other question. A session consists of only one paper or something or is there a possibility that the session consists of three or four? So yesterday we actually had someone sprinting. We had an issue with the slides. Like right now it's like an upload widget and it's a singular upload widget. And we had someone say we want to put in slide share and perform other types of media. And so with my work on Drupal commons, we've made the commons media module and since both commons and cod use organic groups as a baseline to manage events or groups for commons, my hope is to actually get that part into cod and then get rid of the slide field and change it into the media field. That should make it a lot easier to do that type of work. Okay, but that would mean there's still one session and there's got multi slides, but it's not. You can submit one slide and one slide and one slide and the conference organizer says, oh, they fit together. We put them in one session. Oh, you're talking about like taking multiple session submissions. Yeah. And then combining them into one. So far with Linux us, we've just asked people if they wanted to combine their session together and then they pick whichever ones most closely related and covers and then they just add a speaker to that session. It would be an interesting idea though to create a related. I there's a related module which is horrible because the search query like totally. It gets really, really bad, but like it goes nuts, but that would be an interesting idea to add related sessions or have admins be able to say this is a related session. The other thing to think about with that is because the scheduler is now far more flexible. You would have the ability to add multiple sessions to a room and combine them that way. So in that manner you could have single sessions in, you know, next door in that room and then in this room you could plan to have multiple sessions. So you could do it that way as well. Okay. Thank you. Yeah. Thanks for this great distribution. I have a question regarding the sponsorship registrations. I don't know if I understand correctly, but I thought I heard it was like taxonomy terms. You could create different sponsorships. Correct. And you also have sessions and rooms. And I was wondering if in the registrations process it would be easy to make it possible to sponsor a room or a session. So for Linux Fest we had, we've tried sponsored rooms. And usually what we did was we put it in the title, like we haven't put it in. But since rooms are entities, we could essentially just add a sponsor relation field, which would be a fun feature to add for that. Okay. As far as taxonomy goes, old versions of Cod had it hard-coded. The new version of Cod, while we support multiple events, the sponsorship levels are global to the site. So while you may have like four or five different levels, you may only use three in one session or one event, but you may use all five in the next event or something like that. Okay. Yeah. Thanks. Yeah. Any other, yeah, go for it. Thank you. I'm Patrick. I work for the European Commission. And we have one use case. I fear it's not covered here, but please tell me I'm wrong. We organize different conferences totally unrelated at different times. So I think here you organize with one site, one big event with different sessions and so on. So actually Cod supports multiple events and you can do, we've had one site that's meant to run 100 events in a year and it all runs off of the single code base. And it's not multi-site. That's a new feature. Since... Is it recent? Yeah, since Alpha 3, I think was when... Yeah, so basically we move... Cod historically was one site for one camp for one year. And we've moved it to be... For LynxFest, we do annual events, but we didn't want to spin up new sites every year. So in Cod now, you have the ability to add a new event for every single year. But you might want to talk about the Mongo... So MongoDB runs 100 or so events every year and wanted the ability to just have an event site where you have multiple events all located in this one site and they can each have their own theme, they can each have their own system. So a lot of the work was done for that. Okay, I'll go back home with good news. Hi there, Richie. We're based in Zurich, Switzerland. We have increasing inquiries from companies which like to have a kind of end-to-end process for the whole events they actually perform. So my question is, as I see here now on the Cod, is you handle all the administration stuff which is registration and sessioning and booking. What about what's happening actually during the event, kind of one-to-one bookings of people may want to speak with certain people or voting, polling, surveys and that kind of thing, which actually... We just have quite a demand on that because they don't want to come and say, okay, we want to use a kind of management system for this. We would like to have one piece together to actually end... to have an end-to-end process in one application to do this. Do you have any plans on this? Is there any roadmap on that? So one thing that's awesome about Drupal that I forgot to mention was that because it's not in Cod, but for LinuxFest we use Webform to do our session or our event evaluations. It's a little more tailored to what we're doing, but it would be really awesome to get that as a feature for the submissions. I haven't heard about the one-to-one contacts. One thing with the PDF scanner, it's a V card. So when you scan someone's badge, it takes you to the V card that we put output from the database from the site. But that's what we're looking at. People are asking, is there a possibility to network within the event without displaying all the personal addresses? If they feel comfortable, they will open up their account with their personal addresses or whatever. But just the possibility to network in-to-end without disclosing your details. Yeah, there is some basic abilities to do that, simply because, again, we built Cod with Drupal standards. So two of the things that would enable that. One is that there is an attendees view. So if you're registered, you can, as a site administrator, set the permissions. You can allow people to see the other attendees. When they see the other attendees, they can click on that user profile because when you register a ticket, it creates a user account for you. So when you have that user account, Drupal by default has the contact module, and the contact module doesn't expose your information, but it does provide a form that someone can fill out to contact you. So combining those two pieces of Drupal that come out of the box with Cod, you could easily just configure those to have some basic networking. Any other? Thanks again for beautiful work. I was wondering, would it be possible to have people not only register for the event as a whole, but also for the sessions within the event? So we actually have a flag on every session so that people can say, I'm attending this, and that adds it to their schedule, and it also essentially is a kind of registration so you can see who's attending, and you can have a block that shows who's attending that session. Is it like optional, or is it like when you register, you get immediately the option to say, so what session are you going to be visiting? Right now it's in the schedule, so you can click similar to how DrupalCon has the ability to add things to your schedule. The registrations, not yet, I'm just pondering, it wouldn't be trivial to put it during registration, but you're not the first one to actually ask about that. We had an issue in the queue, someone's wondering about registration per item, and it's an interesting one because some people have talked about actually using this as a classroom management system as well to do different classes, and then people, when they register, they can register for those classes. I haven't worked on that, but love to see patches, but yeah, the ability, there's another thing about the flags. We have, add to my schedule, and then we have, I'm interested in attending this session, and the way we sort of do this now is the, I'm interested, it gives us a count for our rooms, and it's about 70 to 80% accurate, so the ones that are fuller, we're pretty good on the room size, but those are probably the best ways to create that information, so. Okay, cool. Thank you. Yeah, right. Yes, so the question, yes, you can make a flag, is exposed to views, and I believe, I don't know if it's in Cod, I know we have one for Linux, but basically when we go to schedule our rooms, we have the listing ranked by which one has the highest number, so when we go to accept our sessions, they're all in the accepted tab because we, to use a five star, or give it some five star rating, and then there's another view where we can basically order them by how many people have voted, and then we can drag them into the scheduler that way. This year was a little more manual, but with all the work done in the last five months, it's pretty, a lot of this is now all done within the site, and you don't need to use Google spreadsheets and things. It's sort of one of the things we're trying to eliminate is the need for extra spreadsheets to manage the data we already have on the site, so. Any other questions? Well, hopefully this was a good update and informative, and yeah, if you have any other questions you want to ask, we'll be up here for a little bit, so thanks very much.