Right, hi everyone. Welcome to Unsiloing Your Project Team with Collaborative Sketches and Digital Prototyping. We're going to be talking a bit about how you can use Collaborative Sketches and Digital Prototyping to supplement your existing UX approach and how doing this can benefit your project team, your clients, and your company. So we'll be talking a bit about how we made the change, what challenges we were trying to address originally, how we incorporated these two approaches into our existing approach, and finally the success stories and benefits that we've had during this. First, a little bit about us. We come from a DC-based firm, Rock Creek Strategic Marketing, and I'm Kat Kuhl, our Director of Technology. With me are Ika Lestari, our Senior Graphic Designer, and Michelle Chin, our Senior UX Strategist. We put this presentation together to show how this approach could benefit three main groups of people. UXers and designers who get more engagement from other people on their project team up front. Developers who tend to have more well thought out requirements by the time this reaches the development phase, and who can have early input into some of the deliverables that they might have had changes to if they had an opportunity to review them. And project managers who tend to get better thought-out products early in the project timeline, and who can have savings in their timelines when this is implemented. We put this together to address some of the challenges of our previous approach, which had been using only wireframing. While we still use wireframing selectively, we found that using wireframes only can lead to some problems because of the way the process works. By default, you're going to have a UXer who spends some time putting together wireframes, revising them, presenting them to the client, revising them, and has that happen a few times according to how many revision rounds are specified in your contract. This leads to lots of revisions, and ultimately we act like we're trying to make a static artifact perfect with our performing wording changes and tweaking that really could be done during the development and design phases of the project because we want to get this right. It's the deliverable the client is expecting, it's in our contract, and it takes on more importance than at times it necessarily should have. We also find that when you're working in a siloed environment where the UXer makes wireframes, hands them off to the designer, they get handed off to the developer and ultimately put into QA, there are lots of handoffs that happen along this process. There are lots of opportunities where the UXer might be saying, I really want it to work this way telling the designer that the designer passes it along to the front-end developer, gets passed along to the back-end developer as well, and you end up playing a game of telephone because you're trying to communicate complex functionality with what boils down to a paper concept. Because you're having a lot of revisions and a lot of handoffs, you're going to have a lack of engagement throughout the project from people who don't get involved quite as early as they should. This is a problem because when everyone on the team understands what's happening at the project, there's opportunity for input. Your accessibility analyst might end up red flagging the fact that that map concept you just proposed is going to have some serious challenges for keyboard-only users and that you need to invest time up front thinking about a fallback. Your designer might say that that approach you're putting into place is really going to look difficult, really challenging on a mobile phone to get that much information on the screen. And your developer might say that that's going to take a lot of time and effort to implement the way that you've laid it out, but with some few small tweaks, it could be a lot more easy to do within your existing timeline. When these people don't get an opportunity to contribute to the project until later, you miss the opportunities to hear your subject matter experts give this kind of feedback and incorporate it into what you're putting forward. This is something that's faced as broadly as a company, but there are also other changes that have faced individual teams. Probably the most frustrating part for developers is that we end up having a lengthy wireframe phase followed by a lengthy design phase and then an equally lengthy development phase that we're cramming quite a lot into. You end up doing your site building, module installation, module development, theming and migration all in a fairly small window of what can be a significantly long project. This means that you're crunching a lot of things in at the end that you could be starting a lot sooner when you're planning for them. And it also means that when you get down to crunch time, you're going to be some things that are overlooked that wouldn't have been overlooked if you've been spending more time with the development along the way. The other development challenge that we've had a lot is hearing the phrase, but now that I see it, once things are actually taking shape, if you're working on something responsive, there's no way that a wireframe or even a design can communicate the full scope of the functionality you're going to be putting into place. Even with heavy annotations, annotations can be misinterpreted, and people have assumptions that don't always necessarily connect during this time. Your designer might think that you're going to have a great-looking design on this mobile phone, a great-looking one on this tablet, and Fablet's probably going to work itself out more or less. So when they end up seeing what their responsive site looks like on a Fablet, they can be a little bit horrified. And you might have misconnections as well between your UXers and your developers about how things are actually going to be powered during this phase. So for designers, even though we were involved during kickoff, we don't really come into mid-stage of the project. And what that means is we often end up asking a lot of questions about why are things being placed in that location? Why are things supposed to function this way? So we find that we waste a lot of time just trying to play catch up. And instead of doing the real design work, we just try to gather a lot of information. Also, having to deliver a JPEG mock-up, it's really easy to misinterpret functionality because it is nothing that's fully functional. You don't really design something that's for a browser. It's really hard to be transparent about how visually, how your visual elements are supposed to work when it comes to functionality. And when it comes to responsive designs, you have, let's say, if you have a carousel design that's really elaborate on your 27-inch monitor. If you have this mesh up of two images together and you have header text, you have caption, and also a link on top of that, it doesn't really translate as well when it comes to mobile. So you spend a lot of time and effort just getting buy-ins from time members because you do have to spend a lot of time explaining what your vision is. How do you want these visuals to work? And you just have to make sure that everybody is on the same page about how your visuals are going to work. So from a UX standpoint, I often face challenges that include designing wireframes in a vacuum. I have to get my concepts down on paper, and I have to get them far enough along so a developer can understand what I'm trying to explain. And that often takes a lot of time. Not only that, I create high-fidelity wireframes. And these wireframes are pretty complicated. So I have a lot of interaction, a lot of details listed in them. So when they go to review, maybe a developer has a suggestion, say we'll have to use another module instead, I actually have to go back and update them. And that's a lot of work. So that can be a little taxing for me. As you can see, I heavily annotate wireframes. I'll add lots of, because these are paper-based wireframes, they're static and they have no interaction, I have to annotate all the interactions. So I have to say what's going to happen when you roll over one item, what happens when you click the submit button, I have to do a lot of explanation. And I take my time trying to explain all these interactions so everyone can understand them. But even with the hefty annotations, they still get misinterpreted. Sometimes Dev might misinterpret what I said wrong. And the designer will feel the same way. And it's really frustrating for all parties involved. In terms of accessibility, wireframe concepts make it difficult to identify accessible trouble spots. So we can go ahead and wireframe something else and the accessibility analyst will say, yeah, I think theoretically that's going to be accessible. This should be cool. All right, awesome.  And all of a sudden, when we're developing it, we realize it's not exactly accessible. So it's the 11th hour. We're having to find an alternative or adjust things. And that's just adding more stress to everyone. All right, so with all these UX challenges, Dev challenges, design challenges, accessibility challenges, you know, we thought maybe there's some other way that we can do this. What's something else that we can do? But first, what did we really need? We needed something easier to understand. We also needed something quicker to iterate upon. Something more realistic. Something that involves everyone earlier. So what could that be? For us, it turned out to be collaborative sketching and digital prototyping. So collaborative sketching brings everyone on board, your entire team on board earlier on in the process. And digital prototyping presents something that's easy and very realistic to understand. So we'll talk about how we got to the collaboration process and how you can implement that at your company. So first off, it's a little bit of a paradigm shift. Making the change to collaboration involves a lot of steps and here are some of them.  And you want to pick something that's small because it's less risky. When it's less risky, more people are willing to try it out. It's also manageable in size. So you don't want to bite off more than you can chew when you're trying something new. Because if all this fails, if this collaboration exercise doesn't work out, you still have some time it's quicker to recover. You also want to get buy-in from your teammates. So what I did when we tried this project out, I went to everyone on the team and said, hey, would you be up for trying out the sketching approach? I think it might help us. I think it might make things easier. And people actually were really into it. Even people who I thought weren't going to be into it were really up for trying this out. All right, so who do you want to involve? You actually want to involve everyone. That includes UXers, developers, designers, accessibility, analysts, content strategists, project managers, everyone. This way you get everyone started on the same page and you guys can get a glimpse of what everyone else does. So for example, the project manager when we tried the sketching, she was just like, wow, I've never tried wireframing. Now I kind of get why it's really challenging. And when Kat provides a solution to a really complicated problem instantly, I'm like, wow, I don't really have a programmer's brain. I can definitely appreciate her insight. All right, so you also want to set expectations when you're establishing this process. You want to tell people sketching is going to lead to a prototype. It's going to be different. There's not going to be any paper wireframes. And let's face it, wireframes are only great for UXers. This could make your life easier, maybe. You know, we're all trying something new to make improvements to our process. But since it's new, it could be a bumpy road, but that's okay. Everyone's willing to try it, so let's get pumped. All right, so how do we sketch collaboratively? There's a couple things and I'll go into the stuff that you need. When to sketch, what to sketch, how to sketch, and some pro tips on sketching and leading the discussions. So what you'll need, you'll need markers, all colors, sizes, everything, paper, eight and a half by 11 to 11 by 17 paper, lots of paper, because this is a sketching activity. Masking tape to post up the designs to a wall. Scissors, some people make mistakes and like to cut them out. Sticky notes, because some people make mistakes and like to cover them up. That's my personal choice. Snacks, so this is a new process for everyone. And in order to get them kind of relaxed, we provide food. We also provide music, because we want them to be into doing this activity and we kind of want to, you know, take away some of the apprehension that they might have. So choosing the right space. When you choose a space to do these sketching sessions, you want an open area, something that has plenty of space where you can stick up designs, and you want it free from distractions. So here we are as our conference room with a big whiteboard wall and we're all sketching together and posting our designs up. So what are you going to sketch? And this is where the UXer comes in. You take your site map and evaluate the site map. You want to look for things like main pages, like a homepage, landing page. You want to do pages with unique features and functionality, so anything that might be complicated or something that could really be really cool, like a gallery, and responsive design versions of the above. So you want to keep that in mind. You want to avoid like saying, oh, we're going to sketch this like interior page, because interior pages, you know, some basic interior pages are kind of boring. All right, so what are you going to sketch? And I like to do a three-part process. So the first part is the pre-sketch meeting. It's about 30 minutes long. I like to actually do this on a Friday and then have people have the weekend to think about it and then start sketching on the Monday. So in the pre-sketch meeting, we'll just go over some ideas and some basics about what they're to expect when they actually do the sketching. So the second part would be the actual sketching sessions. I'll start off small and have like an hour and a half to two hour sketching session, and if needed, we'll add another sketching session. Some people like to do like eight hour sketching sessions. That gets to be really long and really tiring, especially if you're trying out a new process. So you want to start small. You can always add more sketching sessions on if you need it. And lastly, after the sketching, we do a discussion session. And again, I break that up into an hour and a half to two hours long, and sometimes we might have an extra discussion session if we still need to have more discussion. All right, so the pre-sketching meeting. During this meeting, you're going to set expectations. You want to talk about what site you're sketching, the goals of the sketching, the types of pages you're going to be sketching. And also, if you're trying out this process for the first time, you want to explain to your team members what's going to happen when these sessions. So you're going to say, you know, we're doing this meeting now, we're going to do some sketching, and then after that we'll follow up with some discussion. Also, during this pre-sketch meeting, I provide background information. So that includes stuff like the site map, so they can get a lay of the land of how this site's going to work and the pages that they're sketching. I'll list the pages that they're going to sketch, but I'll also add features that should go on those pages. So I'll say keep in mind, you know, at the home page, we need to have a Twitter feed, an events feed, and a recent blog posts feed. I'll also include any user research, so like personas, scenarios, anything that can give them an idea of who the users of this site will be. And previous project work. So one of our clients is Education Pioneers, and prior to that we had done a lot of print collateral for them, and they wanted us to do their website redesign. So I took a lot of the print collateral, brought it to this meeting, and showed everyone, hey, this is kind of the look and feel that they're going for, this is the kind of tone that they're taking with their materials, so let's transfer this to the website. All right, so now we had the pre-sketched meeting, and now we're onto the sketching. So here's a picture of us sketching wildly. There's music going on, snacks to be had, lots of sketching, so we'll go ahead and sketch a couple ideas. We don't have to sketch every page indicated in the sketching session. Some people will pick two or three to sketch, some people will try to do all of them. After you make a sketch, you post it on the wall, and you might be thinking, well, if I told people what pages they need to sketch and what should be on them, aren't you going to get the same sketches? Sometimes you'll get some duplicate sketches, but sometimes you'll get other ideas. So for example, we had an upcoming meetings page and a lot of the sketched grid calendars, and then some of a sketched list view, so you do get quite a variety. So we'll do some more sketching, and it's a very iterative process, lots of back and forth, and it's pretty fun. Here are some pro tips for sketching. You want to encourage everyone to sketch. This is going to be something new to a lot of people. Some people might be intimidated because they're sitting next to UXers and they're sitting next to designers.  Creating a relaxed environment, encouraging everyone really helps. And remember that no idea is a bad one.  We can't use that sketch. You know what? You can repurpose that sketch. So maybe instead of using a video gallery, you have a photo gallery instead. And one of the biggest things for sketching is pay attention to everyone's energy level. If you've scoped out an hour and a half sketching session, but people are starting to fade after 45 minutes, maybe you cut that sketching session short and regroup again later on the afternoon or the next day. You really want everyone's engagement because this is really important to have them all on the same page and not really hating what they're doing. All right. So we're on to the discussion session and here we have everyone's designs posted. So what are we going to do with this? For to facilitate discussion, we all pick a page. So say we'll start with a home page and we'll go over idea. So it's kind of like a show and tell. Everyone will stand by their idea and say, well, I have a carousel doing this. I have a Twitter feed here. I have this functionality and we kind of explain how things are going. People can ask questions. You know, what did you mean by this? You know what happens when you click this link? After we go over all the discussion of all the ideas, we'll pick one sketch. Maybe one sketch isn't perfect. So we'll end up taking parts of some and we'll kind of put together the best of to make something really cool. It's a little Frankensteining and that might make people, some people nervous. But that's where the UXer comes in. So the UXer should really use your UX skills. You want to make sure that all the ideas are being properly vetted, that they're using good UX practices and that they're presenting a comprehensive functionality. And also it's really important that someone take notes. There's a lot of discussion that goes on, a lot of ideas that get yade and a lot of ideas that get made very instantaneously and change directions very quickly. So it's really important that you have someone taking notes to figure out what the final determinations were. Some pro tips for discussion. So UXer and project manager use your facilitation skills. This is a great way to practice facilitating group discussions. And it's also really important to make sure that everyone is heard. This is a collaborative event. You definitely want to make sure everyone is heard so they can get more buy-in and more say with what's going on. And this is probably the biggest part of discussion is vet the ideas with your teammates. So we're all in the room together. We are all sharing ideas and so rather than you know walking over to my desk like in a traditional method of having to wait and pass emails back and forth I can ask my developer right then and there hey can we do this in the timeframe and they can say yes or no the accessibility person can flag it saying I think we're going to have to adapt it for better accessibility. All the experts are in the room right there. They have a say and we can navigate the challenges very early. So what's next after we've discussed stuff it's your turn to have the UX designer. Take those idea and what I'll usually do is create lo-fi reference sketches for the developer. So this usually means I'll take you know whatever the sketches are maybe take some post-it notes and annotate what we finally decided or if I feel that it's easier I'll take make really low low fidelity omni-graffle sketches and just make annotations for the developer. So the developer was already in the sketching session so they pretty much know what to prototype but this is a good final reference checklist. This isn't actual client deliverable it's just an internal resource. And then I'll take those sketches and then I'll work in tandem with the developer to begin building the prototype. So as you're hearing about this you might be wondering whether we never wireframe. That isn't the case. Wireframes are a communication tool and when used properly they're a good way to get sign off and a good way to spell out what's required for different ideas. If we're going to be prototyping if we're going to be doing the UX for a mobile app that's going to have a lot of functionality that would be extremely difficult to quickly prototype we'll put together a wireframe for that functionality. We have a very contentious homepage that we know is going to go through a lot of changes but the point when the client sees it and would rather go ahead and block out the major elements on paper we can do that. What we do try to stay away from is creating a lot of wireframes for different sections of the site that would be much faster to prototype with proper site building. Ultimately wireframes are a quick and dirty communication tool that are going to give you a lot of connection with your client if you do show it to them but they don't think out everything and you need to make sure that when you're building out an interactive site you're paying attention to the medium you're going to wind up working with. I really liked this quote from a Brad Frost recently about the static artifacts kind of clouding the fact that you're ultimately designing for a real website. When you hover over that dropdown something's going to happen. When you click that photo it's going to get bigger. When you play a video it's going to respond and that's not going to happen on your wireframes unless you are crazy good at wireframing. So ultimately we want to get people into the browser as soon as possible and have these connections start getting made in an interactive way. Some people like HTML prototypes. There was a point when we worked on these we were attracted to them because they're quick to build. Once you start putting content on the page you add in your HTML elements add classes style those classes add in some JavaScript functionality. It's not instantaneous but it is pretty quick and pretty efficient initially. The problem is that they're not underpinned with any sort of content management. So when you need to go in and make changes based on your usability testing or based on internal review it's pretty painful to change 30 different pages than a prototype especially when the way that you're changing things is changing across all of them at once. If you're linking to an event and you're initially not providing a description when you do your event linkages and then you realize you really should it's going to take you a while to go back and add that everywhere an event is featured. And that additional time you're going to be spending is extremely frustrating because you know that at the end of the day you're building something throw away. You're not going to be reusing this code in a meaningful way in your final product because while you might have some semantic elements and classes that you can move forward in the process your designer's probably going to change a lot of things during the design phase and you might end up doing a lot of recoding anyway. By contrast if you are making a Drupal prototype it's going to be slower to build up front. You're going to sync a lot of time into site building but you're also going to find that now it's being underpinned by a real content management system. So when you need to change something you can do it quickly. If you need to reorder the blocks on all the pages that are news release template at once you can just do that. If you need to go ahead and change how your views work by adjusting a view mode you can change it once and have it update everywhere it's being used in your prototype. As you might imagine you're going to be syncing a lot of time into this so it's a good thing that it is laying the groundwork for your site. You're going to keep using it as you move through the process and when you finish the UX phase you're not just going to have a prototype or a wireframe you're going to have the beginnings of your site built. This is great because it means that as you move forward you can start immediately doing content migration. You can immediately work on some backend functionality you might need to build a custom module for. You're not emerging from it with an idea you're emerging from it with groundwork. The last time we did an HTML prototype was for the Federal Trade Commission Center the Federal Trade Commission site that we launched in December. This was a pretty comprehensive HTML prototype that had about 30 pages in it. As you can see here it's got a lot of dynamic content being pulled in this is the news and events page show it shows the news and further below some of the events and they're also featured in the right sidebar the very important upcoming events. You also have a content being pulled in in the drop down and featured throughout other places of the site. So if you're using your news releases and your events elsewhere then you're going to need to be updating that. We have topic pages that also reference these and every time that you load in a news release or add a new news release to your prototype you have to make sure that it's getting added to the relevant pages. We did build this out we had a successful usability testing phase and we went back and made modifications it's fairly time consuming. The lesson we took away from this process was that doing these prototypes in the content management system you're going to ultimately be building them in gives you a lot of time and efficiency that you're saving. For the commission of fine arts which we're going to be talking about a little bit later we built out a fully functional prototype all the content types taxonomies and views and masonry photo gallery and some map functionality in about two days and put that in front of the client with great results. They were thrilled with it and we were able to let them navigate through the prototype and the pages of content that we've loaded in a fairly organic realistic way. So at the point when they signed off they had a really great sense of how their site was going to work not just what it was going to look like. Another great thing we found as we're implementing this is that you're going to end up seeing your timelines look a lot different. Unlike the original timeline we showed where you have your development kind of happening at the end this way you have your development spread out through the process and collaboration points throughout that. So during the prototype phase you're collaborating heavily with your UXer and your designer and everyone else on your team and you're doing your site building your module installation and a little bit of migration so that you can support these content types and make sure that they make sense. This lays the groundwork for you to do a much heavier migration phase during the design part of the timeline so as your designer is working on tweaking the final look and feel of it you're making sure that you actually have the functionality built out and that it's working really well. It gives you a lot more opportunities for testing. Then when you get to your development phase which as you can see is now a little bit shorter you can handle your theming and your module development anything else that you need to do and you have more time for testing and QA. There's a warning that goes along with this though because you are not throwing away this product when you're done it gives you a tremendous amount of responsibility to get rid of the things you don't need. So when you're prototyping and you're saying I think the piece of content I think this content type would work really well if it had an event association then you realize later that if you put the association on the event content type and point it to the news release it's going to work better you owe it to yourself to go back and remove what didn't work out. You also need to make sure that if you installed several different modules that do the same thing you turn them off and uninstall them when you're done. This means that you'll end up having a better product and you're doing the same kind of curation that you would be doing on your final site because this is going to become your final site. As we're creating digital prototypes just like creating a Drupal site it's going to fall into a handful of buckets with one notable exception. We have front-end tasks site building tasks and content migration tasks but not back-end tasks during this time because we don't want to be sinking time into doing a lot of custom module development during this phase. The intent is still to have a fairly quick touch point for your client to take a look at not to have your entire site complete during this point. Your front-end tasks should be fairly minimal. You'll go ahead and install a prototype theme. You don't want to be doing too much customization to it because your designer is then going to have all kinds of changes and we usually tend to install a bootstrap something like that that we're not going to put in our final build but it quickly gives us a professional look and feel to show the client and make sure that they're going to be pleased with what they're seeing as opposed to turning on bordering all the boxes in zen. During this you want to consider your source order and your positioning making sure that you understand how your sidebars are going to degrade during the design phase and giving your designer some structure to work with. This is a heavily collaborative effort between the developer, the UXer, and the designer because it's pretty major decision point whether your sidebar is going to end up rolling down beneath your content whether your menu is going to roll up above your content you want to start answering some of these questions now and you're going to sink some time into adjusting the mobile experience as needed. So if you're using a prototype theme that doesn't really handle your mobile menu very well this is a good time to make sure that you tweak that before the client sees it so that you can give that organic experience of resizing the browser and having them understand roughly how it's going to end up working. Your site building tasks are slightly more intense. The first is that you need to build out the site map in your menu structure. Doing these menus is going to be a lot faster if you use a module that will allow you to place content within the menu without actually migrating that content up front. I like the module's special menu items because it allows you to put non-linked items in your menu and then clearly know you need to go back and load that in later. You'll set up your content types your taxonomies and your views during this and make sure that you're setting up those fields on the content types in a way that you can live with later. So this is where you're going to add a lot of functionality that's going to get reused and you can see it taking shape in front of you. We came out of our last prototyping effort with nine content types 10 views and five taxonomies built out fully so that we could continue iterating on them during the rest of our effort. We like to make persistent block associations whenever possible so that as you're doing the site building that's going to make different blocks appear on say your news releases. When you change themes later those associations are going to stick around. I like context for this personally because if you're going to place them with the core Drupal functionality as soon as you switch your theme all your block associations are going to go away. You'll set up your aliases and breadcrumbs during this so that you can see where your content is going to end up living and how people are going to navigate between it. So if you have your news events path set up so that it's just content slash title that's not really useful for anyone and it doesn't reflect how people are going to navigate in your site. Spending the time to set that up and make sure your breadcrumbs are functional here it's going to give a great authentic experience of how people are going to interact with it long term and it's going to force you to address any logic errors you've made if you said that your news releases were going to have a path that put them under about but you forgot to stick them there this is where you're going to be able to catch that very easily. And of course you'll install modules to provide more complex functionality. Some modules are very basic and they're always going to be on your site like views. Others are going to be added to prop up some of the functionality that you might be building out even further later. For example in one version of the site we had a calendar that we knew we were going to end up doing a bunch of custom work with to leverage the calendar a library but we just put in the generic views calendar for our prototype because there was really no need to get to that level in our prototype it was something we could iterate on later with the client as we got them introduced into it. During this phase I do tend to use the occasional alpha or beta module so long as I'm flagging it for later and we know very clearly when it's going to be removed and are keeping some way to track that so you don't have direct winding up in your final product. This is a screenshot from the prototype we're doing for the federal trade commission site you'll notice it is not black and white like a wireframe because we're building inside the theme for the main FTC.gov that we'd already done. What this does is add in the main elements that are going to be in the final product it's extremely functional we went ahead and imported content before we did just about anything else and this helped us catch some logic problems really early in the process so under here you see you might also like along with a short description that was in the content we originally provided and I talked to to the UXer a lot about this because having related content appear here is no small feat and I initially got the response that it was going to work based on taxonomy so we looked at the taxonomy to see if it was going to support some relevant associations here because there was a fairly a fairly large taxonomy and a fairly small number of publications we ended up seeing a lot of reuse of that taxonomy so that what would have appeared here if we just said show things tagged with the same items it wouldn't have really been coherent and it wouldn't have populated the right content onto the page so we took this back to the client asked them how they would like to have this function and it turned out they actually wanted complete fine-tuned control over this so instead we have a node reference that points to what publications are associated with this publication this is something that we wouldn't have found out if we'd just been looking at a wireframe we were confronted with it early and we were able to work with the client to make sure that they knew how they were going to be putting content in here and that if they wanted to set it up like this they needed to provide that information things like this only work really well if you're looking at real content so the most important thing we do during our prototype arguably is to migrate content all the content we put in many pieces of content for each content type and if we have access to a database we can simply import we go ahead and do that to the extent that we can with scripts or with feeds occasionally so this is going to make it so that when you're looking at this product you have a very realistic idea of what your client's content is going to look like when it goes into your prototype now inevitably you are going to end up putting in some Laura Mipsum as you're building this out I we try to avoid this really really hard but if you are knowing that you're going to put in some test content I like to add a Boolean checkbox value to the content type just for test content so that I can check that off and then go back and remove it all later that way you have it tracked and you don't run the risk of having it wind up there when you really weren't intending for it to happen so we'll talk about some of the success stories we've had with this approach probably one of the bigger ones was the Federal Trade Commission site this is the original site that they did the prototype we put together and as I mentioned this one was an HTML prototype and the final site that we ended up with and the reason we're talking about this even though it had an HTML prototype when really what we're advocating is the Drupal prototype is that the reason this effort was successful is that we did a ton of Drupal prototyping along the way we did our initial 30 wireframes but at the time when this site launched it had about 60,000 nodes of content and many different landing pages all a lot of them with unique searching and filtering functionality we'd rolled in some external databases that really expanded and were tweaked to take advantage of the new Drupal content management system this was challenging because with that much variation happening in the site the fact that we had so many content stakeholders became kind of an issue there are many people who were subject matter experts in the FTC content within the FTC and all of them had thoughts about how their content should look so rather than trying to make assumptions based on the wireframes that weren't complete for the sections that we were showing we worked with them to prototype in Drupal present it explain how it would be maintained and what kind of features we built in to make management a little bit easier for them and have them come away with it with a good understanding of how the site was going to work in a lot of cases we showed this to them and found that there were certain distinctions between pieces of content that we wouldn't have come up with organically and that we needed to tell them we need to work with them to find out how they would be pulled out in the content in the final product this has been a really successful engagement for us and as we've moved on to doing additional sites for the FTC like the commerce site that we're rolling into their site now we've relied increasingly on prototyping wireframing out complex pages like the home page or things that would be very difficult to prototype quickly like a modified checkout process but leaving prototyping to do the rest like the faceted filtering for the publications the publication view itself and the language switching between these all right so for one of my projects I worked on education pioneers which is a non-profit placement organization that has a fellowship and partnerships that they pair potential fellows with we originally had a nine-month timeline which already seemed pretty compressed but then that got squeezed even more narrow into a six-month timeframe so that's how this digital prototype really helped us it helped us get further faster we quickly sketched some ideas and then threw that into a prototype which laid the groundwork for the actual site another benefit of this was to demonstrate our client to our client that there was a lot of cross-referencing from pages to pages so you know city pages would show up their fellow display their fellows and upcoming events related to that and they had a hard time understanding that that's how the approach we were going to take with the site but once they saw the prototype they got it oh I see you know these events that are related to the Bay Area are going to show up on only on this page yes and only the people that went to the Bay Area are going to show up on the page so it really helped them understand how their content was going to be used throughout their site so another example that we did digital prototyping for was for U.S. Commission of Fine Arts this is actually their current site and as you could see it's very static so we thought having a digital prototype would really help them kind of transitioning towards the more dynamic content and kind of reel them in during the transition process so this was the digital prototype that we have internally we made sure that we strip off any visual elements that say we make sure everything is very gray there is no color elements and even for fonts we make sure everything is very basic we don't want any elements that the client will kind of get hung up upon even for little things like the logos we did not want them to kind of focus on that and we really want them to make sure that all the structure on the homepage is clear to them so with this we also have an upfront discussion internally that there is nothing that designers can't change we could still move around the positioning and having all this structure established upfront we were able to kind of push the design to the next level so we had to actually present three different designs this was one of them so we were still able to push it and we kind of curate more on the user experience what could we do to kind of push their side to the next level so we come up with three different with the carousel where we have a little bit of the next and previous slide and we where users could have that bigger experience of what the agency is really about the next design is really different instead of having the bigger image we have a set of thumbnails and it's very open and minimalist in the next one we actually tie in all the content with a bigger image bigger visual component and we were able to bring three different design solutions that wasn't at all tied in to the prototype and that was great so the benefits of collaborating, sketching and digital prototype is one you were able to navigate challenges early since we no longer work in our own little corners we're actually able to talk to each other more openly we could we don't wait till issues to come up during 11th hour we could tell them oh what happened if we want to do this FAQ when there is no content all those issues actually come up front and we could iterate more quickly on the design concept we no longer have to come up with a new design component on a layout since all of those little things were established we could actually focus more on the UI elements and if you're doing your prototype interval you could actually reuse your work since you already have your views content types modules and even general configuration all of that actually took place early on and will save a lot of time for your theming and you could actually content migrate your content early on so having a fully function prototype easily demonstrate your responsive behavior so let's say we have an event or a table you could easily see what things would collapse ahead of time as it was waiting later on so you could use your functional prototype to get buy-in from your team because you have actually collaborate and talk to them about it faster and get what it's going on and you could get buy-in from your client since they understand what's going on they understand what's the functionality is so they could actually give their approval in a timely manner and you could do usability testing upfront all right so we have some key takeaways from this presentation that we would like you for to remember the first is smart start with a small project first it's easier to manage and if all this fails you can recover from it quickly keep communication open so this is a collaborative process this is going to be a little bit different than a traditional siloed process you're going to be talking a lot more so make sure that you're keeping those communication lines open that might mean that might mean working sessions with a developer if you're a UXer or a design you know working session with a UXer or we all just get together and hash out more stuff after we've done the wire framing when we iterate upon the prototype this is also a great way to establish collaboration as a company culture so you have new staff bring them into sketching sessions we've done this with a couple new people they have you know they weren't UXers we had them you know come in and wire frame with us they had no idea about UX and they loved it and it's just a great way to prepare them for when it's their turn to sketch that they're ready for it and the biggest thing is that you need to remember that this is a process and to be adaptable so when we first tried this out we started small I actually didn't give anyone any background information I was worried that it was going to give them tunnel vision as to what they were going to create and then after that I realized that you know people were hesitant to sketch because they were like I don't really know what's going on I want to make sure I'm doing this right so I provide a lot of background information so every time we've done the sketching process we've taken lessons learn and applied that to our next sketching session and being adaptable really helps so part of being collaborative is being adaptable and that could be anything from a small as you know someone doesn't want to sketch with marker they want to use pencil instead you know that's cool but it also could be something bigger that the timeline shifts you know for example you might need an extra sketching session or maybe an extra discussion session so being adaptable is really important in order to make this work the more adaptable you are the more this process is going to work for your company and that wraps it up if you guys have any questions feel free to ask you can come up to the microphone and ask do you yeah okay have you ever involved your clients in the sketching discussions so far we haven't and part of it it's we want to make sure that we know what we're doing ourselves and sometimes a lot of clients start to dictate things and as we started this process everyone's still getting comfortable with themselves to end up discussing the minute you bring a client in everyone's demeanor changes thank you so I had a question on the whole sketching process you're involving everyone on the team for a particular project when you get together to sketch is that right yes so we'll have we have a cross-functional team so it's usually a front-end designer or a front-end developer back-end a designer maybe two designers a UXer depending on how big the project is but basically whole the entire team like content strategist everyone even like project manager yes okay so you know presumably one of you has more experience or expertise in the whole idea of of UX and I was just curious what if you how it benefits your team to have everyone producing sketches versus maybe just one person doing sketches and then maybe asking the team for some feedback well so that's a really good question you know this is a great way for us to get to know a little bit about how we all do our jobs so for example you know I'm not a developer so I'm not up on all the latest modules but Kat is so when she's sketching she might sketch in a module that she's just heard about that she thinks is going to be really great for the site or Ika who's a designer knows some design tips that I don't really know so we'll go ahead and collaborate all those ideas so even though like they're not UXers by heart they do know a lot of information and they're great resources and they bring a lot of ideas to the table this is a follow-up to that first question can you talk a little bit more about at what points in this process you're showing things to the client and at what point they review it and sign off for example do you I know you don't bring the client into the sketching process but do you show them the sketches at all? so it varies based on our relationship with the client some clients want to see something a little bit more formal so we might hold off until we see the prototype at times if we're producing some lo-fi reference wireframes as a result of this we'll certainly show them at that point but the main thing we're trying to get at is what the goals of the client are and how we're going to serve that by showing it to them so if we're demonstrating a lot of interactivity then we're probably going to wait until the prototype so that we can show them really how it's going to work but if it's more informal and we're trying to say we think it would be a great idea for you to pull some of this content up and surface it on your home page or on these other pages then showing them a sketch gets them on that page faster it's not formalized in terms of when we're going to show them things but it's usually at the prototype phase always and often a couple of reference documents before that when needed and can you also say a little bit about usability testing and where that fits in so our usability testing process tends to come in when we have a functional prototype we don't usability test our sketches but we do try to usability test when the contract calls for it with the prototype as much as we can and that's dictated by the contract that we have so we've had a lot of success with walking people through that in the same way that they would interact with the site it lets you get a lot of that data much sooner than you ordinarily would and in a more meaningful way than when you're using like a clickable PDF great thank you do you have any ideas on how you would handle the sketching process with a fully remote team I would imagine that would be challenging we don't we haven't had to implement that with a fully remote team because we are working in the office with the exception of some backend developers so the sketching has been in person I imagine you could do something like like screen sharing to put that together and work in something prototyping tool there are quite a few out there but since we're trying to keep things more informal it's not a challenge we've had to tackle yet thank you so with these projects are they project based or are they hourly how do you have you noticed like a change that going over budget because you have such a collaborative team how does that work so we actually we have a mix sometimes they're hourly and sometimes they're project based but what we found that anyone wants to contribute what we've found on that is primarily that we're front loading a lot of the work we would have been doing anyway so while we are having a lot of these discussion sessions as you can see a lot of that time is time that we would have spent getting people up to speed later in the project anyway so we have people in the room who are contributing and kind of for stalling problems that would have been spent afterward our accessibility analysts for example get to contribute early and say you're going to want to watch out for this as opposed to doing an extensive review later and finding a lot of problems they need to document and then work with us to fix so our idea is that we're not creating additional work we're front loading work that would have been done in the later stages anyway I've worked on a lot of projects where there's a lot of similarities do you guys find yourselves using some things over and over again from project to project and kind of recycling things how do you work between keeping things silent from project to project or being more efficient and saying hey we use this in the past and it's a good solution and we're going to use it again I think that's actually helped by having more people in the room when you're doing this because what we're bringing to it is the knowledge of the solutions that we've used in the past we know for example we've gotten really experienced with maps and calendars lately so we're not going to re-imagining how they work every time when we do need to use a calendar a map we tend to use previous projects as reference points when we comes down to actually blocking that out but pulling in different layout elements we're trying not to be constrained as much by what we've done previously and be open to new ideas while relying on previous solutions when they've been time tested and shown to work well Do you package any of that into like a feature that you could then transport from side to side? We have not been packaging any of it into a feature at this point we do have sometimes we'll produce modules during the process of working on previous sites so we might take a module we produced and plug it in to move forward but we don't tend to use features to create new content types for example or to pass views from site to site because generally speaking these things have been pretty unique to the project it would be hard for us to apply for example something we came up with for the FTC Drupal prototyping process to the commission of fine arts because it's wildly different contents and different goals Thanks Quick question on Let me try that again Quick question on migration What happens in situations where you don't have say you're moving from unstructured information to structured where you can't actually migrate it or there's been a strategic change in direction of what they want and so the content they had before really isn't relevant So that's always it's always painful on any project when you're going to be making a big migrations shift like that what we found is that doing this has actually made it easier for us to communicate with our clients when we especially when we have a large migration effort but their content isn't going to map one to one because it allows us to see what we're going to need to do in order to get the migrate to get the content in the site and it also we get to work with them on how they're going to be working in a new content management system as opposed to in a static site so for the prototype purposes we're only moving over a few pieces of content for each content type so copying and pasting and mapping it to fields is not really that terribly painful a process although it's of course easier if you have a some sort of structured data you can pull from but having these conversations during this prototype phase as opposed to assuming yeah it's all going to come in and it's going to be fine we're just going to script it is makes things a lot easier later because you're realizing how much of a change your content is going to have to go through in order to make it in when they're writing content from scratch it's really pays to have your client understand what it is that they need to provide for you at this point and how their content is going to change and if you have a content strategy phase on your project which hopefully you do your content strategies is a huge huge resource during this time yeah thanks so the biggest prototyping tool that we've been using lately is a Drupal I don't know sorry that's a terrible answer what we've been using is mostly just laying setting up the site building the way that we're going to want it to function ultimately on the site I know we've used some other prototyping tools in the past but we've found that they haven't communicated the interaction on the back end as much as we've wanted we haven't been able to create those dynamic relationships and ultimately we are not huge fans of creating throwaway projects so I'm sorry okay the question was what about wire framing tools Michelle you want to take that one sure so I've been just using the sketches as what we keep as a record and then I'll annotate with post in it so I don't actually use software sometimes if things are more complicated we'll use Omnigraphl I found that's been really helpful they've got a whole nice stencil pack so that's primarily what we use but we try to throw things into the prototype into like a Drupal prototype as soon as possible one one quick note on that there was a session yesterday if you're really interested in prototyping in wire framing tools it was wire framing smarter and he had a lot of hey there's my login screen he had a lot of great suggestions for tools that you can use I think the video of that is online now if you want to check it out okay so the question is what modules we use to help in the prototyping process go to the microphone Lauren and we've been using a lot of different modules that have helped out with that as I mentioned special menu items has been helpful for building out the menu really quickly we use views obviously I really prefer context for block associations because it makes things more straightforward and I we spend actually a lot of time importing content with feeds when we need to rather than if scripting it isn't a graceful option any other questions okay thanks so much


Okay, in the previous tutorial, we made this little application here using jQuery mobile. Obviously, you can throw this up on a website or put the files locally, open them up in a web browser on pretty much any computer device regardless of operating system as long as they have a modern browser. So Android, iPhone, Windows, Linux, macOS, BSD, probably even ReactOS. So basically, it's just this list that we can search through real quick. Every basic little web application. Now we're going to package it as a standalone application so that if you didn't want to run it on your server, you could package it all in a package and distribute it on different operating systems. We're going to be using Python with GTK and WebKit today. So basically, this will run on any desktop, Windows, Mac, Linux, BSD, so on and so forth because Python being open source, GTK being open source, and WebKit being open source, they have been compiled for all these different operating systems. So basically once you basically wrap your HTML and JavaScript inside your WebKit in Python, you're good to go. You just have to make sure that each year you make an installer that will install the required packages. Once this is easy, you can make a DEB package, RPM package, or you can make a standalone little self-extracting zip. Windows is a little bit harder because it doesn't have a package manager that will install dependencies for you, so you definitely would have to create an installer that either downloads and gets those things or package them into your entire package. But basically right now I'm just going to show you the basic Python, GTK, WebKit code. It's very short. You do this and now you have written a standalone application with your HTML, JavaScript, jQuery as a desktop application. Hope that makes sense. If not, you'll see here in a moment. So as I always say, you write a program once you write it once properly, with very little to no change. You should run on pretty much all operating systems. And HTML is great for GUI interfaces because pretty much every computer has an interpreter, your web browser installed. So let's go ahead, minimize that. So list out, if you watched the previous tutorial, if you haven't, I would definitely start at the beginning of this series. There should be an annotation on the screen hopefully that will lead you to the playlist. At the end of the last tutorial, we downloaded our CSS files and JavaScript files locally. Once again, you can connect to those online if your application is going to have web access. But if not, package them in here, just put them into your file here. And we can even at this point remove our zip file here because we don't need to distribute that because it's all extracted already. So remove that. Now I'm just going to say, I'm going to use Vim as my text editor, and I'm going to create a package or a script. I'll call it MyListView.py. And we are going to start, as always, with our shebang line. So this isn't important on Windows, but it's a little more important on other operating systems, just letting our operating system know what interpreter to use. So we're going to say Pound, exclamation mark, forward slash, USR, bin, and then ENV for environment. We're going to say Python. That's just telling the operating system this is a Python script. Next we're going to import WebKit and GTK. We're actually going to import something else here in a minute, depending on how we're going to package this. You may or may not need the other module. Next we're just going to create a window object. So we're going to say, I'll call it Win. Again, that's your object name. You can call that pretty much whatever you want. But we're going to call our GTK module, which we imported up here. And we're going to say this Win object is going to be a window. So it's a GTK window. Next we'll say Win.Connect. And we'll say here, we'll give it the string destroy.  Otherwise, the window will close, but our script will keep running. And since we're only running one window script here, we want it to kill the script when we close the window. So Lombada, W colon, and then GTK.main underscore quit. And that's because we're going to run the GTK main at the end of this script. And this is just saying to kill it. In fact, let's just go ahead and do that GTK.main and that's starting all up. Nothing is visible yet though. So at this point, let's create our WebKit window. We'll create a WebObject WebKit. And definitely watch my GTK tutorial series. I go more into detail on all this. I'm trying to explain it as I go, but I've already gone over this in previous tutorials. So we'll be going through it pretty quick. But we're creating an object. We're going to call the object web. We're going to call our WebKit module, which we imported up here. And we're calling for it. We're going to say, let's make a WebView. This is going to be our viewer for our HTML code. Now at this point, I'm just going to give you an example. I'm going to say web.open. And then inside here, I'm just going to say HTTP, whoops, TTP colon four slash forward slash filmsbychris.com. To show you, you can host all these files on your website. And in many cases, I think that's a better option, because now you can modify and update your program anytime you want. And the user doesn't have to worry about their phone or desktop application, in this case, updating, because you make the changes on your website. Next time they open up the application, it's got the updates. So I'm going to show you this, but then I'm going to show you how to run the local program that you would package with this script. So open that, and then we're going to say win.add, and we're going to say our WebObject. And then we're going to say win.show underscore all. And now it's just saying, show the window and everything inside the window, because we don't have any hidden elements in this script. So it's okay to do that. If I didn't miss anything, we should get a basic window right now. So I will save that. I will use changemod plus x, myListView, the name of our script, to make it executable. And I'm going to say myListView for .slash myListView.py. And when I hit Enter, you can see we get this window here. And it's resizing, because it loaded up my website. And it's kind of funky size now, because we didn't give it any size parameters. But this is my website running inside our Python script here. And little JavaScript of me walking across the screen there. So you'll also notice, we'll get to this in a second, that it goes off the bottom of the screen. We didn't give it a window size, and we didn't give it a scroll bar. So those are things we're going to add here in a moment. But first, let's instead of running the application on the website, we'll run it locally. So I will close that. You notice I hit the X, it kills the entire application, because we did our Lombada on the destroy of the window. I'll go back into my text editor here, and we'll change some things up. First off, let's go ahead and give it a scroll bar. Actually, no, let's give it a window size first. So by default, if you don't give it a window size, the window is going to be kind of small and long, depending on your application. But it's going to be like the minimum size in some cases, very, very small. So let's give it a default size. We'll say our window object, our win object, we'll say resize, and we'll give it a size. I'll just say 600, 800. There's other options you can do to lock it in at that size if you don't want your application to change sizes. This particular application, I don't care. I just want to have a default size at the beginning here. Also as I said, it's a long application, so it like resized right away to fit the length of our HTML. If we have a long list as we do in this program, we'll run off the bottom of the screen and people can't scroll because there's no scroll bar. So here we'll say scroller, which is just an object we're creating. We're going to call it scroller. You can call it whatever you want within reason. And then we're going to call our GTK module and say we're going to make a scrolled window object. Okay. Now, we're going to say win.add, so we're taking our window object and we're adding to it our scroller object that we just created. Okay. But a window is a container that can only contain one object at a time. You need to put other containers within it, which the scroller object is. So down here we say win.addWeb. It's going to give you an error there because the windows already containing an object. So instead of adding our web object to the window, we're going to add it to our scroller. Okay. Now, also here, as you saw, we're connecting to a host file online, which is something you can do if you want to run your application off your server, which, depending on what you're doing, once again, may or may not be what you want to do. So instead of that, what I'm going to do here is I'm going to say file. My particular HTML code in here is under forward slash temp, forward slash list, forward slash index.html. So now if we save all this, and if I typed everything right, or we made the script executable, we don't have to do that again, dot slash, name of our script. And here we go. We got our application running locally. I can scroll and I can search through the list. And if I had them do anything, I could click on them. So far, that's what we've got. But you'll notice I had to put in a definite link to where the HTML file is. Let's do a little bit better. And instead, let's go ahead and tell it that we want to run the index from our local directory, our current directory. So to do that, we're going to import another module, the OS module, which is the operating system module. And I am going to put here, whoops, I'm going to say I'm going to create a little holder variable. I'm going to say path equals from our OS module dot get cwd, which will get our current working directory and put it into the path. So basically path is a string variable now. And what I'm going to do here is I'm going to say that it's a file, a local file. Then I'm going to say use the path variable we just created. And inside that path, look for the index.html. We're going to save that. We're going to run that. And you can see that's the same thing. So now, regardless of what folder we install our application to, it will always find that HTML file. So as long as they're all in the folder together, it will always find it. And you can install it anywhere on your system that you want. That's pretty much it for this tutorial. And once again, this is written in Python. So once you've created this wrapper, the short little script, which is, as I said, pretty short. It's, even with all the spaces in there, 22 lines. It's probably actually maybe 10 to 15 lines of code. Once you have that set up, you can now install this and have it run on Windows, Mac, or Linux. Because Python and GTK and WebKit run on all those operating systems already. I thank you for this tutorial. I hope you continue this series. Next, we're going to do the same thing, but with C++. And we'll probably do it with QT and WebKit rather than GTK and WebKit. So I hope you continue watching this series in packaging, web applications as standalone applications on multiple devices and computers. So please visit my site, filmsbychrist.com. There should be a link in the description. That's Chris with a K. And I hope that you have a great day.


You know, I'm finding it easier to be a human these days than to be a Christian. Human, we just kind of do whatever we want to do and whatever comes naturally whatever we think and whatever feels right. But to be a Christian is to have spiritual formation and discipline and to be changed by community and I just find it easier to do the other thing. But I want to be a new kind of human. I want to be spiritually formed by the spirit and by community.


Sites can use the Speculation Rules API to programmatically tell Chrome which pages to pre-render, creating a better user experience by reducing page navigation time. Now the API includes support for document rules. This is an extension to the Speculation Rules syntax that lets the browser obtain the list of URLs for speculative loading from elements in a page. Document rules may include criteria for which of these links can be used. This, coupled with a new ignorance field, allows you to automatically pre-fetch or pre-render links on pages immediately, on hover, or on mouse down. A separate change allows specifying speculation rules using the Speculation Rules HTTP response header. The header is an alternative to using inline script elements.


Hello and welcome to the session on Process Migration in Distributed Computing Environment. At the end of this session, students will be able to uniquely identify process migration in distributed computing environment. In a conventional centralized operating system, process management deals with mechanisms and policies for sharing the processor of the system among all processes. However, in a distributed operating system, the main goal of process management is to make the best possible use of processing resources of the entire system by sharing them among all processes. Three important concepts are used in distributed operating system to achieve this goal are processor allocation deals with the processes of deciding which process should be assigned to which processor. Process migration deals with the moment of a process from its current location to the processor to which it has been assigned. Threads deals with the fine-grained parallelism for better utilization of the processing capability of the system. Process migration is the relocation of a process from its current location like source destination to another node, the destination node. The flow of execution of a migration process is shown here. A process may be migrated either before it starts executing on its source node or during the course of its execution. The former is known as non-preemptive process migration and the latter is known as active process migration. Preemptive process migration is costlier than the non-preemptive process migration. Since the process environment must also accompany the process to its new node for an already existing process. Process migration involves the major steps. Selection of the process should be migrated. Second, the selection of the destination node to which the selected process should be migrated. Actual transfer of selected process to the destination node. A good process migration mechanism must possesses transparency, minimal interferences, minimal residue dependencies, efficiency, robustness and communication between co-processors. First, the transparency. The transparency is an important requirement for a system that supports process migration. The levels of transparencies can be identified here are object access level. Transparency at this object access level is the minimum requirement for a system to support non-preemptive process migration facility. If a system supports transparency at the object access level to access objects such as files and devices can be done in a location independent manner. Thus, the object access layer transparency allows free initiation of programs at an arbitrary node. To support transparency at object access, the system must provide a mechanism for transparent object naming and locating. Second, system call and inter-process communication level. A migrated process does not continue to depend upon its originating node after being migrated. It is necessary that all system calls including inter-process communication are location independent. Thus, transparency at this level must be provided in a system that is to support preemptive process migration facility. However, system calls to request the physical properties of a node need not be located independent. Transparency of inter-process communication is also desired for the transparent redirection of messages during the transient state of the process. Minimal interference. A migration of a process should cause minimal interference to the progress of the process involved and to the system as a whole. One method to achieve this by minimizing the freezing time of the process being migrated. Freezing time is defined as the time period for which the execution of the process is stopped for transferring its information to the destination node. Minimal residual dependencies. No residual dependency should be left on the previous node. That is, a migrated process should not in any way to continue to depend on its previous node once it has started executing on its new node. Otherwise, the following will occur. The migrated process continues to impose a load on its previous node, thus diminishing some of the benefits of migrating the process. A failure reboot of the previous node will cause the process to fail. Efficiency is another major issue in implementing process migration. The main source of inefficiency involved with the process migration are as follows. The time required for migrating a process. The cost of locating an object includes the migration process. The cost of supporting the remote execution once the process is migrated. All these costs be kept for minimum as far as practicable. Robustness. The process migration mechanism must also be robust in the sense that the failure of a node other than the one on which process is currently running should not in any way affect the accessibility for the execution of that process. Communication between co-processes of a job. One further exploitation of process migration is the parallel processing among the processes of a single job distributed over several nodes. Moreover, if this facility is supported to reduce communication costs, it is also necessary that these co-processes be able to directly communicate with each other irrespective of their location. Pause the video, think and answer. The logical extension of a computation migration is process migration. Migration of a process is complex activity that involves proper handling of several sub activities in order to meet the requirements of a good process migration mechanism. The four major sub activities involved in process migrations are freezing the process on its source node and restarting it on its destination node. Transferring the process address space from its source destination to its destination node. Forwarding messages made for the migrant process handling communication between co-operating processes that have been separated as a result of process migration. In preemptive process migration process is to take a snapshot of the processes state on its source node and reinstate the snapshot on the destination node. For this, at some point during the migration, the process is frozen on its source node. Its state information is transferred on its destination node using this state information. By freezing the process, it means that the execution of the process is suspended and all external interactions with the process are deferred. Although the freezing and restart operations differ from system to system, some general issues involved in these operations are as follows. Immediate and delayed blocking of the process. Before a process can be frozen, its execution must be blocked. Depending upon the process's current state, it may be blocked immediately or immediately or the blocking may have to be delayed until the process reaches a state when it can be blocked. Some typical cases are if the process is not executing a system call, it can be immediately blocked for further execution. If the process is an executive system call but it is sleeping at an interruptible priority waiting for a kernel event to occur, it can be immediately blocked from further execution. If the process is executing a system call and it is sleeping at a non-interruptible priority waiting for a kernel event to occur, it cannot be blocked immediately. The process blocking has to be delayed until the system call is complete. Therefore, in this situation, a flag is set telling the process that when the system call is complete, it should be blocked itself from further execution. Here is my reference. Thank you.


And those personal relationships, both with the Rootserver Operators and with the TLD Delegate Operators. And it was actually extremely unfortunate. It was a formative event also when he passed. Because he didn't get the chance, even though that was the plan, he didn't get the chance to do the personal work of turning his personal relationships into institutional ones. And there was a great deal of trouble and discomfort and distrust that followed from the fact that he wasn't able to be part of that process. Because there was a certain amount of, I can, what's that? And you guys, who are you and why should I listen to you? Well, so let me ask a kind of provocative question here. So it's extremely unfortunate, no question, that John passed away sort of on the eve of the formal start of ICANN. So that's an event heard around the world and everybody knows that that's not good.