Where No Wiki Has Gone Before

Notas do Editor

4. That was the Ares I-X Test Flight. Wasn’t that cool? How many of you here today watched that live last October, either on TV or online? I’ve always loved watching launches, and that’s one of the very few new vehicles NASA’s launched in my lifetime. There’s nothing like watching a launch, but I can’t even begin to describe what it’s like to watch a rocket clear the tower that you know you had a hand in, even in some small way. It’s really cool. And the part that I and other members of our company, Freedom Information Systems, played involved helping NASA implement tools like Atlassian Confluence.
5. This is a composite picture of of all 13 launches of the Saturn V rocket, one of the most complex machines man’s ever invented. I think all of us realize that these launches weren’t done by any one person or even group of people alone. It required the coordination and mobilization of a small army of people working together. Thousands of people worked in centers spread across the country to make these launches happen. Now, these launches took place between 1967 and 1973. Which means that at the time, document collaboration looked like...
6. This is a composite picture of of all 13 launches of the Saturn V rocket, one of the most complex machines man’s ever invented. I think all of us realize that these launches weren’t done by any one person or even group of people alone. It required the coordination and mobilization of a small army of people working together. Thousands of people worked in centers spread across the country to make these launches happen. Now, these launches took place between 1967 and 1973. Which means that at the time, document collaboration looked like...
7. This is a composite picture of of all 13 launches of the Saturn V rocket, one of the most complex machines man’s ever invented. I think all of us realize that these launches weren’t done by any one person or even group of people alone. It required the coordination and mobilization of a small army of people working together. Thousands of people worked in centers spread across the country to make these launches happen. Now, these launches took place between 1967 and 1973. Which means that at the time, document collaboration looked like...
8. ...this. This was only 40 or so years ago, but back then, if someone in Houston needed documents produced in Huntsville, it meant that the document had to be mailed or driven, physically carried from one place to the other. When you realize that it becomes even more amazing that those people spread across the country accomplished all they did. But, what that says to me is that we today, with all of our incredible modern tools for communicating, ought to be able to accomplish far more incredible feats of collaboration. But if we don’t learn how to use those tools effectively we might as well not have them. We’re here this week to learn about Atlassian’s awesome collaboration tools. My goal in this presentation is two-fold. First, I hope to inspire you by telling you that folks at places like NASA are using the very same tools many of you are to do awesomeness like what we just watched. Second, I hope to share with you some of the things Freedom has learned in working with clients like NASA that will enable you to help your organizations use these tools even better.
9. ...this. This was only 40 or so years ago, but back then, if someone in Houston needed documents produced in Huntsville, it meant that the document had to be mailed or driven, physically carried from one place to the other. When you realize that it becomes even more amazing that those people spread across the country accomplished all they did. But, what that says to me is that we today, with all of our incredible modern tools for communicating, ought to be able to accomplish far more incredible feats of collaboration. But if we don’t learn how to use those tools effectively we might as well not have them. We’re here this week to learn about Atlassian’s awesome collaboration tools. My goal in this presentation is two-fold. First, I hope to inspire you by telling you that folks at places like NASA are using the very same tools many of you are to do awesomeness like what we just watched. Second, I hope to share with you some of the things Freedom has learned in working with clients like NASA that will enable you to help your organizations use these tools even better.
10. So here’s the situation. Back in the summer of 2008, the Ares I Launch Vehicle was undergoing its Preliminary Design Review. This review took place at Marshall Space Flight Center in Huntsville, AL, but involved hundreds of people from across the US.
11. Whenever NASA designs any new vehicle or product they follow a systems engineering process, which is a rigorous, well-established design life cycle. Each phase of the design and realization of the vehicle has multiple reviews that must be passed successfully. These reviews are crucial milestones in which it is verified that the program is on track and that the design is meeting the requirements established for the vehicle. The way these reviews work is representatives from all the teams working on the vehicle’s design get together in one physical location and then look over and comment on the vehicle’s design data. This data can include requirements documents, drawings, CAD models, etc from multiple internal teams and external companies from across the US. The Ares rocket had to successfully pass the review to continue to exist as a program. If the rocket didn’t pass the review, it’s basically a “do not pass go, do not collect the rest of your funding” situation. It’s critical that these reviews be executed effectively to ensure that the vehicle is ready to proceed to the next phase of design.
12. Whenever NASA designs any new vehicle or product they follow a systems engineering process, which is a rigorous, well-established design life cycle. Each phase of the design and realization of the vehicle has multiple reviews that must be passed successfully. These reviews are crucial milestones in which it is verified that the program is on track and that the design is meeting the requirements established for the vehicle. The way these reviews work is representatives from all the teams working on the vehicle’s design get together in one physical location and then look over and comment on the vehicle’s design data. This data can include requirements documents, drawings, CAD models, etc from multiple internal teams and external companies from across the US. The Ares rocket had to successfully pass the review to continue to exist as a program. If the rocket didn’t pass the review, it’s basically a “do not pass go, do not collect the rest of your funding” situation. It’s critical that these reviews be executed effectively to ensure that the vehicle is ready to proceed to the next phase of design.
13. Whenever NASA designs any new vehicle or product they follow a systems engineering process, which is a rigorous, well-established design life cycle. Each phase of the design and realization of the vehicle has multiple reviews that must be passed successfully. These reviews are crucial milestones in which it is verified that the program is on track and that the design is meeting the requirements established for the vehicle. The way these reviews work is representatives from all the teams working on the vehicle’s design get together in one physical location and then look over and comment on the vehicle’s design data. This data can include requirements documents, drawings, CAD models, etc from multiple internal teams and external companies from across the US. The Ares rocket had to successfully pass the review to continue to exist as a program. If the rocket didn’t pass the review, it’s basically a “do not pass go, do not collect the rest of your funding” situation. It’s critical that these reviews be executed effectively to ensure that the vehicle is ready to proceed to the next phase of design.
14. Let me talk a little about the number of people involved. In some sense, all of the thousands of people working on the project were involved, since it was their designs, documents, and CAD models that were getting reviewed.
15. That said, there were hundreds of men and women chosen to participate directly in this review by reviewing and commenting on those documents.
17. The reviewers were both internal NASA personnel as well as external corporate partners which meant that whatever tool we chose had to support people who differed significantly in the range of local knowledge, knowledge of the Ares program, and knowledge of the tools. After all the reviewers got to the review location...
18. ...they were broken up into teams to review specific documents.
19. ...they were broken up into teams to review specific documents.
20. ...they were broken up into teams to review specific documents.
21. ...they were broken up into teams to review specific documents.
22. ...they were broken up into teams to review specific documents.
23. ...they were broken up into teams to review specific documents.
25. The activities of all those people, who live and work in many different areas of the US, had to be coordinated by a review planning team of about fifteen core people working at Marshall Space Flight Center. That was it. So from a people standpoint it was a relatively small team coordinating the efforts of a really large group of people.
26. The other factor to consider in all this was the data. First was the number of documents that were being reviewed. In all there were somewhere in the neighborhood of 75 documents that had to be reviewed at PDR. That’s a lot of technical details to be gone over in the two or so weeks allotted for the review. But that wasn’t the only data that needed to be organized. Information about the review itself needed to be made available, too. Information such as where would everyone need to go once they were here in Huntsville, what was the process for entering comments, where could they find the documents they needed to review, etc. The planning team needed a way to get information about review documents, the review locations, training information for the tools being used to collect the reviewer’s comments to the reviewers wherever they were.
27. The other factor to consider in all this was the data. First was the number of documents that were being reviewed. In all there were somewhere in the neighborhood of 75 documents that had to be reviewed at PDR. That’s a lot of technical details to be gone over in the two or so weeks allotted for the review. But that wasn’t the only data that needed to be organized. Information about the review itself needed to be made available, too. Information such as where would everyone need to go once they were here in Huntsville, what was the process for entering comments, where could they find the documents they needed to review, etc. The planning team needed a way to get information about review documents, the review locations, training information for the tools being used to collect the reviewer’s comments to the reviewers wherever they were.
28. The other factor to consider in all this was the data. First was the number of documents that were being reviewed. In all there were somewhere in the neighborhood of 75 documents that had to be reviewed at PDR. That’s a lot of technical details to be gone over in the two or so weeks allotted for the review. But that wasn’t the only data that needed to be organized. Information about the review itself needed to be made available, too. Information such as where would everyone need to go once they were here in Huntsville, what was the process for entering comments, where could they find the documents they needed to review, etc. The planning team needed a way to get information about review documents, the review locations, training information for the tools being used to collect the reviewer’s comments to the reviewers wherever they were.
29. So the importance of the review coupled with the number of people involved and the sheer volume of data presented us with some unique challenges. First off was the far-flung nature of the team of reviewers. We had to coordinate lots of people in lots of different places. This caused us to think about setting up a website to disseminate information to people wherever they were. This led to a second challenge. All of the PDR planning team members were excellent at their roles, but were not necessarily familiar with building and maintaining a website. Even if one or two of them had known HTML and CSS, the sheer volume of the data we would need to organize and make available would lead to serious technical bottlenecks. A third issue to deal with was that most of the planning information was changing all the time. People were working on updating the documents that were being reviewed right up until just before the review started. The venues for the various teams were changing due to various different factors. And even the list of who would be participating in the review was changing right up to the last minute. About a year before the review we at Freedom had noticed that NASA had its own instance of Confluence but no one we talked to had ever used it. We learned later that basically what happened was that someone had suggested NASA buy Confluence at one point and when they went to evaluate it, they saw how inexpensive it was and they’re attitude was that it’s so inexpensive, let’s just purchase it, install it and see what happens. When we found it, some other projects were using it, but no one on our Ares team had used it before. We started looking into it just to see if it would be of value to us and saw a lot of potential. So we began using it here and there for various different tasks. We got better and better and even had some success helping other working groups and project teams to use it. When the time came for the PDR we realized that Confluence would be a good solution to many of the challenges we were facing, so we asked if we could give it a try and after a little explanation of what it was and how we thought we would use it, the planning team said “yes.”
30. So the importance of the review coupled with the number of people involved and the sheer volume of data presented us with some unique challenges. First off was the far-flung nature of the team of reviewers. We had to coordinate lots of people in lots of different places. This caused us to think about setting up a website to disseminate information to people wherever they were. This led to a second challenge. All of the PDR planning team members were excellent at their roles, but were not necessarily familiar with building and maintaining a website. Even if one or two of them had known HTML and CSS, the sheer volume of the data we would need to organize and make available would lead to serious technical bottlenecks. A third issue to deal with was that most of the planning information was changing all the time. People were working on updating the documents that were being reviewed right up until just before the review started. The venues for the various teams were changing due to various different factors. And even the list of who would be participating in the review was changing right up to the last minute. About a year before the review we at Freedom had noticed that NASA had its own instance of Confluence but no one we talked to had ever used it. We learned later that basically what happened was that someone had suggested NASA buy Confluence at one point and when they went to evaluate it, they saw how inexpensive it was and they’re attitude was that it’s so inexpensive, let’s just purchase it, install it and see what happens. When we found it, some other projects were using it, but no one on our Ares team had used it before. We started looking into it just to see if it would be of value to us and saw a lot of potential. So we began using it here and there for various different tasks. We got better and better and even had some success helping other working groups and project teams to use it. When the time came for the PDR we realized that Confluence would be a good solution to many of the challenges we were facing, so we asked if we could give it a try and after a little explanation of what it was and how we thought we would use it, the planning team said “yes.”
31. So the importance of the review coupled with the number of people involved and the sheer volume of data presented us with some unique challenges. First off was the far-flung nature of the team of reviewers. We had to coordinate lots of people in lots of different places. This caused us to think about setting up a website to disseminate information to people wherever they were. This led to a second challenge. All of the PDR planning team members were excellent at their roles, but were not necessarily familiar with building and maintaining a website. Even if one or two of them had known HTML and CSS, the sheer volume of the data we would need to organize and make available would lead to serious technical bottlenecks. A third issue to deal with was that most of the planning information was changing all the time. People were working on updating the documents that were being reviewed right up until just before the review started. The venues for the various teams were changing due to various different factors. And even the list of who would be participating in the review was changing right up to the last minute. About a year before the review we at Freedom had noticed that NASA had its own instance of Confluence but no one we talked to had ever used it. We learned later that basically what happened was that someone had suggested NASA buy Confluence at one point and when they went to evaluate it, they saw how inexpensive it was and they’re attitude was that it’s so inexpensive, let’s just purchase it, install it and see what happens. When we found it, some other projects were using it, but no one on our Ares team had used it before. We started looking into it just to see if it would be of value to us and saw a lot of potential. So we began using it here and there for various different tasks. We got better and better and even had some success helping other working groups and project teams to use it. When the time came for the PDR we realized that Confluence would be a good solution to many of the challenges we were facing, so we asked if we could give it a try and after a little explanation of what it was and how we thought we would use it, the planning team said “yes.”
32. Finally, let me just say a little about our role. We’re not system administrators. We can’t go in and install plugins as needed and change settings at will. Our role was configuration and implementation only, which meant that we were little more than basic users with Space Admin rights. Once we had convinced the planning team to let us give Confluence a shot it was up to us to set up the wiki from top to bottom. We requested a separate space just for the review and started setting it up.
33. Finally, let me just say a little about our role. We’re not system administrators. We can’t go in and install plugins as needed and change settings at will. Our role was configuration and implementation only, which meant that we were little more than basic users with Space Admin rights. Once we had convinced the planning team to let us give Confluence a shot it was up to us to set up the wiki from top to bottom. We requested a separate space just for the review and started setting it up.
34. Finally, let me just say a little about our role. We’re not system administrators. We can’t go in and install plugins as needed and change settings at will. Our role was configuration and implementation only, which meant that we were little more than basic users with Space Admin rights. Once we had convinced the planning team to let us give Confluence a shot it was up to us to set up the wiki from top to bottom. We requested a separate space just for the review and started setting it up.
35. Our basic strategy was three basic steps. Design the wiki space and build it. Train the planning team to use it. Then tweak the design as the review got closer and needs arose.
36. Our basic strategy was three basic steps. Design the wiki space and build it. Train the planning team to use it. Then tweak the design as the review got closer and needs arose.
37. Our basic strategy was three basic steps. Design the wiki space and build it. Train the planning team to use it. Then tweak the design as the review got closer and needs arose.
38. This is an example of a basic PDR wiki page minus any content. We’re obviously using the Confluence Clickr theme. This was a couple years ago when Clickr was one of the cleaner looking themes but if we built this today we’d use the EZ Reader theme that has now replaced the Clickr theme. You can see the navigation buttons. We came up with those completely on our own. This was our basic template to start from and we then built separate templates for each of these navigation items to give users a framework to start populating. During the review, we tried to have the wiki be a one stop shop for all information about the review. We wanted anyone who pulled up the wiki to have all the meeting agendas and presentations, all the meeting locations, links to all of the data that was being reviewed available at their fingertips. And the beautiful thing was that no one person became the bottleneck. Any time a planning team member wanted to add or change something, they did it themselves.
39. After the review NASA conducted some surveys of the review planners, review participants, and managers...anyone involved in the review, to capture what had gone well and what had gone poorly. The surveys covered several different aspects of the review, but one of the overwhelmingly noticeable things was that all the groups from planners, to managers, to basic reviewers, had really appreciated the wiki. Those surveyed said things like they loved having one place to go for all review information and they recommended that we use a wiki for all future reviews. They were raving about it and the general consensus was that the wiki idea had been a huge success. And all for this little tool that they had just purchased and said “let’s see what happens.” Now, I could tell you about all the specific, technical challenges we had to overcome during PDR and exactly how we were able to solve them. But that would take a long time and I don’t think it would be as beneficial to you as if we just give you the take-aways we collected from this experience. So instead, we’ve compiled a list...
40. After the review NASA conducted some surveys of the review planners, review participants, and managers...anyone involved in the review, to capture what had gone well and what had gone poorly. The surveys covered several different aspects of the review, but one of the overwhelmingly noticeable things was that all the groups from planners, to managers, to basic reviewers, had really appreciated the wiki. Those surveyed said things like they loved having one place to go for all review information and they recommended that we use a wiki for all future reviews. They were raving about it and the general consensus was that the wiki idea had been a huge success. And all for this little tool that they had just purchased and said “let’s see what happens.” Now, I could tell you about all the specific, technical challenges we had to overcome during PDR and exactly how we were able to solve them. But that would take a long time and I don’t think it would be as beneficial to you as if we just give you the take-aways we collected from this experience. So instead, we’ve compiled a list...
41. After the review NASA conducted some surveys of the review planners, review participants, and managers...anyone involved in the review, to capture what had gone well and what had gone poorly. The surveys covered several different aspects of the review, but one of the overwhelmingly noticeable things was that all the groups from planners, to managers, to basic reviewers, had really appreciated the wiki. Those surveyed said things like they loved having one place to go for all review information and they recommended that we use a wiki for all future reviews. They were raving about it and the general consensus was that the wiki idea had been a huge success. And all for this little tool that they had just purchased and said “let’s see what happens.” Now, I could tell you about all the specific, technical challenges we had to overcome during PDR and exactly how we were able to solve them. But that would take a long time and I don’t think it would be as beneficial to you as if we just give you the take-aways we collected from this experience. So instead, we’ve compiled a list...
42. After the review NASA conducted some surveys of the review planners, review participants, and managers...anyone involved in the review, to capture what had gone well and what had gone poorly. The surveys covered several different aspects of the review, but one of the overwhelmingly noticeable things was that all the groups from planners, to managers, to basic reviewers, had really appreciated the wiki. Those surveyed said things like they loved having one place to go for all review information and they recommended that we use a wiki for all future reviews. They were raving about it and the general consensus was that the wiki idea had been a huge success. And all for this little tool that they had just purchased and said “let’s see what happens.” Now, I could tell you about all the specific, technical challenges we had to overcome during PDR and exactly how we were able to solve them. But that would take a long time and I don’t think it would be as beneficial to you as if we just give you the take-aways we collected from this experience. So instead, we’ve compiled a list...
43. ...of the top ten things we learned about wiki implementation from the Ares PDR. It’s our hope that, presented this way, you can take these pointers back to your home companies and organizations and immediately put them to work to make your own Confluence spaces better. Over the last 7 weeks, we’ve been unveiling these top ten items one at a time. You can see the first seven here. You can read about all of them in detail on our blogs at blogs dot freedom eye ess dot com, and you can also print out a PDF with all of these on it to keep handy by your desk if you want. Today all of you get to be the first to hear the top three items. And remember as we go through these that they’re not just some of the lessons we learned. These three are what we decided upon as being the most helpful, the most valuable things we discovered about implementing Confluence during our PDR experience.
44. The number three item on our list of what we learned about Confluence from the Ares PDR is to “get away from the computer.”
45. So when we say “get away from the computer,” what we mean is that you have to go talk to people about how they’re going to use Confluence. And that means finding out about how they do their work. You can’t just give them a space and hand them the keys (most of the time). Blank pages really intimidate people. And if they’re intimidated by something, they won’t use it. If you can give them, instead, a framework for their information, then they find it much easier to go fill in the blanks.
46. Here’s a quote from Alan Kay. [read quote] What Alan is saying is that the raw ideas don’t need to be expressed via machinery. Most of my best brainstorming gets done with a pencil and paper. So before you ever turn on your laptop, before you log into Confluence, before you click edit, you need to know what you’re planning use Confluence to do. If you can sketch it on paper or on a whiteboard beforehand, it’ll make the process of getting things set up much easier.
47. You can also summarize this as “make a plan.” At first blush, wikis seem like tools that just evolve over time. Little by little, they become the useful collection of everyone’s knowledge. This is partly true, but think about Wikipedia, for instance.
48. Here’s a typical Wikipedia entry. It’s true that all of this content can by edited by anyone. [click to reveal blue box] But all of this area [click to reveal red] is hard coded into the site. All the navigation, and layout decisions are made for you. Decisions about standards for displaying various types of content so it all looks the same from page to page is out of your control, too. That’s not to mention that the overall goal of Wikipedia is very well defined. So while wikis are editable by anyone, the reason this one succeeds is because the framework provided by Wikipedia is so well-conceived. Let me show you an example of how our review space ended up looking...
49. Here’s a typical Wikipedia entry. It’s true that all of this content can by edited by anyone. [click to reveal blue box] But all of this area [click to reveal red] is hard coded into the site. All the navigation, and layout decisions are made for you. Decisions about standards for displaying various types of content so it all looks the same from page to page is out of your control, too. That’s not to mention that the overall goal of Wikipedia is very well defined. So while wikis are editable by anyone, the reason this one succeeds is because the framework provided by Wikipedia is so well-conceived. Let me show you an example of how our review space ended up looking...
50. So here’s our basic PDR wiki page again. What you see here showed up on every page. It consists of a header and footer section that we built on separate pages and added to every other page using a the {include} macro. We made sure everyone would use the header and footer by creating a page template and then asking everyone to choose that template if and when they created new pages. The nav buttons at the top corresponded to the basic tasks the planning team needed to accomplish, such as schedules and calendars, event information, and directions to the events. Those nav buttons are just reproductions of the iPhone buttons that an artist made available for free, and we just inserted them into links to make them clickable.
51. So here’s our basic PDR wiki page again. What you see here showed up on every page. It consists of a header and footer section that we built on separate pages and added to every other page using a the {include} macro. We made sure everyone would use the header and footer by creating a page template and then asking everyone to choose that template if and when they created new pages. The nav buttons at the top corresponded to the basic tasks the planning team needed to accomplish, such as schedules and calendars, event information, and directions to the events. Those nav buttons are just reproductions of the iPhone buttons that an artist made available for free, and we just inserted them into links to make them clickable.
52. So here’s our basic PDR wiki page again. What you see here showed up on every page. It consists of a header and footer section that we built on separate pages and added to every other page using a the {include} macro. We made sure everyone would use the header and footer by creating a page template and then asking everyone to choose that template if and when they created new pages. The nav buttons at the top corresponded to the basic tasks the planning team needed to accomplish, such as schedules and calendars, event information, and directions to the events. Those nav buttons are just reproductions of the iPhone buttons that an artist made available for free, and we just inserted them into links to make them clickable.
53. So here’s our basic PDR wiki page again. What you see here showed up on every page. It consists of a header and footer section that we built on separate pages and added to every other page using a the {include} macro. We made sure everyone would use the header and footer by creating a page template and then asking everyone to choose that template if and when they created new pages. The nav buttons at the top corresponded to the basic tasks the planning team needed to accomplish, such as schedules and calendars, event information, and directions to the events. Those nav buttons are just reproductions of the iPhone buttons that an artist made available for free, and we just inserted them into links to make them clickable.
54. So here’s our basic PDR wiki page again. What you see here showed up on every page. It consists of a header and footer section that we built on separate pages and added to every other page using a the {include} macro. We made sure everyone would use the header and footer by creating a page template and then asking everyone to choose that template if and when they created new pages. The nav buttons at the top corresponded to the basic tasks the planning team needed to accomplish, such as schedules and calendars, event information, and directions to the events. Those nav buttons are just reproductions of the iPhone buttons that an artist made available for free, and we just inserted them into links to make them clickable.
55. So here’s our basic PDR wiki page again. What you see here showed up on every page. It consists of a header and footer section that we built on separate pages and added to every other page using a the {include} macro. We made sure everyone would use the header and footer by creating a page template and then asking everyone to choose that template if and when they created new pages. The nav buttons at the top corresponded to the basic tasks the planning team needed to accomplish, such as schedules and calendars, event information, and directions to the events. Those nav buttons are just reproductions of the iPhone buttons that an artist made available for free, and we just inserted them into links to make them clickable.
56. So here’s our basic PDR wiki page again. What you see here showed up on every page. It consists of a header and footer section that we built on separate pages and added to every other page using a the {include} macro. We made sure everyone would use the header and footer by creating a page template and then asking everyone to choose that template if and when they created new pages. The nav buttons at the top corresponded to the basic tasks the planning team needed to accomplish, such as schedules and calendars, event information, and directions to the events. Those nav buttons are just reproductions of the iPhone buttons that an artist made available for free, and we just inserted them into links to make them clickable.
57. So here’s our basic PDR wiki page again. What you see here showed up on every page. It consists of a header and footer section that we built on separate pages and added to every other page using a the {include} macro. We made sure everyone would use the header and footer by creating a page template and then asking everyone to choose that template if and when they created new pages. The nav buttons at the top corresponded to the basic tasks the planning team needed to accomplish, such as schedules and calendars, event information, and directions to the events. Those nav buttons are just reproductions of the iPhone buttons that an artist made available for free, and we just inserted them into links to make them clickable.
58. Here’s the same idea but from a different space. This was for our communications team. You can see we handled navigation using a similar included page. We also used this space on the left to try to provide links to the tasks people would need to do most often.
59. And here’s a screenshot of our company intranet. This we built just a few months ago and we used the new Documentation Theme. And can I just say, is Jens Schumacher here? His new theme is incredible. So many of the things we’ve wanted to do with wikis like the left sidebar, and the customizable header and footer, and rounded panel corners are now all built in to that theme. We just love it. We use Confluence for our corporate intranet so we wanted to create a dashboard that would show links to lots of the other things that were important to our employees. So we have links in the sidebar to important company info and tool. Then on the right we have some user-specific info. It lists who’s out of the office, what big stuff is going on today and a summary of the user’s timecard for the day. The rest of the space is displaying blog posts from the manager’s personal blogs and farther down the page, off the screen here, there’s a section displaying blog posts from all the other employee blogs. This was our attempt to make this page as tailored as possible to what our team wanted to get done.
60. So you can see from these that it’s important to start planning away from the computer. We go talk to the people we’re setting the space up for, determine what their needs are and how best to meet them. Then we spend a lot of time designing the look of the space so that it’s easy for them to navigate. So that’s number three. Get away from the computer.
61. The number two piece of advice we’d give you is to Shoot for Star Wars. What does that mean? When I was in college I took a course on communicating via mass media and I loved that class because we would watch movies and discuss them. I practically had a degree in that before I got to college. But one of the on-going debates in that class was the debate over spectacle versus story, and which was more important to a good film.
62. An example of a spectacle driven film is Avatar. Avatar had amazing special effects. Incredibly detailed 3D environments. It was just mind-numbingly gorgeous. But it’s story [click to reveal Pocahontas] was basically “Pocahontas in Space.” High marks for spectacle, pretty low marks for story. But the film’s still a success.
63. An example of a story-driven film is Witness. Witness won an Academy Award for best screenplay and it’s often cited by people like Robert McKee in screenwriting seminars as a really, really tight screenplay. So it has a really good story. But unless you’re a fan of the Amish country and sweeping vistas of farmland, it’s not all that high on the spectacle scale. But the movie’s still successful.
64. But then there are movies like Star Wars. Star Wars had really incredible special effects for its time when it was released in 1977. And the story was really compelling, too. So in the spectacle vs. story debate, this film scores high in both areas. Your Confluence spaces need to be like Star Wars. The spectacle side is the technical side of Confluence, and it’s the part I usually get caught up in getting right. Making sure my wiki markup is clean. Making sure the page or space or macro does exactly what it should. That’s important, and a space can’t be successful without it. But the story side is the side that’s easy to forget about. It’s the human side. It’s taking the time to consider that this tool has to eventually be used by people and if it doesn’t work the way they expect it to, they won’t use it. You’ve gotta think about usability, and I’d even say this is as important if not more important than the spectacle side.
65. If you look at these three examples, what we’ve really done here isn’t revolutionary. It’s just to try to layout the pages in a way that’s intuitive for our users. And that doesn’t usually happen naturally. Think about how much time you spent in school learning how to layout and structure a research paper. The whole layout and organization is something you had to learn. But because you learned it, you know what to do when you open up Microsoft Word. Well it makes sense that now that Confluence has in a sense made us all web designers, we need to learn how to layout web pages, too. But most of us haven’t been taught that in school, so we need some remedial usability training. For that the best book I know to tell you to read is Steve Krug’s book, Don’t Make Me Think. I recommend that book all the time, but that one book more than any other has changed the way I think about setting up wikis for people.
66. But just remember: you have balance both spectacle and story, both human and technical considerations.
67. So that’s number two. And the number one thing we learned in this whole Ares PDR wiki experience is something we like to call...
68. ...KISS Confluence. KISS is the old acronym we all know. Keep It Simple Stupid. This is really important when it comes to Confluence, and it’s especially important when you think about trying to get users to adopt a wiki for the first time. Think about the widespread popularity of tools like...
69. ...Google...
70. ...the iPod...
71. ...or Twitter. Who would have thought that 140 characters would would make such a huge impact on so many things?
72. So what’s the deal here? If you think about what all three of those products, and countless other products like them, have in common, it’s that they all take something and make it dead simple. That’s it. Google takes the complicated ball of twine that is the internet and makes it as simple as a text box and a button. The iPod and iTunes make it really easy to get your music collection into you pocket. Or take this for example...
73. Here’s a really nice HD video camera with all the options. With this you can take really great HD video. You can adjust the settings for all kinds of different shooting conditions and effects. But for most people, the options are overwhelming. It takes a lot of skill and training to use this. This is the best thing on the market but most people don’t want best...they want it to be simpler. So camera companies came up with this...
74. This kind of camera also takes HD video. It’s resolution is the same, but its options are more limited in favor of making it easier to use. This is a good camera but it doesn’t offer the same options that the other one does. And for most people that’s just fine. Much simpler. Wider appeal. But then there’s this...
75. The Flip Video. This is HD video make ridiculously easy. It has a lens in the front, and a record button and view screen on the back. That’s it. None of the frills of either of the other two cameras. And sales of this kind of video camera are through the roof. But it has less features!
76. Here’s an example of the navigation for one of the spaces we set up. We’re just using a basic {pagetree} macro inside a {panel} macro. This worked great for a while, but eventually we wound up with so many pages, and so many pages that were the child of a child of a child, that the page tree just became unmanageable. We realized that what we had here was actually several sub-spaces all nested in this one mother space. So we looked at all the pages and sorted them into spaces and then sorted those spaces into five or six main tasks that people were trying to accomplish. What we wound up with was multiple spaces with navigation in each space that looked something like...
77. this. Much simpler, cleaner layout. Much easier to find what you need, or at least get pointed in the right direction. And this new layout met with rave reviews because people could find stuff much more easily. We created this navigation bar using the {rollover} macro, some stylesheets we embedded using the {style} macro, and some custom graphics we built ourselves. If you’d like to know more about exactly how we did this, or any of the things you see here today, come find me after this speech and I’d be happy to go into more detail on this. So...what Google, iPods, Twitter, the Flip Video, and then experiences like this navigation tells us is...
78. People like simple tools. I’d even go a step further and say...
79. People USE simple tools. The converse of that is that people WON’T use tools that aren’t simple. Here’s the crucial thing to remember. People were doing reviews at NASA with older tools like email and track-changes in Microsoft Word. They know those tools work. They’re comfortable using them. If you tell them you have a new tool that will make things better, they’re gonna be skeptical. So skeptical, in fact, that you get one chance to win them over. If they use your tool for five minutes and don’t see immediate benefits over the old way of doing things, they go right back to doing things the older, more comfortable way because it’s just easier for them. You have to remember this when you’re designing your wikis. They’ve got to be easy as pie to use and people should be able to figure them out without thinking about it. Certainly without instructions.
80. So those are our top three. Get away from the computer, shoot for Star Wars, and KISS the wiki. It’s our hope that if you think about and start to implement these three things, along with the other seven outlined on our blogs, you’ll start to see drastic changes in the success of your Confluence implementation.
81. At this point I’d like to open up the floor to questions for about five to ten minutes of question and answer. If you can’t think of any I’ve got a few starters on the slide that might help you think of one.
82. Alright, well I’ve got just one more thought to share with you. This is Jake Shimabukuro. Jake is the best ukulele player in the world. Ever. If you’ve never seen Jake play, you need to look him up on YouTube. Most people have never have heard of any ukulele players. Most people’s initial reaction, including mine, is that a ukulele is not a serious instrument. It’s like a toy, or a kazoo or something. But then Jake plays and completely blows people away with his virtuosity. The crowds are usually blown away. In fact the reactions Jake gets to his amazing, amazing playing is at least in part due to the fact that no one’s ever seen a great ukulele player before. A few weeks ago, Jake spoke at an event in Tokyo and this is a quote of what he said in between songs. He said, “One of the things I love about being a ukulele player is that no matter where I go in the world to play, the audience has such low expectations. This is a huge plus for sure.” Isn’t that awesome. When I heard that I laughed. But then I thought about most people’s first reaction to Confluence or wikis in general. And it’s usually pretty similar to Jake’s audiences’. They’re not expecting much. It’s just a wiki. Now I’m far from being the Jake Shimabukuro of Confluence, or of anything for that matter. But what I do want to leave you with is the idea that you and I and everyone here can change peoples expectations about Confluence and blow them away in the process. We’re all wiki users, but most people we work with still have never even heard of a wiki when we meet them. So their expectations are low, or maybe non-existent. It’s my guess that one day Confluence will be like email or PowerPoint...everyone in business will be using it. Don’t fall victim to thinking, “Oh, this is just a wiki” or “this isn’t that important.” Wikis are just humble little tools but there’s a ton of potential in them and I think we’re only just starting to scratch the surface. Those of us here today have the opportunity to be on the leading edge of helping organizations adopt Confluence. And until Confluence is as ubiquitous as email and PowerPoint, we who understand them already have a huge opportunity to be very valuable to those organizations.