It's time to get started. I'm Cliff Lynch. I'm the director of the Coalition for Networked Information and I welcome you to another project briefing session that's part of the spring 2020 CNI virtual meeting which will be running until the end of May. Today we have two presenters, Tim Marconi and Chrissy Rissmeyer. Tim is from UC San Diego and Chrissy is from the University of California Santa Barbara and they will be giving us a presentation on a project called Project Surfliner which is a really quite unusual and deep collaboration between the two organizations centered around work with Sam Vera and they'll fill you in on all the details of that. After the two talks, Diane Goldenberg Hart will come, will materialize and will moderate a question and answer session with our two speakers. There is a chat box and we'll be posting a couple of URLs out to that that may be helpful and you're also free to use the chat box of course. There's also a Q&A tool at the bottom of your screen and we'd invite you to use that to pose questions. Feel free to enter questions using that Q&A tool at any point during the presentation when those questions occur to you and Diane will come and moderate them and we'll try and answer them all at the end of the presentation. With that I'll just thank you for joining us today and I want to thank Tim and Chrissy for contributing their insights in this project briefing and with that over to you Tim. Okay thank you Cliff and a big thanks to CNI for putting this together virtually. It has been amazing to have access to the recordings as well as just be able to see so much more content than we could normally if it was trying to go in that day and a half so thank you for making it and done so quickly and gracefully so thanks to CNI on that. All right thank you for the introduction so one more time. My name is Tim Marconi I'm from the UC San Diego Library and I'm the Director of Technology and Digital Experience. And I'm Chrissy Rissmeyer from the UC Santa Barber Library and I'm the Director of Digital Library Development. Excellent. Today we're going to talk about Project Surfliner and Every Great Project has an origin story and that is where we'd like to start today. We'll then discuss how we work together a few DevOps practices and we'll follow that up with what we've learned so far. So what is Project Surfliner? Project Surfliner is a collaborative project UC San Diego and UC Santa Barber libraries to create our next generation San Vera based digital library products. The collaboration has been named Project Surfliner after the Amtrak route that links our two campuses together. If you aren't familiar with it, San Vera, formerly Hydra is a grassroots open source community of library and cultural heritage professionals who've been working together over the past 10 years to create digital repository solutions. San Vera software is based around an open source framework that generally combines four major components Fedora, Solar, Blacklight and San Vera Ruby Gems. Both UC San Diego and UC Santa Barbara are San Vera partner institutions. Sticking with the train analogy here this project got started because both of our engines were stuck at our respective stations. We had the engineers and we had an idea of where we wanted to go but we didn't want to take the wrong tracks. It was easier to do nothing than pick the wrong direction. So we started some informal conversations. We did some collective research and found that many of our other colleagues were in the same situation. So to minimize our risk and to maximize the benefit for the University of California, we decided to go together. This slide has obviously some links that I'm not going to click into. You'll have access to the slides via the portal and all these are just articles that helped us shape our vision. A document was created and shared proposing a UC centric collaborative project with San Diego and Santa Barbara to start. When successful, it could expand to other campuses in the system. The document is shared here if you're interested. We talk about risks in that document. My favorite line is doing nothing is our biggest risk. Something better is always on the horizon. We can build something now and pivot in the future if it makes sense at that point. Shortly after our way forward document was agreed upon we had our first project surfliner in person meeting and the buzz around the room was this new fancy project and what it was and how it was going to be and what it was going to be. The first order of business in that meeting was clarifying to all of our wonderful colleagues in the room that the project was not a product. Surfliner would never be done. More importantly, project surfliner is a collaboration effort. It is building and leveraging the strengths and experiences of the different campuses to focus on shared concepts and products. The project incorporates the San Berra community where it makes sense including core components but will not be defined by what the community at large develops. Well, what does make this different? We have been trying to approach the collaboration in a thoughtful manner. Mindful that what we are developing might be of interest to other folks within the UC system or within the larger San Berra and library community. So keeping that in mind, we have come up with a couple of general approaches to help guide this collaboration. The first is the idea of shared code separate installations. Ideally, this means that each campus does not have to maintain their own forks of the code. This is currently a widespread problem within the San Berra community. Rather, we truly want to have a shared code base that each campus is using for their own standalone systems. This means that we are doing a lot of work up front to make it easy for each campus to deploy on their own infrastructure without needing local code changes or to separately maintain that code. The code can be pristine, but if another campus can't deploy it in their own environment, it is useless within the surfliner context. We also know that each campus has unique needs, so rather than trying to design a single monolithic stack, we're working to develop a suite of products that are designed to work together, but can be mixed and matched based on an individual campus need. Finally, we want to be transparent with our work, so we've adopted a strategy of open communication. In addition to a project blog, all of the product documentation, code, sprint review, sprint review recordings, etc., it's all open to anyone who's interested in learning more. We're working to be totally open about our failures, in addition to our successes. That's our origin story, and I'm going to pass this on to Chrissy to tell us more about how we work together as a team. Thanks, Tim. So when you consider how we work together as people, it's important to remember that surfliner is a cross-campus and remote first by design. We don't divide if the products develop them separately and then share the results with each other. Every product that we work on includes team members from each campus, ideally with cross-campus leadership. This has helped us in several ways. The first is avoiding local bias and development decisions. For example, if both the product donor and technical leads for a particular product were from UCSB, we might unintentionally prioritize the development in such a way that benefits us more. It also helps avoid accidentally excluding team members at other campuses because of conversations happening among co-workers who regularly work together. We don't want water cooler conversations to influence development decisions. As Tim mentioned, we have worked to adopt an open communication strategy. Coming from two campuses, we have a lot of stakeholders and wanted to make sure that everyone who is interested in knowing what we were doing, when we were doing it, and more importantly, why we weren't doing something, could find out. We have tried to build that into the way that we work together. For example, our sprint reviews are publicly available and we try to hold all of our Slack conversations in our Surfliner channel, which is open to any member of the UC community who wants to join. We have also created a communication channels page on our blog that points people to our GitLab so that interested folks can find out the status of any work at any time. From the beginning, we recognized that for the project to succeed, we needed to develop a strong framework for how we work together, including good collaborative remote work practices. This has helped us to build a strong working relationship through the collaboration and ensures that the needs of individual campus stakeholders are being met by our product designs. We don't just want to leverage the strengths and experiences of each campus, but also want to continue to build individual team knowledge and capacity at each campus. At an early Surfliner planning meeting, we developed a sprint framework for the collaboration during inspiration from agile and scrum methodologies. This framework includes clearly defined roles in sprint cycles. Because we have multiple products being developed as part of the collaboration, we identified two distinct types of teams which meet on a regular basis as part of our ongoing work. Product teams are only those people working on a given product where the project team includes all the team members working on any Surfliner project. Every Surfliner product team follows the same overall philosophy and methodology. This helps team members more easily transition between working on different products. Each product team includes a product owner who represents the user community and is responsible for working with stakeholders to determine what features will be in each product release and also a tech lead who is responsible for the technical decision-making on that product. Tech leads also provide facilitation and direction to guide development and architectural decisions. Ideally, but not always in practice, the product owner and the tech lead come from different campuses. Product teams also include the developers who build and create the applications. Whenever possible, developers only participate as part of one product team during any given sprint in order to minimize context switching. These first three roles are involved with the project on a daily basis when on sprint. Product teams also include domain or subject experts who are authorities in a particular area, for example metadata to a spatial or operation specialist or accessibility experts. These folks work alongside the developers on the team and depending on the product may be involved daily or pulled in only as needed. Stakeholders are responsible for informing the decisions that the product teams make and have specific knowledge and influence that help the product. Stakeholders include user advocates, staff, administration, faculty, researchers, etc. and are engaged on a regular but not daily basis. While on sprint, core stakeholders are invited to participate in the sprint review meetings that happen every two weeks to provide iterative feedback to the team about their work. At the project level, we have project champions who are those higher level administrators who help with resourcing, advocacy, and clearing major blockers. This is in addition to our respective university librarians who are the official project sponsors and definitely helped pave the way for the collaboration to get started. Surfliner Development follows two-week sprint cycles that include both Santa Barbara and San Diego team members for all products. In the first year of the collaboration, we experimented with working in dedicated work cycles and in ongoing sprints. It turned out that for us, ongoing sprints was a disaster. As I talk about more later, scheduling and calendaring has been one of our biggest challenges working together, which probably isn't surprising to anyone who has tried to schedule a meeting for more than a few people. So starting in 2020, we have settled on a 60-day on-off work cycles, meaning that we're currently working together approximately six months a year. During every two-week sprint, each product team holds their own sprint planning at the beginning to negotiate and select tickets and then their own sprint review and demo at the end to show what the team has accomplished for stakeholders. The sprint reviews are recorded and shared on our blog, so stakeholders who can't attend the meetings can stay up to date. Each team is also responsible for scheduling their own backlog refinements as needed prior to sprint planning to refine and prioritize tickets. Daily stand-ups and retrospectives are held as project-wide meetings. In daily stand-up, the project team as a whole meets briefly to discuss ongoing work in blockers. Given our developmental methodology and shared monorepo, this has been an effective way at resolving issues as they arrive. The whole project team also participates in a retrospective on the last day of each sprint to discuss how things went and what to change for future sprints. Another really important aspect of how we work together to build individual team knowledge and capacities through pair programming. If you aren't familiar with it, pair programming is an agile technique in which two programmers work together, usually at one workstation. Usually one is the driver who actively codes and the other person is the navigator who reviews the code and then they switch roles frequently. The navigator is also in charge of looking out for future problems that might come up from the code in doing something a certain way and looking for ways the code might be improved. Whenever possible, we encourage cross-campus pairing as this also helps team members build individual relationships with each other. I think that because we were collaborating with another campus, we were hyper aware of the need for inclusive remote work practices. During the project's first work cycle, we had team members located both on and off site in Santa Barbara and San Diego, but also in Los Angeles, Portland, Oregon, Seattle, and Bethel, Ohio. Some team members were full-time remote throughout the project, others were primarily remote but still live locally, so others were temporarily remote for only parts of the project. But even if all of our respective team members worked on-site at our respective campuses, they would still be remote from each other. This was such an important takeaway for me. Once one member of a team is remote, essentially your whole team is remote, and that means that you need to change the work the way you work together as a team. I know that right now we are in a time where most if not all of us are working remotely. However, as members of your teams begin to slowly transition back to the workplace, some of these practices may be especially useful. First, surfliner, and now for my team at UCSB, this means a couple of concrete things in practice. The first is we use agreed upon communication channels and encourage surfacing important conversations to those channels so that all team members can see and participate. We also feel really strongly that good documentation is a crucial tool for inclusion, both in our code and to document when and why decisions are made. This extends to recording important meetings and of course our sprint reviews. We also do our best to avoid what I call conference room Zoom calls. If you've ever been the one person calling into an in-person meeting, you can know how tough it can be to fully participate. You miss facial expressions and it can be really difficult to interrupt the flow of conversation if you have a point to make. If one person is on Zoom, then if possible, everyone should call in via Zoom. But this does mean that in practice I frequently participate in Zoom meetings with members of my development team sitting 10 feet away, which is admittedly a little awkward. This slide may also represent much of your daily work toolkit now. Things have definitely changed for all of our lives since we proposed this talk. However, I thought it would still be helpful to run briefly through the tools that we found most useful for remote work in surfliner. Zoom and Slack form the backbone of our day-to-day interactions, providing voice and video calls for synchronous communication and texts for near synchronous day-to-day chatter. For Slack, we use the UC Tech Slack team. This makes our chat highly visible to internal stakeholders as well as to prospective collaborators around the University of California system. We have a shared Google Drive that we use for collaborative document editing and use it for meeting notes, reports, and white papers, and also slide decks like this one. GitLab supports most aspects of the day-to-day technical work, including ticketing and campin boards for products, version control, development lifecycle and code review, and CI CD pipelines. We chose GitLab because it provided a comprehensive DevOps platform for the team. But probably the team's overall favorite discovery is a platform called Retrium, which is what we use to do our retrospectives remotely. If anyone has worked on an agile team, retrospectives are usually done in a conference room, and there's a stack of post-it notes. People take a moment without the bias of anyone else's opinions to write down responses to whatever topic the person leading the retro put forth to discuss, like what worked well during the sprint, what didn't, or what you have learned. Finding a replacement for an in-person retro that we could do effectively online seemed impossible. But fortunately, a team member at UCSD discovered Retrium, which does this really, really well. It can be super tempting to skip retros when you're working on a team, but I can't tell you enough how important retros have been to Surfliner. They really enhanced the team's experience by being able to act on problems that came up in a past sprint immediately. And because participants are able to share feedback anonymously, it encouraged folks who are less likely to speak up in other settings to provide their feedback. Much of our daily practices in Surfliner came out of our retrospectives. So for example, in daily stand-ups, we now have a volunteer who always shares the board in Zoom, and team members use ticket numbers when sharing updates. We always end our DSUs with a board check and a check of the merge request to see if any work is waiting to be reviewed. As successful as our remote collaboration has been, we do still find it incredibly useful whenever possible to hold quarterly in-person meetings. These meetings have been really useful in strategic planning, determining next steps, and building team cohesion. As much as possible, we should try to center these in-person gatherings around something the team members might already be traveling to, such as Simvir Connect or UC Tech to keep down travel costs. So this is how we've been working together, and now I'm going to pass it back on over to Tim to talk about our DevOps practices. Excellent. Thank you, Chrissy. In the interest of time, I'm going to move through these DevOps slides rather quickly, as there are a ton of rabbit holes. We could go down. So please consider this a high-level overview. We're happy to answer any questions in Q&A, or if it gets down further technical, I might need to direct you towards our team. So DevOps is a culture shift. I really love this quote by Jez Humble, who wrote the DevOps handbook with Jean Kim. And on that note, if you haven't had a chance to read the Phoenix project and the Unicorn project, I strongly recommend it. It really does a good job. Of describing DevOps as a culture, as well as incorporating it into kind of from the IT side of things. They're good books. DevOps can enlist at all kinds of different reactions in 2020.  Some people think it should be in all the titles, and that if you have a development and an operations team that you're living in the distant past. So it makes sense that DevOps has a different meaning depending on your organization and where you are along the continuum. I come from an operations background, serving as a sysadmin for many years before getting into management. I supported Hyzer applications previously and had little to no idea what we were deploying. Simply, what was required from the build procedures and that the development team gave us. Given the proverbial code over the wall scenario, it isn't a surprise that our initial builds had difficulty scaling in production as our ops team had very little interest or buy-in for what development was giving us. Project surfliner needed to be different. Each library in the UC has very different staffing. The technology on some campuses is centralized in a campus IT shop. Some libraries had developers, while some others have one or two do-it-all technology folks. We didn't want to point at a code repository and say, there's the open source code. We documented as well as we could. Good luck. We wanted to make a design that could incorporate limited ops or dev with deployment options that could go in the cloud on premise or a mix of both depending on the solution they needed to solve. Wanted to look at the shared infrastructure, where it made sense. Make sure everyone could operate in their silos if they preferred. The best of both worlds, which comes back to development and operations together, DevOps. Recognizing that each have important jobs and that their identity isn't being taken away. We did this by making some difficult design decisions early on. One of our earliest design decisions was to go with the single mono code repository, also known as we'll continue to refer to as a mono repo, which is a unique aspect of this project and the thing that stops most folks in their tracks because it is very different than how the open source community does their development. But it has worked really well for us so far. Mono repos are common in big companies like Google, Twitter, Facebook, and other tech giants because they need to move quickly and updating a bunch of individual dependencies creates more technical debt and unplanned work than simply adhering to a shared practice. We follow 12 factor methodology, which a quick overview means we build one application and deploy it to many environments. We build applications for modern cloud deployments. We build applications that can be deployed continuously. We build applications that can scale. 12 factor means clean separation of the application from its environment. Environments may vary between development, staging, and production, but also between campuses. We want to know that we can deploy our applications anywhere. Christy already mentioned our agile processes and we have a bit more of that in our further section. We also build code review into our processes as a best practice. It is proving very beneficial along with paired programming as mentorship and learning opportunities in new staff onboarding. Because we wanted to make everything super hard, both teams left the comfort of their respective GitHub repositories and adopted GitLab from the beginning simply because of their advanced auto DevOps features. If we stayed with GitHub, we would need to introduce another piece of complexity for CI CD like CircleCI or one of Jenkins, one of the many other products that exist out there. GitLab had the tooling that we needed, but it did mean leaving the comfort of GitHub, which we are all very familiar with and still use to this day in different scenarios. For us, CI is a practice we adhere to. We keep branches short, lived, and up to date. This allows us to move the mainline rapidly and bring developers up to speed on it quickly. For continuous delivery, we deploy to multiple environments. Both campuses are using Rancher and EKS standardizing on Helm charts in Chart Museum. I'm going to apologize to everyone that felt like I spoke a different language the last couple of slides. DevOps relies on a lot of different products, the names of which can be more confusing than the products and orchestration layers themselves. The good news is I'm passing this back to Christy for what we learned. Thanks, Tim. Just so that you don't get the impression that all of this was super easy, we definitely had some challenges along the way. So many challenges. It has been wonderful working with the team at UTSD, but throughout the project, the absolute hardest challenge has definitely been calendaring. In addition to just the sheer logistic challenge of scheduling lots of people at two campuses, we also had some really specific problems. One of the biggest causes of all of this is that our campuses use different calendaring platforms, Google and Outlook, which, surprise, don't always work well together. Team members at different campuses couldn't see each other's availability without jumping through major hoops, canceled events didn't get deleted, and updates to events didn't make changes. It was and still is an ongoing technological headache. We also don't have a project manager, so scheduling all of these meetings isn't really part of anyone's overall responsibility. In our first work cycle, the two product owners took on the work of calendaring, which worked okay, except for we did it in different ways. One team had a set schedule in advance, the other was more ad hoc, different team members had different expectations, that led to miscommunications, and it was all kind of a mess. Ultimately, we figured it out for that work cycle, but once we started new sprints, calendaring continued to be a problem, and then we made it even worse for ourselves. We decided to try out working together in a series of ongoing sprints instead of a dedicated work cycle. We're just some teams work together during a given time period, and then as the project got more complex, more products, more product owners, more tech leads, we discovered that some of the sprint meetings weren't being scheduled. It became pretty apparent how scheduling had happened in the first work cycle, wasn't really visible to the rest of the team. The original product owners had done the work so that it would get done, but we didn't really share that this was additional work that had been taken on top of our official PO responsibilities. And this became very, very clear when one of our new product owners asked, why hasn't anyone been scheduling demos or retrospectives for my team? Which this leads me to our next challenge, onboarding. We totally failed at this. Following our first successful work cycle, we spun up two new product teams. The tech leads and developers had worked on the first work cycle, but the product owners were both new. We had tons of documentation and sent them to two days of formal product owner training, but then never really watched them through helping a PO worked within the surfliner framework as opposed to the peer agile scrum that they had learned in training. But to give another shout out to the value of retros, again, all of this came out in a retro. We ended up addressing both of these challenges in several ways. We clarified for the project team who is responsible for calendaring what meetings. So now team meetings, stand-ups and retros are at set times every work cycle, and it's now the responsibility of individual team members to add those to their calendars. We also explicitly made the product owners responsible for their individual team meetings and decided that dedicated work cycles were a better fit for the way we worked together. Finally, we developed a checklist for onboarding future product owners. Ones for other roles are also in development to help ensure that we don't miscommunicate, miscommunicating these types of crucial information again. The project came together sort of eerily fast, and I think because of this, we expected the team to jump into working together. I think a lot of us forgot that it takes a while to build trust. Some of us have been working together in the open source community for quite a while, but really missed that not all of our team members had worked together that often. For the product teams, this meant that they went easy on each other when reviewing each other's code during merge requests and didn't speak up when they had questions. We have worked to resolve this in several ways, encouraging pair programming among team members, calling out merge requests daily in stand-up, providing guidance on how to provide constructive and kind code reviews, and talking about this awkwardness and retros. And speaking of retros, we sent all of our product owners to formal training, and most of our development team members had some kind of scrum or agile backgrounds. But guess what we forgot? No one else had any agile experience. None of our stakeholders and definitely none of the subject matter experts who are actually participating in the product teams. So that was a big flop. We learned that moving forward, we need to make sure that everyone involved in the project understands at least the basic principles and vocabularies of how we work together. Like Tim mentioned, we ended up choosing GitLab because it provided a comprehensive DevOps platform. However, we really underestimated the time it would take for the development team to transition to working in the new development platform. We also had, and truthfully, continue to have issues with our GitLab licensing. The short version of the story is that early on, our free trial with lots of features ran out before our licensing negotiations were complete. This ended up causing some major problems because our deployment infrastructure relied on features we no longer had access to. Fortunately, our developers have been able to implement a workaround, but we all spent way too many hours trying to resolve these issues. We also had several challenges related to communication. While open communication is one of our principles, we learned that there is such thing as overcommunication. Several months in, we received feedback that stakeholders and subject matter experts didn't know what meetings were important, and they got too many infights and too many emails. Following that feedback, we tried to clarify whose attendance was required and optional during sprint meetings. This way, we're not excluding folks, but they know when they can opt out. We also stopped holding a weekly public stand up because team members and stakeholders alike felt it didn't provide additional value over what they could learn via other channels. The transparency aspect of our communication strategy will always be challenging because transparency can be super scary, and the things that you're bad at, everyone knows what you're bad at by the end of the project. We also found that communicating openly is a really great way of getting attention, and that gets people interested in participating. I would argue that this is a reason people hide their work from the larger community until it's complete. You're working on something cool and then someone else wants to join, but you feel that getting them up to speed or incorporating their criteria for a product might slow you down, which is completely understandable. So how did we handle it in Surfliner? We decided early on to limit the people in the sprints and the product planning sessions to the teams that were actually contributing resources immediately, which for us was UCSD and UCSB. But we also did a ton of information sessions. If someone from another campus was interested in joining, we wanted to be upfront and honest about what we were doing and how. We also decided early on to create a matrix of what participation meant and what the expectation from our end and their end for being part of the collaboration was. This took a lot of pressure off of us and off the other UC campuses who wanted to stay in the loop about what we were doing, but weren't at a point where they were ready to commit resources. But despite all of these challenges, the impacts of the collaboration have been more than worth it. I know we haven't really talked about any of the products we're developing, but they are of course a major outcome of the collaboration. So far, we have both successfully put our exhibits platform Starlight into production at both campuses and have several additional products coming soon, including a geospatial platform shoreline, a shared linked data authority platform LARC, and a staff-facing digital objects management platform Comet. And yes, we do name all of our products after historic California trains. I also feel like some of the more idealistic benefits of the collaboration have become reality, but UCSB and UCSD are in similar situations. We have significant legacy infrastructure, which requires maintenance and relatively small development teams. However, the collaboration has increased our capacity to innovate and make progress towards our next generation digital library platforms. When we are on work cycle, we effectively double each of our team sizes. Over time, as each of us is able to slowly replace portions of our legacy systems with surflander developed infrastructure, that capacity to innovate should hopefully increase. Knowledge sharing among individuals on the teams has had a major impact on our overall success. Neither campus needs to be the expert in all the things, but we are able to leverage those strengths that do exist. For example, UCSB has more expertise in working with geospatial materials, so we took the lead on the geospatial product, whereas UCSD has a really strong operations unit, which UCSB in turn has been able to benefit from. Beyond just sharing knowledge with each other, we are also learning new skills as part of the collaboration, which in turn have also improved our local practice. Our local teams have been able to apply this knowledge to improve our existing infrastructure. We really have been able to build and leverage the strengths and experiences of both of our campuses. And finally, while this has been immediately difficult at times to balance our local work with our surflander work, even when we aren't working together, the lessons we learned and the practices we have developed have resulted in lasting cultural shifts for our local teams. Speaking now from the UCSB perspective, our development team enjoyed working in the surflander agile framework so much that we have begun adopting a modified version for our local work, likewise for our DevOps practices. It has also deeply affected our cultural perspective on remote work. Since the launch of surflander, we were able to hire our first full-time remote developer and have since had another developer transition to full-time remote work and move out of state. When my department was formed late last year, remote first practices were a major influence guiding how we wanted to all work together as a team. And moving forward, I believe that any new develop developer position in my department will also be able to work remotely if they so choose. So finally to wrap up, what's next for surflander? As we continue to work together, we are continuously reevaluating practices and processes to ensure that we can meet growing demands, especially how to manage development on so many products without the overall coordination of a project manager. We purposely tackled some of the smaller products first, but now that those start to be put into production, we also need to figure out how we can best collaboratively support those now that they've stopped being active development projects. And as we begin to plan for our larger products, we also need to figure out how to do things that weren't necessary at the same scale for the smaller projects, like how to conduct multi-campus requirement gatherings with very large groups of stakeholders. However, whatever the challenges we continue to face to bring it back to our train puns, I'm really excited for the journey to continue down the track. So thank you all. Before we move on to questions, I do want to take a moment to recognize that this is truly all a team effort and want to acknowledge all of the individuals at both campuses that have contributed to the project. A listing of all of those team members are included at the end of the slide deck. So with that, are there any questions? Thanks. Thanks so much, Tim. Thank you, Chrissy. Very thorough and candid overview of your collaboration. We really appreciate that. I think this was part of your radical transparency mantra, and we're really delighted that you came to CNI to share that with us. So with that, and as Chrissy said, I'd like to reiterate that the floor is now open for questions or comments. Please take a moment to type your questions into the Q&A box, and I'll be happy to read them aloud here, and Tim and Chrissy will respond live. There's also a chat box if you prefer to use that where we shared a few links to their project, links to the project briefing page, which also contains a link to their slides, and we will embed the video of this webinar at that URL after the presentation as well. So while we're waiting to see if we've got some questions, I just want to take a moment to remind everybody that this webinar is part of CNI's spring 2020 virtual membership meeting, which is continuing on through the end of the month. So we have a couple more weeks of webinars. I've just chatted out to you there, a direct link to the schedule for the rest of the meeting, and there's lots to come. We actually have a very packed agenda for the next two weeks. So Tim and Chrissy, I was wondering if you could comment a little bit on, or rather, share maybe a short list. So you gave us a very comprehensive overview of the process, which was definitely a challenge by any measure. If we have folks listening here now who are thinking about trying to implement a similar kind of collaboration, have you got some kind of top of the list? These are the things to look out for, and these are the things you would have done in advance if you'd had it to do over again. Maybe too hard to get this still down. It's a great question. Did you want to take one? I have a little bit of an idea. Yeah, why don't you jump in? The one thing I would make sure is that we were very lucky, I'll be very honest, we were very lucky with this, that we had pretty much, we had executive buy-in and support pretty early on. There are a lot of things that made that happen, but the fact that we were working with another UC within the UC system, there's safety in doing that. I think we would have had a much bigger issue going forward with this project if we didn't have that executive buy-in from the beginning. I would recommend that if folks are planning on this, it would be very good to start with that. I know that's silly if I, of course, start with executive buy-in, but have that ready and be ready to get their feelings on it and figure out maybe if there's some modifications you're going to have to make. I know initially we had talked about being like, whoa, we could really expand this to multiple campuses and our scope got well out of our, it was going to be way too difficult to try and deal with, it was difficult enough to work with two schedules to deal with one of the 10 campuses was going to be very hard. So getting the executive buy-in was really helpful and we took their advice if they gave us any on how that worked. Yeah, and I'll just add to that, there are also very practical things when putting a collaboration like this together that were easier because we were part of the UC system's issues like copyright. So all of our copyright is owned by the UC region. So just having, there was some lack of friction because we are part of the same university system. But I do actually want to chime in and talk a little bit about on the other side too. Tim had alluded to some grassroots relationship building and this didn't just come out of nowhere. This wasn't, you know, oh, a couple people got this idea and we ran it by our ULs and all of a sudden we're working together is that the teams had actually been talking and collaborating on things like our metadata models and discussing that for probably about three years before we actually jumped in and started working together. So we actually had a really good sense that our philosophical approach to some of these big questions was very similar. Our teams do work very well together, just the personalities on our team. So I think we already had a good sense that the personalities on the team, that it was a really, really good fit for the collaboration. So I think that that can't be stressed enough too, is you kind of need to do your homework and you need to have built some of those relationships first. And in some ways, I feel like it was just a sort of a logical continuation of a lot of those relationships that we had already been building, which I think is just added, especially combined with the really amazing support we had from our administrations, did set us up to be quite successful. Yeah, so setting, setting a solid foundation at the outset, doing a lot of the legwork in advance really will set you ahead later. So that's great advice. Thank you. And forgive me if you spoke to this. I know you mentioned the, you know, how we're working now given the current crisis. But has that really impacted your workflow now, the current situation? Or is it, are you just set up to be able to continue work as usual on this project? And so that's actually, I would be happy to speak to that. There's a couple things about this project that have, I think really impacted our ability to respond to the current crisis. I mean, I think first thing to acknowledge is that, yes, things are just able to continue as normal. That has been great, except for, I do think for everyone, no matter how long you've been working remote and how good you are at it, you know, there is the added, sort of the added situation that we're all in.  But actually a really major benefit of this is because our teams had gotten really good. We were actually able to offer our support to the rest of our organizations as this started. So at UCS, me and myself and my senior digital library architect, Tom Johnson, actually held a series of remote work sessions for our staff who had no experience to really hopefully get them up to speed. And this was in a time when our governor had not yet shut things down, but we had started to already have some folks transition to remote work. And so, you know, that was just a really fantastic resource that we had for our institutions that we were able to lend and give some advice and help folks really prepare for our new reality. And I really appreciated that. Tim, did you have anything you wanted to add to that? Just the same kind of feelings, like when I remember being asked in that emergency response team to try and detail how we were going to start working remote, I was like, we'll just not come into work. But otherwise, we'll just continue doing what we're doing. Like there really isn't the team was already because we had some remote developers, we had some remote folks already and telecommuting kind of built in. We just said, don't come into the building, keep the equipment that you're still using that you normally use on your day to day and just do that. Obviously, as Chrissy mentioned, there's plenty of other complications. Folks have families, they're caring for folks, for other folks in the place. Some folks, you know, ended up getting sick. So it is all just like there's the difficulties of the pandemic, but there is just the idea that remote work was we're well suited for it.  So there is a couple of times when you're like, no, you gotta just press the mute button. Like that isn't, it wasn't a big thing to us because that's been our lives for years. It did come into a crashing remembering that this isn't how people normally operate. So yeah, we were well positioned and that helped a lot. Yeah, I'll also mention that the timing of this, I said we're on 60 day on off work cycles. So we were sort of in the last couple of weeks of our existing work cycle when this started. And so we did sort of finish that out the last, you know, really since now I'm trying to think it back. So all of May we've been off work cycle and we start up again in June. So but yeah, we don't really anticipate that this will affect our progress at all. You know, it's funny, we say all this except it absolutely affected Chrissy and I's progress, because we were on a sprint together, known as an administrative sprint, which way we were, we were working through writing an annual reports, finishing up some of the slides for this presentation as well as a couple of others. And all of a sudden, both of us as respective directors were told like, you need to prepare the organization for this remote work.  Because like, there's no way I've spent any time looking at an annual report. Yeah, no one escapes the pivot. All right, I see Cliff has a question for us now. So let me go ahead and read that. He asks when the world went remote, the transition was obviously easier because you had already built up a lot of social capital. Have you had to onboard anyone new into the collaboration since we went remote? And if so, how well has that worked? So that's a great question, Cliff. I'll say we haven't had to onboard anyone new into surfliner since the world went remote. But we have actually at UCSB, we had one of our new associate university librarians begin in the middle of that. And actually several other team member or library staff members start in the middle of that. And so I can't really speak directly to how that experience has been for them. But it is definitely, it has been really interesting to sort of only meet people remotely. But I will also mention that, you know, one of our developers that use UCSB, Tom Johnson, who was our first remote hire, has always been a remote worker. He lives in the Pacific Northwest. I think some of the other folks, I don't know if this is true for all the San Diego staff, but I think it had been much more common for people to sort of gradually add days to telecommuting as opposed to starting remotely. And Tom is someone that reports directly to me. And so all of our relationship as a supervisor and an employee has all been done in these virtual channels. And so that's actually a very different practice and is probably more time than we have to sort of talk about my approaches to supervising remote staff. Although the biggest takeaway is it's really no different than physical staff. You have the same expectations. You just have to be very thoughtful about things like we mentioned, you know, making sure that you have agreed upon communication for your whole team, making sure you can have calendars, making sure that you're building those two relationships. So I think all of that is very different just having that sort of extra consciousness that once really once one member of your team is remote, your whole team is remote, that as a, you know, I have all of my employees that are remote. I am also a remote employee in my day-to-day life because I am remote from the folks that I supervise and, you know, that has really influenced the way that I approach my relationships with everyone on my team, regardless of whether or not they're in the building with me or not. Tim, did you have anything that you wanted to share? Not that I mean just that obviously this collaboration has been going on for about two years and we have had to onboard folks outside of the pandemic that were remote because they had to get on the remote team. So it wasn't so much the hiring practice of hiring someone remote, but it was the idea of like we had a couple of new ops folks that had to join the team. They had to get up to speed on a new project with the project was respectively remote because none of the UC Santa, we haven't had a chance to meet with the team ever since a couple of our folks have joined. I think UCSB's had an ops person join and San Diego's also had an ops person join. So it's tough to have them, they've never physically met these folks, but they've absolutely participated on sprint reviews and been, you know, slacking with them for, gosh, months now, six months or so.  It's a really great, it's really nice to be able to see people in person. I'm sure all of you can relate to that now. It will be really nice when we can see each other. And so, you know, we do still try to build that into our team relationship, those quarterly meetings when we were able to have them were really fantastic. It's the same for, you know, my staff, we try to do a quarterly all hands where everyone comes to Santa Barbara, just because there really isn't a substitute for seeing each other in person. I think we've been able to be really successful in our remote working relationship, but that has also been an equally important part of just building the relationships in the team. Perhaps a glimpse into our future. Thank you. Thank you so much. And Cliff says, he thanks you. He says, I find that if one is remote, you are all remote, a really compelling insight, which we're all living right now for sure. Yeah. And it is, it is one of, as we're creating these emergency plans to come back, one of the things that is commonly referenced is if you can work from home, continue working from home for, you know, until things get a little, little more clarity, but the folks that obviously have to come in the building to work with the collection, like that makes sense. The emphasis that we kind of keep keeping the mantra up is that if you are doing this hybrid idea, it is not a great experience to do the hybrid Zoom sessions. It's your remote folks feel ostracized, that the rooms are never set up right for it, the mics are not great, doesn't matter. I've seen the best audio in the world and it still fails when someone asks a question or something happens on the side. So it does, it is important as we all start transitioning back to respective workplaces to think of that hybrid in this area. Sometimes it's just not as effective. So start thinking of these remote practices, at least while you're transitioning staff back into the building to think about that and really try to have the Zoom meetings from your desks or whatever, so everyone feels like they're on the same platform. It's a really good tip. Thank you. With that, I just want to thank you both again for coming and I want to thank Oliver. All right, thank you so much.


Welcome to one of the last sessions in this room today, I Hope you are not too tired for this last session Let's start with Some reports of our experience with the so-named separate downstream development We Have made in the last couple of years some experience to work with safer in product development and we that is to be us and me Stefan we come from different companies that bought surprise We work together for a couple of years to make some medical devices and also connected health systems together with yokto or several technologies and so all what you see here in this slides is more an Example of best practice we have learned to work with these technologies and at least this is a theme of really about the several in environment and so as a result of this we create a project on GitHub that has some public access or where you can see all the learnings We see here And then public environment. That's the name bridle and so We to be as and me. We are the maintenance behind this small project And what it is we will learn today in this session on the end With all our experience we know in the face of that we can made some trainings on our customer side in-house trainings online and That's our thought for the community Try to integrate several technology into medical devices So let me start with a short story I Think a story of Your life with several or in the future When you come the first time in contact with several You see oh cool thing. Let me play with it and all of all is start with a documentation and learn what several is and What are the pieces of several to create Start to create your own experience to create your ideas and Some time later you come to conclusion. Oh, it's a cool thing But on the end I have made many many changes on the source code base You will have new apps new drivers new boards maybe new tools whatever subsystems and libraries or You need in-house or to create your product and then leads exactly to the old pattern you have made a fork of several and To protect your product development for the future It's not the ideal Situation on this point and you are looking for any kind that's bind all these things together I have named it your kite line and What you need on a really kite is on the end Any point where you bind all together? That's the reason why we name bridal this project and On the end what bridal will be for you Is an example? Exactly a separate downstream development example Where you can learn? What is the best practice or what is the thing? You will need at least to start your product development in a professional environment So the background to come to this conclusion Was Was a story we have hold in a talk on Tuesday To be as had a Talk about how I feel love in self fall in love with suffer and There is one important conclusion in this talk That when you start a professional product development with open source components You will need more architectural efforts Beside your system architecture That means you need any environment or infrastructure for knowledge base management and also for the collaboration management and Let me sort this three parts a little bit in a other order What we have made with bridal was to start with a collaboration side You will see in this talk Some ideas and best practice how to come to a calibration with the community or with other parts in your product development contributors or customers and customers and That leads on the end to a Really really fancy project logistic on github that explain the loosely coupling from your downstream environment to the upstream the environment to suffer and Also, you can see then on the end that this is a tool for you to create your own life cycle or release management and And For the architectural perspective that is exactly this point where you create your qa environment to fulfill any kind of Regulation efforts or requirements Here for example the norm from the medical environment and The second point is the knowledge base management You will see an idea How you can create more than only a single document from the suffer environment you will Create your own code base. You will create your own product and Application and so that have to document in the same manner as sufferers do and so we have a Best practice Integrate that split your documents into different perspectives That's the beginning today and that can be Extended to any kind of perspectives for any kind of domains for example test environments test reports test specifications or Here reflected to the architectural environment the traceability and Yes, on the end you will create your system your product so you need a system architecture level and That is the most important effort made by the suffer community That you are will be able to create such kind of downstream development that you found the exit or Entry points to extend the framework itself the tooling the tool environment provided by suffer and also the code base so Let me start with a little bit of history where we come with this example project Yes, we have made some projects for the medical environment and Anytime in 2020 We have the first contact with the Nordic SDK environment and Nordic has made exactly that what we have missed and so We start to extract exactly that point that is important for our product development And also what we can split out to provide and template and blueprint for the community That was the idea and in spring 2021 we have a first prototype of the product of our project and In summer We was on the point that we need more collaboration environment to work with students for teaching or with other companies in the same level for product preparation and so it creates this virtual company the Tyak systems and integrate all our ideas under this organization on github and when you are looking for in github on user links in this Slides online, then you will land on exactly this point where you can see what we've done in the last two years On the end where we are today We are happy to say that our bridal project is exactly on the same Release point where suffer is we have not introduced any kind of new versioning That is The reason is the better orientation for external partners where we are and so In the time being until today We create some more documentations our over our development model and contribution workflow so that potential contributors have an orientation or where you where they can ask What to do to help us or? us together and on the Latest version we have start some feasibilities That is a really important thing. We can talk maybe have a talk in the on the next conference next year to integrate an Architectural model to use more and more the device tree abstraction to create System models so that we can change hardware components Protester boards and so on that is more the idea that Tobias has talked on Tuesday, so you should have a look on these slides and then later Have a look on the documentation in our vital project a project so that you can have an entry point for the abstraction So on the end, let me start with the project logistic we know we need any kind of collaboration tool and Over the years on the end we come to this conclusion Where you can see on the orientation for you Some important workers github workers In the middle is one and on the upper side is one the upper side one is the first point where we can Sure that we are loosely decoupled from several But important is loosely we have an Synchronization of our own mirror only every two hours or boat and When we see we need some quick changes on the code base of several This worker makes our rebasing automatically and when this will fail We got emails that we have to do some manually. So that is important because several is a dynamic project and It grows up with new ideas and we will capture all these new ideas in our own product development and so we can Be safe that we catch this or But on some points we need some proof force changes or we need some Backports or we need some Reductions of test fixtures whatever and the second really important task Here in this diagram is our bridal worker that's on the end as a west workspace every time when we made our own pull requests and also it's a nightly protection or All the major releases we will maintenance I Will run every night with Qa tests the Qa tests are reduced of a minimum It's a virtual project, but on the end we have created the infrastructure. We would need an and exactly We would need exactly in a product environment. You see on this side We have a self-hosted a github action runner On a Raspberry Pi with real hardware on it our own reference system the Tirec McPie and every night we run the architectural tests suite for arm and So we see oh the basic is good enough that we can go on and On the other side is a really important thing. We see soon in the next slides That's our documentation store And this documentation store Will be provided with each pull request or Major releases with new artifacts assorted by versions so that a doc set from of different documents Will be holds also for the history for each past versions Quick look on our hardware in the loop. That's real Exactly the next gen we work on a improvement on this the current is too slow To work exactly on every pull request and In a good power that we can make more test suites inside so Here you have only an impression of what is possible On the end and that depends exactly on your product environment Hit the Maker boards on the upper side and place in mind your own product on this point and you have a hardware in the loop We create until the next year new Definitions that we can use modern systems like lab grid to integrate Scaled hardware environment to the github environment and The other slot was our deployment environment for the Websites for the documentation That's a decoupled system complete decoupled system from the github environment It's a standalone web server within monitor the monitor will Instrumented by the pipeline from github itself and sort in exactly the right Position your documentation you have made on the github side Yes, we have learned in all other sessions that You need a rest manifest For such kind of development That's only a short impression What bridle Gives you bridle comes with its own vest Manifest and Please have a look on the online slides. There are some more detail information What you can do? but on the end our own manifest Declare us your software structure so software configuration management is fulfilled with this and on the end of this is your build environment on the local place and also on the CI pipelines and The second important thing is bridle is a suffer module It's the same situation for other downstream developments and in this Module description we have added as much as possible entries so that you That we can Evaluate all the situation or the best practice We need to create Product with all the features that suffer provides Some words to the document sets We need it for our own for the knowledge base management and This document set online Provides you with some features you will not see exactly on the suffer documentation side It starts with the different sets You see here you have a completely coupled Documentation for the suffer content itself that is this entry when I click on it we land exactly on the currents state of the suffer documentation and The same is For our own documentation on the bridle side This is a complete different document and the suffer documentation is maintained by suffer and the community and our own bridle documentation is maintained by us and What we have also do is to introduce a new perspective of documentation For example, the take a k-config Zumba library or the device tree bind Things that is more a reference for programmer and so All these components are split it up from the original suffer documentation so that you can search again as you know it from the suffer documentation, but now Includes all the symbols we made in our own environment in the bridle environment and This is exactly the case for the device bindings Furthermore, we see the API's are a little bit hidden in the original documentation and so we split it Also the API's we have our own API's started and We can also see the API provided by suffer and so that all is Splitted and provided in different perspectives for a given version and on the end you have the same environment for all historical versions and when we go really really far away back You see the documentation is complete different and also The doc sets are slightly different so How it works a quick overview We're in bridle have our own documentation folder. It's the same as suffer And then we provide our own CMAC magic to create different build environments And that is a point where we split up the different perspectives and bridle separate k-config in device tree environments And then we protesting in the same manner as suffer with things and oxygen over the content and on the end We result in different sets of documents That's Happen for all version we maintain Is it a release that? then we have a release tech and it works on this pattern and Heavy a branch then it's the same situation and we have an head on a different released branch and also on the latest greatest Documentation that reflects the main branches of suffer and bridle Let me show some artifacts only a few artifacts What it what is possible in a downstream environment? Really interesting is That you are able to extend your wrist command environment and also the CMAC extension Yes, we know suffer provides you with some nice tools and on the CMAC level and also on the rest level and With the current state You have no problem to create new boards new subsystem and so on application development and so on but what is not really? Knowing about the other tools that you can also extend the best command environment and the CMAC and let me start with the CMAC for understanding What we provide with bridle is a little bit more extension in the boilerplate sequence so Why we do this? Yes, we try to create a blueprint for medical products and so and this environment You will need some fix two versions because the most of Medical developers have to fix the versions because they have a validated tool Maybe they need not the suffer SDK or more a validated tool from Made by arm for example, and so We need some prepared setups what is required to build the bridle project and Also, we made some checks if this description is also valid found on your build environment and so the working behind this is really simple all application we're looking for suffer and server provides an CMAC config package for this and this entry is a default Sequence to set up the server boilerplate and before this is happen Suffer itself looking in all sub modules in all server modules If there are any kind of a suffer build configuration environment When this happen for example here in our bridle we Inject some new CMAC modules that process our requirements our version checkups guards for the toolchain and then suffer goes on with the Rest of the boilerplate set up and so you can be safe set your application has The right environment to build for a medical device There are some more features Please have a look on the online presentation. There are some more slides what bridle Will provide in the future for this or what currently is really working Behind this magic. We have also some protection to create our document sets On the end we have start to create our own rest command because one of the CMAC integration and bridle is that CMAC tries to provide an its own CMAC package So that you can later create a freestyle or freestanding application looking not looking for suffer because looking for bridle and Then bridle do all the job to set up the right boilerplate To create your application against a workspace that is bridle and not suffer alone so on the end yes We create for for preparation on this our own command so that rest can be used as a meta tool to export the bridle CMAC package in your home space and The goal behind this is when we have a quick look on the implementation That here This is a common case when you start with your own command that you need an constructor and command line parser and a runner and in the implementation of the runner you stumbled over this Line and see oh now I need a runner that called CMAC and exactly that is always implemented in the suffer environment and What we do here that is a good example for you maybe We try to avoid reinvention of a real what is rolling since years and so what we need on this point is to Extend our search path on python Though that we can import the original functional implementation of the run CMAC method and The trick behind this is a new feature in west maybe since last summer That we can add besides your path Information where suffer live also our own key value pairs for a hint for our own trampoline code that we can Combine a search path on the end that under suffer script West commands will live the original implementation of our of the suffer functionality to run CMAC so The solution on the end is to go over two different decorators on the python environment The one decorator Looking for the right this path Content extends this path that will happen on the only ones on this line here and The second decorator Will be Will be added or fixed the runtime environment for the for the python scripts That you have and global symbol towards the to the original method in the suffer environment and On the end your implementation looks similar as to the beginning, but now you only need to add one decorator and This what we see here is Exactly the same Of the rest command extension in suffer when suffer made a suffer export Now we have a bridal export and the only extension is this declaration magic so that we can reuse as original implementation to call a CMAC a command Behind the scene as suffer do Yeah Yes, only a quick overview because We know that there is an example application in the suffer project how you can start with the downstream application and development That's okay for beginning and when you only will play with suffer with a freestanding Environment or your own downstream development you can do this on the end bridal have tried to extend the functionality of such kind of example To a more professional and product productive downstream project. So the red label things is more or less the The features you will get when you study the bridal source code and Yes For you is an offer for you. You can also start quickly with With bridal itself. We have a getting started page You can see how should I set up install the source code and made a quick hello world That's in common case similar as if you would like start with suffer itself, you need Your toolchain you need your host tools You need a python virtual environment get your code Through the vest manifest file and You made some extensions in your CMAKE environment with the experts and On the end you can start with a quick hello world and But what will be new when you do this you see that suffer will notify it's there and bridal and bridal also say hey, I'm happy I found exactly the version of the SDK you will need That is a new feature that only bridal provides Reflected on your ideas of our product development. That is exactly this was an medical developer would need on the end a short summary Where you can identify was suffer downstream project is It has your project has an vest manifest exactly this manifest That defined your software structure Your project will be a suffer module so that you can Edit your exit or entry points for the several tool framework At least you will create your own kconfig and CMAKE environment and maybe a little bit more frenzy as you need and If required you added your own rest commands in a similar case as we have done with the example with the export So that's why we say bridal is a little bit more as a example as a standard example But this is also the reason why we release it in public as soon as possible so that other people have a big picture what is on the end possible with the suffer's tool landscape so that you can Come in sooner in your own professional workflow a short highlights. I will notify you We have some of our own boards some boards of this are not yet supported by suffer So that was a good place to start with such kind of boards For example the lotus from Siege studio That is for us exactly the plan to qualify new ideas and Later in this year we start to integrate it in the suffer upstream and also we have start with some tests of new strategies to come in with some architectural ideas to play with the with the tool landscape from Saffa that is behind the Siege studio proof interconnected shields Yeah, we have our own application tests apis and so on and Yeah, we have also a Much full list of things to do in sorted in When you see some interesting points here come to us talk with us You can arrive us over github or discord Yeah, I have to say thank you for your attention and And What more take over to you there any question. Yeah, thank you


Hi, my name is Carl Griffiths and I'm an account manager in the UK super office team I'm here today to talk about one of my favorite features within the super office CRM solution today We'll be looking at getting the most out of your activities in your CRM One of the best things about super office is how easy it is to see all that vital customer communication As your business grows and you reach out to more and more customers You need a solution that can help not only store all your communications and activities But also allow you to locate this information efficiently With super office, you are originally welcomed by a simple list of all activities that have been recorded Through the many years of communication with this customer as the length of your customer relationship increases So too, well the activities completed Even though all your customer communications are conveniently all in one place This may become difficult to locate specific information you are looking for for example You may want to just see all your external meetings completed. I Can do this easily by activating grouping via the setting symbol in the right hand corner on the company section tabs. I Can then select which criteria I wish to group by I will choose by activity type So I can group all my activities by their specific type I can also group by more than one criteria. I may wish to also include the activity date So by doing this, I can now not only see all my external meetings grouped together, but it will also group by date, too Super office also helps you simply filter your activities You can do this again by activating filtering on the settings button Followed by choosing which column you wish to filter by I may want to only see activities within a certain period of time for example Please note the ability to group and filter can be found in all areas of super office where you can see activities listed This may include wanting to group and filter your sales activities or even projects One more area. I would like to show you is how this feature could be extremely helpful when using with selections created As you can see I have created a selection where I can see all my customers who haven't purchased from us this year By using grouping I can then easily locate specific customers within these results For example, I may want to group by city so I can clearly see what location as the most results I could from this now select these London companies and maybe create a call list to make contact This is not a feature you tend to currently use I do hope this short video has inspired you to see all the amazing ways you can view your activities in super office Thank you for watching my favorite feature of super office that any further information Please feel free to contact with the details provided. Have a great day